Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4 |
|
#
81d17f6f |
| 24-Oct-2022 |
Minsuk Kang <linuxlovemin@yonsei.ac.kr> |
wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()
This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device i
wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()
This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITS_PER_TYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.
Found by a modified version of syzkaller.
UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? process_one_work+0x13e0/0x13e0 kthread+0x379/0x450 ? _raw_spin_unlock_irq+0x24/0x30 ? set_kthread_struct+0x100/0x100 ret_from_fork+0x1f/0x30
Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr> Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr> Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221024071329.504277-1-linuxlovemin@yonsei.ac.kr
show more ...
|
Revision tags: v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69 |
|
#
687f767d |
| 16-Sep-2022 |
Hector Martin <marcan@marcan.st> |
wifi: brcmfmac: firmware: Allow platform to override macaddr
On Device Tree platforms, it is customary to be able to set the MAC address via the Device Tree, as it is often stored in system firmware
wifi: brcmfmac: firmware: Allow platform to override macaddr
On Device Tree platforms, it is customary to be able to set the MAC address via the Device Tree, as it is often stored in system firmware. This is particularly relevant for Apple ARM64 platforms, where this information comes from system configuration and passed through by the bootloader into the DT.
Implement support for this by fetching the platform MAC address and adding or replacing the macaddr= property in nvram. This becomes the dongle's default MAC address.
On platforms with an SROM MAC address, this overrides it. On platforms without one, such as Apple ARM64 devices, this is required for the firmware to boot (it will fail if it does not have a valid MAC at all).
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnx-0077ae-VK@rmk-PC.armlinux.org.uk
show more ...
|
#
7cb46e72 |
| 16-Sep-2022 |
Hector Martin <marcan@marcan.st> |
wifi: brcmfmac: firmware: Support passing in multiple board_types
Apple platforms have firmware and config files identified with multiple dimensions. We want to be able to find the most specific fir
wifi: brcmfmac: firmware: Support passing in multiple board_types
Apple platforms have firmware and config files identified with multiple dimensions. We want to be able to find the most specific firmware available for any given platform, progressively trying more general firmwares.
To do this, first add support for passing in multiple board_types, which will be tried in sequence.
Since this will cause more log spam due to missing firmwares, also switch the secondary firmware fecthes to use the _nowarn variant, which will not log if the firmware is not found.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnd-0077aG-Dk@rmk-PC.armlinux.org.uk
show more ...
|
#
e263d722 |
| 16-Sep-2022 |
Hector Martin <marcan@marcan.st> |
wifi: brcmfmac: firmware: Handle per-board clm_blob files
Teach brcm_alt_fw_paths to correctly split off variable length extensions, and enable alt firmware lookups for the CLM blob firmware request
wifi: brcmfmac: firmware: Handle per-board clm_blob files
Teach brcm_alt_fw_paths to correctly split off variable length extensions, and enable alt firmware lookups for the CLM blob firmware requests.
Apple platforms have per-board CLM blob files.
Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnT-0077a4-4k@rmk-PC.armlinux.org.uk
show more ...
|
Revision tags: v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64 |
|
#
bf99f11d |
| 30-Aug-2022 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
wifi: move from strlcpy with unused retval to strscpy
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by
wifi: move from strlcpy with unused retval to strscpy
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script.
Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220830201457.7984-2-wsa+renesas@sang-engineering.com
show more ...
|
Revision tags: v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49 |
|
#
98e152c1 |
| 17-Jun-2022 |
Ard Biesheuvel <ardb@kernel.org> |
brcmfmac: Switch to appropriate helper to load EFI variable contents
Avoid abusing the efivar layer by invoking it with locally constructed efivar_entry instances, and instead, just call the EFI rou
brcmfmac: Switch to appropriate helper to load EFI variable contents
Avoid abusing the efivar layer by invoking it with locally constructed efivar_entry instances, and instead, just call the EFI routines directly if available.
Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19 |
|
#
d19d8e3b |
| 31-Jan-2022 |
Hector Martin <marcan@marcan.st> |
brcmfmac: firmware: Allocate space for default boardrev in nvram
If boardrev is missing from the NVRAM we add a default one, but this might need more space in the output buffer than was allocated. E
brcmfmac: firmware: Allocate space for default boardrev in nvram
If boardrev is missing from the NVRAM we add a default one, but this might need more space in the output buffer than was allocated. Ensure we have enough padding for this in the buffer.
Fixes: 46f2b38a91b0 ("brcmfmac: insert default boardrev in nvram data if missing") Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: stable@vger.kernel.org Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220131160713.245637-3-marcan@marcan.st
show more ...
|
Revision tags: v5.15.18, v5.15.17, v5.4.173, v5.15.16 |
|
#
665408f4 |
| 18-Jan-2022 |
Phil Elwell <phil@raspberrypi.com> |
brcmfmac: firmware: Fix crash in brcm_alt_fw_path
The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected by a check to the validity of the fwctx->req->board_type pointer. This resul
brcmfmac: firmware: Fix crash in brcm_alt_fw_path
The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected by a check to the validity of the fwctx->req->board_type pointer. This results in a crash in strlcat when, for example, the WLAN chip is found in a USB dongle.
Prevent the crash by adding the necessary check.
See: https://github.com/raspberrypi/linux/issues/4833
Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220118154514.3245524-1-phil@raspberrypi.com
show more ...
|
#
6e2dfa82 |
| 31-Jan-2022 |
Hector Martin <marcan@marcan.st> |
brcmfmac: firmware: Allocate space for default boardrev in nvram
commit d19d8e3ba256f81ea4a27209dbbd1f0a00ef1903 upstream.
If boardrev is missing from the NVRAM we add a default one, but this might
brcmfmac: firmware: Allocate space for default boardrev in nvram
commit d19d8e3ba256f81ea4a27209dbbd1f0a00ef1903 upstream.
If boardrev is missing from the NVRAM we add a default one, but this might need more space in the output buffer than was allocated. Ensure we have enough padding for this in the buffer.
Fixes: 46f2b38a91b0 ("brcmfmac: insert default boardrev in nvram data if missing") Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: stable@vger.kernel.org Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220131160713.245637-3-marcan@marcan.st Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
c4caf72a |
| 18-Jan-2022 |
Phil Elwell <phil@raspberrypi.com> |
brcmfmac: firmware: Fix crash in brcm_alt_fw_path
commit 665408f4c3a5c83e712871daa062721624b2b79e upstream.
The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected by a check to the
brcmfmac: firmware: Fix crash in brcm_alt_fw_path
commit 665408f4c3a5c83e712871daa062721624b2b79e upstream.
The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected by a check to the validity of the fwctx->req->board_type pointer. This results in a crash in strlcat when, for example, the WLAN chip is found in a USB dongle.
Prevent the crash by adding the necessary check.
See: https://github.com/raspberrypi/linux/issues/4833
Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220118154514.3245524-1-phil@raspberrypi.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
c2dac3d2 |
| 08-Aug-2021 |
Linus Walleij <linus.walleij@linaro.org> |
brcmfmac: firmware: Fix firmware loading
The patch that would first try the board-specific firmware had a bug because the fallback would not be called: the asynchronous interface is used meaning req
brcmfmac: firmware: Fix firmware loading
The patch that would first try the board-specific firmware had a bug because the fallback would not be called: the asynchronous interface is used meaning request_firmware_nowait() returns 0 immediately.
Harden the firmware loading like this:
- If we cannot build an alt_path (like if no board_type is specified) just request the first firmware without any suffix, like in the past.
- If the lookup of a board specific firmware fails, we get a NULL fw in the async callback, so just try again without the alt_path from a dedicated brcm_fw_request_done_alt_path callback.
- Drop the unnecessary prototype of brcm_fw_request_done.
- Added MODULE_FIRMWARE match for per-board SDIO bins, making userspace tools to pull all the relevant firmware files.
Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") Cc: Stefan Hansson <newbyte@disroot.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210808180510.8753-1-digetx@gmail.com
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50 |
|
#
5ff01391 |
| 11-Jul-2021 |
Linus Walleij <linus.walleij@linaro.org> |
brcmfmac: firmware: Allow per-board firmware binaries
After some crashes in the 3D engine (!) on the Samsung GT-I8530 it turns out that the main firmware file can be device dependent, something that
brcmfmac: firmware: Allow per-board firmware binaries
After some crashes in the 3D engine (!) on the Samsung GT-I8530 it turns out that the main firmware file can be device dependent, something that was previously only handled for the NVRAM parameter file.
Rewrite the code a bit so we can a per-board suffixed firmware binary as well, if this does not exist we fall back to the canonical firmware name.
Example: a 4330 device with the OF board compatible is "samsung,gavini". We will first try "brcmfmac4330-sdio.samsung,gavini.bin" then "brcmfmac4330-sdio.bin" if that does not work.
Cc: phone-devel@vger.kernel.org Cc: newbyte@disroot.org Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210711231659.255479-1-linus.walleij@linaro.org
show more ...
|
Revision tags: v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
73c65541 |
| 22-Dec-2020 |
Zheng Yongjun <zhengyongjun3@huawei.com> |
brcmfmac: Delete useless kfree code
A null pointer will be passed to a kfree() call after a kzalloc() call failed. This code is useless. Thus delete the extra function call.
A goto statement is als
brcmfmac: Delete useless kfree code
A null pointer will be passed to a kfree() call after a kzalloc() call failed. This code is useless. Thus delete the extra function call.
A goto statement is also no longer needed. Thus adjust an if branch.
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201222135113.20680-1-zhengyongjun3@huawei.com
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60 |
|
#
866cf939 |
| 21-Aug-2020 |
Lee Jones <lee.jones@linaro.org> |
brcmfmac: firmware: Demote seemingly unintentional kernel-doc header
The function parameter is not documented and either are any of the other functions in this source file.
Fixes the following W=1
brcmfmac: firmware: Demote seemingly unintentional kernel-doc header
The function parameter is not documented and either are any of the other functions in this source file.
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:69: warning: Function parameter or member 'c' not described in 'is_nvram_char'
Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Cc: Wright Feng <wright.feng@cypress.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: brcm80211-dev-list@cypress.com Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200821071644.109970-13-lee.jones@linaro.org
show more ...
|
Revision tags: v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3 |
|
#
daeccac2 |
| 16-May-2019 |
Arend van Spriel <arend.vanspriel@broadcom.com> |
brcmfmac: switch source files to using SPDX license identifier
With ISC license text in place under the LICENSES folder switch to using the SPDX license identifier to refer to the ISC license.
Revi
brcmfmac: switch source files to using SPDX license identifier
With ISC license text in place under the LICENSES folder switch to using the SPDX license identifier to refer to the ISC license.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7 |
|
#
0cf83903 |
| 03-Apr-2019 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
brcmfmac: Use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for
brcmfmac: Use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example:
struct foo { int stuff; struct boo entry[]; };
size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL)
Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
Notice that, in this case, variable reqsz is not necessary, hence it is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26 |
|
#
c9692820 |
| 26-Feb-2019 |
Rafał Miłecki <rafal@milecki.pl> |
brcmfmac: support repeated brcmf_fw_alloc_request() calls
During a normal brcmfmac lifetime brcmf_fw_alloc_request() is called once only during the probe. It's safe to assume provided array is clear
brcmfmac: support repeated brcmf_fw_alloc_request() calls
During a normal brcmfmac lifetime brcmf_fw_alloc_request() is called once only during the probe. It's safe to assume provided array is clear.
Further brcmfmac improvements may require calling it multiple times though. This patch allows it by fixing invalid firmware paths like: brcm/brcmfmac4366c-pcie.binbrcm/brcmfmac4366c-pcie.bin
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.25, v4.19.24, v4.19.23, v4.19.22 |
|
#
a250c91c |
| 14-Feb-2019 |
Arend van Spriel <arend.vanspriel@broadcom.com> |
brcmfmac: use chipname in brcmf_fw_alloc_request() for error path as well
The local variable chipname is string representation of chip id and revision which is printed in the good flow of brcmf_fw_a
brcmfmac: use chipname in brcmf_fw_alloc_request() for error path as well
The local variable chipname is string representation of chip id and revision which is printed in the good flow of brcmf_fw_alloc_request(). Also use it for the error path, ie. for unknown/unsupported devices.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.21, v4.19.20, v4.19.19 |
|
#
2359dd09 |
| 29-Jan-2019 |
Matteo Croce <mcroce@redhat.com> |
brcmfmac: fix typos
Fix spelling mistakes in brcmfmac: "lenght" -> "length". The typos are also in the special comment blocks which translates to documentation.
Signed-off-by: Matteo Croce <mcroce@
brcmfmac: fix typos
Fix spelling mistakes in brcmfmac: "lenght" -> "length". The typos are also in the special comment blocks which translates to documentation.
Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9 |
|
#
412dd15c |
| 10-Dec-2018 |
Arnd Bergmann <arnd@arndb.de> |
brcmfmac: fix false-positive -Wmaybe-unintialized warning
When CONFIG_NO_AUTO_INLINE is set, we get a false-postive warning for the brcmf_fw_request_nvram_done() function, after gcc figures out that
brcmfmac: fix false-positive -Wmaybe-unintialized warning
When CONFIG_NO_AUTO_INLINE is set, we get a false-postive warning for the brcmf_fw_request_nvram_done() function, after gcc figures out that brcmf_fw_nvram_from_efi() might not set the 'data_len' variable, but fails to notice that it always returns NULL:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function 'brcmf_fw_request_nvram_done': drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:560:11: error: 'data_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Mark it 'inline' to force gcc to understand this.
Fixes: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
Revision tags: v4.19.8, v4.19.7, v4.19.6, v4.19.5 |
|
#
b72c51a5 |
| 24-Nov-2018 |
Lyude Paul <lyude@redhat.com> |
brcmfmac: Fix out of bounds memory access during fw load
I ended up tracking down some rather nasty issues with f2fs (and other filesystem modules) constantly crashing on my kernel down to a combina
brcmfmac: Fix out of bounds memory access during fw load
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: 2baa3aaee27f ("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>
show more ...
|
Revision tags: v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14 |
|
#
29ec3394 |
| 11-Oct-2018 |
Hans de Goede <hdegoede@redhat.com> |
brcmfmac: Fix ccode from EFI nvram when necessary
In some cases the EFI-var stored nvram contains "ccode=ALL" or "ccode=XV" to specify "worldwide" compatible settings, but these 2 ccode-s do not wor
brcmfmac: Fix ccode from EFI nvram when necessary
In some cases the EFI-var stored nvram contains "ccode=ALL" or "ccode=XV" to specify "worldwide" compatible settings, but these 2 ccode-s do not work properly.
I've tested the different known "worldwide" ccode-s used in various nvram sources with the latest firmwares from linux-firmware for various brcmfmac models, here is a simplified (*) table with what each setting results in:
ALL: 12-14 disab, U-NII-1, U-NII-2 no-IR/radar, U-NII-3 XV: 12-14 no-IR, disables all 5G channels XY: 12-13 enab, 14 disab, U-NII-1 enab, U-NII-2 no-IR/radar, U-NII-3 disab X2: 12-13 no-IR, 14 dis, U-NII-1 no-IR, U-NII-2 no-IR/radar, U-NII-3 no-IR
Where 12,13,14 are 2.4G channels 12-14 and U-NII-1/2/3 are the 3 different 5G channel groups. no-IR is no-Initiate-Radiation, we will never send on these channels without first having received valid wifi traffic there.
This immediately shows that both ALL and XV are not as worldwide as we want them to be. ALL causes channels 12 and 13 to not be available and XV causes all 5GHz channels to not be available. Also ALL unconditionally enables the U-NII-1 and U-NII-3 5G groups, while we really should be using no-IR for these.
This commit replace XV and ALL with X2, which allows usage of chan 12-13 and 5G channels, but only after receiving valid wifi traffic there first.
Note that this configure the firmware's channel limits, the kernels own regulatory restrictions based on e.g. regulatory info received from the access-point, will be applied on top of this.
This fixes channels 12+13 not working on the Asus T200TA and the Lenovo Mixx 2 8 and 5G channels not working on the Asus T100HA.
This has been tested on the following models: Acer Iconia Tab8 w1-810, Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a Lenovo Mixx 2 8.
*) There are some exceptions to this table: 1) On really old firmware e.g. linux-firmware's 2011 brcmfmac4330-sdio.bin ALL really means all, unconditionally enabling everything 2) The exact meaning might be influenced by setting the regrev nvram var. Specifically using ccode=XV + regrev=1 on brcmfmac43241b4 leads to: 12-14 no-ir, U-NII-1 no-ir, U-NII-2 no-ir/radar, U-NII-3 no-ir But only on the brcmfmac43241b4 and not on e.g. the brcmfmac43340
Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
#
ce2e6db5 |
| 11-Oct-2018 |
Hans de Goede <hdegoede@redhat.com> |
brcmfmac: Add support for getting nvram contents from EFI variables
Various X86 laptops with a SDIO attached brcmfmac wifi chip, store the nvram contents in a special EFI variable. This commit adds
brcmfmac: Add support for getting nvram contents from EFI variables
Various X86 laptops with a SDIO attached brcmfmac wifi chip, store the nvram contents in a special EFI variable. This commit adds support for getting nvram directly from this EFI variable, without the user needing to manually copy it.
This makes Wifi / Bluetooth work out of the box on these devices instead of requiring manual setup.
This has been tested on the following models: Acer Iconia Tab8 w1-810, Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a Lenovo Mixx 2 8.
Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
#
55e491ed |
| 10-Oct-2018 |
Hans de Goede <hdegoede@redhat.com> |
brcmfmac: Cleanup brcmf_fw_request_done()
The "cur" variable is now only used for a debug print and we already print the same info from brcmf_fw_complete_request(), so the debug print does not provi
brcmfmac: Cleanup brcmf_fw_request_done()
The "cur" variable is now only used for a debug print and we already print the same info from brcmf_fw_complete_request(), so the debug print does not provide any extra info and we can remove it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|
#
eae8e506 |
| 10-Oct-2018 |
Hans de Goede <hdegoede@redhat.com> |
brcmfmac: Add support for first trying to get a board specific nvram file
The nvram files which some brcmfmac chips need are board-specific. To be able to distribute these as part of linux-firmware,
brcmfmac: Add support for first trying to get a board specific nvram file
The nvram files which some brcmfmac chips need are board-specific. To be able to distribute these as part of linux-firmware, so that devices with such a wifi chip will work OOTB, multiple (one per board) versions must co-exist under /lib/firmware.
This commit adds support for callers of the brcmfmac/firmware.c code to pass in a board_type parameter through the request structure.
If that parameter is set then the code will first try to load chipmodel.board_type.txt before falling back to the old chipmodel.txt name.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
show more ...
|