- 20 Jan, 2017 16 commits
-
-
Larry Finger authored
These two debugging formss implement debugging using rather complicated macro constructions. These are replaced with compiled code that is easier to understand. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Rafał Miłecki authored
This intends to make init/attach process slightly easier to follow. What driver was doing in brcmf_bus_start wasn't bus specific at all and function brcmf_bus_stop wasn't undoing things done there. This function is supposed to be called by bus specific code when the bus is ready. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Rafał Miłecki authored
Driver used to call brcmf_bus_detach only from one place and it already contained a check for drvr not being NULL. We can get rid of this extra function, call brcmf_bus_stop directly and simplify the code. There also isn't brcmf_bus_attach function which one could expect so it looks more consistent this way. Signed-off-by:
-
Rafał Miłecki authored
Function brcmf_c_set_joinpref_default is in common.c, so move it to the related header. Signed-off-by:
-
Rafał Miłecki authored
Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we really don't need their declarations. Function brcmf_parse_tlvs is used in cfg80211.c only so make it static and drop from header as well. Signed-off-by:
-
Gavin Li authored
brcmf_sdio_fromevntchan() was being called on the the data frame rather than the software header, causing some frames to be mischaracterized as on the event channel rather than the data channel. This fixes a major performance regression (due to dropped packets). With this patch the download speed jumped from 1Mbit/s back up to 40MBit/s due to the sheer amount of packets being incorrectly processed. Fixes: c56caa9d ("brcmfmac: screening firmware event packet") Signed-off-by:
Gavin Li <git@thegavinli.com> Cc: <stable@vger.kernel.org> # 4.7+ Acked-by:
-
Jes Sorensen authored
Update copyright year and email address. Signed-off-by:
Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by:
-
Axel Köllhofer authored
These IDs originate from the vendor driver Signed-off-by:
Axel Köllhofer <AxelKoellhofer@web.de> Signed-off-by:
-
Axel Köllhofer authored
This was tested by David Patiño. Reported-by:
David Patiño <davidpatino82@gmail.com> Signed-off-by:
-
Jes Sorensen authored
TP-Link TL-WN822N v4 (2357:0108) Reported-by:
Gregory Auzanneau <linux@reolight.net> Signed-off-by:
-
Jes Sorensen authored
Device reported as working fine, so tell the driver not to warn about it being untested. Reported-by:
Aex Aey <aexaey@gmail.com> Signed-off-by:
-
Martin Blumenstingl authored
BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455 got a dedicated SDIO device ID which is currently not supported by brcmfmac. Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455 supported because the chip itself is already supported (due to BCM4345 support in the driver). Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Andreas Färber <afaerber@suse.de> Tested-by:
-
Brian Norris authored
Marvell folks tell me this is a debugging event that the driver doesn't need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of these sorts of messages at (for instance) boot time: [ 13.825848] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 14.838561] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 14.850397] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 32.529923] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 Let's handle this "event" with a much lower verbosity. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Brian Norris authored
In mwifiex_delay_for_sleep_cookie(), we're looping and waiting for the PCIe endpoint to write a magic value back to memory, to signal that it has finished going to sleep. We're not letting the compiler know that this might change underneath our feet though. Let's do that, for good hygiene. I'm not aware of this fixing any concrete problems. I also give no guarantee that this loop is actually correct in any other way, but at least this looks like an improvement to me. Signed-off-by:
-
Brian Norris authored
The following sequence occurs when using IEEE power-save on 8997: (a) driver sees SLEEP event (b) driver issues SLEEP CONFIRM (c) driver recevies CMD interrupt; within the interrupt processing loop, we do (d) and (e): (d) wait for FW sleep cookie (and often time out; it takes a while), FW is putting card into low power mode (e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value But at (e), no one actually signaled an interrupt (i.e., we didn't check adapter->int_status). And what's more, because the card is going to sleep, this register read appears to take a very long time in some cases -- 3 milliseconds in my case! Now, I propose that (e) is completely unnecessary. If there were any additional interrupts signaled after the start of this loop, then the interrupt handler would have set adapter->int_status to non-zero and queued more work for the main loop -- and we'd catch it on the next iteration of the main loop. So this patch drops all the looping/re-reading of PCIE_HOST_INT_STATUS, which avoids the problematic (and slow) register read in step (e). Incidentally, this is a very similar issue to the one fixed in commit ec815dd2 ("mwifiex: prevent register accesses after host is sleeping"), except that the register read is just very slow instead of fatal in this case. Tested on 8997 in both MSI and (though not technically supported at the moment) MSI-X mode. Signed-off-by: -
Brian Norris authored
Depending on system factors (e.g., the PCIe link PM state), the first read to wake up the Wifi firmware can take a long time. There is no reason to use a (blocking, non-posted) read at this point, so let's just use a write instead. Write vs. read doesn't matter functionality-wise -- it's just a dummy operation. But let's make sure to re-write with the correct "ready" signature, since we check for that in other parts of the driver. This has been shown to decrease the time spent blocking in this function on RK3399. Signed-off-by:
-
- 19 Jan, 2017 7 commits
-
-
Daniel Golle authored
This is needed for WiFi to work e.g. on DIR-615 rev.H1 which got external RF power amplifiers connected to the WiSoC. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Serge Vasilugin authored
Simple patch to correct HT20/HT40 filter setting. Tested with Rt3290, Rt3352 and Rt5350 Signed-off-by:
Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by:
-
Stanislaw Gruszka authored
Since rt2800pci update beacon settings asynchronously from tbtt tasklet, without beacon_skb_mutex protection, number of currently active beacons entries can be different than number pointed by rt2x00dev->intf_beaconing. Remove warning about that inconsistency. Reported-by: evaxige@qq.com Signed-off-by:
-
Xinming Hu authored
We already ensure 64 bytes alignment and add padding if required during skb_aggr allocation. Alignment and padding in mwifiex_11n_form_amsdu_txpd() is redundant. We may end up accessing more data than allocated size with this. This patch fixes following issue by removing redundant padding. [ 370.241338] skbuff: skb_over_panic: text:ffffffffc046946a len:3550 put:72 head:ffff880000110000 data:ffff8800001100e4 tail:0xec2 end:0xec0 dev:<NULL> [ 370.241374] ------------[ cut here ]------------ [ 370.241382] kernel BUG at net/core/skbuff.c:104! 370.244032] Call Trace: [ 370.244041] [<ffffffff8c3df5ec>] skb_put+0x44/0x45 [ 370.244055] [<ffffffffc046946a>] mwifiex_11n_aggregate_pkt+0x1e9/0xa50 [mwifiex] [ 370.244067] [<ffffffffc0467c16>] mwifiex_wmm_process_tx+0x44a/0x6b7 [mwifiex] [ 370.244074] [<ffffffffc0411eb8>] ? 0xffffffffc0411eb8 [ 370.244084] [<ffffffffc046116b>] mwifiex_main_process+0x476/0x5a5 [mwifiex] [ 370.244098] [<ffffffffc0461298>] mwifiex_main_process+0x5a3/0x5a5 [mwifiex] [ 370.244113] [<ffffffff8be7e9ff>] process_one_work+0x1a4/0x309 [ 370.244123] [<ffffffff8be7f4ca>] worker_thread+0x20c/0x2ee [ 370.244130] [<ffffffff8be7f2be>] ? rescuer_thread+0x383/0x383 [ 370.244136] [<ffffffff8be7f2be>] ? rescuer_thread+0x383/0x383 [ 370.244143] [<ffffffff8be83742>] kthread+0x11c/0x124 [ 370.244150] [<ffffffff8be83626>] ? kthread_parkme+0x24/0x24 [ 370.244157] [<ffffffff8c4da1ef>] ret_from_fork+0x3f/0x70 [ 370.244168] [<ffffffff8be83626>] ? kthread_parkme+0x24/0x24 Fixes: 84b313b3 ("mwifiex: make tx packet 64 byte DMA aligned") Signed-off-by:
Xinming Hu <huxm@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Rafał Miłecki authored
We may want to use Open Firmware for other devices than just SDIO ones. In future we may want to support more Broadcom properties so there is really no reason for such limitation. Call brcmf_of_probe for all kind of devices & move extra conditions to the body of that funcion. Signed-off-by:
-
Pan Bian authored
Function lbs_cmd_802_11_sleep_params() always return 0, even if the call to lbs_cmd_with_response() fails. In this case, the parameter @sp will keep uninitialized. Because the return value is 0, its caller (say lbs_sleepparams_read()) will not detect the error, and will copy the uninitialized stack memory to user sapce, resulting in stack information leak. To avoid the bug, this patch returns variable ret (which takes the return value of lbs_cmd_with_response()) instead of 0. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188451Signed-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
-
- 17 Jan, 2017 14 commits
-
-
Larry Finger authored
In commit c93ac39d ("rtlwifi: Remove some redundant code), a goto statement was inadvertently left in the code. Fixes: c93ac39d ("rtlwifi: Remove some redundant code) Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Brian Norris authored
Similar to commit fcd2042e ("mwifiex: printk() overflow with 32-byte SSIDs"), we failed to account for the existence of 32-char SSIDs in our debugfs code. Unlike in that case though, we zeroed out the containing struct first, and I'm pretty sure we're guaranteed to have some padding after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes long). So, this is the difference between: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef " ... and the correct output: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef" ... Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by:
-
Rafał Miłecki authored
During bands setup we disable all channels that firmware doesn't support in the current regulatory setup. If we do this before wiphy_register it will result in copying set flags (including IEEE80211_CHAN_DISABLED) to the orig_flags which is supposed to be persistent. We don't want this as regulatory change may result in enabling some channels. We shouldn't mess with orig_flags then (by changing them or ignoring them) so it's better to just take care of their proper values. This patch cleanups code a bit (by taking orig_flags more seriously) and allows further improvements like disabling really unavailable channels. We will need that e.g. if some frequencies should be disabled for good due to hardware setup (design). Signed-off-by:
-
Rafał Miłecki authored
During init we take care of regulatory stuff by disabling all unavailable channels (see brcmf_construct_chaninfo) so this predisabling them is not really required (and this patch won't change any behavior). It will on the other hand allow more detailed runtime control over channels which is the main reason for this change. Signed-off-by:
-
Stanislaw Gruszka authored
All Ralink USB devices I have, including old ones, work well with max_psdu = 3 (64kB tx AMPDUs). Fix indent on the way. Signed-off-by:
-
Stanislaw Gruszka authored
Signed-off-by:
-
Stanislaw Gruszka authored
If we do not get TX status in reasonable time, we most likely fail to send frame hence mark it as so. Signed-off-by:
-
Stanislaw Gruszka authored
Enable RTS frame retry fall-back and limit number of RTS retries to 7 what is default number of retries for small frames. As RTS/CTS is used for TXOP protection, those settings prevent posting lots of RTS frames when remote station do not response with CTS at the moment. After sending 7 RTS's the HW will start back-off mechanism and after it will start posing RTS again to get access to the medium. Signed-off-by:
-
Stanislaw Gruszka authored
We do not have option to set per frame retry count. We have only global TX_RTY_CFG registers which specify the number or retries. Set setting of that register to value that correspond rate control algorithm number of frame post (number of retries + 1), which is 3 for aggregated frames. This should help with big amount of retries on bad conditions, hence mitigate buffer-bloat like problems. Signed-off-by:
-
Stanislaw Gruszka authored
Reset tuner use curr_band value, make sure it is updated. Signed-off-by:
-
Stanislaw Gruszka authored
When medium is busy or frames have to be resend, it takes time to send the frames and get TX status from hardware. For some really bad medium conditions it can take seconds. Patch change TX status timeout to give HW more time to provide it, however 500ms is not enough for bad conditions. In the future this timeout should be removed and replaced with proper watchdog mechanism. Increase flush timeout accordingly as well. Signed-off-by:
-
Stanislaw Gruszka authored
On rt2800usb, if we do not get TX status from HW, we assume frames were posted and after entry->last_action timeout, we forcibly provide TX status to mac80211. So it's not possible to detect hardware TX hung based on the timeout. Additionally TXRQ_PCNT tells on number of frames in the Packet Buffer (buffer between bus interface and chip MAC subsystem), which can be non zero on normal conditions. To check HW hung we will need provide some different mechanism, for now remove watchdog as current implementation is wrong and not useful. Signed-off-by:
-
Rafał Miłecki authored
Our code was assigning number of channels to the index variable by default. If firmware reported channel we didn't predict this would result in using that initial index value and writing out of array. This never happened so far (we got a complete list of supported channels) but it means possible memory corruption so we should handle it anyway. This patch simply detects unexpected channel and ignores it. As we don't try to create new entry now, it's also safe to drop hw_value and center_freq assignment. For known channels we have these set anyway. I decided to fix this issue by assigning NULL or a target channel to the channel variable. This was one of possible ways, I prefefred this one as it also avoids using channel[index] over and over. Fixes: 58de92d2 ("brcmfmac: use static superset of channels for wiphy bands") Signed-off-by:
-
Arnd Bergmann authored
Checking the firmware status from PCIe register only works if the register is available, otherwise we end up with random behavior: drivers/net/wireless/marvell/mwifiex/pcie.c: In function 'mwifiex_pcie_remove': drivers/net/wireless/marvell/mwifiex/pcie.c:585:5: error: 'fw_status' may be used uninitialized in this function [-Werror=maybe-uninitialized] This makes sure we treat the absence of the register as a failure. Fixes: 045f0c1b ("mwifiex: get rid of global user_rmmod flag") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 12 Jan, 2017 3 commits
-
-
Xinming Hu authored
This patch moves sdio_work to card structure, in this way we can get adapter structure in the work, so save_adapter won't be needed. Signed-off-by:
-
Xinming Hu authored
__mwifiex_sdio_remove helper is not needed after our enhancements in SDIO card reset. Signed-off-by:
-
Xinming Hu authored
Commit b4336a28 ("mwifiex: sdio: reset adapter using mmc_hw_reset") introduces a simple sdio card reset solution based on card remove and re-probe. This solution has proved to be vulnerable, as card and adapter structures are not protected, concurrent access will result in kernel panic issues. Let's reuse PCIe FLR's functions for SDIO reset to avoid freeing and reallocating adapter and card structures. Signed-off-by:
-
