- 30 Nov, 2018 16 commits
-
-
Lorenzo Bianconi authored
Add submit_urb and rx_urb static tracepoints in mt76-usb module. Move trace_mac_txstat_fetch in mt76x02_mac_load_tx_status routine in order to be available to usb drivers. Moreover remove no longer used mt76x0/trace.{c,h} Signed-off-by:Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Some RF registers need different values for various chips. For at least mt76x0_rf_central_tab registers, overwriting them later does not work, as the wrong values can cause the entire system to hang on some devices with MT7610E Signed-off-by: -
Felix Fietkau authored
Make previously exported functions static where possible Acked-by:
-
Stanislaw Gruszka authored
Driver works better for MT7630 without MCU calibration, which looks like it can hangs the firmware. Vendor driver do not perform it for MT7630 as well. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Lorenzo Bianconi authored
Align phy calibration logic between mt76x0u and mt76x0e drivers This patch improves connection stability with low SNR Signed-off-by:
-
Lorenzo Bianconi authored
Add mac workqueue support to mt76x2u driver in order to compute device statistics and add mac stuck routine Signed-off-by:
-
Lorenzo Bianconi authored
Use mt76x02_mac_work utility routine as stats workqueue handler and remove duplicated code. Moreover run mac stuck check in mt76x02_mac_work for client interfaces. Remove no longer used avg_ampdu_len and mt76x02_mac_stats data structure in mt76x02_dev Signed-off-by:
-
Lorenzo Bianconi authored
Use mt76x02 debugfs implementation and remove duplicated code Signed-off-by:
-
Lorenzo Bianconi authored
Move mt76x02_debugfs in mt76x02-lib module in order to be reused by mt76x0 driver and remove duplicated code Signed-off-by:
-
Lorenzo Bianconi authored
Move mt76x02_mac_work routine in mt76x02_mac.c in order to be reused by mt76x0 driver to read device statistics Signed-off-by:
-
Lorenzo Bianconi authored
Move mt76x02_update_channel routine in mt76x02-lib module in order to be reused by mt76x0 driver adding get_survey support Signed-off-by:
-
Lorenzo Bianconi authored
Improve initvals_phy.h code readability (there are no actual changes of original values) Signed-off-by:
-
Lorenzo Bianconi authored
Simplify mt76x0_phy_vco_cal and mt76x0_phy_set_chan_rf_params routines using mt76x0_rf_wr, mt76x0_rf_set and mt76x0_rf_clear helper routines. Moreover over get rid of magic numbers Signed-off-by:
-
Lorenzo Bianconi authored
Use mt76x0_phy as prefix for routines in mt76x0/phy.c Moreover use mt76x0_rf_set to enable vco calibration in mt76x0_phy_vco_cal Signed-off-by:
-
Lorenzo Bianconi authored
Update vga tuning algorithm to the one used in mt76x2 driver Signed-off-by:
-
Lorenzo Bianconi authored
Unify firmware version used on mt76x2e and mt76x2u drivers Signed-off-by:
-
- 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:
-
