| Age | Commit message (Collapse) | Author |
|---|
|
Cc: Paul Shaw <paul.shaw@atheros.com>
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
From the original report:
"I had problems to get my rtl8185 PCI card running on Sparc64: I always
got an error about "No suitable DMA available" followed by an error
that no device could be detected. When comparing the rtl8180 driver to
others I noticed that others are mostly using DMA_BIT_MASK so I changed
the custom mask to DMA_BIT_MASK(32) which fixed my issue."
Reported-by: Tiziano Müller <tm@dev-zero.ch>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
rt2800 devices use a different enumeration to specify what IFS values should
be used on frame transmission compared to the other rt2x00 devices. Hence,
create a new enum called txop that contains the valid values.
Furthermore use the appropriate txop values as found in the ralink drivers:
- TXOP_BACKOFF for management frames
- TXOP_SIFS for subsequent fragments in a burst
- TXOP_HTTXOP for all data frames
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Currently, we configure a 128ms hang over period for the PSM entry
(the firmware will remain active for 128ms after sending the null func for
PSM and getting an ack for it.) This is a huge power consumption issue, and
appears unnecessary. So, configure the value to 1 ms.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Janne Ylalehto <janne.ylalehto@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Incresed the timeout value for command complete event waiting from 100
ms to 750 ms. In some rare cases it can take about 600 ms before
complete event for join command is received. This is most propably
caused by the firmware being busy with scanning related activities.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch changes the way JOIN's are performed, and channel numbers updated.
The reason for this is that the firmware JOIN command clears WPA(2) key
material, and if done while associated to a WPA(2) secured AP, will render
the data-path unusable.
While the channel is not usually changed while associated (and currently we
could not even support something like that), after performing a scan operation
while associated, mac80211 will re-set the current channel to the driver. This
caused our problem.
Also, the mac80211 is assuming that the driver channel configuration remains
persistent over periods of IDLE. Therefore remove channel resetting to zero
from the unjoin function.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Reading single registers did not pay attention to data endianness. This patch
fix that.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch reads the HW PG version (along with a ROM-version, embedded in the
same value) from the wl1271 hardware and publishes the value in a sysfs -file.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Switch LED off/on when handling CONF_CHANGE_IDLE.
Not doing this would leave the radio LED on even
though the chip would be in full sleep mode.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Generated using the new shiny intivals-tool [1]:
initvals -w -f ar9003 > ar9003_initvals.h
The respective checksums are:
0x000000005a76829d ar9300_2p0_radio_postamble
0x000000009d90cb74 ar9300Modes_lowest_ob_db_tx_gain_table_2p0
0x00000000e0bc2c84 ar9300Modes_fast_clock_2p0
0x00000000852fca34 ar9300_2p0_radio_core
0x0000000000000000 ar9300Common_rx_gain_table_merlin_2p0
0x0000000078658fb5 ar9300_2p0_mac_postamble
0x0000000023235333 ar9300_2p0_soc_postamble
0x0000000054d41904 ar9200_merlin_2p0_radio_core
0x00000000618455d4 ar9300_2p0_baseband_postamble
0x000000009aa590a4 ar9300_2p0_baseband_core
0x000000004783d946 ar9300Modes_high_power_tx_gain_table_2p0
0x000000006681db44 ar9300Modes_high_ob_db_tx_gain_table_2p0
0x000000001f318700 ar9300Common_rx_gain_table_2p0
0x000000009990cb74 ar9300Modes_low_ob_db_tx_gain_table_2p0
0x00000000c9d66d40 ar9300_2p0_mac_core
0x0000000039139500 ar9300Common_wo_xlna_rx_gain_table_2p0
0x00000000a0c54980 ar9300_2p0_soc_preamble
0x00000000292e2544 ar9300PciePhy_pll_on_clkreq_disable_L1_2p0
0x000000002d3e2544 ar9300PciePhy_clkreq_enable_L1_2p0
0x00000000293e2544 ar9300PciePhy_clkreq_disable_L1_2p0
[1] http://wireless.kernel.org/en/users/Drivers/ath9k_hw/initvals-tool
Cc: Tom Hammel <thammel@atheros.com>
Cc: Enis Akay <Enis.Akay@Atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
ath9k_common (used by ath9k and ath9k_htc) trusts the frames
blessed by hardware as OK are infact correct even if the rate
seen by the driver is unrecognized. ath9k_common just treats
these frames in mac80211 as frames as frames under 1 mbps rate.
It seems this might not be the best thing to do as other parts of
the frame might not be valid so just drop these frames for now.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This has no real functional change, this just moves the setting the
the mac80211 rate index into ath9k_process_rate(). This allows us
to eventually make ath9k_process_rate() return a negative value
in case we have detected a specific case rate situation which should
have been ignored.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Device documentation suggests that hardware support for beaconing
is available. But I implemented software-based beacon generation
as an experiment and it seems better to have that working now rather
than waiting for something better to materialize.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This is a step towards support for beaconing modes of operation.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Update channel initialization for the RF3052 chipset.
According to the Ralink drivers, the rt3x array must be
used for this chipset, rather then the rt2x array.
Furthermore RF3052 supports the 5GHz band, extend
the rt3x array with the 5GHz channels, and use them
for the RF3052 chip.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The SIFS value is a constant and doesn't need to be updated on erp changes.
Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
initial SIFS values" for details).
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
used by the Ralink driver nor specified in 802.11.
Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
11g + CTS protected connections. Add a comment to the code why we don't use 10us
for CCK SIFS value.
The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
Ralink drivers).
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The current way of managing beaconing in ad-hoc
mode has a subtle race - the beacon obtained from mac80211
is freed in the SWBA handler rather than the TX
completion routine. But transmission of beacons goes
through the normal SKB queue maintained in hif_usb,
leading to a situation where __skb_dequeue() in the TX
completion handler goes kaput.
Fix this by simply getting a beacon from mac80211 for
every SWBA and free it in its completion routine.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Currently, when one interface switches HT mode,
all others will follow along. This is clearly
undesirable, since the new one might switch to
no-HT while another one is operating in HT.
Address this issue by keeping track of the HT
mode per interface, and allowing only changes
that are compatible, i.e. switching into HT40+
is not possible when another interface is in
HT40-, in that case the second one needs to
fall back to HT20.
Also, to allow drivers to know what's going on,
store the per-interface HT mode (channel type)
in the virtual interface's bss_conf.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
... so orinoco_usb can share some common functionality.
Handle 802.2 encapsulation and MIC calculation in that function.
The 802.3 header is prepended to the SKB. The calculated MIC is written
to a specified buffer. Also modify the transmit control word that will
be passed onto the hardware to specify whether the MIC is present, and
the key used.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Atheros hardware supports receiving frames that span multiple
descriptors and buffers. In this case, the rx status of every
descriptor except for the last one is invalid and may contain random
data. Because the driver does not support this, it needs to drop such
frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch removes the incomplete AMPDU implementation in ar9170usb.
The code in question is:
* too big and complex (more than 550 SLOC.)
This is enough to qualify for a new separate code file!
* unbalanced quantity & quality
over-engineered areas like:
* xmit scheduling and queuing frames for multiple HT peers
* redundant frame sorting
are confronted by gaping holes:
* accurate transmission feedback
* firmware error-handling and device reset
* HT rate control algorithm
* error-prone
Since its inclusion, hardly anything was done to fix
any of the outlined flaws from the initial commit message.
=> This also indicates poor maintainability.
* relies heavily on several spinlocks.
As a result of this shortcomings, the code is slow and does not
even support the most basic 11n requirement: HT station mode.
Therefore, I request to purge my heap of **** from the kernel:
"ar9170: implement transmit aggregation".
The next item on the agenda is: (re-)start from scratch with
an adequate design to accommodate the special requirements
and features of the available frameworks and tools.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch fixes a regression introduced by the following patch:
"ar9170: load firmware asynchronously"
When we kick off a firmware loading request and then unbind,
or disconnect the usb device right away, we get into trouble:
> ------------[ cut here ]------------
> WARNING: at lib/kref.c:44 kref_get+0x1c/0x20()
> Hardware name: 18666GU
> Modules linked in: ar9170usb [...]
> Pid: 6588, comm: firmware/ar9170 Not tainted 2.6.34-rc5-wl #43
> Call Trace:
> [<c102b05e>] ? warn_slowpath_common+0x6e/0xb0
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c102b0b3>] ? warn_slowpath_null+0x13/0x20
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c117bb2f>] ? kobject_get+0xf/0x20
> [<c124d630>] ? get_device+0x10/0x20
> [<c124e5a0>] ? device_add+0x60/0x530
> [<c117b8b5>] ? kobject_init+0x25/0xa0
> [<c12569f9>] ? _request_firmware+0x139/0x3e0
> [<c1256cc0>] ? request_firmware_work_func+0x20/0x70
> [<c1256ca0>] ? request_firmware_work_func+0x0/0x70
> [<c103ff24>] ? kthread+0x74/0x80
> [<c103feb0>] ? kthread+0x0/0x80
> [<c1003136>] ? kernel_thread_helper+0x6/0x10
>---[ end trace 2d50bd818f64a1b7 ]---
- followed by a random Oops -
Avoid that by waiting for the firmware loading to finish
(whether successfully or not) before the unbind in
ar9170_usb_disconnect.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Bug-fixed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
|
|
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
And use it consistently in the chipset drivers.
Preparation for further clean ups.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Inspection of the Ralink vendor driver shows that the TX_BAND_CFG register
and BBP register 3 are about HT40- indication, not about HT40+ indication.
Inverse the meaning of these fields in the code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Now that RT30xx support is at the same level as RT28xx support we can enable
these devices by default.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
PCI specific code has been remove quite some time ago.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
We currently have this check as a BUG_ON, which is being hit by people.
Previously it was an error with a recalculation if not current, return that
code.
The BUG_ON was introduced by:
commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
Author: Guy Cohen <guy.cohen@intel.com>
Date: Tue Sep 9 10:54:54 2008 +0800
iwlwifi: Added support for 3 antennas
... the portion adding the BUG_ON is reverted since we are encountering the error
and BUG_ON was created with assumption that error is not encountered.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Looks like we missed removing the return statement in the non-CONFIG_IWM_DEBUG
dummy implementation of iwm_debugfs_init...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6
|
|
0x07d1,0x3c17 D-Link Wireless N 150 USB Adapter DWA-125
0x1b75,0x3071 Ovislink Airlive WN-301USB
0x1d4d,0x0011 Pegatron Ralink RT3072 802.11b/g/n Wireless Lan USB Device
0x083a,0xf511 Arcadyan 802.11 USB Wireless LAN Card
0x13d3,0x3322 AzureWave 802.11 n/g/b USB Wireless LAN Card
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Currently, hwsim will always detect a double scan
after the first one has finished ...
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This allows enabling TX and disabling both TX and
RX aggregation sessions manually in debugfs. It is
very useful for debugging session initiation and
teardown problems since with this you don't have
to force a lot of traffic to get aggregation and
thus have less data to analyse.
Also, to debug mac80211 code itself, make hwsim
"support" aggregation sessions. It will still just
transfer the frame, but go through the setup and
teardown handshakes.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This involves some refactorring of the common fw download code to
substitute ezusb versions of various functions.
Note that WPA-enabled firmwares (9.xx series) will not work fully with
orinoco_usb yet.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
We expect to be either in process contect or soft interrupt context. So
use in_softirq instead.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This driver uses the core orinoco modules for the bulk of
the functionality. The low level hermes routines (for local bus
cards) are replaced, the driver supplies its own ndo_xmit_start
function, and locking is done with the _bh variant.
Some recent functionality is not available to the USB cards yet
(firmware loading and WPA).
Out-of-tree driver originally written by Manuel Estrada Sainz.
Thanks to Mark Davis for supplying hardware to test the updates.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Local bus and USB drivers will need to do locking differently.
The original orinoco_usb patches had a boolean variable controlling
whether spin_lock_bh was used, or irq based locking. This version
provides wrappers for the lock functions and the drivers specify the
functions pointers needed.
This will introduce a performance penalty, but I'm not expecting it to
be noticable.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Allow the main drivers to specify a custom version of the net_device_ops
structure. This is required by orinoco_usb to supply a separate transmit
function.
Export existing net_device_ops callbacks so that the drivers can reuse
some of the existing code.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Pave the way for introducing USB alternative functions.
Force callers to dereference ops instead of providing wrappers.
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
|
|
"iwl: cleanup: remove unneeded error handling" missed the one in
if_sdio_debugfs_init().
I don't think we even need to check -ENODEV ourselves because if
DEBUG_FS is not compiled in, all the debugfs utility functions will
become no-op.
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Acked-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Greenfield is a 11n feature, remove it from non-11n devices
configuration parameters list
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
|
|
Separate the hw_set_hw_params() function to per device based; different
devices can have different hardware parameters set, when separate the
function based on device type can avoid mistakes, give more flexibilities and
easier to read.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
|
|
The TX status code is currently abusing the ampdu_ack_map field (a bitmap) to
count the number of successfully received frames. The comments in mac80211.h
show there are actually three different, relevant variables, of which we are
currently using two, both incorrectly. Fix this by making
- ampdu_ack_len -> the number of ACKed frames (i.e. successes)
- ampdu_ack_map -> the bitmap
- ampdu_len -> the total number of frames sent (i.e., attempts)
to match the header file (and verified with ath9k's usage) and updating Intel's
RS code to match.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
|
|
Add general, rx and tx uCode statistics to 3945. This will help
in debugging
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
|
