Commit Graph

64921 Commits

Author SHA1 Message Date
Rafał Miłecki
f5611e0381 brcmfmac: move brcmf_c_set_joinpref_default declaration to common.h
Function brcmf_c_set_joinpref_default is in common.c, so move it to the
related header.

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>
2017-01-20 12:03:56 +02:00
Rafał Miłecki
c8d870794d brcmfmac: drop unneeded function declarations from headers
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>
2017-01-20 12:03:55 +02:00
Gavin Li
8e290cecdd brcmfmac: fix incorrect event channel deduction
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: c56caa9db8 ("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>
2017-01-20 12:02:28 +02:00
Jes Sorensen
1ee83789fc rtl8xxxu: Update author/maintainer contact info
Update copyright year and email address.

Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-20 11:49:01 +02:00
Axel Köllhofer
5407fd7de6 rtl8xxxu: Add additional USB IDs for rtl8192eu devices
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>
2017-01-20 11:49:01 +02:00
Axel Köllhofer
66dfa26ebc rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)
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>
2017-01-20 11:49:01 +02:00
Jes Sorensen
c14239f23a rtl8xxxu: Add another 8192eu device to the USB list
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>
2017-01-20 11:49:00 +02:00
Jes Sorensen
d607e39656 rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested
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>
2017-01-20 11:49:00 +02:00
Martin Blumenstingl
a62a77881b brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF
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>
2017-01-20 11:47:57 +02:00
Brian Norris
0ed917d09d mwifiex: don't complain about 'unknown event id: 0x63'
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>
2017-01-20 11:47:23 +02:00
Brian Norris
fe11678839 mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE()
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>
2017-01-20 11:46:32 +02:00
Brian Norris
5d5ddb5e0d mwifiex: pcie: don't loop/retry interrupt status checks
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
ec815dd2a5 ("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>
2017-01-20 11:46:32 +02:00
Brian Norris
062e008a6e mwifiex: pcie: use posted write to wake up firmware
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>
2017-01-20 11:46:31 +02:00
Daniel Golle
dab38e7d25 rt2x00: rt2800lib: support for for RT3352 with external PA
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>
2017-01-19 14:49:12 +02:00
Felix Fietkau
b8c2db58d5 rt2x00: rt2800lib: fix rf id for RT3352
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>
2017-01-19 14:49:12 +02:00
Serge Vasilugin
e974f3acaf rt2x00: rt2800lib: correctly set HT20/HT40 filter
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>
2017-01-19 14:49:11 +02:00
Stanislaw Gruszka
feecb0cb46 rt2800: remove warning on bcn_num != rt2x00dev->intf_beaconing
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>
2017-01-19 14:48:16 +02:00
Xinming Hu
5f0a221f59 mwifiex: remove redundant dma padding in AMSDU
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: 84b313b35f ("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>
2017-01-19 14:47:45 +02:00
Rafał Miłecki
e457a8a01a brcmfmac: make brcmf_of_probe more generic
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>
2017-01-19 14:45:13 +02:00
Pan Bian
259010c509 libertas: fix improper return value
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>
2017-01-19 14:38:43 +02:00
Larry Finger
7f2f61377b rtlwifi: rtl8192de: Remove a pointless goto
In commit c93ac39da0 ("rtlwifi: Remove some redundant code), a goto
statement was inadvertently left in the code.

Fixes: c93ac39da0 ("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>
2017-01-17 14:13:12 +02:00
Brian Norris
6183468a23 mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print
Similar to commit fcd2042e8d ("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: 5e6e3a92b9 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-17 14:03:32 +02:00
Rafał Miłecki
ab99063f87 brcmfmac: setup wiphy bands after registering it first
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>
2017-01-17 14:01:10 +02:00
Rafał Miłecki
9ea0c30760 brcmfmac: don't preset all channels as disabled
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>
2017-01-17 14:01:09 +02:00
Stanislaw Gruszka
66ecec02e8 rt2800: set max_psdu to 3 on usb devices
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>
2017-01-17 13:58:38 +02:00
Stanislaw Gruszka
5158324818 rt2x00: do not flush empty queue
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-17 13:58:38 +02:00
Stanislaw Gruszka
1701221696 rt2800usb: mark tx failure on timeout
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>
2017-01-17 13:58:37 +02:00
Stanislaw Gruszka
e4019e7f95 rt2800: tune TX_RTS_CFG config
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>
2017-01-17 13:58:37 +02:00
Stanislaw Gruszka
01d97ef4b2 rt2800: change default retry settings
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>
2017-01-17 13:58:36 +02:00
Stanislaw Gruszka
15ec51b25e rt2x00: save conf settings before reset tuner
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>
2017-01-17 13:58:36 +02:00
Stanislaw Gruszka
cfe82fbd84 rt2800: increase TX timeout
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>
2017-01-17 13:58:36 +02:00
Stanislaw Gruszka
480b468625 rt2800usb: remove watchdog
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>
2017-01-17 13:58:35 +02:00
Rafał Miłecki
77c0d0cd10 brcmfmac: avoid writing channel out of allocated array
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: 58de92d2f9 ("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>
2017-01-17 13:56:35 +02:00
Arnd Bergmann
0e8edb9aed mwifiex: fix uninitialized variable access in pcie_remove
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: 045f0c1b5e ("mwifiex: get rid of global user_rmmod flag")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-01-17 13:54:57 +02:00
Xinming Hu
cc75c57780 mwifiex: get rid of global save_adapter and sdio_work
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>
2017-01-12 16:49:18 +02:00
Xinming Hu
a7513a4fa9 mwifiex: get rid of __mwifiex_sdio_remove helper
__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>
2017-01-12 16:49:18 +02:00
Xinming Hu
c742e623e9 mwifiex: sdio card reset enhancement
Commit b4336a282d ("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>
2017-01-12 16:49:17 +02:00
Xinming Hu
ec750f1082 mwifiex: cleanup in PCIe flr code path
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>
2017-01-12 16:49:17 +02:00
Xinming Hu
8750ab6236 mwifiex: get rid of mwifiex_do_flr wrapper
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>
2017-01-12 16:49:16 +02:00
Amitkumar Karwar
c0e6aa4268 mwifiex: use module_*_driver helper macros
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>
2017-01-12 16:47:31 +02:00
Xinming Hu
045f0c1b5e mwifiex: get rid of global user_rmmod flag
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>
2017-01-12 16:46:23 +02:00
Xinming Hu
90ff71f955 mwifiex: code rearrangement in pcie.c and sdio.c
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>
2017-01-12 16:46:22 +02:00
Ganapathi Bhat
3860e5e395 mwifiex: move pcie_work and related variables inside card
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>
2017-01-12 16:44:30 +02:00
Xinming Hu
41efaf5824 mwifiex: wait firmware dump complete during card remove process
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>
2017-01-12 16:44:30 +02:00
Xinming Hu
d27121fca1 mwifiex: get rid of drv_info* adapter variables
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>
2017-01-12 16:44:29 +02:00
Xinming Hu
fb45bd0c6d mwifiex: do not free firmware dump memory in shutdown_drv
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>
2017-01-12 16:44:29 +02:00
Xinming Hu
5bf15e3fb8 mwifiex: don't wait for main_process in shutdown_drv
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>
2017-01-12 16:44:29 +02:00
Mahesh Bandewar
da36e13cf6 ipvlan: improvise dev_id generation logic in IPvlan
The patch 009146d117 ("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: 009146d117 ("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>
2017-01-10 20:47:12 -05:00
Prasad Kanneganti
de28c99d71 liquidio: store the L4 hash of rx packets in skb
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>
2017-01-10 14:22:34 -05:00
Bert Kenward
0d71a84c74 sfc: stop setting dev_port
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: 8be41320f3 ("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>
2017-01-10 14:16:17 -05:00