summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/broadcom/brcm80211
Commit message (Collapse)AuthorAgeFilesLines
* brcmfmac: print firmware messages after a firmware crashRafał Miłecki2019-05-011-6/+18
| | | | | | | | | | | | | | Normally firmware messages are printed with debugging enabled only. It's a good idea as firmware may print a lot of messages that normal users don't need to care about. However, on firmware crash, it may be very helpful to log all recent messages. There is almost always a backtrace available as well as rought info on the latest actions/state. 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>
* brcmfmac: set txflow request id from 1 to pktids array sizeWright Feng2019-05-011-3/+3
| | | | | | | | | | | | | | Some PCIE firmwares drop txstatus if pktid is 0 and make packet held in host side and never be released. If that packet type is 802.1x, the pend_8021x_cnt value will be always greater than 0 and show "Timed out waiting for no pending 802.1x packets" error message when sending key to dongle every time. To be compatible with all firmwares, host should set txflow request id from 1 instead of from 0. Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler()Dan Carpenter2019-05-011-2/+3
| | | | | | | | | | | | | | | | | | | | If "ret_len" is negative then it could lead to a NULL dereference. The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative then we don't allocate the "dcmd_buf" buffer. Then we pass "ret_len" to brcmf_fil_cmd_data_set() where it is cast to a very high u32 value. Most of the functions in that call tree check whether the buffer we pass is NULL but there are at least a couple places which don't such as brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd(). We memcpy() to and from the buffer so it would result in a NULL dereference. The fix is to change the types so that "ret_len" can't be negative. (If we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an issue). Fixes: 1bacb0487d0e ("brcmfmac: replace cfg80211 testmode with vendor command") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: send mailbox interrupt twice for specific hardware deviceWright Feng2019-04-261-1/+6
| | | | | | | | | For PCIE wireless device with core revision less than 14, device may miss PCIE to System Backplane Interrupt via PCIEtoSBMailbox. So add sending mail box interrupt twice as a hardware workaround. Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* Revert "brcmfmac: send mailbox interrupt twice for specific hardware device"Kalle Valo2019-04-251-5/+1Star
| | | | | | | | This reverts commit 99d94ef367af67f630b38c93ff46c5819b7d06b6. I accidentally applied this broken (failed to compile) patch due to a bug in my patchwork script. Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: send mailbox interrupt twice for specific hardware deviceWright Feng2019-04-251-1/+5
| | | | | | | | | | For PCIE wireless device with core revision less than 14, device may miss PCIE to System Backplane Interrupt via PCIEtoSBMailbox. So add sending mail box interrupt twice as a hardware workaround. Signed-off-by: Wright Feng <wright.feng@cypress.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCsHans de Goede2019-04-251-0/+26
| | | | | | | | | | | | | | | | | | | | | The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which is way too generic. The DMI strings on which we are matching are somewhat generic too, but "To be filled by O.E.M." is less common then "Default string" and the system-sku and bios-version strings are pretty unique. Beside the DMI strings we also check the wifi-module chip-id and revision. I'm confident that the combination of all this is unique. Both the T8 and T11 use the same wifi-module, this commit adds DMI quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt . BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: fix leak of mypkt on error return pathColin Ian King2019-04-131-5/+3Star
| | | | | | | | | | | | | | Currently if the call to brcmf_sdiod_set_backplane_window fails then error return path leaks mypkt. Fix this by returning by a new error path labelled 'out' that calls brcmu_pkt_buf_free_skb to free mypkt. Also remove redundant check on err before calling brcmf_sdiod_skbuff_write. Addresses-Coverity: ("Resource Leak") Fixes: a7c3aa1509e2 ("brcmfmac: Remove brcmf_sdiod_addrprep()") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: Loading the correct firmware for brcm43456Ondrej Jirman2019-04-131-1/+3
| | | | | | | | | SDIO based brcm43456 is currently misdetected as brcm43455 and the wrong firmware name is used. Correct the detection and load the correct firmware file. Chiprev for brcm43456 is "9". Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: Use struct_size() in kzalloc()Gustavo A. R. Silva2019-04-131-3/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* brcmfmac: fix missing checks for kmemdupKangjie Lu2019-04-041-0/+4
| | | | | | | | | In case kmemdup fails, the fix sets conn_info->req_ie_len and conn_info->resp_ie_len to zero to avoid buffer overflows. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: convert dev_init_lock mutex to completionPiotr Figiel2019-04-041-9/+8Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leaving dev_init_lock mutex locked in probe causes BUG and a WARNING when kernel is compiled with CONFIG_PROVE_LOCKING. Convert mutex to completion which silences those warnings and improves code readability. Fix below errors when connecting the USB WiFi dongle: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43143 for chip BCM43143/2 BUG: workqueue leaked lock or atomic: kworker/0:2/0x00000000/434 last function: hub_event 1 lock held by kworker/0:2/434: #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac] CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: usb_hub_wq hub_event [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14) [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4) [<809c4324>] (dump_stack) from [<8014195c>] (process_one_work+0x710/0x808) [<8014195c>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564) [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c) [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20) Exception stack(0xed1d9fb0 to 0xed1d9ff8) 9fa0: 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ====================================================== WARNING: possible circular locking dependency detected 4.19.23-00084-g454a789-dirty #123 Not tainted ------------------------------------------------------ kworker/0:2/434 is trying to acquire lock: e29cf799 ((wq_completion)"events"){+.+.}, at: process_one_work+0x174/0x808 but task is already holding lock: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devinfo->dev_init_lock){+.+.}: mutex_lock_nested+0x1c/0x24 brcmf_usb_probe+0x78/0x550 [brcmfmac] usb_probe_interface+0xc0/0x1bc really_probe+0x228/0x2c0 __driver_attach+0xe4/0xe8 bus_for_each_dev+0x68/0xb4 bus_add_driver+0x19c/0x214 driver_register+0x78/0x110 usb_register_driver+0x84/0x148 process_one_work+0x228/0x808 worker_thread+0x2c/0x564 kthread+0x13c/0x16c ret_from_fork+0x14/0x20 (null) -> #1 (brcmf_driver_work){+.+.}: worker_thread+0x2c/0x564 kthread+0x13c/0x16c ret_from_fork+0x14/0x20 (null) -> #0 ((wq_completion)"events"){+.+.}: process_one_work+0x1b8/0x808 worker_thread+0x2c/0x564 kthread+0x13c/0x16c ret_from_fork+0x14/0x20 (null) other info that might help us debug this: Chain exists of: (wq_completion)"events" --> brcmf_driver_work --> &devinfo->dev_init_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devinfo->dev_init_lock); lock(brcmf_driver_work); lock(&devinfo->dev_init_lock); lock((wq_completion)"events"); *** DEADLOCK *** 1 lock held by kworker/0:2/434: #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac] stack backtrace: CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: events request_firmware_work_func [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14) [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4) [<809c4324>] (dump_stack) from [<80172838>] (print_circular_bug+0x210/0x330) [<80172838>] (print_circular_bug) from [<80175940>] (__lock_acquire+0x160c/0x1a30) [<80175940>] (__lock_acquire) from [<8017671c>] (lock_acquire+0xe0/0x268) [<8017671c>] (lock_acquire) from [<80141404>] (process_one_work+0x1b8/0x808) [<80141404>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564) [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c) [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20) Exception stack(0xed1d9fb0 to 0xed1d9ff8) 9fa0: 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: fix Oops when bringing up interface during USB disconnectPiotr Figiel2019-04-041-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a race which leads to an Oops with NULL pointer dereference. The dereference is in brcmf_config_dongle() when cfg_to_ndev() attempts to get net_device structure of interface with index 0 via if2bss mapping. This shouldn't fail because of check for bus being ready in brcmf_netdev_open(), but it's not synchronised with USB disconnect and there is a race: after the check the bus can be marked down and the mapping for interface 0 may be gone. Solve this by modifying disconnect handling so that the removal of mapping of ifidx to brcmf_if structure happens after netdev removal (which is synchronous with brcmf_netdev_open() thanks to rtln being locked in devinet_ioctl()). This assures brcmf_netdev_open() returns before the mapping is removed during disconnect. Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = bcae2612 [00000008] *pgd=8be73831 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: brcmfmac brcmutil nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether usb_serial_simple usbserial cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc usbmisc_imx ulpi 8250_exar 8250_pci 8250 8250_base libcomposite configfs udc_core [last unloaded: brcmutil] CPU: 2 PID: 24478 Comm: ifconfig Not tainted 4.19.23-00078-ga62866d-dirty #115 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) PC is at brcmf_cfg80211_up+0x94/0x29c [brcmfmac] LR is at brcmf_cfg80211_up+0x8c/0x29c [brcmfmac] pc : [<7f26a91c>] lr : [<7f26a914>] psr: a0070013 sp : eca99d28 ip : 00000000 fp : ee9c6c00 r10: 00000036 r9 : 00000000 r8 : ece4002c r7 : edb5b800 r6 : 00000000 r5 : 80f08448 r4 : edb5b968 r3 : ffffffff r2 : 00000000 r1 : 00000002 r0 : 00000000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 7ca0c04a DAC: 00000051 Process ifconfig (pid: 24478, stack limit = 0xd9e85a0e) Stack: (0xeca99d28 to 0xeca9a000) 9d20: 00000000 80f873b0 0000000d 80f08448 eca99d68 50d45f32 9d40: 7f27de94 ece40000 80f08448 80f08448 7f27de94 ece4002c 00000000 00000036 9d60: ee9c6c00 7f27262c 00001002 50d45f32 ece40000 00000000 80f08448 80772008 9d80: 00000001 00001043 00001002 ece40000 00000000 50d45f32 ece40000 00000001 9da0: 80f08448 00001043 00001002 807723d0 00000000 50d45f32 80f08448 eca99e58 9dc0: 80f87113 50d45f32 80f08448 ece40000 ece40138 00001002 80f08448 00000000 9de0: 00000000 80772434 edbd5380 eca99e58 edbd5380 80f08448 ee9c6c0c 80805f70 9e00: 00000000 ede08e00 00008914 ece40000 00000014 ee9c6c0c 600c0013 00001043 9e20: 0208a8c0 ffffffff 00000000 50d45f32 eca98000 80f08448 7ee9fc38 00008914 9e40: 80f68e40 00000051 eca98000 00000036 00000003 80808b9c 6e616c77 00000030 9e60: 00000000 00000000 00001043 0208a8c0 ffffffff 00000000 80f08448 00000000 9e80: 00000000 816d8b20 600c0013 00000001 ede09320 801763d4 00000000 50d45f32 9ea0: eca98000 80f08448 7ee9fc38 50d45f32 00008914 80f08448 7ee9fc38 80f68e40 9ec0: ed531540 8074721c 00000800 00000001 00000000 6e616c77 00000030 00000000 9ee0: 00000000 00001002 0208a8c0 ffffffff 00000000 50d45f32 80f08448 7ee9fc38 9f00: ed531560 ec8fc900 80285a6c 80285138 edb910c0 00000000 ecd91008 ede08e00 9f20: 80f08448 00000000 00000000 816d8b20 600c0013 00000001 ede09320 801763d4 9f40: 00000000 50d45f32 00021000 edb91118 edb910c0 80f08448 01b29000 edb91118 9f60: eca99f7c 50d45f32 00021000 ec8fc900 00000003 ec8fc900 00008914 7ee9fc38 9f80: eca98000 00000036 00000003 80285a6c 00086364 7ee9fe1c 000000c3 00000036 9fa0: 801011c4 80101000 00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364 9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003 9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc 600c0010 00000003 00000000 00000000 [<7f26a91c>] (brcmf_cfg80211_up [brcmfmac]) from [<7f27262c>] (brcmf_netdev_open+0x74/0xe8 [brcmfmac]) [<7f27262c>] (brcmf_netdev_open [brcmfmac]) from [<80772008>] (__dev_open+0xcc/0x150) [<80772008>] (__dev_open) from [<807723d0>] (__dev_change_flags+0x168/0x1b4) [<807723d0>] (__dev_change_flags) from [<80772434>] (dev_change_flags+0x18/0x48) [<80772434>] (dev_change_flags) from [<80805f70>] (devinet_ioctl+0x67c/0x79c) [<80805f70>] (devinet_ioctl) from [<80808b9c>] (inet_ioctl+0x210/0x3d4) [<80808b9c>] (inet_ioctl) from [<8074721c>] (sock_ioctl+0x350/0x524) [<8074721c>] (sock_ioctl) from [<80285138>] (do_vfs_ioctl+0xb0/0x9b0) [<80285138>] (do_vfs_ioctl) from [<80285a6c>] (ksys_ioctl+0x34/0x5c) [<80285a6c>] (ksys_ioctl) from [<80101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xeca99fa8 to 0xeca99ff0) 9fa0: 00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364 9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003 9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc Code: e5970328 eb002021 e1a02006 e3a01002 (e5909008) ---[ end trace 5cbac2333f3ac5df ]--- Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: remove unused variable i from brcmf_usb_free_qPiotr Figiel2019-04-041-2/+0Star
| | | | | | | Variable i is not used so remove it. Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: remove pending parameter from brcmf_usb_free_qPiotr Figiel2019-04-041-9/+6Star
| | | | | | | | brcmf_usb_free_q is no longer called with pending=true thus this boolean parameter is no longer needed. Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: fix race during disconnect when USB completion is in progressPiotr Figiel2019-04-041-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was observed that rarely during USB disconnect happening shortly after connect (before full initialization completes) usb_hub_wq would wait forever for the dev_init_lock to be unlocked. dev_init_lock would remain locked though because of infinite wait during usb_kill_urb: [ 2730.656472] kworker/0:2 D 0 260 2 0x00000000 [ 2730.660700] Workqueue: events request_firmware_work_func [ 2730.664807] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac) [ 2730.670587] [<809dd164>] (schedule) from [<8069af44>] (usb_kill_urb+0xdc/0x114) [ 2730.676815] [<8069af44>] (usb_kill_urb) from [<7f258b50>] (brcmf_usb_free_q+0x34/0xa8 [brcmfmac]) [ 2730.684833] [<7f258b50>] (brcmf_usb_free_q [brcmfmac]) from [<7f2517d4>] (brcmf_detach+0xa0/0xb8 [brcmfmac]) [ 2730.693557] [<7f2517d4>] (brcmf_detach [brcmfmac]) from [<7f251a34>] (brcmf_attach+0xac/0x3d8 [brcmfmac]) [ 2730.702094] [<7f251a34>] (brcmf_attach [brcmfmac]) from [<7f2587ac>] (brcmf_usb_probe_phase2+0x468/0x4a0 [brcmfmac]) [ 2730.711601] [<7f2587ac>] (brcmf_usb_probe_phase2 [brcmfmac]) from [<7f252888>] (brcmf_fw_request_done+0x194/0x220 [brcmfmac]) [ 2730.721795] [<7f252888>] (brcmf_fw_request_done [brcmfmac]) from [<805748e4>] (request_firmware_work_func+0x4c/0x88) [ 2730.731125] [<805748e4>] (request_firmware_work_func) from [<80141474>] (process_one_work+0x228/0x808) [ 2730.739223] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564) [ 2730.746105] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c) [ 2730.752227] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20) [ 2733.099695] kworker/0:3 D 0 1065 2 0x00000000 [ 2733.103926] Workqueue: usb_hub_wq hub_event [ 2733.106914] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac) [ 2733.112693] [<809dd164>] (schedule) from [<809e2a8c>] (schedule_timeout+0x214/0x3e4) [ 2733.119621] [<809e2a8c>] (schedule_timeout) from [<809dde2c>] (wait_for_common+0xc4/0x1c0) [ 2733.126810] [<809dde2c>] (wait_for_common) from [<7f258d00>] (brcmf_usb_disconnect+0x1c/0x4c [brcmfmac]) [ 2733.135206] [<7f258d00>] (brcmf_usb_disconnect [brcmfmac]) from [<8069e0c8>] (usb_unbind_interface+0x5c/0x1e4) [ 2733.143943] [<8069e0c8>] (usb_unbind_interface) from [<8056d3e8>] (device_release_driver_internal+0x164/0x1fc) [ 2733.152769] [<8056d3e8>] (device_release_driver_internal) from [<8056c078>] (bus_remove_device+0xd0/0xfc) [ 2733.161138] [<8056c078>] (bus_remove_device) from [<8056977c>] (device_del+0x11c/0x310) [ 2733.167939] [<8056977c>] (device_del) from [<8069cba8>] (usb_disable_device+0xa0/0x1cc) [ 2733.174743] [<8069cba8>] (usb_disable_device) from [<8069507c>] (usb_disconnect+0x74/0x1dc) [ 2733.181823] [<8069507c>] (usb_disconnect) from [<80695e88>] (hub_event+0x478/0xf88) [ 2733.188278] [<80695e88>] (hub_event) from [<80141474>] (process_one_work+0x228/0x808) [ 2733.194905] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564) [ 2733.201724] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c) [ 2733.207913] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20) It was traced down to a case where usb_kill_urb would be called on an URB structure containing more or less random data, including large number in its use_count. During the debugging it appeared that in brcmf_usb_free_q() the traversal over URBs' lists is not synchronized with operations on those lists in brcmf_usb_rx_complete() leading to handling brcmf_usbdev_info structure (holding lists' head) as lists' element and in result causing above problem. Fix it by walking through all URBs during brcmf_cancel_all_urbs using the arrays of requests instead of linked lists. Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: fix NULL pointer derefence during USB disconnectPiotr Figiel2019-04-047-13/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case USB disconnect happens at the moment transmitting workqueue is in progress the underlying interface may be gone causing a NULL pointer dereference. Add synchronization of the workqueue destruction with the detach implementation in core so that the transmitting workqueue is stopped during detach before the interfaces are removed. Fix following Oops: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = 9e6a802d [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether usb_serial_simple usbserial cdc_acm brcmfmac brcmutil smsc95xx usbnet ci_hdrc_imx ci_hdrc ulpi usbmisc_imx 8250_exar 8250_pci 8250 8250_base libcomposite configfs udc_core CPU: 0 PID: 7 Comm: kworker/u8:0 Not tainted 4.19.23-00076-g03740aa-dirty #102 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: brcmf_fws_wq brcmf_fws_dequeue_worker [brcmfmac] PC is at brcmf_txfinalize+0x34/0x90 [brcmfmac] LR is at brcmf_fws_dequeue_worker+0x218/0x33c [brcmfmac] pc : [<7f0dee64>] lr : [<7f0e4140>] psr: 60010093 sp : ee8abef0 ip : 00000000 fp : edf38000 r10: ffffffed r9 : edf38970 r8 : edf38004 r7 : edf3e970 r6 : 00000000 r5 : ede69000 r4 : 00000000 r3 : 00000a97 r2 : 00000000 r1 : 0000888e r0 : ede69000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 7d03c04a DAC: 00000051 Process kworker/u8:0 (pid: 7, stack limit = 0x24ec3e04) Stack: (0xee8abef0 to 0xee8ac000) bee0: ede69000 00000000 ed56c3e0 7f0e4140 bf00: 00000001 00000000 edf38004 edf3e99c ed56c3e0 80d03d00 edfea43a edf3e970 bf20: ee809880 ee804200 ee971100 00000000 edf3e974 00000000 ee804200 80135a70 bf40: 80d03d00 ee804218 ee809880 ee809894 ee804200 80d03d00 ee804218 ee8aa000 bf60: 00000088 80135d5c 00000000 ee829f00 ee829dc0 00000000 ee809880 80135d30 bf80: ee829f1c ee873eac 00000000 8013b1a0 ee829dc0 8013b07c 00000000 00000000 bfa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000 bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<7f0dee64>] (brcmf_txfinalize [brcmfmac]) from [<7f0e4140>] (brcmf_fws_dequeue_worker+0x218/0x33c [brcmfmac]) [<7f0e4140>] (brcmf_fws_dequeue_worker [brcmfmac]) from [<80135a70>] (process_one_work+0x138/0x3f8) [<80135a70>] (process_one_work) from [<80135d5c>] (worker_thread+0x2c/0x554) [<80135d5c>] (worker_thread) from [<8013b1a0>] (kthread+0x124/0x154) [<8013b1a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c) Exception stack(0xee8abfb0 to 0xee8abff8) bfa0: 00000000 00000000 00000000 00000000 bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e1530001 0a000007 e3560000 e1a00005 (05942008) ---[ end trace 079239dd31c86e90 ]--- Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: fix WARNING during USB disconnect in case of unempty psqPiotr Figiel2019-04-041-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | brcmu_pkt_buf_free_skb emits WARNING when attempting to free a sk_buff which is part of any queue. After USB disconnect this may have happened when brcmf_fws_hanger_cleanup() is called as per-interface psq was never cleaned when removing the interface. Change brcmf_fws_macdesc_cleanup() in a way that it removes the corresponding packets from hanger table (to avoid double-free when brcmf_fws_hanger_cleanup() is called) and add a call to clean-up the interface specific packet queue. Below is a WARNING during USB disconnect with Raspberry Pi WiFi dongle running in AP mode. This was reproducible when the interface was transmitting during the disconnect and is fixed with this commit. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1171 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x3c/0x40 Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc ulpi usbmisc_imx 8250_exar 8250_pci 8250 8250_base libcomposite configfs udc_core CPU: 0 PID: 1171 Comm: kworker/0:0 Not tainted 4.19.23-00075-gde33ed8 #99 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: usb_hub_wq hub_event [<8010ff84>] (unwind_backtrace) from [<8010bb64>] (show_stack+0x10/0x14) [<8010bb64>] (show_stack) from [<80840278>] (dump_stack+0x88/0x9c) [<80840278>] (dump_stack) from [<8011f5ec>] (__warn+0xfc/0x114) [<8011f5ec>] (__warn) from [<8011f71c>] (warn_slowpath_null+0x40/0x48) [<8011f71c>] (warn_slowpath_null) from [<805a476c>] (brcmu_pkt_buf_free_skb+0x3c/0x40) [<805a476c>] (brcmu_pkt_buf_free_skb) from [<805bb6c4>] (brcmf_fws_cleanup+0x1e4/0x22c) [<805bb6c4>] (brcmf_fws_cleanup) from [<805bc854>] (brcmf_fws_del_interface+0x58/0x68) [<805bc854>] (brcmf_fws_del_interface) from [<805b66ac>] (brcmf_remove_interface+0x40/0x150) [<805b66ac>] (brcmf_remove_interface) from [<805b6870>] (brcmf_detach+0x6c/0xb0) [<805b6870>] (brcmf_detach) from [<805bdbb8>] (brcmf_usb_disconnect+0x30/0x4c) [<805bdbb8>] (brcmf_usb_disconnect) from [<805e5d64>] (usb_unbind_interface+0x5c/0x1e0) [<805e5d64>] (usb_unbind_interface) from [<804aab10>] (device_release_driver_internal+0x154/0x1ec) [<804aab10>] (device_release_driver_internal) from [<804a97f4>] (bus_remove_device+0xcc/0xf8) [<804a97f4>] (bus_remove_device) from [<804a6fc0>] (device_del+0x118/0x308) [<804a6fc0>] (device_del) from [<805e488c>] (usb_disable_device+0xa0/0x1c8) [<805e488c>] (usb_disable_device) from [<805dcf98>] (usb_disconnect+0x70/0x1d8) [<805dcf98>] (usb_disconnect) from [<805ddd84>] (hub_event+0x464/0xf50) [<805ddd84>] (hub_event) from [<80135a70>] (process_one_work+0x138/0x3f8) [<80135a70>] (process_one_work) from [<80135d5c>] (worker_thread+0x2c/0x554) [<80135d5c>] (worker_thread) from [<8013b1a0>] (kthread+0x124/0x154) [<8013b1a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c) Exception stack(0xecf8dfb0 to 0xecf8dff8) dfa0: 00000000 00000000 00000000 00000000 dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace 38d234018e9e2a90 ]--- ------------[ cut here ]------------ Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: reset PCIe bus on a firmware crashRafał Miłecki2019-04-044-0/+59
| | | | | | | | | | | This includes bus reset & reloading a firmware. It should be sufficient for a user space to (setup and) use a wireless device again. Support for reset on USB & SDIO can be added later. 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>
* brcmfmac: add a function designated for handling firmware failsRafał Miłecki2019-04-044-3/+15
| | | | | | | | | | | | This improves handling PCIe firmware halts by printing a clear error message and replaces a similar code in the SDIO bus support. It will also allow further improvements like trying to recover from a firmware crash. 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>
* brcmfmac: support repeated brcmf_fw_alloc_request() callsRafał Miłecki2019-04-041-0/+1
| | | | | | | | | | | | | 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>
* brcmfmac: print firmware reported general status errorsRafał Miłecki2019-02-281-0/+24
| | | | | | | | | | | | | Firmware may report general errors using a special message type. Add basic support for it by simply decoding & printing an error number. A sample situation in which firmware reports a buf error: CONSOLE: 027084.733 no host response IOCTL buffer available..so fail the request will now produce a "Firmware reported general error: 9" on the host. 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>
* brcmfmac: fix size of the struct msgbuf_ring_statusRafał Miłecki2019-02-281-1/+1
| | | | | | | | | This updates host struct to match the in-firmawre definition. It's a cosmetic change as it only applies to the reserved struct space. Fixes: c988b78244df ("brcmfmac: print firmware reported ring status errors") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: add basic validation of shared RAM addressRafał Miłecki2019-02-201-0/+6
| | | | | | | | | | | | | | While experimenting with firmware loading I ended up in a state of firmware reporting shared RAM address 0x04000001. It was causing: [ 94.448015] Unable to handle kernel paging request at virtual address cd680001 due to reading out of the mapped memory. This patch adds some basic validation to avoid kernel crashes due to the unexpected firmware behavior. 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>
* brcmfmac: use bphy_err() in all wiphy-related codeRafał Miłecki2019-02-2011-173/+224
| | | | | | | | | | 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>
* brcmfmac: remove set but not used variable 'old_state'YueHaibing2019-02-191-2/+0Star
| | | | | | | | | | | | | | Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_state_change': drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:578:6: warning: variable 'old_state' set but not used [-Wunused-but-set-variable] It's never used and can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: rework bphy_err() to take struct brcmf_pub argumentRafał Miłecki2019-02-192-233/+281
| | | | | | | | | | | | | | | | | This macro will be used in more places not just the cfg80211.c. It makes sense to pass some common struct to it as "struct wiphy" is mostly referenced in cfg80211 code only. A very common one (used above the bus abstraction layer) is struct brcmf_pub. Many functions already keep reference to it which will make using bphy_err() simpler. It should also allow extending that macro's logic if it's ever needed. This improves code recently added in the commit 3ef005b82e2a ("brcmfmac: add bphy_err() and use it in the cfg80211.c"). Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: support firmware reporting 160 MHz channelsRafał Miłecki2019-02-191-0/+3
| | | | | | | | | So far 160 MHz channels were treated as 20 MHz ones which was breaking support for 40/80 MHz due to the brcmf_construct_chaninfo() logic and its assumptions. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: improve code handling bandwidth of firmware reported channelsRafał Miłecki2019-02-191-3/+10
| | | | | | | | 1) Use switch to simplify/improve the code & avoid some duplication 2) Add warning for unsupported values Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: print firmware reported ring status errorsRafał Miłecki2019-02-191-0/+25
| | | | | | | | | | Firmware is capable of reporting ring status. It's used e.g. to signal some problem with a specific ring setup. This patch adds support for printing ring & error number which may be useful for debugging setup issues. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: use chipname in brcmf_fw_alloc_request() for error path as wellArend van Spriel2019-02-191-3/+3
| | | | | | | | | | | | 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>
* brcmfmac: check and dump trap info during sdio probeArend van Spriel2019-02-191-19/+40
| | | | | | | | | | | | When the firmware crashes during the probe sequence we provide little information on what really failed. This patch checks the sdpcm shared location and show the trap information if a firmware trap has happened. 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>
* brcmfmac: disable MBSS feature for bcm4330 deviceArend van Spriel2019-02-191-2/+8
| | | | | | | | | | | | | | | The MBSS feature was already disabled for bcm43362 as it resulted in a beacon with BRCM_TEST_SSID regardless user configuration in hostapd. Now the same has been reported for bcm4330 so disable the feature for this device as well. Reported-by: Russell King <linux@armlinux.org.uk> Tested-by: Christopher Martin <chrsmrtn@gmail.com> 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>
* brcmfmac: create debugfs files for bus-specific layerArend van Spriel2019-02-193-5/+18
| | | | | | | | | | | | | | Since we moved the drivers debugfs directory under ieee80211 debugfs the debugfs entries need to be added after wiphy_register() has been called. For most part that has been done accordingly, but for the debugfs entries added by SDIO it was not and failed silently. This patch fixes that by adding a bus-layer callback for it. Fixes: 856d5a011c86 ("brcmfmac: allocate struct brcmf_pub instance using wiphy_new()") Reported-by: Russel King <linux@armlinux.org.uk> 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>
* brcmfmac: add subtype check for event handling in data pathArend van Spriel2019-02-193-7/+16
| | | | | | | | | | | | | | For USB there is no separate channel being used to pass events from firmware to the host driver and as such are passed over the data path. In order to detect mock event messages an additional check is needed on event subtype. This check is added conditionally using unlikely() keyword. 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>
* brcmfmac: assure SSID length from firmware is limitedArend van Spriel2019-02-191-0/+2
| | | | | | | | | | | The SSID length as received from firmware should not exceed IEEE80211_MAX_SSID_LEN as that would result in heap overflow. 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>
* brcmfmac: support monitor frames with the hardware/ucode headerRafał Miłecki2019-02-083-1/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | So far there were two monitor frame formats: 1) 802.11 frames (with frame (sub)type & all addresses) 2) 802.11 frames with the radiotap header Testing the latest FullMAC firmwares for 4366b1/4366c0 resulted in discovering a new format being used. It seems (almost?) identical to the one known from ucode used in SoftMAC devices which is most likely the same codebase anyway. While new firmwares will /announce/ radiotap header support using the "rtap" fw capability string it seems no string was added for the new ucode header format. All above means that: 1) We need new format support when dealing with a received frame 2) A new feature bit & mapping quirks have to be added manually As for now only an empty radiotap is being created. Adding support for extracting some info (band, channel, signal, etc.) is planned for the future. 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>
* brcmfmac: fix typosMatteo Croce2019-02-084-4/+4
| | | | | | | | | 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>
* brcmfmac: add bphy_err() and use it in the cfg80211.cRafał Miłecki2019-02-082-224/+282
| | | | | | | | | This new macro uses wiphy_err() which: 1) Should be the best choice with wiphy already created 2) Uses dev_err() which allows identifying error-affected device Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: pass bus to the __brcmf_err() in pcie.cRafał Miłecki2019-02-082-23/+38
| | | | | | | | | | | This enables dev_err() usage (instead of pr_err()) in the __brcmf_err(). It makes error messages more meaningful and is important for debugging errors/bugs on systems with multiple brcmfmac supported devices. All bus files should follow & get updated similarly (soon). Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
* brcmfmac: modify __brcmf_err() to take bus as a parameterRafał Miłecki2019-02-083-7/+17
| | | | | | | | | | | | | | 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>
* Merge tag 'wireless-drivers-next-for-davem-2019-02-06' of ↵David S. Miller2019-02-0611-45/+40Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.1 First set of patches for 5.1. Lots of new features in various drivers but nothing really special standing out. Major changes: brcmfmac * DMI nvram filename quirk for PoV TAB-P1006W-232 tablet rsi * support for hardware scan offload iwlwifi * support for Target Wakeup Time (TWT) -- a feature that allows the AP to specify when individual stations can access the medium * support for mac80211 AMSDU handling * some new PCI IDs * relicense the pcie submodule to dual GPL/BSD * reworked the TOF/CSI (channel estimation matrix) implementation * Some product name updates in the human-readable strings mt76 * energy detect regulatory compliance fixes * preparation for MT7603 support * channel switch announcement support mwifiex * support for sd8977 chipset qtnfmac * support for 4addr mode * convert to SPDX license identifiers ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * wireless: prefix header search paths with $(srctree)/Masahiro Yamada2019-02-013-8/+6Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf5bc6 ("kbuild: do not drop -I without parameter"). I also removed one header search path in: drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile I was able to compile without it. [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * brcmsmac: no need to check return value of debugfs_create functionsGreg Kroah-Hartman2019-02-012-23/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. 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: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: brcm80211-dev-list@cypress.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Arend van Spriel Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * wireless: remove unneeded semicolonYueHaibing2019-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | remove unneeded semicolon Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Acked-by: Steve deRosier <derosier@cal-sierra.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * brcmfmac: Use firmware_request_nowarn for the clm_blobHans de Goede2019-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * brcmfmac: fix system warning message during wowl suspendLo-Hsiang Lo2019-01-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | There is a system warning message, warn_slowpath-fmt, during suspend while using supplicant join AP and enable wowl feature by IW command. It's caused by brcmf_pno_remove_request path can't find the reqid. This fix will not go to remove pno request function if there is no pno scan. Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Lo-Hsiang Lo <double.lo@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * brcmfmac: add a check for the status of usb_registerKangjie Lu2019-01-101-1/+5
| | | | | | | | | | | | | | | | usb_register() may fail, so let's check its status and issue an error message if it fails. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * brcmfmac: Add DMI nvram filename quirk for PoV TAB-P1006W-232 tabletHans de Goede2019-01-101-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | The Point of View TAB-P1006W-232 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: brcmfmac43340-sdio.Insyde-BayTrail.txt as nvram file which is a bit too generic. Add a DMI quirk so that a unique and clearly identifiable nvram file name is used on the PoV TAB-P1006W-232 tablet. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * brcmsmac: remove set but not used variables 'phybw40, maxtargetpwr'YueHaibing2019-01-101-11/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:1202:5: warning: variable 'phybw40' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4625:5: warning: variable 'phybw40' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4834:5: warning: variable 'phybw40' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:3085:17: warning: variable 'maxtargetpwr' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:4215:17: warning: variable 'maxtargetpwr' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-02 00:35:27 +0200