- 26 Jan, 2017 14 commits
-
-
Kirtika Ruchandani authored
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 dcab8ecd ("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 76f8c0e1 ("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: dcab8ecd ("iwlwifi: mvm: support ucode load for family_8000 B0 only") Fixes: 76f8c0e1 ("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>
-
Kirtika Ruchandani authored
Commit 5fc0f76c 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] Fixes: 5fc0f76c (iwlwifi: mvm: add Rx frames statistics via debugfs) Signed-off-by:
-
Kirtika Ruchandani authored
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 e621c228 ("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: e621c228 ("iwlwifi: rs: Remove workaround that disables MIMO on P2P") Signed-off-by:
-
Luca Coelho authored
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; ^ Signed-off-by: -
Jürg Billeter authored
IWL6000G2B_UCODE_API_MAX is not defined. ucode_api_max of IWL_DEVICE_6030 uses IWL6000G2_UCODE_API_MAX. Use this also for MODULE_FIRMWARE. Fixes: 9d9b21d1 ("iwlwifi: remove IWL_*_UCODE_API_OK") Signed-off-by:
Jürg Billeter <j@bitron.ch> Signed-off-by:
-
Sara Sharon authored
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:
-
Sara Sharon authored
In preparation for the new TX cmd - move the rate calculation to a diffrent function, and make it independent of the TX command. Signed-off-by:
-
Sara Sharon authored
Currently the function changes the TX cmd itself. Make it more generic by returning a value, as preperation to the new TX cmd. Signed-off-by:
-
Sara Sharon authored
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 authored
The logic in the paging calculations is a bit hard to follow. Replace it with a kernel define. Signed-off-by:
-
Sara Sharon authored
Some of the code there is duplicate while the only change is the block size. Unifying it shortens the code and make the difference clearer. Signed-off-by:
-
Luca Coelho authored
We skipped one release, so bump twice, to 28. Signed-off-by: -
Johannes Berg authored
When copying from vmalloc'ed memory to the SG list, don't crash if the transport didn't provide any data. Fixes: 7e62a699 ("iwlwifi: mvm: use dev_coredumpsg()") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
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:
-
- 23 Jan, 2017 4 commits
-
-
Johannes Berg authored
The return value is never used, so make the function void. Signed-off-by:
-
Johannes Berg authored
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:
-
Luca Coelho authored
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: 23ae6128 ("iwlwifi: mvm: Do not switch to D3 image on suspend") Signed-off-by:
-
Johannes Berg authored
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:
-
- 20 Jan, 2017 21 commits
-
-
Larry Finger authored
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 authored
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 authored
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 authored
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:
-
Larry Finger authored
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 authored
These two debugging formss implement debugging using rather complicated macro constructions. These are replaced with compiled code that is easier to understand. Signed-off-by:
-
Rafał Miłecki authored
This intends to make init/attach process slightly easier to follow. What driver was doing in brcmf_bus_start wasn't bus specific at all and function brcmf_bus_stop wasn't undoing things done there. This function is supposed to be called by bus specific code when the bus is ready. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Rafał Miłecki authored
Driver used to call brcmf_bus_detach only from one place and it already contained a check for drvr not being NULL. We can get rid of this extra function, call brcmf_bus_stop directly and simplify the code. There also isn't brcmf_bus_attach function which one could expect so it looks more consistent this way. Signed-off-by:
-
Rafał Miłecki authored
Function brcmf_c_set_joinpref_default is in common.c, so move it to the related header. Signed-off-by:
-
Rafał Miłecki authored
Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we really don't need their declarations. Function brcmf_parse_tlvs is used in cfg80211.c only so make it static and drop from header as well. Signed-off-by:
-
Gavin Li authored
brcmf_sdio_fromevntchan() was being called on the the data frame rather than the software header, causing some frames to be mischaracterized as on the event channel rather than the data channel. This fixes a major performance regression (due to dropped packets). With this patch the download speed jumped from 1Mbit/s back up to 40MBit/s due to the sheer amount of packets being incorrectly processed. Fixes: c56caa9d ("brcmfmac: screening firmware event packet") Signed-off-by:
Gavin Li <git@thegavinli.com> Cc: <stable@vger.kernel.org> # 4.7+ Acked-by:
-
Jes Sorensen authored
Update copyright year and email address. Signed-off-by:
Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by:
-
Axel Köllhofer authored
These IDs originate from the vendor driver Signed-off-by:
Axel Köllhofer <AxelKoellhofer@web.de> Signed-off-by:
-
Axel Köllhofer authored
This was tested by David Patiño. Reported-by:
David Patiño <davidpatino82@gmail.com> Signed-off-by:
-
Jes Sorensen authored
TP-Link TL-WN822N v4 (2357:0108) Reported-by:
Gregory Auzanneau <linux@reolight.net> Signed-off-by:
-
Jes Sorensen authored
Device reported as working fine, so tell the driver not to warn about it being untested. Reported-by:
Aex Aey <aexaey@gmail.com> Signed-off-by:
-
Martin Blumenstingl authored
BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455 got a dedicated SDIO device ID which is currently not supported by brcmfmac. Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455 supported because the chip itself is already supported (due to BCM4345 support in the driver). Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Andreas Färber <afaerber@suse.de> Tested-by:
-
Brian Norris authored
Marvell folks tell me this is a debugging event that the driver doesn't need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of these sorts of messages at (for instance) boot time: [ 13.825848] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 14.838561] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 14.850397] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 [ 32.529923] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63 Let's handle this "event" with a much lower verbosity. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Brian Norris authored
In mwifiex_delay_for_sleep_cookie(), we're looping and waiting for the PCIe endpoint to write a magic value back to memory, to signal that it has finished going to sleep. We're not letting the compiler know that this might change underneath our feet though. Let's do that, for good hygiene. I'm not aware of this fixing any concrete problems. I also give no guarantee that this loop is actually correct in any other way, but at least this looks like an improvement to me. Signed-off-by:
-
Brian Norris authored
The following sequence occurs when using IEEE power-save on 8997: (a) driver sees SLEEP event (b) driver issues SLEEP CONFIRM (c) driver recevies CMD interrupt; within the interrupt processing loop, we do (d) and (e): (d) wait for FW sleep cookie (and often time out; it takes a while), FW is putting card into low power mode (e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value But at (e), no one actually signaled an interrupt (i.e., we didn't check adapter->int_status). And what's more, because the card is going to sleep, this register read appears to take a very long time in some cases -- 3 milliseconds in my case! Now, I propose that (e) is completely unnecessary. If there were any additional interrupts signaled after the start of this loop, then the interrupt handler would have set adapter->int_status to non-zero and queued more work for the main loop -- and we'd catch it on the next iteration of the main loop. So this patch drops all the looping/re-reading of PCIE_HOST_INT_STATUS, which avoids the problematic (and slow) register read in step (e). Incidentally, this is a very similar issue to the one fixed in commit ec815dd2 ("mwifiex: prevent register accesses after host is sleeping"), except that the register read is just very slow instead of fatal in this case. Tested on 8997 in both MSI and (though not technically supported at the moment) MSI-X mode. Signed-off-by: -
Brian Norris authored
Depending on system factors (e.g., the PCIe link PM state), the first read to wake up the Wifi firmware can take a long time. There is no reason to use a (blocking, non-posted) read at this point, so let's just use a write instead. Write vs. read doesn't matter functionality-wise -- it's just a dummy operation. But let's make sure to re-write with the correct "ready" signature, since we check for that in other parts of the driver. This has been shown to decrease the time spent blocking in this function on RK3399. Signed-off-by:
-
- 19 Jan, 2017 1 commit
-
-
Daniel Golle authored
This is needed for WiFi to work e.g. on DIR-615 rev.H1 which got external RF power amplifiers connected to the WiSoC. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
