summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
AgeCommit message (Collapse)Author
2025-05-09wifi: brcmfmac: support per-vendor cfg80211 callbacks and firmware eventsArend van Spriel
Adding two vendor operations that can be used to provide per-vendor cfg80211 callbacks and per-vendor handlers for firmware events. These two are often related to handling interactions from user-space through nl80211. Exporting brcmf_fweh_register() for registering the per-vendor event handler callbacks. Some other exports for get event name string and allowing use of brcmf_dbg() in per-vendor module. Tested-by: James Prestwood <prestwoj@gmail.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250425085519.492267-2-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-02wifi: brcmfmac: fix memory leak in brcmf_get_module_paramAbdun Nihaal
The memory allocated for settings is not freed when brcmf_of_probe fails. Fix that by freeing settings before returning in error path. Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable support") Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250330103425.44197-1-abdun.nihaal@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-11-11wifi: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/net/wireless to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. En passant several whitespace changes are done to make indentation consistent in the struct initializers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241106170706.38922-2-u.kleine-koenig@baylibre.com
2024-09-18wifi: brcmfmac: Add optional lpo clock enable supportJacobe Zang
WiFi modules often require 32kHz clock to function. Add support to enable the clock to PCIe driver and move "brcm,bcm4329-fmac" check to the top of brcmf_of_probe. Change function prototypes from void to int and add appropriate errno's for return values that will be send to bus when error occurred. Co-developed-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Ondrej Jirman <megi@xff.cz> Co-developed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Reviewed-by: Sai Krishna <saikrishnag@marvell.com> Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> # On RK3588 EVB1 Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240910-wireless-mainline-v14-3-9d80fea5326d@wesion.com
2024-01-19wifi: brcmfmac: allow per-vendor event handlingArend van Spriel
The firmware interface also defines events generated by firmware on the device. As the get/set primitives the events are likely to diverge between the vendors so this commit adds support for per-vendor handling. The number of events may differ so we let the vendor-specific code allocate the struct brcmf_fweh_info which contains array of event handlers. The existing event enumeration will be used by the higher layers and thus are common definitions. The vendor-specific code can provide a mapping table for converting the common definition to the vendor-specific firmware event definition and vice-versa. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240106103835.269149-4-arend.vanspriel@broadcom.com
2023-11-30wifi: brcmfmac: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231117093056.873834-13-u.kleine-koenig@pengutronix.de
2023-02-27wifi: brcmfmac: common: Add support for external calibration blobsHector Martin
The calibration blob for a chip is normally stored in SROM and loaded internally by the firmware. However, Apple ARM64 platforms instead store it as part of platform configuration data, and provide it via the Apple Device Tree. We forward this into the Linux DT in the bootloader. Add support for taking this blob from the DT and loading it into the dongle. The loading mechanism is the same as used for the CLM and TxCap blobs. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230214092423.15175-10-marcan@marcan.st
2023-02-27wifi: brcmfmac: common: Add support for downloading TxCap blobsHector Martin
The TxCap blobs are additional data blobs used on Apple devices, and are uploaded analogously to CLM blobs. Add core support for doing this. 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> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230214092423.15175-8-marcan@marcan.st
2023-02-27wifi: brcmfmac: acpi: Add support for fetching Apple ACPI propertiesHector Martin
On DT platforms, the module-instance and antenna-sku-info properties are passed in the DT. On ACPI platforms, module-instance is passed via the analogous Apple device property mechanism, while the antenna SKU info is instead obtained via an ACPI method that grabs it from non-volatile storage. Add support for this, to allow proper firmware selection on Apple platforms. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230214080034.3828-2-marcan@marcan.st
2023-01-16wifi: brcmfmac: ensure CLM version is null-terminated to prevent ↵Jisoo Jang
stack-out-of-bounds Fix a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with a CLM version string by memcpy() in brcmf_fil_iovar_data_get(). Ensure buf is null-terminated. Found by a modified version of syzkaller. [ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22 [ 33.021554][ T1896] ================================================================== [ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110 [ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896 [ 33.023852][ T1896] [ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 [ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event [ 33.026581][ T1896] Call Trace: [ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d [ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334 [ 33.028037][ T1896] ? strreplace+0xf2/0x110 [ 33.028403][ T1896] ? strreplace+0xf2/0x110 [ 33.028807][ T1896] kasan_report.cold+0x83/0xdf [ 33.029283][ T1896] ? strreplace+0xf2/0x110 [ 33.029666][ T1896] strreplace+0xf2/0x110 [ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40 [ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0 [ 33.032091][ T1896] ? find_held_lock+0x2d/0x110 [ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260 [ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 33.033582][ T1896] brcmf_attach+0x246/0xd40 [ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50 [ 33.034383][ T1896] ? kmemdup+0x30/0x40 [ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690 [ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 33.035833][ T1896] usb_probe_interface+0x25f/0x710 [ 33.036315][ T1896] really_probe+0x1be/0xa90 [ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0 [ 33.037383][ T1896] driver_probe_device+0x49/0x120 [ 33.037790][ T1896] __device_attach_driver+0x18a/0x250 [ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120 [ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0 [ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20 [ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120 [ 33.042330][ T1896] __device_attach+0x207/0x330 [ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0 [ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0 [ 33.043515][ T1896] bus_probe_device+0x1a2/0x260 [ 33.043914][ T1896] device_add+0xa61/0x1ce0 [ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660 [ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550 [ 33.045531][ T1896] usb_set_configuration+0x984/0x1770 [ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230 [ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90 [ 33.046931][ T1896] usb_probe_device+0x9c/0x220 [ 33.047434][ T1896] really_probe+0x1be/0xa90 [ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.048134][ T1896] driver_probe_device+0x49/0x120 [ 33.048516][ T1896] __device_attach_driver+0x18a/0x250 [ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120 [ 33.049437][ T1896] bus_for_each_drv+0x123/0x1a0 [ 33.049814][ T1896] ? bus_rescan_devices+0x20/0x20 [ 33.050164][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 33.050579][ T1896] ? trace_hardirqs_on+0x1c/0x120 [ 33.050936][ T1896] __device_attach+0x207/0x330 [ 33.051399][ T1896] ? device_bind_driver+0xb0/0xb0 [ 33.051888][ T1896] ? kobject_uevent_env+0x230/0x12c0 [ 33.052314][ T1896] bus_probe_device+0x1a2/0x260 [ 33.052688][ T1896] device_add+0xa61/0x1ce0 [ 33.053121][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550 [ 33.053568][ T1896] usb_new_device.cold+0x463/0xf66 [ 33.053953][ T1896] ? hub_disconnect+0x400/0x400 [ 33.054313][ T1896] ? rwlock_bug.part.0+0x90/0x90 [ 33.054661][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 33.055094][ T1896] hub_event+0x10d5/0x3330 [ 33.055530][ T1896] ? hub_port_debounce+0x280/0x280 [ 33.055934][ T1896] ? __lock_acquire+0x1671/0x5790 [ 33.056387][ T1896] ? wq_calc_node_cpumask+0x170/0x2a0 [ 33.056924][ T1896] ? lock_release+0x640/0x640 [ 33.057383][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 33.057916][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 33.058402][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 33.059019][ T1896] process_one_work+0x873/0x13e0 [ 33.059488][ T1896] ? lock_release+0x640/0x640 [ 33.059932][ T1896] ? pwq_dec_nr_in_flight+0x320/0x320 [ 33.060446][ T1896] ? rwlock_bug.part.0+0x90/0x90 [ 33.060898][ T1896] worker_thread+0x8b/0xd10 [ 33.061348][ T1896] ? __kthread_parkme+0xd9/0x1d0 [ 33.061810][ T1896] ? process_one_work+0x13e0/0x13e0 [ 33.062288][ T1896] kthread+0x379/0x450 [ 33.062660][ T1896] ? _raw_spin_unlock_irq+0x24/0x30 [ 33.063148][ T1896] ? set_kthread_struct+0x100/0x100 [ 33.063606][ T1896] ret_from_fork+0x1f/0x30 [ 33.064070][ T1896] [ 33.064313][ T1896] [ 33.064545][ T1896] addr ffffc90001d6efc8 is located in stack of task kworker/0:2/1896 at offset 512 in frame: [ 33.065478][ T1896] brcmf_c_preinit_dcmds+0x0/0xc40 [ 33.065973][ T1896] [ 33.066191][ T1896] this frame has 4 objects: [ 33.066614][ T1896] [48, 56) 'ptr' [ 33.066618][ T1896] [80, 148) 'revinfo' [ 33.066957][ T1896] [192, 210) 'eventmask' [ 33.067338][ T1896] [256, 512) 'buf' [ 33.067742][ T1896] [ 33.068304][ T1896] Memory state around the buggy address: [ 33.068838][ T1896] ffffc90001d6ee80: f2 00 00 02 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 [ 33.069545][ T1896] ffffc90001d6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.070626][ T1896] >ffffc90001d6ef80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 33.072052][ T1896] ^ [ 33.073043][ T1896] ffffc90001d6f000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.074230][ T1896] ffffc90001d6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.074914][ T1896] ================================================================== [ 33.075713][ T1896] Disabling lock debugging due to kernel taint Reviewed-by: Arend van Spriel<arend.vanspriel@broadcom.com> Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221230075139.56591-1-jisoo.jang@yonsei.ac.kr
2022-12-22wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()Jisoo Jang
This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [ 47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.633002][ T1897] ? usb_generic_driver_match+0x75/0x90 [ 47.633573][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.634170][ T1897] driver_probe_device+0x4e/0x150 [ 47.634703][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.635248][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.635748][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.636271][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.636881][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.637396][ T1897] __device_attach+0x23f/0x3a0 [ 47.637904][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.638426][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.638985][ T1897] bus_probe_device+0x1da/0x290 [ 47.639512][ T1897] device_add+0xb7b/0x1eb0 [ 47.639977][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.640612][ T1897] ? kfree+0x14a/0x6b0 [ 47.641055][ T1897] ? __usb_get_extra_descriptor+0x116/0x160 [ 47.641679][ T1897] usb_new_device.cold+0x49c/0x1029 [ 47.642245][ T1897] ? hub_disconnect+0x450/0x450 [ 47.642756][ T1897] ? rwlock_bug.part.0+0x90/0x90 [ 47.643273][ T1897] ? _raw_spin_unlock_irq+0x24/0x30 [ 47.643822][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.644445][ T1897] hub_event+0x1c98/0x3950 [ 47.644939][ T1897] ? hub_port_debounce+0x2e0/0x2e0 [ 47.645467][ T1897] ? check_irq_usage+0x861/0xf20 [ 47.645975][ T1897] ? drain_workqueue+0x280/0x360 [ 47.646506][ T1897] ? lock_release+0x640/0x640 [ 47.646994][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.647572][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.648111][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.648735][ T1897] process_one_work+0x92b/0x1460 [ 47.649262][ T1897] ? pwq_dec_nr_in_flight+0x330/0x330 [ 47.649816][ T1897] ? rwlock_bug.part.0+0x90/0x90 [ 47.650336][ T1897] worker_thread+0x95/0xe00 [ 47.650830][ T1897] ? __kthread_parkme+0x115/0x1e0 [ 47.651361][ T1897] ? process_one_work+0x1460/0x1460 [ 47.651904][ T1897] kthread+0x3a1/0x480 [ 47.652329][ T1897] ? set_kthread_struct+0x120/0x120 [ 47.652878][ T1897] ret_from_fork+0x1f/0x30 [ 47.653370][ T1897] [ 47.653608][ T1897] [ 47.653848][ T1897] addr ffffc90001f6f000 is located in stack of task kworker/0:2/1897 at offset 512 in frame: [ 47.654891][ T1897] brcmf_c_preinit_dcmds+0x0/0xc40 [ 47.655442][ T1897] [ 47.655690][ T1897] this frame has 4 objects: [ 47.656151][ T1897] [48, 56) 'ptr' [ 47.656159][ T1897] [80, 148) 'revinfo' [ 47.656534][ T1897] [192, 210) 'eventmask' [ 47.656953][ T1897] [256, 512) 'buf' [ 47.657410][ T1897] [ 47.658035][ T1897] Memory state around the buggy address: [ 47.658743][ T1897] ffffc90001f6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 47.659577][ T1897] ffffc90001f6ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 47.660394][ T1897] >ffffc90001f6f000: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 [ 47.661199][ T1897] ^ [ 47.661625][ T1897] ffffc90001f6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 47.662455][ T1897] ffffc90001f6f100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 [ 47.663318][ T1897] ================================================================== [ 47.664147][ T1897] Disabling lock debugging due to kernel taint 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: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221115043458.37562-1-jisoo.jang@yonsei.ac.kr
2022-11-22wifi: brcmfmac: Use struct_size() in code ralated to struct brcmf_dload_data_leGustavo A. R. Silva
Prefer struct_size() over open-coded versions of idiom: sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count where count is the max number of items the flexible array is supposed to contain. In this particular case, in the open-coded version sizeof(typeof-flex-array-elements) is implicit in _count_ because the type of the flex array data is u8: drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h:941: 941 struct brcmf_dload_data_le { 942 __le16 flag; 943 __le16 dload_type; 944 __le32 len; 945 __le32 crc; 946 u8 data[]; 947 }; Link: https://github.com/KSPP/linux/issues/160 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/41845ad3660ed4375f0c03fd36a67b2e12fafed5.1668548907.git.gustavoars@kernel.org
2022-11-22wifi: brcmfmac: replace one-element array with flexible-array member in ↵Gustavo A. R. Silva
struct brcmf_dload_data_le One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct brcmf_dload_data_le. Important to mention is that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/230 Link: https://github.com/KSPP/linux/issues/79 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/905f5b68cf93c812360d081caae5b15221db09b6.1668548907.git.gustavoars@kernel.org
2022-11-04wifi: brcmfmac: Fix potential NULL pointer dereference in ↵Jisoo Jang
'brcmf_c_preinit_dcmds()' This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when ptr which is NULL pointer passed as an argument of strlcpy() in brcmf_c_preinit_dcmds(). This happens when the driver passes a firmware version string that does not contain a space " ", making strrchr() return a null pointer. This patch adds a null pointer check. Found by a modified version of syzkaller. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 1983 Comm: kworker/0:2 Not tainted 5.14.0+ #79 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 RIP: 0010:strlen+0x1a/0x90 Code: 23 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 48 b8 00 00 00 00 00 fc ff df 48 89 fa 55 48 89 fd 48 c1 ea 03 53 48 83 ec 08 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 04 84 c0 75 48 80 7d 00 00 RSP: 0018:ffffc90002bfedd8 EFLAGS: 00010296 RAX: dffffc0000000000 RBX: 1ffff9200057fdc1 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000020 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000039 R09: ffffed1023549801 R10: ffff88811aa4c007 R11: ffffed1023549800 R12: ffff88800bc68d6c R13: ffffc90002bfef08 R14: ffff88800bc6bc7c R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020546180 CR3: 0000000117ff1000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: brcmf_c_preinit_dcmds+0x9f2/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+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1703/0x1dd0 ? kmemdup+0x43/0x50 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x2aa/0x760 ? usb_probe_device+0x250/0x250 really_probe+0x205/0xb70 ? driver_allows_async_probing+0x130/0x130 __driver_probe_device+0x311/0x4b0 ? driver_allows_async_probing+0x130/0x130 driver_probe_device+0x4e/0x150 __device_attach_driver+0x1cc/0x2a0 bus_for_each_drv+0x156/0x1d0 ? bus_rescan_devices+0x30/0x30 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x46/0x160 __device_attach+0x23f/0x3a0 ? device_bind_driver+0xd0/0xd0 ? kobject_uevent_env+0x287/0x14b0 bus_probe_device+0x1da/0x290 device_add+0xb7b/0x1eb0 ? wait_for_completion+0x290/0x290 ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 usb_set_configuration+0xf59/0x16f0 usb_generic_driver_probe+0x82/0xa0 usb_probe_device+0xbb/0x250 ? usb_suspend+0x590/0x590 really_probe+0x205/0xb70 ? driver_allows_async_probing+0x130/0x130 __driver_probe_device+0x311/0x4b0 ? usb_generic_driver_match+0x75/0x90 ? driver_allows_async_probing+0x130/0x130 driver_probe_device+0x4e/0x150 __device_attach_driver+0x1cc/0x2a0 bus_for_each_drv+0x156/0x1d0 ? bus_rescan_devices+0x30/0x30 ? _raw_spin_unlock_irqrestore+0x47/0x50 __device_attach+0x23f/0x3a0 ? device_bind_driver+0xd0/0xd0 ? kobject_uevent_env+0x287/0x14b0 bus_probe_device+0x1da/0x290 device_add+0xb7b/0x1eb0 ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 ? kfree+0x14a/0x6b0 ? __usb_get_extra_descriptor+0x116/0x160 usb_new_device.cold+0x49c/0x1029 ? hub_disconnect+0x450/0x450 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_unlock_irq+0x24/0x30 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 hub_event+0x248b/0x31c9 ? usb_port_suspend.cold+0x139/0x139 ? check_irq_usage+0x861/0xf20 ? drain_workqueue+0x280/0x360 ? 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+0x92b/0x1460 ? pwq_dec_nr_in_flight+0x330/0x330 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x95/0xe00 ? __kthread_parkme+0x115/0x1e0 ? process_one_work+0x1460/0x1460 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30 Modulesdd linked in: ---[ end trace c112c68924ddd800 ]--- RIP: 0010:strlen+0x1a/0x90 Code: 23 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 90 48 b8 00 00 00 00 00 fc ff df 48 89 fa 55 48 89 fd 48 c1 ea 03 53 48 83 ec 08 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 04 84 c0 75 48 80 7d 00 00 RSP: 0018:ffffc90002bfedd8 EFLAGS: 00010296 RAX: dffffc0000000000 RBX: 1ffff9200057fdc1 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000020 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000039 R09: ffffed1023549801 R10: ffff88811aa4c007 R11: ffffed1023549800 R12: ffff88800bc68d6c R13: ffffc90002bfef08 R14: ffff88800bc6bc7c R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020546180 CR3: 0000000117ff1000 CR4: 0000000000750ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled 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: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221101183642.166450-1-jisoo.jang@yonsei.ac.kr
2022-09-19wifi: brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanismHector Martin
Now that the firmware fetcher can handle per-board CLM files, load the CLM blob alongside the other firmware files and change the bus API to just return the existing blob, instead of fetching the filename. This enables per-board CLM blobs, which are required on Apple platforms. 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/E1oZDnY-0077aA-8f@rmk-PC.armlinux.org.uk
2022-09-02wifi: move from strlcpy with unused retval to strscpyWolfram Sang
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
2022-07-28wifi: brcmfmac: Replace default (not configured) MAC with a random MACHans de Goede
On some boards there is no eeprom to hold the nvram, in this case instead a board specific nvram is loaded from /lib/firmware. On most boards the macaddr=... setting in the /lib/firmware nvram file is ignored because the wifi/bt chip has a unique MAC programmed into the chip itself. But in some cases the actual MAC from the /lib/firmware nvram file gets used, leading to MAC conflicts. The MAC addresses in the troublesome nvram files seem to all come from the same nvram file template, so we can detect this by checking for the template nvram file MAC. Detect that the default MAC address is being used and replace it with a random MAC address to avoid MAC address conflicts. Note that udev will detect this is a random MAC based on /sys/class/net/wlan0/addr_assign_type and then replace this with a MAC based on hashing the netdev-name + the machine-id. So that the MAC address is both guaranteed to be unique per machine while it is still the same/persistent at each boot (assuming the default Link.MACAddressPolicy=persistent udev setting). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220708133712.102179-2-hdegoede@redhat.com
2022-07-28wifi: brcmfmac: Add brcmf_c_set_cur_etheraddr() helperHans de Goede
Add a little helper to send "cur_etheraddr" commands to the interface and to handle the error reporting of it in a single place. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Arend van Spriel <aspriel@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220708133712.102179-1-hdegoede@redhat.com
2022-05-11brcmfmac: allow setting wlan MAC address using device treePavel Löbl
This allows firmware to provide MAC address using device tree. Like in case there is no MAC burned in wlan NVRAM. Signed-off-by: Pavel Löbl <pavel@loebl.cz> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220506044246.67146-1-pavel@loebl.cz
2020-07-14brcmfmac: fix invalid permanent MAC address in wiphyWright Feng
When host driver retrieves mac addresses from dongle, driver copies memory from drvr->mac to perm_addr. But at the moment, drvr->mac is all zero array which causes permanent MAC address in wiphy is all zero as well. To fix this, we set drvr->mac before setting perm_addr. Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200604071835.3842-3-wright.feng@cypress.com
2019-07-24brcmfmac: remove unnecessary strlcpy() upon obtaining "ver" iovarArend van Spriel
Recently a strcpy() was replaced by strlcpy(). However, the strcpy() was not needed in the first place. So removing that line of code. 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>
2019-05-28brcmfmac: use strlcpy() instead of strcpy()Neo Jou
The function strcpy() is inherently not safe. Though the function works without problems here, it would be better to use other safer function, e.g. strlcpy(), to replace strcpy() still. Signed-off-by: Neo Jou <neojou@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-05-28brcmfmac: switch source files to using SPDX license identifierArend van Spriel
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>
2019-02-20brcmfmac: use bphy_err() in all wiphy-related codeRafał Miłecki
This recently added macro provides more meaningful error messages thanks to identifying a specific wiphy. It's especially important on systems with few cards supported by the same (brcmfmac) driver. 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>
2019-02-08brcmfmac: modify __brcmf_err() to take bus as a parameterRafał Miłecki
So far __brcmf_err() was using pr_err() which didn't allow identifying device that was affected by an error. It's crucial for systems with more than 1 device supported by brcmfmac (a common case for home routers). This change allows passing struct brcmf_bus to the __brcmf_err(). That struct has been agreed to be the most common one. It allows accessing struct device easily & using dev_err() printing helper. 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>
2019-01-10brcmfmac: Use firmware_request_nowarn for the clm_blobHans de Goede
The linux-firmware brcmfmac firmware files contain an embedded table with per country allowed channels and strength info. For recent hardware these versions of the firmware are specially build for linux-firmware, the firmware files directly available from Cypress rely on a separate clm_blob file for this info. For some unknown reason Cypress refuses to provide the standard firmware files + clm_blob files it uses elsewhere for inclusion into linux-firmware, instead relying on these special builds with the clm_blob info embedded. This means that the linux-firmware firmware versions often lag behind, but I digress. The brcmfmac driver does support the separate clm_blob file and always tries to load this. Currently we use request_firmware for this. This means that on any standard install, using the standard combo of linux-kernel + linux-firmware, we will get a warning: "Direct firmware load for ... failed with error -2" On top of this, brcmfmac itself prints: "no clm_blob available (err=-2), device may have limited channels available". This commit switches to firmware_request_nowarn, fixing almost any brcmfmac device logging the warning (it leaves the brcmfmac info message in place). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29brcmfmac: Call brcmf_dmi_probe before brcmf_of_probeHans de Goede
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: bd1e82bb420a ("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: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: fix spelling mistake "Retreiving" -> "Retrieving"Colin Ian King
Trivial fix to spelling mistake in brcmf_err error message. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06brcmfmac: Set board_type from DMI on x86 based machinesHans de Goede
For x86 based machines, set the board_type used for nvram file selection based on the DMI sys-vendor and product-name strings. Since on some models these strings are too generic, this commit also adds a quirk table overriding the strings for models listed in that table. The board_type setting is used to load the board-specific nvram file with a board-specific name so that we can ship files for each supported board in linux-firmware. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-31brcmfmac: fix wrong strnchr usageRasmus Villemoes
strnchr takes arguments in the order of its name: string, max bytes to read, character to search for. Here we're passing '\n' aka 10 as the buffer size, and searching for sizeof(buf) aka BRCMF_DCMD_SMLEN aka 256 (aka '\0', since it's implicitly converted to char) within those 10 bytes. Just interchanging the last two arguments would still leave a bug, because if we've been successful once, there are not sizeof(buf) characters left after the new value of p. Since clmver is immediately afterwards passed as a %s argument, I assume that it is actually a properly nul-terminated string. For that case, we have strreplace(). Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-23brcmfmac: move ALLFFMAC variable in flowring moduleArend Van Spriel
The only user of ALLFFMAC is the flowring module so no need to expose it in a header file. 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>
2018-03-28Merge git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.gitKalle Valo
Requested by Luca, needed for upcoming patch "iwlwifi: add a bunch of new 9000 PCI IDs".
2018-03-27brcmfmac: add extension to .get_fwname() callbacksArend Van Spriel
This changes the bus layer api by having the caller provide an extension. With this the callback can use brcmf_fw_alloc_request() to get the needed firmware name. 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>
2018-03-27brcmfmac: use wiphy debugfs dir entryArend Van Spriel
The driver used to create a brcmfmac dir entry at the top level debugfs mount point. This moves the debugfs entries into the wiphy debugfs dir entry. 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>
2018-03-27brcmfmac: allocate struct brcmf_pub instance using wiphy_new()Arend Van Spriel
Rework the driver so the wiphy instance holds the main driver information in its private buffer. Previously it held struct brcmf_cfg80211_info instance so a bit of reorg was needed. This was done so that the wiphy name or its parent device can be shown in debug output. 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>
2018-03-27brcmfmac: use brcmf_chip_name() to store name in revinfoArend Van Spriel
The chip id can either be four or five digits. For the chip name either the hexadecimal value needs to be taken (four digits) or the decimal value (five digits). The function brcmf_chip_name() does this conversion so use it to store the name in driver revision info. 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>
2018-03-27wireless: Use octal not symbolic permissionsJoe Perches
Prefer the direct use of octal for permissions. Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace and some typing. Miscellanea: o Whitespace neatening around these conversions. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-16brcmfmac: drop Inter-Access Point Protocol packets by defaultRafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging resulted in discovering support for IAPP in Broadcom's firmwares. Older firmwares were only generating 802.11f frames. Newer ones like: 1) 10.10 (TOB) (r663589) 2) 10.10.122.20 (r683106) for 4366b1 and 4366c0 respectively seem to also /respect/ 802.11f frames in the Tx path by performing a STA disassociation. This obsoleted standard and its implementation is something that: 1) Most people don't need / want to use 2) Can allow local DoS attacks 3) Breaks AP interfaces in some specific bridge setups To solve issues it can cause this commit modifies brcmfmac to drop IAPP packets. If affects: 1) Rx path: driver won't be sending these unwanted packets up. 2) Tx path: driver will reject packets that would trigger STA disassociation perfromed by a firmware (possible local DoS attack). It appears there are some Broadcom's clients/users who care about this feature despite the drawbacks. They can switch it on using a new module param. This change results in only two more comparisons (check for module param and check for Ethernet packet length) for 99.9% of packets. Its overhead should be very minimal. 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>
2018-02-27brcmfmac: move brcmf_bus_preinit() call just after changing bus stateArend Van Spriel
Moving the brcmf_bus_preinit() call allows the bus code to do some required initialization before handling firmware control messages. 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>
2018-01-16brcmfmac: fix CLM load error for legacy chips when user helper is enabledWright Feng
For legacy chips without CLM blob files, kernel with user helper function returns -EAGAIN when we request_firmware(), and then driver got failed when bringing up legacy chips. We expect the CLM blob file for legacy chip is not existence in firmware path, but the -ENOENT error is transferred to -EAGAIN in firmware_class.c with user helper. Because of that, we continue with CLM data currently present in firmware if getting error from doing request_firmware(). Cc: stable@vger.kernel.org # v4.15.y Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-11-11brcmfmac: add CLM download supportChung-Hsien Hsu
The firmware for brcmfmac devices includes information regarding regulatory constraints. For certain devices this information is kept separately in a binary form that needs to be downloaded to the device. This patch adds support to download this so-called CLM blob file. It uses the same naming scheme as the other firmware files with extension of .clm_blob. The CLM blob file is optional. If the file does not exist, the download process will be bypassed. It will not affect the driver loading. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-03-20brcmfmac: Do not print the firmware version as an errorHans de Goede
Using pr_err for things which are not errors is a bad idea. E.g. it will cause the plymouth bootsplash screen to drop back to the text console so that the user can see the error, which is not what we normally want to happen. Instead add a new brcmf_info macro and use that. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-02-08brcmfmac: switch to C function (__brcmf_err) for printing errorsRafał Miłecki
This will allow extending code and using more detailed messages e.g. with the help of dev_err. 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>
2017-01-20brcmfmac: rename brcmf_bus_start function to brcmf_bus_startedRafał Miłecki
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>
2017-01-19brcmfmac: make brcmf_of_probe more genericRafał Miłecki
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>
2016-04-26brcmfmac: add support for nl80211 BSS_SELECT featureArend van Spriel
Announce support for nl80211 feature BSS_SELECT and process BSS selection behaviour provided in .connect() callback. Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Lei Zhang <leizh@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-03-07brcmfmac: merge platform data and module paramatersHante Meuleman
Merge module parameters and platform data in one struct. This is the last step to move to the new platform data per device. Now parameters of platform data will be merged with module parameters per device. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-03-07brcmfmac: switch to new platform dataHante Meuleman
Platform data is only available for sdio. With this patch a new platform data structure is being used which allows for platform data for any device and configurable per device. This patch only switches to the new structure and adds support for SDIO devices. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-03-07brcmfmac: move platform data retrieval code to commonHante Meuleman
In preparation of module parameters for all devices the module platform data retrieval is moved from sdio to common. It is still only used for sdio devices. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-03-07brcmfmac: move module init and exit to commonHante Meuleman
In preparation of module parameters for all devices the module init and exit routines are moved to the common file. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit (git 2.34.1) at 2025-07-25 16:19:25 +0000