Eliad Peller [Tue, 7 Jun 2011 09:50:46 +0000 (12:50 +0300)]
wl12xx: use freezable workqueue for netstack_work
When resuming (after wowlan), we want the rx packets (which is
usually the wake-up packet itself) to be passed to mac80211 only
after the resume notifier was completed, and mac80211 is up and
running (otherwise, the packets will be dropped).
By enqueueing the netstack_work to a freezable workqueue, we can
guarantee the rx processing to occur only after mac80211 was resumed.
Eliad Peller [Tue, 7 Jun 2011 07:40:39 +0000 (10:40 +0300)]
wl12xx: use _ni version of ieee80211_tx_status
wl1271_flush_deferred_work(), which calls ieee80211_rx() and
ieee80211_tx_status(), is called from a process context.
hence, use ieee80211_tx_status_ni() instead of ieee80211_tx_status().
Eliad Peller [Mon, 6 Jun 2011 10:03:12 +0000 (13:03 +0300)]
wl12xx: check the vif's operstate after join
When resuming while connected (without wowlan), the interface
is already IF_OPER_UP, so we won't get the notifier callback,
and hence never complete the association (from wl12xx perspective)
This situation, among other potential problems, prevents the
station from entering psm.
Eliad Peller [Mon, 6 Jun 2011 09:21:53 +0000 (12:21 +0300)]
wl12xx: clear wl->wow_enabled on resume
We set wl->wow_enabled on every suspend(), so we need to clear it
on every resume().
(we can't rely on setting wl->wow_enabled=false in suspend(),
as it being called only when wowlan triggers are configured)
Eliad Peller [Mon, 6 Jun 2011 09:21:52 +0000 (12:21 +0300)]
wl12xx: don't check wow param on suspend/resume
Since mac80211 calls suspend/resume only when wowlan triggers
exist, there is no need to check for triggers existance in the
callbacks as well.
Add a WARN_ON() to verify it.
Shahar Levi [Sun, 12 Jun 2011 07:34:43 +0000 (10:34 +0300)]
wl12xx: Add Support for Low Power DRPw (LPD) Mode
The Low Power DRPw (LPD) mode contains several optimizations
that designed to reduce power consumption. The purpose
is to save current consumption in RX and Listen mode.
LPD setting apply only for wl127x AP mode (not wl128x)
Signed-off-by: Shahar Levi <shahar_levi@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
Ohad Ben-Cohen [Sun, 29 May 2011 13:36:03 +0000 (16:36 +0300)]
wl12xx: don't bail if mmc isn't MMC_CAP_POWER_OFF_CARD
If our SDIO function has its runtime PM disabled, don't try to
manipulate its runtime PM status at all. This way we can still
power on cards plugged to mmc hosts that are not MMC_CAP_POWER_OFF_CARD.
Luciano Coelho [Tue, 31 May 2011 13:38:56 +0000 (16:38 +0300)]
wl12xx: split channel array per band in sched_scan
The firmware, in practice, treats the channels in three separate
blocks, one for each band (bg, a and j). Instead of using a single
array and doing some magic with indices, split the array in 3 to make
it more readable.
Eliad Peller [Tue, 24 May 2011 11:33:08 +0000 (14:33 +0300)]
wl12xx: fix erroneous commit (cb5ae0)
Due to rebase error, the patch for commit cb5ae0 ("wl12xx: configure
rates when working in ibss mode") was wrong - a blob was added
into the wrong function. fix it.
Eliad Peller [Sun, 15 May 2011 08:10:29 +0000 (11:10 +0300)]
wl12xx: add automatic rx streaming triggers
When rx_streaming.interval is non-zero, use automatic rx streaming.
Enable rx streaming on the each rx/tx packet, and disable it
rx_streaming.duration msecs later.
When rx_streaming.always=0 (default), rx streaming is enabled only
when there is a coex operation.
Eliad Peller [Sun, 15 May 2011 08:10:28 +0000 (11:10 +0300)]
wl12xx: add support for rx streaming
wl12xx supports the "rx streaming" feature:
When in ps mode, and @timeout msecs have been passed since
the last rx/tx, it issues trigger packets (QoS-null/PS-Poll packets,
according to the ac type) in const intervals (in order to reduce
the rx time).
Hauke Mehrtens [Tue, 21 Jun 2011 18:57:16 +0000 (20:57 +0200)]
ssb: add __devinit to some functions
Two functions in ssb are using register_pci_controller() which is
__devinit. The functions ssb_pcicore_init_hostmode() and
ssb_gige_probe() should also be __devinit.
This fixes the following warning:
WARNING: vmlinux.o(.text+0x2727b8): Section mismatch in reference from the function ssb_pcicore_init_hostmode() to the function .devinit.text:register_pci_controller()
The function ssb_pcicore_init_hostmode() references
the function __devinit register_pci_controller().
This is often because ssb_pcicore_init_hostmode lacks a __devinit
annotation or the annotation of register_pci_controller is wrong.
WARNING: vmlinux.o(.text+0x273398): Section mismatch in reference from the function ssb_gige_probe() to the function .devinit.text:register_pci_controller()
The function ssb_gige_probe() references
the function __devinit register_pci_controller().
This is often because ssb_gige_probe lacks a __devinit
annotation or the annotation of register_pci_controller is wrong.
Reported-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Gabor Juhos [Tue, 21 Jun 2011 09:23:23 +0000 (11:23 +0200)]
ath9k: add MAC revision detection for AR9330
The AR9330 1.0 and 1.1 are using the same revision,
thus it is not possible to distinguish the two chips.
The platform setup code can distinguish the chips based
on the SoC revision.
Add a callback function to ath9k_platform_data in order
to allow getting the revision number from the platform code.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Tue, 21 Jun 2011 07:45:33 +0000 (09:45 +0200)]
nl80211: use netlink consistent dump feature for BSS dumps
Use the new consistent dump feature from (generic) netlink
to advertise when dumps are incomplete.
Readers may note that this does not initialize the
rdev->bss_generation counter to a non-zero value. This is
still OK since the value is modified only under spinlock
when the list is modified. Since the dump code holds the
spinlock, the value will either be > 0 already, or the
list will still be empty in which case a consistent dump
will actually be made (and be empty).
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jussi Kivilinna [Mon, 20 Jun 2011 11:42:54 +0000 (14:42 +0300)]
zd1211rw: detect stalled beacon interrupt faster
As USB_INT_ID_RETRY_FAILED can override USB_INT_ID_REGS, beacon interrupt
(CR_INTERRUPT) might be lost. Problem is that when device trigger CR_INTERRUPT
it disables HW interrupt. Now if USB_INT_ID_REGS with CR_INTERRUPT gets lost,
beacon interrupt stays disabled until beacon watchdog notices the stall. This
happen very often on heavy TX. Improve watchdog to trigger earlier, after three
missing beacon interrupts.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jussi Kivilinna [Mon, 20 Jun 2011 11:42:49 +0000 (14:42 +0300)]
zd1211rw: don't let zd_mac_config_beacon() run too long from beacon interrupt handler
zd_mac_config_beacon() has only limited time to set up beacon when called from
beacon interrupt handler/worker. So do not let it retry acquiring beacon fifo
semaphore in interrupt handler. Beacon fifo semaphore should not be locked by
firmware anyway at this time, it's only locked when device is using/txing
beacon.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jussi Kivilinna [Mon, 20 Jun 2011 11:42:44 +0000 (14:42 +0300)]
zd1211rw: handle lost read-reg interrupts
Device losses read-reg interrupts. By looking at usbmon it appears that
USB_INT_ID_RETRY_FAILED can override USB_INT_ID_REGS. This causes read
command to timeout, usually under heavy TX.
Fix by retrying read registers again if USB_INT_ID_RETRY_FAILED is received
while waiting for USB_INT_ID_REGS.
However USB_INT_ID_REGS is not always lost but is received after
USB_INT_ID_RETRY_FAILED and is usually received by the retried read
command. USB_INT_ID_REGS of the retry is then left unhandled and might
be received by next read command. Handle this by ignoring previous
USB_INT_ID_REGS that doesn't match current read command request.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jussi Kivilinna [Mon, 20 Jun 2011 11:42:28 +0000 (14:42 +0300)]
zd1211rw: fix invalid signal values from device
Driver uses IEEE80211_HW_SIGNAL_UNSPEC and so signal values reported to
mac80211 should be in range 0..100. Sometimes device return out of range
values. These out of range values can then trigger warning in
cfg80211_inform_bss_frame.
This patch adds checks to enforce range returned from driver to
mac80211 be in 0..100 range.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Mon, 20 Jun 2011 11:40:46 +0000 (13:40 +0200)]
netlink: advertise incomplete dumps
Consider the following situation:
* a dump that would show 8 entries, four in the first
round, and four in the second
* between the first and second rounds, 6 entries are
removed
* now the second round will not show any entry, and
even if there is a sequence/generation counter the
application will not know
To solve this problem, add a new flag NLM_F_DUMP_INTR
to the netlink header that indicates the dump wasn't
consistent, this flag can also be set on the MSG_DONE
message that terminates the dump, and as such above
situation can be detected.
To achieve this, add a sequence counter to the netlink
callback struct. Of course, netlink code still needs
to use this new functionality. The correct way to do
that is to always set cb->seq when a dumpit callback
is invoked and call nl_dump_check_consistent() for
each new message. The core code will also call this
function for the final MSG_DONE message.
To make it usable with generic netlink, a new function
genlmsg_nlhdr() is needed to obtain the netlink header
from the genetlink user header.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rafał Miłecki [Mon, 20 Jun 2011 01:12:19 +0000 (03:12 +0200)]
b43: HT-PHY: calibrate radio after switching channel
After uploading radio values calibration goes in. In MMIO dump it is:
radio_read(0x002b) -> 0x0008
radio_write(0x002b) <- 0x0008
radio_read(0x002e) -> 0x0004
radio_write(0x002e) <- 0x0000
radio_read(0x002e) -> 0x0000
radio_write(0x002e) <- 0x0004
radio_read(0x002b) -> 0x0008
radio_write(0x002b) <- 0x0009
To find masks and sets, MMIO hacks were used to fool closed driver.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
When module is reloaded, device may fail to work, with messages:
[ 342.211926] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0059, type=2.
[ 342.314254] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x004a, type=2.
[ 342.416458] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 3183 max 2432.
[ 342.518605] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00c9, type=2.
[ 342.620836] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00ae, type=1.
[ 342.723201] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
[ 342.825399] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
[ 342.927624] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
[ 343.029804] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 2491 max 2432.
[ 343.132008] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 2576 max 2432.
[ 343.234326] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x004c, type=1.
[ 343.438723] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00e6, type=1.
Whereas replugging device make it functional. To solve that problem
force reset device during probe.
With patch messages are gone. Unfortunately device may sometimes
still does not operate correctly after module reload (fail to receive
data after associate), but such cases are rarer than without the patch.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: fix possible memory corruption in case of invalid rxdesc.size
Sometimes rxdesc descriptor provided by hardware contains invalid
(random) data. For example rxdesc.size can be bigger than actual
size of the buffer. When this happen rt2x00crypto_rx_insert_iv()
corrupt memory doing memmove outside of buffer boundaries.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rafał Miłecki [Sun, 19 Jun 2011 10:17:21 +0000 (12:17 +0200)]
b43: HT-PHY: switch radio to requested channel
Switching channel happens after specific SHM write to B43_SHM_SH_CHAN.
This is the way we found it in BCM4331 MMIO dumps. By comparing with
N-PHY code we noticed there is routing used for SYN and TX/RX.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rafał Miłecki [Sun, 19 Jun 2011 00:18:11 +0000 (02:18 +0200)]
b43: HT-PHY: implement killing radio
Closed drivers kill radio right after reading radio version and MACCTL,
so it was easy to find related PHY ops:
phy_read(0x0810) -> 0x0000
phy_write(0x0810) <- 0x0000
To find out the mask of above OP, MMIO hack was used to fake read val:
phy_read(0x0810) -> 0xffff
phy_write(0x0810) <- 0x0000
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mike McCormack [Mon, 20 Jun 2011 01:47:51 +0000 (10:47 +0900)]
rtlwifi: rtl8192{c,ce,cu,se}: Remove comparisons of booleans with true
These are a potential source of confusion, as most C code treats all
non-zero values as true.
Signed-off-by: Mike McCormack <mikem@ring3k.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mike McCormack [Mon, 20 Jun 2011 01:46:05 +0000 (10:46 +0900)]
rtlwifi: rtl8192cu: Remove unused parameter
rtl_ps_set_rf_state's protect_or_not parameter is not set to
true anywhere, except for commented out code.
It enables some legacy locking code, which is no longer used,
so delete the parameter and the old locking code.
Signed-off-by: Mike McCormack <mikem@ring3k.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mike McCormack [Mon, 20 Jun 2011 01:44:58 +0000 (10:44 +0900)]
rtlwifi: Fix typo in variable name
offchan_deley should be offchan_delay
Signed-off-by: Mike McCormack <mikem@ring3k.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rafał Miłecki [Fri, 17 Jun 2011 23:01:59 +0000 (01:01 +0200)]
bcma: clean exports of functions
Function managing IRQs is needed for external drivers like b43.
On the other side we do not expect writing any hosts drivers outside of
bcma, so this is safe to do not export functions related to this.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw: make sure PAPRD training is properly done
checking the status of PAPRD_AGC2_POWER(Log(ADC_power) measured after
last gain-change in dB) field suggests whether the PAPRD is completely/properly
done. This is an additional check apart from polling for PAPRD done bit being set.
Susinder suggests that the ideal power range value should be
0xf0 to 0xfe. With AR9382 we do have the values in this range. to have a
common check for all platforms we take agc2_power should be atleast greater
than 0xe0
Cc: susinder@qca.qualcomm.com Cc: senthilb@qca.qualcomm.com Cc: kmuthusa@qca.qualcomm.com Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k: Fix a corner case failure in sending PAPRD frames in HT40
when the AP is configured with HT40/2.4GHz and when PAPRD is enabled in station
we have PAPRD training frames never sent out because of the following
failure "PAPRD target power delta out of range". This consistently happens
in channel 10,11 in Over The Air testing and rarely in channel 6 under wired
setup.
the reason behind this issue is all the HT40 rates target power
are 0 when we operate in channel 10/11 at 2.4GHz
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Kalle Valo [Mon, 13 Jun 2011 22:35:04 +0000 (01:35 +0300)]
rtlwifi: include mac80211.h from core.h
core.h references ieee80211_ops but doesn't include mac80211.h, which issues
a warning once mac80211-compat.h is taken into use.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Kalle Valo [Mon, 13 Jun 2011 22:34:57 +0000 (01:34 +0300)]
zd1211rw: include mac80211.h from zd_chip.h
zd_chip.h contains one function with a pointer to ieee80211_hw but doesn't
include mac80211.h. As a temporary solution include mac80211.h to avoid
a warning.
Signed-off-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
projects / karo-tx-linux.git / log