The patch "cfg80211: add a timer for invalid user reg hints"
introduced a regression for the case where a secondary identical
regulatory hint from a user is sent. What would happen is the
second hint would schedule delayed work in to catch a timeout
but since we are never processing it given that the hint was already
applied we'd always hit the timeout and and restore regulatory
settings back to world regulatory domain. This is fixed by simply
avoiding sheduling work if the hint was already applied.
Tested-by: Felix Fietkau <nbd@openwrt.org> Reported-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: rtl8192ce: Change rtl8192ce routines phy and trx and modify rtl8192cu for addition of rtl8192se and rtl8192de
Change rtl8192ce routines phy and trx for addition of RTL8192SE and RTL8192DE.
In addition, make necessary modifications to rtl8192cu. This patch also
removes the temporary patches needed to enable intermediate steps to build
without error.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: rtl8192ce: Change phy and rc routines for addition of rtl8192se and rtl8192de
Change rtl8192ce routines phy and rc for addition of RTL8192SE and
RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: rtl8192ce: Change sw and LED routines for addition of rtl8192se and rtl8192de
Change rtl8192ce sw and LED routines for addition of RTL8192SE and
RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: rtl8192ce: Change hw routine for addition of rtl8192se and rtl8192de
Change rtl8192ce hw routine for addition of RTL8192SE and RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: rtl8192c-common: Change common PHY routines for addition of rtl8192se and rtl8192de
Change common PHY routines for addition of RTL8192SE and RTL8192DE code.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: rtl8192c-common: Change common firmware routines for addition of rtl8192se and rtl8192de
Change common firmware routines for addition of RTL8192SE and
RTL8192DE code.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: rtl8192c-common: Convert common dynamic management routines for addition of rtl8192se and rtl8192de
Convert common dynamic management routines for addition of RTL8192SE
and RTL8192DE code.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Convert usb routines for addition of rtl8192se and rtl8192de
Convert usb routines for addition of RTL8192SE and RTL8192DE code
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Convert regulatory domain routines for addition of rtl8192se and rtl8192de
Convert regulatory domain routines for addition of RTL8192SE and
RTL8192DE code.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Convert rc routines for addition of rtl8192se and rtl8192de
Convert rc routines for addition of RTL8192SE and RTL8192DE code
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Convert ps routines for addition of rtl8192se and rtl8192de
Convert ps routines for addition of RTL8192SE and RTL8192DE code
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Convert pci routines for addition of rtl8192se and rtl8192de
Convert pci routines for addition of RTL8192SE and RTL8192DE code
These changes allow the upper-level driver to specify the BAR to be
used as it is different for rtl8192se than for the others.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Convert core routines for addition of rtl8192se and rtl8192de
Convert core routines for addition of RTL8192SE and RTL8192DE code.
Additional files are changed to allow compilation.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Change cam routines for addition of rtl8192se and rtl8192de
Change cam routines for addition of RTL8192SE and RTL8192DE code
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Change base routines for addition of rtl8192se and rtl8192de
Change base routines for addition of RTL8192SE and RTL8192DE code.
Additional files are modified to allow compilation.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Change wifi.h for rtl8192se and rtl8192de
Change wifi.h for addition of RTL8192SE and RTL8192DE code
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtlwifi: Change efuse routines addition of RTL8192SE and RTL8192DE
Change efuse routines for addition of RTL8192SE and RTL8192DE code
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Fix warnings due to -Wunused-but-set-variable
These warnings are exposed by gcc 4.6.
net/mac80211/sta_info.c: In function 'sta_info_cleanup_expire_buffered':
net/mac80211/sta_info.c:590:32: warning: variable 'sdata' set but not used
net/mac80211/ibss.c: In function 'ieee80211_rx_mgmt_auth_ibss':
net/mac80211/ibss.c:43:34: warning: variable 'status_code' set but not used
net/mac80211/work.c: In function 'ieee80211_send_assoc':
net/mac80211/work.c:203:9: warning: variable 'len' set but not used
net/mac80211/tx.c: In function '__ieee80211_parse_tx_radiotap':
net/mac80211/tx.c:1039:35: warning: variable 'sband' set but not used
net/mac80211/mesh.c: In function 'ieee80211_mesh_rx_queued_mgmt':
net/mac80211/mesh.c:616:28: warning: variable 'ifmsh' set but not used
...
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
The release timer has to expire "just" after a
frame is up for release. Currently, if the timer
callback starts on time, the "!time_after" check
above will start a new timer instead of
releasing the frames.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
"For best CPU usage and power consumption, having as few
frames as possible percolate through the stack is
desirable. Hence, the hardware should filter as much
as possible."
Note: Not all firmwares include the multicast filter
feature and the stack does not filter them either.
The ARP filter on the other hand was dropped from the
patch since it does not work correctly:
Quote from: Max Filippov <jcmvbkbc@gmail.com>
<http://www.spinics.net/lists/linux-wireless/msg67466.html>
"In the ARP case, when there's no other traffic on p54spi,
all ARP requests are dropped. But if there's some egress
traffic from p54spi, filter seems to work correctly:
only ARP requests that match filter pass through.
In the multicast case filter seems to work correctly, but
it treats broadcast as subject to that filtering too. By
default only 01:00:5e:00:00:01 gets into priv->mc_maclist,
so we miss all broadcasts.
These two filters seem to interfere:
- if we set ARP filter and multicast filter without bc
=> we miss all ARPs if there's no egress traffic;
- if we set ARP filter and multicast filter with bc or
don't set mc filter at all => we get all ARPs.
This effect does not depend on filter setup order."
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Tested-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
My 14e4:4315 is SSB_IDLOW_SSBREV_26:
read32 0xfaafcff8 -> 0x600422d5
My 14e4:4328 is SSB_IDLOW_SSBREV_24:
read32 0xfaafcff8 -> 0x400422c5
My 14e4:432b is SSB_IDLOW_SSBREV_26 again:
read32 0xfaafcff8 -> 0x600422d5
For all of them wl driver is using 0x2 reject bit:
write32(0xf98) <- 0x00010002
So it seems SSB 2.3 is the exception using another bit.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ssb_chipco_set_clockmode may want to touch CC registers to control power of the
bus. However touching registers without powered_up set causes warnings.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
The xpaBiasLvlFreq parameter array is made up of 16 bit words which
aren't byte-swapped like the other 16-bit eeprom parameters are.
It's only used by the AR9160.
Signed-off-by: Adrian Chadd <adrian@freebsd.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k: set beacon related ps flags on bss_info change
Requesting beacon sync up to configure beacon timers properly
in hw, has be done after doing beacon config with default values.
Setting the flags in beacon config is causing the device to not
enter into network sleep on idle state.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: Fix Tx IQ Calibration hang issue in AR9003 chips
On AR9003 chips, doing three IQ calibrations will possibly cause chip
in stuck state. In noisy environment, chip could receive
a packet during the middle of three calibrations and it causes
the conflict of HW access and the eventual failure. It also
causes IQ calibration outliers which results in poor Tx EVM.
The IQ Cal procedure is after resetting the chip, run IQ cal 3 times
per each cal cycle and find the two closest readings and average of two.
The advantage of running Tx IQ cal more than once is that we can compare
calibration results for the same gain setting over multiple iterations.
Most of the cases the IQ failures were observed after first pass.
For the AR9485 and later chips, Tx IQ Calibration is performed along
with AGC cal. But for pre-AR9485 chips, Tx IQ cal HW has to be separated
from the rest of calibration HW to avoid chip hang. After all
calibrations are done in HW, we can start SW post-processing.
By doing this way, we minimize the SW difference among all chips.
The order of calibration (run IQ cal before other calibration) is also
needed to avoid chip hang for chips before AR9485. This issue was
originally observed with AR9382.
During the issue kernel log was filled with following message
ath: timeout (100000 us) on reg 0xa640: 0x00000001 & 0x00000001 != 0x00000000
ath: timeout (100000 us) on reg 0xa2c4: 0x00158dd9 & 0x00000001 != 0x00000000
ath: Unable to reset channel (2412 MHz), reset status -5
ath: Unable to set channel
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
We need not wake up the chip even before mutex lock is acquired and also
that it is required only if we are going to drain the txq. So place the
wrappers accordingly and this change is also useful when there are no
pending frames in the txq as we do not wake up the chip unnecessarily.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: Fix incorrect baseband PLL phase shift for AR9485
we should program the AR9485 baseband PLL phase shift to 6 and
a redundant setting overwrites the correct value. Remove the
incorrect and unwnated register setting.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
cfg80211: module_param to disable HT40 in 2.4GHz band
Currently mac80211 uses ieee80211_disable_40mhz_24ghz module
parameter to allow disabling 40MHz operation in the 2.4GHz band.
Move this handling from mac80211 to cfg80211 so that the feature
will be more generic.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hw next tigger time is configured as current_tsf + (timer_period * 10) which
is wrong, it should be current_tsf + timer_period. The wrong hw timer configuration
would cause btcoex related issues.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 21 Apr 2011 11:38:00 +0000 (13:38 +0200)]
mac80211: tear down BA sessions properly on suspend
Currently, the code to tear down BA sessions will
execute after queues are stopped, but attempt to
send frames, so those frames will just get queued,
which isn't intended. Move this code to before to
tear down the sessions properly.
Additionally, after stopping queues, flush the TX
queues in the driver driver to make sure all the
frames went out.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mwl8k: Enable life time expiry for tx packets in the hardware
Tell the firmware to enable the life time expiry of tx packets
in the hardware. The hardware will now refer to the timestamp
in every tx packet and decide whether the packet needs to be
dropped or transmitted.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since queues are not stopped anymore, management frames would be
dropped if the corresponding tx queue is full.
This can cause issues say when we want to setup an ampdu stream and
action frames i.e addba requests keep getting dropped frequently.
Fix this by reserving some buffers to allow management frames to
go through in queue full conditions.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Timestamp tx packets using a HW micro-second timer.
This timestamp will be compared to the current timestamp
in the hardware and if the difference is greater than 500ms,
the packet will be dropped.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is in preparation to support life time expiry of packets in the
hardware to avoid head-of-line blocking where a slow client can
hog a tx queue and affect the traffic to a faster client from the same
queue. Time stamp the packets in driver to allow dropping them in the
hardware if they are queued for more than 500ms.
If queues are stopped, packets will be queued up outside the driver.
Since we will be able to timestamp the packets only after they hit the
driver, the timestamp will be less accurate since we cannot consider
the time the packets spent in queues outside the driver. With this commit,
to achieve accurate timestamping, the tx queues will not be stopped in
normal conditions. The only scenarios where the queues will be stopped are
when firmware commands are executing or if the interface is brought down.
Now, we need to be prepared for a situation where packets hit the driver
even after the tx queues are full. Drop all such packets in the driver itself.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com> Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwlwifi: fix possible data overwrite in hcmd callback
My commit 3598e1774c94e55c71b585340e7dc4538f310e3f
"iwlwifi: fix enqueue hcmd race conditions" move hcmd callback after
command queue reclaim, to avoid call it with hcmd_lock. But since
queue read index was updated, cmd data can be overwritten. Fix problem
by calling callback before taking hcmd_lock and queue reclaim.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Register the driver's maximum ampdu subframe limit to mac80211.
* Cleanup the target capabilities structure and fix an endian issue.
* Fix BTCOEX by sending a command to the target when the BT priority
changes.
* Bump the required firmware version to 1.1
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Wed, 13 Apr 2011 10:14:52 +0000 (03:14 -0700)]
iwlagn: remove hw_ready variable
This variable is only ever checked right after
the function that sets it, but the same function
will also return the status, so we can pass it
through instead of checking hw_ready later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Johannes Berg [Sat, 16 Apr 2011 15:29:24 +0000 (08:29 -0700)]
iwlagn: combine firmware code/data
On new hardware, ucode images always come in
pairs: code and data. Therefore, combine the
variables into an appropriate struct and use
that when both code and data are needed.
Also, combine allocation and copying so that
we have less code in total.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Johannes Berg [Fri, 22 Apr 2011 17:15:23 +0000 (10:15 -0700)]
iwlagn: implement synchronous firmware load
The current firmware loading mechanism in
iwlwifi is very hard to follow, and thus
hard to maintain. To make it easier, make
the firmware loading synchronous.
For now, as a side effect, this removes a
number of retry possibilities we had. It
isn't typical for this to fail, but if it
does happen we restart from scratch which
this also makes easier to do should it be
necessary.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Johannes Berg [Wed, 13 Apr 2011 10:14:49 +0000 (03:14 -0700)]
iwlagn: leave notification waits on firmware errors
When the firmware encounters an error while the
driver is waiting for a notification, it will
never get that notification. Therefore, instead
of timing out, bail out on errors when waiting
for notifications.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Johannes Berg [Wed, 13 Apr 2011 10:14:47 +0000 (03:14 -0700)]
iwlagn: extend notification wait function
A notification wait function is called with the
command, but currently has no way of passing
data back to the caller -- fix that by adding a
void pointer to the function that can be used
between the caller and the function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Johannes Berg [Wed, 13 Apr 2011 10:14:46 +0000 (03:14 -0700)]
iwlagn: refactor up path
Starting the device consists of many things,
refactor out enabling the hardware and also
return -ERFKILL when the rfkill signal is
found to be asserted (which makes more sense
anyway, but is also required now to make the
__iwl_up function return right away.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Johannes Berg [Wed, 13 Apr 2011 10:14:44 +0000 (03:14 -0700)]
iwlagn: clean up some exit code
There's no point in running through iwl_down()
when we never registered with mac80211, as it
just cleans up internal structures that were
never initialised in this case. Therefore we
can also remove the special handling for this
case from __iwl_down().
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Johannes Berg [Wed, 13 Apr 2011 10:14:43 +0000 (03:14 -0700)]
iwlagn: simplify error table reading
The current code to read the error table header
just hardcodes all the offsets, which is a bit
hard to understand. We can read in the entire
header (as much as we need) into a structure,
and then take the data from there, which makes
it easier to understand. To read a bigger blob
we also don't need to grab NIC access for each
word read, making the code more efficient.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
iwlwifi: sanity check before counting number of tfds can be free
we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.
On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link, making bisection of other problems impossible.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Tue, 19 Apr 2011 18:44:04 +0000 (20:44 +0200)]
mac80211: fix SMPS debugfs locking
The locking with SMPS requests means that the
debugs file should lock the mgd mutex, not the
iflist mutex. Calls to __ieee80211_request_smps()
need to hold that mutex, so add an assertion.
This has always been wrong, but for some reason
never been noticed, probably because the locking
error only happens while unassociated.
Cc: stable@kernel.org [2.6.34+] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ivo van Doorn [Mon, 18 Apr 2011 13:35:12 +0000 (15:35 +0200)]
rt2x00: Implement get_antenna and set_antenna callback functions
Implement the get_antenna and set_antenna callback functions, which will
allow clients to control the antenna for all non-11n hardware (Antenna handling
in rt2800 is still a bit magical, so we can't use the set_antenna for those drivers
yet).
To best support the set_antenna callback some modifications are needed in the
diversity handling. We should never look at the default antenna settings to determine
if software diversity is enabled. Instead we should set the diversity flag when
possible, which will allow the link_tuner to automatically pick up the tuning.
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>
Ivo van Doorn [Mon, 18 Apr 2011 13:34:41 +0000 (15:34 +0200)]
rt2x00: Implement get_ringparam callback function
With the get_ringparam callback function we can export ring parameters
to ethtool through the mac80211 interface.
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>
Ivo van Doorn [Mon, 18 Apr 2011 13:34:22 +0000 (15:34 +0200)]
rt2x00: Optimize register access in rt2800usb
All register reads/writes in rt2800usb were previously done with
rt2800_register_read/rt2800_register_write. These however indirectly
call rt2x00usb_register_read/rt2x00usb_register_write which adds an
additional overhead of at least one call and several move instructions
to each register access.
Replacing the calls to rt2800_register_read/rt2800_register_write with
direct calls to rt2x00usb_register_read/rt2x00usb_register_write gets
rid of quite a number of instructions in the drivers hotpaths (IRQ
handling and txdone handling).
For consistency replace all references to rt2800_register_read/write
with the rt2x00usb_register_read/write variants.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Helmut Schaa [Mon, 18 Apr 2011 13:34:01 +0000 (15:34 +0200)]
rt2x00: Optimize register access in rt2800pci
All register reads/writes in rt2800pci were previously done with
rt2800_register_read/rt2800_register_write. These however indirectly
call rt2x00pci_register_read/rt2x00pci_register_write which adds an
additional overhead of at least one call and several move instructions
to each register access.
Replacing the calls to rt2800_register_read/rt2800_register_write with
direct calls to rt2x00pci_register_read/rt2x00pci_register_write gets
rid of quite a number of instructions in the drivers hotpaths (IRQ
handling and txdone handling).
For consistency replace all references to rt2800_register_read/write
with the rt2x00pci_register_read/write variants.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
The two functions that are in rt2x00ht.c can be much better placed
closer to the places where the call-sites of these functions are (one
in rt2x00config.c and one in rt2x00queue.c) allowing us to make these
functions static.
Also, conditional compilations doesn't seem to be necessary anymore as
802.11n support is quite common nowadays.
This makes the code a bit easier readable and searchable.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: Enable support for RT53xx PCI devices by default.
Code seems to be feature-complete, so no reason to not enable
these devices by default.
Also, remove the sentence about the support for these devices being
non-functional.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: RT33xx device support is no longer experimental.
The rt33xx devices support for both PCI and USB devices has been in
the tree for a couple of months now, and seems to be functional and
not in a worse shape than the support for rt28xx and rt30xx devices.
No longer mark it as experimental and enable the support for these
devices by default.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
projects / linux-beck.git / log