summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* brcmfmac: drop unneeded function declarations from headersRafał Miłecki2017-01-203-7/+1
| | | | | | | | | | 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: Rafał Miłecki <rafal@milecki.pl> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: fix incorrect event channel deductionGavin Li2017-01-201-1/+1
| | | | | | | | | | | | | | | | | 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: c56caa9db8ab ("brcmfmac: screening firmware event packet") Signed-off-by: Gavin Li <git@thegavinli.com> Cc: <stable@vger.kernel.org> # 4.7+ Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> [kvalo@codeaurora.org: improve commit logs based on email discussion] Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtl8xxxu: Update author/maintainer contact infoJes Sorensen2017-01-207-8/+8
| | | | | | | Update copyright year and email address. Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtl8xxxu: Add additional USB IDs for rtl8192eu devicesAxel Köllhofer2017-01-201-0/+7
| | | | | | | | These IDs originate from the vendor driver Signed-off-by: Axel Köllhofer <AxelKoellhofer@web.de> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)Axel Köllhofer2017-01-201-0/+3
| | | | | | | | | This was tested by David Patiño. Reported-by: David Patiño <davidpatino82@gmail.com> Signed-off-by: Axel Köllhofer <AxelKoellhofer@web.de> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtl8xxxu: Add another 8192eu device to the USB listJes Sorensen2017-01-201-0/+3
| | | | | | | | TP-Link TL-WN822N v4 (2357:0108) Reported-by: Gregory Auzanneau <linux@reolight.net> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as testedJes Sorensen2017-01-201-0/+1
| | | | | | | | | 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: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BFMartin Blumenstingl2017-01-201-0/+1
| | | | | | | | | | | | | | | 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: Arend van Spriel <arend.vanspriel@broadcom.com> Reviewed-by: Andreas Färber <afaerber@suse.de> Tested-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: don't complain about 'unknown event id: 0x63'Brian Norris2017-01-202-0/+5
| | | | | | | | | | | | | | | | 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: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE()Brian Norris2017-01-201-1/+1
| | | | | | | | | | | | | | | 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 <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: pcie: don't loop/retry interrupt status checksBrian Norris2017-01-201-70/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ec815dd2a5f1 ("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 <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: pcie: use posted write to wake up firmwareBrian Norris2017-01-201-4/+3
| | | | | | | | | | | | | | | | 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: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2x00: rt2800lib: support for for RT3352 with external PADaniel Golle2017-01-193-13/+89
| | | | | | | | | | 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: Kalle Valo <kvalo@codeaurora.org>
* rt2x00: rt2800lib: fix rf id for RT3352Felix Fietkau2017-01-191-0/+2
| | | | | | | Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2x00: rt2800lib: correctly set HT20/HT40 filterSerge Vasilugin2017-01-192-2/+13
| | | | | | | | | | 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: Daniel Golle <daniel@makrotopia.org> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2800: remove warning on bcn_num != rt2x00dev->intf_beaconingStanislaw Gruszka2017-01-191-2/+0
| | | | | | | | | | | | 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: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: remove redundant dma padding in AMSDUXinming Hu2017-01-191-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 84b313b35f8158d ("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: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: make brcmf_of_probe more genericRafał Miłecki2017-01-193-9/+12
| | | | | | | | | | | | 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: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* libertas: fix improper return valuePan Bian2017-01-191-1/+1
| | | | | | | | | | | | | | | 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=188451 Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rtlwifi: rtl8192de: Remove a pointless gotoLarry Finger2017-01-171-1/+0
| | | | | | | | | | In commit c93ac39da0064 ("rtlwifi: Remove some redundant code), a goto statement was inadvertently left in the code. Fixes: c93ac39da0064 ("rtlwifi: Remove some redundant code) Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: debugfs: Fix (sometimes) off-by-1 SSID printBrian Norris2017-01-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to commit fcd2042e8d36 ("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: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: setup wiphy bands after registering it firstRafał Miłecki2017-01-171-2/+7
| | | | | | | | | | | | | | | | | | | 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 <rafal@milecki.pl> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: don't preset all channels as disabledRafał Miłecki2017-01-171-2/+0
| | | | | | | | | | | 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: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2800: set max_psdu to 3 on usb devicesStanislaw Gruszka2017-01-171-5/+6
| | | | | | | | | | 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 <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2x00: do not flush empty queueStanislaw Gruszka2017-01-171-1/+2
| | | | | Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2800usb: mark tx failure on timeoutStanislaw Gruszka2017-01-171-3/+2
| | | | | | | | 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 <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2800: tune TX_RTS_CFG configStanislaw Gruszka2017-01-171-2/+2
| | | | | | | | | | | | 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 <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2800: change default retry settingsStanislaw Gruszka2017-01-171-2/+9
| | | | | | | | | | | | 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 <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2x00: save conf settings before reset tunerStanislaw Gruszka2017-01-171-16/+16
| | | | | | | Reset tuner use curr_band value, make sure it is updated. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2800: increase TX timeoutStanislaw Gruszka2017-01-173-3/+3
| | | | | | | | | | | | | | 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 <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* rt2800usb: remove watchdogStanislaw Gruszka2017-01-171-42/+0
| | | | | | | | | | | | | | 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: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: avoid writing channel out of allocated arrayRafał Miłecki2017-01-171-15/+17
| | | | | | | | | | | | | | | | | | | | | | 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: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy bands") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: fix uninitialized variable access in pcie_removeArnd Bergmann2017-01-171-0/+2
| | | | | | | | | | | | | | | 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: 045f0c1b5e26 ("mwifiex: get rid of global user_rmmod flag") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: get rid of global save_adapter and sdio_workXinming Hu2017-01-122-18/+24
| | | | | | | | | 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 <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: get rid of __mwifiex_sdio_remove helperXinming Hu2017-01-121-8/+3
| | | | | | | | | __mwifiex_sdio_remove helper is not needed after our enhancements in SDIO card reset. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: sdio card reset enhancementXinming Hu2017-01-122-43/+33
| | | | | | | | | | | | | | | Commit b4336a282db8 ("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: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: cleanup in PCIe flr code pathXinming Hu2017-01-122-10/+11
| | | | | | | | | | | adapter and card variables don't get freed during PCIe function level reset. "adapter->ext_scan" variable need not be re-initialized. fw_name and tx_buf_size initialization is moved to pcie specific code so that mwifiex_reinit_sw() can be used by SDIO. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: get rid of mwifiex_do_flr wrapperXinming Hu2017-01-123-29/+9
| | | | | | | | | | | This patch gets rid of mwifiex_do_flr. We will call mwifiex_shutdown_sw() and mwifiex_reinit_sw() directly. These two general purpose functions will be useful for sdio card reset handler. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: use module_*_driver helper macrosAmitkumar Karwar2017-01-123-103/+8
| | | | | | | | | | | | | After user_rmmod global flag removal, *_init_module() and *_cleanup_module() have become just a wrapper functions. We will get rid of them with the help of module_*_driver() macros. For pcie, existing ".init_if" handler has same name as what module_pcie_driver() macro will create. Let's rename it to avoid conflict. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: get rid of global user_rmmod flagXinming Hu2017-01-123-39/+17
| | | | | | | | | | | | | | | | | bus.remove() callback function is called when user removes this module from kernel space or ejects the card from the slot. The driver handles these 2 cases differently. Few commands (FUNC_SHUTDOWN etc.) are sent to the firmware only for module unload case. The variable 'user_rmmod' is used to distinguish between these two scenarios. This patch checks hardware status and get rid of global variable user_rmmod. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: code rearrangement in pcie.c and sdio.cXinming Hu2017-01-122-208/+201
| | | | | | | | | | Next patch in this series is going to use mwifiex_read_reg() in remove handlers. The changes here are prerequisites to avoid forward declarations. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: move pcie_work and related variables inside cardGanapathi Bhat2017-01-122-11/+14
| | | | | | | | | | | Currently pcie_work and related variables are global. It may create problem while supporting multiple devices simultaneously. Let's move it inside card structure so that separate instance will be created/ cancelled in init/teardown threads of each connected devices. Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: wait firmware dump complete during card remove processXinming Hu2017-01-122-4/+17
| | | | | | | | | | | | Wait for firmware dump complete in card remove function. For sdio interface, there are two diffenrent cases, card reset trigger sdio_work and firmware dump trigger sdio_work. Do code rearrangement for distinguish between these two cases. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: get rid of drv_info* adapter variablesXinming Hu2017-01-124-33/+29
| | | | | | | | | We can avoid drv_info_dump and drv_info_size adapter variables. This info can be passed to mwifiex_upload_device_dump() as parameters Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: do not free firmware dump memory in shutdown_drvXinming Hu2017-01-121-19/+0
| | | | | | | | | mwifiex_upload_device_dump() already takes care of freeing firmware dump memory. Doing the same thing in mwifiex_shutdown_drv() is redundant. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* mwifiex: don't wait for main_process in shutdown_drvXinming Hu2017-01-124-72/+22
| | | | | | | | | | | | | | | | | | | | main_process is not expected to be running when shutdown_drv function is called. currently we wait for main_process completion in the function. Actually the caller has already made sure main_process is completed by performing below actions. (1) disable interrupts in if_ops->disable_int. (2) set adapter->surprise_removed = true, main_process wont be queued. (3) mwifiex_terminate_workqueue(adapter), wait for workqueue to be completed. This patch removes redundant wait code and takes care of related cleanup. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* ipvlan: improvise dev_id generation logic in IPvlanMahesh Bandewar2017-01-112-1/+13
| | | | | | | | | | | | | | | | | | | | | The patch 009146d117b ("ipvlan: assign unique dev-id for each slave device.") used ida_simple_get() to generate dev_ids assigned to the slave devices. However (Eric has pointed out that) there is a shortcoming with that approach as it always uses the first available ID. This becomes a problem when a slave gets deleted and a new slave gets added. The ID gets reassigned causing the new slave to get the same link-local address. This side-effect is undesirable. This patch adds a per-port variable that keeps track of the IDs assigned and used as the stat-base for the IDR api. This base will be wrapped around when it reaches the MAX (0xFFFE) value possibly on a busy system where slaves are added and deleted routinely. Fixes: 009146d117b ("ipvlan: assign unique dev-id for each slave device.") Signed-off-by: Mahesh Bandewar <maheshb@google.com> CC: Eric Dumazet <edumazet@google.com> CC: David Miller <davem@davemloft.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* liquidio: store the L4 hash of rx packets in skbPrasad Kanneganti2017-01-103-3/+33
| | | | | | | | | | | Store the L4 hash of received packets in the skb; the hash is computed in the NIC firmware. Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by: Derek Chickles <derek.chickles@cavium.com> Signed-off-by: Satanand Burla <satananda.burla@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sfc: stop setting dev_portBert Kenward2017-01-101-2/+0
| | | | | | | | | | | | Setting dev_port changes the device names allocated by systemd. Any devices with a dev_port >0 will (in default distro configurations) have a suffix of "d<port-number>" appended. This is not something done by other drivers, and causes confusion for users. Fixes: 8be41320f346 ("sfc: Add code to export port_num in netdev->dev_port") Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sfc: implement ndo_get_phys_port_nameBert Kenward2017-01-101-0/+11
| | | | | | | | | | Output is of the form p<port-number>. Note that the port numbers don't necessarily map one-to-one to physical cages, partly because of 4x10G port modes on QSFP+ and partly because of hw/fw implementation details. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 11:09:00 +0100