- 23 6月, 2011 16 次提交
-
-
由 Jussi Kivilinna 提交于
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: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jussi Kivilinna 提交于
Update HW beacon only when needed. This appears to make device work in AP-mode (dtim_period=1) somewhat more stable. Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jussi Kivilinna 提交于
This message is should be debug-only as it tells almost nothing useful. It also happens very often and just floods logs. Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jussi Kivilinna 提交于
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: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes.berg@intel.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
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: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
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: NStanislaw Gruszka <stf_xl@wp.pl> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
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: NStanislaw Gruszka <stf_xl@wp.pl> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Specs were recently updated. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
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: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
The trick was to find 0x810 PHY reg ops close to analog enabling code. To find out proper masks and sets, MMIO hacks were used. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
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: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
-
- 22 6月, 2011 2 次提交
-
-
由 Vinicius Costa Gomes 提交于
When the connection is ready we should set the connection to CONNECTED so userspace can use it. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Gustavo F. Padovan 提交于
Conflicts: net/bluetooth/l2cap_core.c
-
- 21 6月, 2011 18 次提交
-
-
由 Mike McCormack 提交于
These are a potential source of confusion, as most C code treats all non-zero values as true. Signed-off-by: NMike McCormack <mikem@ring3k.org> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mike McCormack 提交于
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: NMike McCormack <mikem@ring3k.org> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mike McCormack 提交于
offchan_deley should be offchan_delay Signed-off-by: NMike McCormack <mikem@ring3k.org> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
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: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Roskin 提交于
Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
Nothing else is freeing it, and this mirrors the error handling path already in ath5k_init_softc. https://bugzilla.kernel.org/show_bug.cgi?id=37592Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Reported-by: NTsyvarev Andrey <tsyvarev@ispras.ru>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
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: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
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: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Eliad Peller 提交于
Cancel all relevant timers/works before suspending (wowlan). This patch handles the following warning: WARNING: at net/mac80211/util.c:565 queueing ieee80211 work while going to suspend Backtrace: [<bf07b598>] (ieee80211_can_queue_work+0x0/0x4c [mac80211]) [<bf07c28c>] (ieee80211_queue_work+0x0/0x30 [mac80211]) [<bf0690dc>] (ieee80211_sta_timer+0x0/0x3c [mac80211]) [<c00a3008>] (run_timer_softirq+0x0/0x220) [<c009e530>] (__do_softirq+0x0/0x130) [<c009e660>] (irq_exit+0x0/0xb4) [<c004c4a0>] (ipi_timer+0x0/0x4c) [<c0046350>] (do_local_timer+0x0/0x88) [<c00488ec>] (cpu_idle+0x0/0xe0) [<c05294e8>] (rest_init+0x0/0xe0) [<c0008958>] (start_kernel+0x0/0x314) Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vinicius Costa Gomes 提交于
We already have access to the chan, we don't have to access the socket to get its imtu. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 Vinicius Costa Gomes 提交于
We should not try to do any other type of configuration for LE links when they become ready. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
-
由 John W. Linville 提交于
Merge branch 'wireless-next-2.6' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6
-
由 Kalle Valo 提交于
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: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NKalle Valo <kvalo@adurom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Kalle Valo 提交于
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: NKalle Valo <kvalo@adurom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Kalle Valo 提交于
The hacks break once mac80211-compat.h is taken into use. Fix it by adding an ifdef check. Signed-off-by: NKalle Valo <kvalo@adurom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Kalle Valo 提交于
The hacks break once mac80211-compat.h is taken into use. Fix it by adding an ifdef check. Signed-off-by: NKalle Valo <kvalo@adurom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 18 6月, 2011 4 次提交
-
-
由 Wey-Yi Guy 提交于
Remove unused and incorrect EEPROM define Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
由 Wey-Yi Guy 提交于
Same operation needed by multiple devices, move to single function. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
由 Wey-Yi Guy 提交于
Code alignment, no functional changes. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
由 Wey-Yi Guy 提交于
Add offset define for subsystem id in EEPROM Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-