Michael Schenk [Thu, 26 Jan 2017 17:25:04 +0000 (11:25 -0600)]
rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down
In the function rtl_usb_start we pre-allocate a certain number of urbs
for RX path but they will not be freed when calling rtl_usb_stop. This
results in leaking urbs when doing ifconfig up and down. Eventually,
the system has no available urbs.
Signed-off-by: Michael Schenk <michael.schenk@albis-elcon.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Amitkumar Karwar [Tue, 24 Jan 2017 13:35:45 +0000 (19:05 +0530)]
mwifiex: use pci_dma_sync_single* APIs
On some platforms, driver is unable read sleep cookie signature even
if firmware has written it through DMA. The problem is fixed by using
pci_dma_sync_single* APIs while reading DMA buffer shared with firmware.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Amitkumar Karwar [Tue, 24 Jan 2017 13:35:44 +0000 (19:05 +0530)]
mwifiex: mwifiex_unmap_pci_memory() handling for sleep confirm
Sleep confirm is a special command for which "adapter->cur_cmd" pointer
is not set. When it's response is received, host writes SLEEP confirm done
to a register. Firmware will perform DMA for writing sleep cookie signature
on same buffer after this.
Let's not immediately call mwifiex_unmap_pci_memory() for this special
command. Unmapping will be done when firmware completes writing sleep
cookie signature.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Serge Vasilugin [Fri, 20 Jan 2017 13:28:26 +0000 (14:28 +0100)]
rt2x00: add support for RT5350 WiSoC
Support for the RT5350 WiSoC was added to OpenWrt after having a
lengthy debate about the legality of the original submission, see
https://lists.openwrt.org/pipermail/openwrt-devel/2013-January/018224.html
MTK/Ralink Acked replied and says we can merge this patch under the GPL.
https://dev.openwrt.org/changeset/36177
Signed-off-by: Serge Vasilugin <vasilugin@yandex.ru> Tested-by: Michel Stempin <michel.stempin@wanadoo.fr> Acked-by: John Crispin <blogic@openwrt.org>
[daniel@makrotopia.org: added commit message, cleaned up code] Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Daniel Golle [Fri, 20 Jan 2017 13:28:25 +0000 (14:28 +0100)]
rt2x00: rt2800lib: add support for RT3352 with 20MHz crystal
On Rt3352 the driver needs to know the frequency of an external
crystal which can be either 40 MHz (as on all other WiSoCs until now)
or 20 MHz.
Get the clock attached by ramips WiSoC platform code which probes
SYSC_REG_SYSCFG (added by John Crispin in commit 6ac8579b96e3b) and
introduce a new flag clk_is_20mhz in struct hw_mode_spec to make the
driver aware and use either 40 MHz or 20 MHz specific rf_vals on those
WiSoC platforms.
The introduced support for boards with a 20 MHz crystal is also needed
for RT5350.
Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Mathias Kresin <dev@kresin.me> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kalle Valo [Fri, 27 Jan 2017 11:23:48 +0000 (13:23 +0200)]
Merge tag 'iwlwifi-next-for-kalle-2017-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Some improvements, bugfixes and new features:
* A bunch of cleanups here and there;
* A few simple bugfixes;
* Some more work in preparation for A000 family support;
* Add support for radiotap timestamps;
* Some work on our firmware debugging capabilities;
Luca Coelho [Wed, 9 Nov 2016 08:02:46 +0000 (10:02 +0200)]
iwlwifi: mvm: mark ret as maybe_unused in iwl_dbgfs_fw_restart_write()
The value returned from iwl_mvm_send_cmd_pdu() in this function is not
used and always returns an error (which is the whole point of the
call). Tag the ret variable with __maybe_unused to avoid this compile
warning when W=1 is used:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c: In function ‘iwl_dbgfs_fw_restart_write’:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:875:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
int ret;
^
Luca Coelho [Wed, 9 Nov 2016 07:45:58 +0000 (09:45 +0200)]
iwlwifi: dvm: remove unused variable compiler warning in debugfs.c
When compiling with W=1, we get the following warning in debugfs.c:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c: In function ‘iwl_dbgfs_fw_restart_write’:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c:2313:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
int ret;
^
Luca Coelho [Wed, 9 Nov 2016 08:05:18 +0000 (10:05 +0200)]
iwlwifi: mvm: remove unused sta_id variable in iwl_mvm_change_queue_owner()
Remove the sta_id variable, to avoid this compile warning when
compiling with W=1:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/sta.c: In function ‘iwl_mvm_change_queue_owner’:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/sta.c:871:5: warning: variable ‘sta_id’ set but not used [-Wunused-but-set-variable]
s8 sta_id;
^
Luca Coelho [Wed, 9 Nov 2016 07:48:49 +0000 (09:48 +0200)]
iwlwifi: dvm: make rs_tl_get_load() return void
The return value from this function is never used, so make it return
void to avoid getting the following warning when compiling wiht W=1:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/dvm/rs.c: In function ‘rs_tl_turn_on_agg_for_tid’:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/dvm/rs.c:400:6: warning: variable ‘load’ set but not used [-Wunused-but-set-variable]
u32 load;
^
shift_param is defined and set in iwl_pcie_load_cpu_sections but not
used. Fix this to avoid -Wunused-but-set-variable warning.
The code using it turned into dead code with commit dcab8ecd5617
("iwlwifi: mvm: support ucode load for family_8000 B0 only") which
added a separate function iwl_pcie_load_given_ucode_8000 (then 8000b)
for IWL_DEVICE_FAMILY_8000. Commit 76f8c0e17edc ("iwlwifi: pcie:
remove dead code") removed the dead code but left shift_param as is.
iwlwifi/pcie/trans.c: In function ‘iwl_pcie_load_cpu_sections’:
iwlwifi/pcie/trans.c:871:6: warning: variable ‘shift_param’ set but not used [-Wunused-but-set-variable]
Fixes: dcab8ecd5617 ("iwlwifi: mvm: support ucode load for family_8000 B0 only") Fixes: 76f8c0e17edc ("iwlwifi: pcie: remove dead code") Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Cc: Sara Sharon <sara.sharon@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Liad Kaufman <liad.kaufman@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[removed some unnecessary braces] Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Commit 5fc0f76c4 introduced Rx stats from debugfs, the function
iwl_mvm_reset_frame_stats from that commit defines and sets mcs but
does not use it. Compiling iwlwifi with W=1 gives this warning -
iwlwifi/mvm/rs.c: In function ‘iwl_mvm_update_frame_stats’:
iwlwifi/mvm/rs.c:3074:14: warning: variable ‘mcs’ set but not used [-Wunused-but-set-variable]
mvmvif is defined and set in rs_mimo_allow but not used. Compiling
iwlwifi with W=1 gives the following warning, remove it. mvmsta is
used only to obtain mvmvif so remove it as well.
iwlwifi/mvm/rs.c: In function 'rs_mimo_allow':
iwlwifi/mvm/rs.c:165:22: warning: variable 'mvmvif' set but not used.[-Wunused-but-set-variable]
This fix removes calls to iwl_mvm_sta_from_mac &
iwl_mvm_vif_from_mac. They are both accessors, and do not have any
side-effects. Commit e621c2282e31 ("iwlwifi: rs: Remove workaround
that disables MIMO on P2P") removed a workaround that disabled MIMO on
P2P, 'mvmvif' was used for that workaround, but not removed with it.
Fixes: e621c2282e31 ("iwlwifi: rs: Remove workaround that disables MIMO on P2P") Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Cc: Alexander Bondar <alexander.bondar@intel.com> Cc: Emmanuel Grumbach <emmmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Luca Coelho [Wed, 9 Nov 2016 08:07:14 +0000 (10:07 +0200)]
iwlwifi: mvm: remove unused variable in iwl_mvm_handle_statistics()
The temperature variable is set but not used in
iwl_mvm_handle_statistics(). Remove it to avoid the following
compiler warning when W=1 is used:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/rx.c: In function ‘iwl_mvm_handle_rx_statistics’:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/rx.c:759:6: warning: variable ‘temperature’ set but not used [-Wunused-but-set-variable]
u32 temperature;
^
Sara Sharon [Tue, 8 Nov 2016 16:34:42 +0000 (18:34 +0200)]
iwlwifi: mvm: support version 2 of stored beacon notification
For 9000 devices withg upload, FW cannot send the entire phy
flags, and will send only the band - which is what we really
care about anyway. Change is backward compatible.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Sara Sharon [Tue, 25 Oct 2016 08:38:31 +0000 (11:38 +0300)]
iwlwifi: enlarge number of ucode sections
The maximum number of firmware sections is now 32 instead of 16 for
a000 devices. Set the appropriate define. Avoid out of bounds access
in case there are more sections than the maximum set by driver.
Make the driver extensible to FW size changes by allocating the
section memory dynamically.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Johannes Berg [Thu, 20 Oct 2016 08:01:43 +0000 (10:01 +0200)]
iwlwifi: allow memory debug TLV to specify the memory type
Due to some new features and changes, the firmware file will now
specify what type of memory to dump, in upper 8 bits of the type
field of the TLV. Parse it (types we don't understand are errors)
and teach the code to dump periphery memory.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Johannes Berg [Thu, 20 Oct 2016 07:41:14 +0000 (09:41 +0200)]
iwlwifi: mvm: accept arbitrary memory dump TLVs
There's no reason to be validating the memory dump types, or
checking them for duplication, or anything, since we really
just pass them through from the TLV to the dump.
Thus, change the way we handle memory dump TLVs to let the
driver just blindly use anything specified there, dumping it
into the memory dump output file.
This makes the system extensible without driver changes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Luca Coelho [Fri, 7 Oct 2016 12:16:26 +0000 (15:16 +0300)]
iwlwifi: mvm: don't restart HW if suspend fails with unified image
For unified images, we shouldn't restart the HW if suspend fails. The
only reason for restarting the HW with non-unified images is to go
back to the D0 image.
Fixes: 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on suspend") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Johannes Berg [Mon, 15 Aug 2016 07:26:32 +0000 (09:26 +0200)]
iwlwifi: mvm: expose device timestamp in radiotap
Set the relevant fields to export the 32-bit device timestamp to
radiotap using the new mac80211 infrastructure. This will be useful
to allow synchronising monitor captures taken on different hardware
simultaneously.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Larry Finger [Thu, 19 Jan 2017 20:28:08 +0000 (14:28 -0600)]
rtlwifi: rtl8192cu: Convert driver to use common macros
These drivers use a set of complicated macros to extract and insert
information for the RX and TX descriptors. Driver rtl8192cu had a
different set than was used for the PCI-based drivers. To simplify
the code, rtl8192cu is switched to use the common version. In the
process, two errors in those common macros were found and fixed.
Besides simplifying the code, there is an additional benefit. We have
no BE hardware to test the PCI driver, but using the common macros
provides an additional test for the validity of many endian-sensitive
operations.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Thu, 19 Jan 2017 20:28:07 +0000 (14:28 -0600)]
rtlwifi: rtl8192cu: Calculate descriptor checksum correctly for BE
This driver requires a checksum for the descriptors so that the wifi
chip is assured that the USB transmission was correct. These entries
are little-endian, but the driver was always using cpu order in the
calculation. As a result, the driver failed on BE hardware.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Thu, 19 Jan 2017 20:28:06 +0000 (14:28 -0600)]
rtlwifi: Download firmware as bytes rather than as dwords
The firmware is read from disk as a little-endian byte string. The code
that loads the firmware into the device transfers it as 4-byte quantities.
The routines that write multi-byte quantities on BE hardware assume that
the data are in CPU order, and automatically do the conversion to the LE
order required by the device. As a result, the firmware is transmitted
incorrectly. Rather than do multiple byte swaps on the data, the download
routine is revised to transmit bytes rather than dwords. Although the
number of I/O operations is increased, the firmware is not often loaded.
All drivers have the same bug, and use essentially the same code to
download firmware. These routines have been moved into rtlwifi.
Some CamelCase variables have been renamed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Thu, 19 Jan 2017 17:25:21 +0000 (11:25 -0600)]
rtlwifi: Remove debugging entry in sysfs
As the kernel provides access to module parameters through entries in
/sys/module/<driver>/parameters/, there is no need for a private
interface. Thus the existing code for setting the debug level is
removed.
Reported-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Thu, 19 Jan 2017 17:25:20 +0000 (11:25 -0600)]
rtlwifi: Convert COMP_XX entries into a proper debugging mask
The debugging macros contain a parameter COMP_XX that could be used as a
mask; however, the code turns all these various bits on at the same time.
This change implements them as a proper mask, and adds module parameters
to set the mask at load time.
The current name "debug" for the debug level has been changed to
"debug_level" to better differentiate it from "debug_mask".
The debug routines have also been changed to interrogate the structure
that is loaded at entry time. As a result, the structure rtl_debug is no
longer needed, and all references to it are deleted.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Thu, 19 Jan 2017 17:25:19 +0000 (11:25 -0600)]
rtlwifi: Redo debugging macros RTPRINT and RT_PRINT_DATA
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 [Wed, 18 Jan 2017 10:48:54 +0000 (11:48 +0100)]
brcmfmac: rename brcmf_bus_start function to brcmf_bus_started
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: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Wed, 18 Jan 2017 10:48:53 +0000 (11:48 +0100)]
brcmfmac: drop brcmf_bus_detach and inline its code
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 <rafal@milecki.pl> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Wed, 18 Jan 2017 10:48:52 +0000 (11:48 +0100)]
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>
Rafał Miłecki [Wed, 18 Jan 2017 10:48:51 +0000 (11:48 +0100)]
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>
Gavin Li [Tue, 17 Jan 2017 23:24:05 +0000 (15:24 -0800)]
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: 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>
Axel Köllhofer [Tue, 17 Jan 2017 23:18:55 +0000 (18:18 -0500)]
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>
Axel Köllhofer [Tue, 17 Jan 2017 23:18:54 +0000 (18:18 -0500)]
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>
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>
Brian Norris [Sat, 14 Jan 2017 02:16:57 +0000 (18:16 -0800)]
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:
Brian Norris [Fri, 13 Jan 2017 23:35:38 +0000 (15:35 -0800)]
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>
Brian Norris [Fri, 13 Jan 2017 23:35:37 +0000 (15:35 -0800)]
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 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>
Brian Norris [Fri, 13 Jan 2017 23:35:36 +0000 (15:35 -0800)]
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>
Felix Fietkau [Mon, 16 Jan 2017 03:13:01 +0000 (04:13 +0100)]
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>
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>
Rafał Miłecki [Sat, 7 Jan 2017 22:43:45 +0000 (23:43 +0100)]
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>
Pan Bian [Sat, 3 Dec 2016 10:27:37 +0000 (18:27 +0800)]
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.
Larry Finger [Tue, 10 Jan 2017 16:15:26 +0000 (10:15 -0600)]
rtlwifi: rtl8192de: Remove a pointless goto
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>
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).
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>
Rafał Miłecki [Sat, 7 Jan 2017 20:36:05 +0000 (21:36 +0100)]
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>
Rafał Miłecki [Sat, 7 Jan 2017 20:36:04 +0000 (21:36 +0100)]
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>
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>
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>
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>
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>
Rafał Miłecki [Wed, 4 Jan 2017 11:09:41 +0000 (12:09 +0100)]
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: 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>
Arnd Bergmann [Fri, 13 Jan 2017 15:35:03 +0000 (16:35 +0100)]
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: 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>
Xinming Hu [Wed, 14 Dec 2016 14:10:49 +0000 (19:40 +0530)]
mwifiex: sdio card reset enhancement
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>
Xinming Hu [Wed, 14 Dec 2016 14:10:48 +0000 (19:40 +0530)]
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>
Xinming Hu [Wed, 14 Dec 2016 14:10:47 +0000 (19:40 +0530)]
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>
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>
Xinming Hu [Wed, 30 Nov 2016 14:52:17 +0000 (20:22 +0530)]
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>
Ganapathi Bhat [Wed, 16 Nov 2016 13:09:09 +0000 (18:39 +0530)]
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>
Xinming Hu [Wed, 16 Nov 2016 13:09:08 +0000 (18:39 +0530)]
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>
Xinming Hu [Wed, 16 Nov 2016 13:09:05 +0000 (18:39 +0530)]
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>
Sowmini Varadhan [Tue, 10 Jan 2017 15:47:15 +0000 (07:47 -0800)]
packet: pdiag_put_ring() should return TX_RING info for TPACKET_V3
Commit 7f953ab2ba46 ("af_packet: TX_RING support for TPACKET_V3")
now makes it possible to use TX_RING with TPACKET_V3, so make the
the relevant information available via 'ss -e -a --packet'
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Tobias Klauser [Tue, 10 Jan 2017 14:02:16 +0000 (15:02 +0100)]
bpf: Make unnecessarily global functions static
Make the functions __local_list_pop_free(), __local_list_pop_pending(),
bpf_common_lru_populate() and bpf_percpu_lru_populate() static as they
are not used outide of bpf_lru_list.c
This fixes the following GCC warnings when building with 'W=1':
kernel/bpf/bpf_lru_list.c:363:22: warning: no previous prototype for ‘__local_list_pop_free’ [-Wmissing-prototypes]
kernel/bpf/bpf_lru_list.c:376:22: warning: no previous prototype for ‘__local_list_pop_pending’ [-Wmissing-prototypes]
kernel/bpf/bpf_lru_list.c:560:6: warning: no previous prototype for ‘bpf_common_lru_populate’ [-Wmissing-prototypes]
kernel/bpf/bpf_lru_list.c:577:6: warning: no previous prototype for ‘bpf_percpu_lru_populate’ [-Wmissing-prototypes]
Cc: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Tobias Klauser [Tue, 10 Jan 2017 14:02:07 +0000 (15:02 +0100)]
bpf: Remove unused but set variable in __bpf_lru_list_shrink_inactive()
Remove the unused but set variable 'first_node' in
__bpf_lru_list_shrink_inactive() to fix the following GCC warning when
building with 'W=1':
kernel/bpf/bpf_lru_list.c:216:41: warning: variable ‘first_node’ set but not used [-Wunused-but-set-variable]
Cc: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Mahesh Bandewar [Mon, 9 Jan 2017 23:05:54 +0000 (15:05 -0800)]
ipvlan: improvise dev_id generation logic in IPvlan
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>
Bert Kenward [Tue, 10 Jan 2017 16:24:31 +0000 (16:24 +0000)]
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: 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>
Bert Kenward [Tue, 10 Jan 2017 16:23:56 +0000 (16:23 +0000)]
sfc: implement ndo_get_phys_port_name
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>
Timur Tabi [Mon, 9 Jan 2017 18:03:12 +0000 (12:03 -0600)]
net: qcom/emac: add ethtool support
Add support for some ethtool methods: get/set link settings, get/set
message level, get statistics, get link status, get ring params, get
pause params, and restart autonegotiation.
The code to collect the hardware statistics is moved into its own
function so that it can be used by "get statistics" method.
Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Vivien Didelot [Mon, 9 Jan 2017 21:49:26 +0000 (16:49 -0500)]
net: dsa: select NET_SWITCHDEV
The support for DSA Ethernet switch chips depends on TCP/IP networking,
thus explicit that HAVE_NET_DSA depends on INET.
DSA uses SWITCHDEV, thus select it instead of depending on it.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / karo-tx-linux.git / log