- 30 Nov, 2018 1 commit
-
-
Lorenzo Bianconi authored
Unify firmware version used on mt76x2e and mt76x2u drivers Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
- 29 Nov, 2018 8 commits
-
-
Lyude Paul authored
I ended up tracking down some rather nasty issues with f2fs (and other filesystem modules) constantly crashing on my kernel down to a combination of out of bounds memory accesses, one of which was coming from brcmfmac during module load: [ 30.891382] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2 [ 30.894437] ================================================================== [ 30.901581] BUG: KASAN: global-out-of-bounds in brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac] [ 30.909935] Read of size 1 at addr ffff2000024865df by task kworker/6:2/387 [ 30.916805] [ 30.918261] CPU: 6 PID: 387 Comm: kworker/6:2 Tainted: G O 4.20.0-rc3Lyude-Test+ #19 [ 30.927251] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018 [ 30.935964] Workqueue: events brcmf_driver_register [brcmfmac] [ 30.941641] Call trace: [ 30.944058] dump_backtrace+0x0/0x3e8 [ 30.947676] show_stack+0x14/0x20 [ 30.950968] dump_stack+0x130/0x1c4 [ 30.954406] print_address_description+0x60/0x25c [ 30.959066] kasan_report+0x1b4/0x368 [ 30.962683] __asan_report_load1_noabort+0x18/0x20 [ 30.967547] brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac] [ 30.967639] brcmf_sdio_probe+0x163c/0x2050 [brcmfmac] [ 30.978035] brcmf_ops_sdio_probe+0x598/0xa08 [brcmfmac] [ 30.983254] sdio_bus_probe+0x190/0x398 [ 30.983270] really_probe+0x2a0/0xa70 [ 30.983296] driver_probe_device+0x1b4/0x2d8 [ 30.994901] __driver_attach+0x200/0x280 [ 30.994914] bus_for_each_dev+0x10c/0x1a8 [ 30.994925] driver_attach+0x38/0x50 [ 30.994935] bus_add_driver+0x330/0x608 [ 30.994953] driver_register+0x140/0x388 [ 31.013965] sdio_register_driver+0x74/0xa0 [ 31.014076] brcmf_sdio_register+0x14/0x60 [brcmfmac] [ 31.023177] brcmf_driver_register+0xc/0x18 [brcmfmac] [ 31.023209] process_one_work+0x654/0x1080 [ 31.032266] worker_thread+0x4f0/0x1308 [ 31.032286] kthread+0x2a8/0x320 [ 31.039254] ret_from_fork+0x10/0x1c [ 31.039269] [ 31.044226] The buggy address belongs to the variable: [ 31.044351] brcmf_firmware_path+0x11f/0xfffffffffffd3b40 [brcmfmac] [ 31.055601] [ 31.057031] Memory state around the buggy address: [ 31.061800] ffff200002486480: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 [ 31.068983] ffff200002486500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 31.068993] >ffff200002486580: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00 [ 31.068999] ^ [ 31.069017] ffff200002486600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 31.096521] ffff200002486680: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa [ 31.096528] ================================================================== [ 31.096533] Disabling lock debugging due to kernel taint It appears that when trying to determine the length of the string in the alternate firmware path, we make the mistake of not handling the case where the firmware path is empty correctly. Since strlen(mp_path) can return 0, we'll end up accessing mp_path[-1] when the firmware_path isn't provided through the module arguments. So, fix this by just setting the end char to '\0' by default, and only changing it if we have a non-zero length. Additionally, use strnlen() with BRCMF_FW_ALTPATH_LEN instead of strlen() just to be extra safe. Fixes: 2baa3aae ("brcmfmac: introduce brcmf_fw_alloc_request() function") Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Arend Van Spriel <arend.vanspriel@broadcom.com> Cc: Himanshu Jha <himanshujha199640@gmail.com> Cc: Dan Haab <dhaab@luxul.com> Cc: Jia-Shyr Chuang <saint.chuang@cypress.com> Cc: Ian Molton <ian@mnementh.co.uk> Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Hans de Goede authored
ARM systems with UEFI may have both devicetree (of) and DMI data in this case we end up setting brcmf_mp_device.board_type twice. In this case we should prefer the devicetree data, because: 1) The devicerree data is more reliable 2) Some ARM systems (e.g. the Raspberry Pi 3 models) support both UEFI and classic uboot booting, the devicetree data is always there, so using it makes sure we ask for the same nvram file independent of how we booted. This commit moves the brcmf_dmi_probe call to before the brcmf_of_probe call, so that the latter can override the value of the first if both are set. Fixes: bd1e82bb ("brcmfmac: Set board_type from DMI on x86 based ...") Cc: Peter Robinson <pbrobinson@gmail.com> Tested-and-reported-by:
Peter Robinson <pbrobinson@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Dan Haab authored
The newest firmwares provide STA info using v7 of the struct. As v7 isn't backward compatible, a union is needed. Even though brcmfmac does not use any of the new info it's important to provide the proper struct buffer. Without this change new firmwares will fallback to the very limited v3 instead of something in between such as v4. Signed-off-by:
Dan Haab <dan.haab@luxul.com> Reviewed-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Priit Laes authored
Kernel library has a common cordic algorithm which is identical to internally implemented one, so use it and drop the duplicate implementation. Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Priit Laes <plaes@plaes.org> Signed-off-by:
-
Larry Finger authored
The cordic routine for calculating sines and cosines that was added in commit 6f98e62a ("b43: update cordic code to match current specs") contains an error whereby a quantity declared u32 can in fact go negative. This problem was detected by Priit Laes who is switching b43 to use the routine in the library functions of the kernel. Fixes: 98650454 ("b43: make cordic common (LP-PHY and N-PHY need it)") Reported-by:
-
Priit Laes authored
Current driver includes macro that is available from general cordic library. Use that and drop unused duplicate and unneeded internal definitions. Signed-off-by:
-
Priit Laes authored
Now that these macros are in header file, we can eventually clean up the duplicate macros present in the drivers that utilize the same cordic algorithm implementation. Also add CORDIC_ prefix to nonprefixed macros. Reviewed-by:
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2018-11-23' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next second batch of iwlwifi patches intended for v4.21 * New FW debugging infrastructure; * Some more work on 802.11ax; * Improve support for multiple RF modules with 22000 devices; * Remove an unused FW parameter; * Other debugging improvements;
-
- 23 Nov, 2018 16 commits
-
-
Shaul Triebitz authored
Enable the VHT extended NSS BW feature in iwlwifi/mvm. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Shaul Triebitz authored
In AP mode, if AP supports HE (and the STA), send the STA_HE_CTXT command. This is needed mainly for PPE (packet extension) params. Signed-off-by:
-
Shaul Triebitz authored
In AP mode, if AP supports 11ax, add the MAC_FILTER_IN_11AX flag in MAC_CTXT command (needed for various 11ax stuff). Signed-off-by:
-
Sara Sharon authored
A new field was added. Since the code isn't operational (yet) no need to worry about backward compatibility. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
-
Lior Cohen authored
FW debug data will oneshot read all data available in DRAM and fill the supplied user buffer. In case the read request is greater than the new data in DRAM, the driver will write all data it has and return the buffer immediately. Signed-off-by:
Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by:
Lior Cohen <lior2.cohen@intel.com> Signed-off-by:
-
Sara Sharon authored
Add a function to be called when apply point occurs. For each of the TLVs, the function will perform the apply point logic: - For HCMD - send the stored host command - For buffer allocation - allocate the memory and send the buffer allocation command - For trigger and region - update the stored configuration Signed-off-by:
-
Sara Sharon authored
When ini is loaded, disable all legacy trigger configuration. Signed-off-by:
-
Sara Sharon authored
Support loading and storing ini TLVs from external file. Those TLVs are appended to the default TLVs, so store them separately. Signed-off-by:
-
Sara Sharon authored
The new debug ini TLVs can be either packed into firmware binary or written in external file. Support loading them from both. Store the data per apply point. Apply point is a point during driver runtime, where the TLV becomes active. For example, a trigger of hardware error may be configured to collect a subset of data pre-alive, as a opposed to HW error that occurs after alive. Signed-off-by:
-
Sara Sharon authored
Add the FW API of the new debug infrastructure. Next patches will introduce the utilization of this infra. Signed-off-by:
-
Emmanuel Grumbach authored
We need to check the TWT support of the peer and to propagte the capability to the firmware. The current implementation will enable TWT only if the TWT support is advertised in the HE CAP IE and in the Extended Capability IE. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Lior Cohen authored
FW dump was missing in case the RT FW ucode section failed to load. This failure happens when the RT section of the FW file is corrupted. Signed-off-by:
-
Luca Coelho authored
We have to choose different configuration and different firmwares depending on the external RF module that is installed. Since the external module is not represented in the PCI IDs, we need to change the configuration at runtime, after checking the RF ID of the module installed. We have a bit of a mess in the code that does this, because it applies cfg's according to the RF ID only, ignoring the integrated module that is in use. Fix that for some devices by adding correct configurations for them and not ignoring the integrated module's type when making the decision. Signed-off-by: -
Emmanuel Grumbach authored
The firmware stopped looking at this field long ago. Signed-off-by:
-
Sara Sharon authored
Split the dump of RXF and TXF. This is in order to enable code reuse for INI, which may decide to dump only RXF and not TXF, and vice versa. Signed-off-by:
-
Sara Sharon authored
Currently opmode is limited to asking transport to either dump all the dumps configured at startup, or monitor only. Instead, pass to transport a bitmask, to allow flexibility. Signed-off-by:
-
- 15 Nov, 2018 1 commit
-
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2018-11-11' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next First set of iwlwifi patches for 4.21 * PCI IDs for some new 9000-series cards; * Improve antenna usage on connection problems; * Some improvements in the debugging code; * Other clean-ups and small fixes;
-
- 11 Nov, 2018 14 commits
-
-
Sara Sharon authored
Logic is there twice, and we'll need a third place soon for ini dumping. In addition move the dumping to a function, also to enable reuse. Signed-off-by:
-
Ihab Zhaika authored
add few PCI ID'S for 9560, 9462, 9461 and killer series. Cc: stable@vger.kernel.org Signed-off-by:
Ihab Zhaika <ihab.zhaika@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
chanwidths isn't used now in debugfs-vif.c. Remove it. Signed-off-by:
-
Sara Sharon authored
This enables to incorporate more logic in one place. Signed-off-by:
-
Andrei Otcheretianski authored
TDLS discovery response frame is a unicast direct frame to the peer. Since we don't have a STA for this peer, this frame goes through iwl_tx_skb_non_sta(). As the result aux_sta and some completely arbitrary queue would be selected for this frame, resulting in a queue hang. Fix that by sending such frames through AP sta instead. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
-
Naftali Goldstein authored
FW asserts 0x70, 0x71, and 0x73 all just mean that the real error happened in another MAC, and to look there for the problem. Add their descriptions to the assert number lookup table so users get a nicer error message in the logs. Also, since the 4 most-significant bits of the assert number are dynamic, and depend on which MAC the assert occurred on, ignore those bits when looking up the assert name. Signed-off-by:
Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by:
-
Sara Sharon authored
The trigger structure is being passed around, when all we care about is whether to dump only monitor or not. Pass a bool instead. Signed-off-by:
-
Sara Sharon authored
Currently code sets the write pointer when getting the TX queue allocate response. This causes a redundant interrupt with any actual change in the pointer. Remove this write altogether. Fixes: 310181ec ("iwlwifi: move to TVQM mode") Signed-off-by:
-
Avraham Stern authored
If tx fails during connection establishment, try another antenna for the next tx. This will increase the chance to establish connection if one of the antennas is blocked. Note that the antenna is toggled even when failing to tx data frames since connection establishment may use EAPOLs for 802.1X authentication/ 4 way handshake. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Naftali Goldstein authored
If the association supports HE, HT/VHT rates will never be used for Tx and therefore there's no need to set the sgi-per-channel-width-support bits, so don't set them in this case. Fixes: 110b32f0 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") Signed-off-by:
-
Avraham Stern authored
Switch the antenna used for management tx only if previous tx failed. If previous tx succeeded, there is no reason to switch antennas. Signed-off-by:
-
Tova Mussai authored
Enable low latency for softAP in all modes (standalone, SCM and DCM). This is in order to minimize the time the softAP leaves the channel for other operations Signed-off-by:
Tova Mussai <tova.mussai@intel.com> Signed-off-by:
-
Shahar S Matityahu authored
In D3 suspend flow in 9260 gen2 HW, the NIC receives two PERST signals. The first PERST is expected and indicates the device on coming resume flow. The second PERST causes FW restart FW restart. In order to avoid this issue, the FW set the persistence bit on. Once this bit is set, the FW ignores reset attempts. The problem is when the FW gets assert during D3 and then the persistence bit is set and causes the FW to ignore reset. To handle this issue, the FW opens the preg bit which allows access to the persistence bit, so that the driver clear the persistence bit and reset the NIC. The flow is as follows: the driver checks if the persistence bit is set. If the bit is set, the driver checks if he can clear the bit. If the driver can not clear the bit then there is no point to continue configuring the NIC since it will fail. The fix was added is in start HW flow instead of the resume flow since in general, if the persistence bit is set, the driver can not start the FW. So it is good to check it when we start configuring the NIC. The driver does not need to close the preg bit since the FW close it during the start flow. Signed-off-by:
-
Johannes Berg authored
All the queue management code runs under mvm->mutex, so there are only very few cases of accessing the data structures without it: * TX path, which doesn't take any locks anyway * iwl_mvm_wake_sw_queue() and iwl_mvm_stop_sw_queue() where we just (atomically) read a bitmap, so the lock isn't needed. Therefore, we can remove the spinlock. This enables some cleanup in the ugly locking in iwl_mvm_inactivity_check(). Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
