aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-04-04qtnfmac: replace qtnf_cmd_acl_data_size() with struct_size()Gustavo A. R. Silva1-11/+4
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: size = struct_size(instance, entry, count); or instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL) Based on the above, replace qtnf_cmd_acl_data_size() with the new struct_size() helper. This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Sergey Matyukevich <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04drm/amd/display: fix cursor black issuetiancyin1-0/+1
[Why] the member sdr_white_level of struct dc_cursor_attributes was not initialized, then the random value result that dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal value is 0x3c00), this cause the black cursor issue. [how] just initilize the obj of struct dc_cursor_attributes to zero to avoid the random value. Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Tianci Yin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-04drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in ↵wentalou1-4/+9
shadow_list amdgpu_bo_restore_shadow would assign zero to r if succeeded. r would remain zero if there is only one node in shadow_list. current code would always return failure when r <= 0. restart the timeout for each wait was a rather problematic bug as well. The value of tmo SHOULD be changed, otherwise we wait tmo jiffies on each loop. Signed-off-by: Wentao Lou <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-04drm/amdgpu: Adjust IB test timeout for XGMI configurationshaoyunl1-0/+3
On XGMI configuration the ib test may take longer to finish Signed-off-by: shaoyunl <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-04drm/amdkfd: Add picasso pci idAlex Deucher1-0/+1
Picasso is a new raven variant. Reviewed-by: Kent Russell <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-04-04rtlwifi: move spin_lock_bh to spin_lock in taskletJeff Xie1-3/+3
It is unnecessary to call spin_lock_bh in a tasklet. Signed-off-by: Jeff Xie <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04rtlwifi: fix potential NULL pointer dereferencePing-Ke Shih6-0/+14
In case dev_alloc_skb fails, the fix safely returns to avoid potential NULL pointer dereference. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04rtlwifi: fix a potential NULL pointer dereferenceKangjie Lu1-0/+5
In case alloc_workqueue fails, the fix reports the error and returns to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04mwifiex: add a bounds check in mwifiex_process_sta_rx_packet()Dan Carpenter1-1/+2
Smatch complains that "local_rx_pd->priority" can't be trusted because it comes from skb->data and it can go up to 255 instead of being capped in the 0-7 range. A few lines earlier, on the other side of the if statement, we cap priority so it seems harmless to add a bounds check here as well. Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Brian Norris <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04mwifiex: Fix mem leak in mwifiex_tm_cmdYueHaibing1-1/+5
'hostcmd' is alloced by kzalloc, should be freed before leaving from the error handling cases, otherwise it will cause mem leak. Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04net: mwifiex: fix a NULL pointer dereferenceKangjie Lu1-0/+6
In case dev_alloc_skb fails, the fix returns -ENOMEM to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04iwlegacy: remove redundant assignment to *resColin Ian King1-1/+0
Currently 1 is being assigned to *res and then it is immediately updated with the computed result. The first assignment is redundant and can be removed. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04b43: shut up clang -Wuninitialized variable warningArnd Bergmann1-3/+3
Clang warns about what is clearly a case of passing an uninitalized variable into a static function: drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here [-Werror,-Wuninitialized] lpphy_papd_cal(dev, gains, 0, 1, 30); ^~~~~ drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here struct lpphy_tx_gains gains, oldgains; ^ 1 error generated. However, this function is empty, and its arguments are never evaluated, so gcc in contrast does not warn here. Both compilers behave in a reasonable way as far as I can tell, so we should change the code to avoid the warning everywhere. We could just eliminate the lpphy_papd_cal() function entirely, given that it has had the TODO comment in it for 10 years now and is rather unlikely to ever get done. I'm doing a simpler change here, and just pass the 'oldgains' variable in that has been initialized, based on the guess that this is what was originally meant. Fixes: 2c0d6100da3e ("b43: LP-PHY: Begin implementing calibration & software RFKILL support") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Larry Finger <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: fix missing checks for kmemdupKangjie Lu1-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 <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: convert dev_init_lock mutex to completionPiotr Figiel1-9/+8
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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: fix Oops when bringing up interface during USB disconnectPiotr Figiel1-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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: remove unused variable i from brcmf_usb_free_qPiotr Figiel1-2/+0
Variable i is not used so remove it. Signed-off-by: Piotr Figiel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: remove pending parameter from brcmf_usb_free_qPiotr Figiel1-9/+6
brcmf_usb_free_q is no longer called with pending=true thus this boolean parameter is no longer needed. Signed-off-by: Piotr Figiel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: fix race during disconnect when USB completion is in progressPiotr Figiel1-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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: fix NULL pointer derefence during USB disconnectPiotr Figiel7-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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: fix WARNING during USB disconnect in case of unempty psqPiotr Figiel1-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 <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: reset PCIe bus on a firmware crashRafał Miłecki4-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 <[email protected]> Reviewed-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: add a function designated for handling firmware failsRafał Miłecki4-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 <[email protected]> Reviewed-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04brcmfmac: support repeated brcmf_fw_alloc_request() callsRafał Miłecki1-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 <[email protected]> Reviewed-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: use scan duration param for different scan typesIgor Mitsyanko2-11/+49
Use scan duration param for both active and passive scan dwell times. Document what different types of dwell times are used for. Explicitly specify that if unset, automatic selection by device firmware will be used. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: send EAPOL frames via control pathIgor Mitsyanko10-25/+89
Use control path to send EAPOL frames to make sure they are sent with higher priority with aggregation disabled. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: allow changing the netnsSergey Matyukevich1-1/+2
Allow to change netns for wireless interfaces created by qtnfmac driver. Signed-off-by: Sergey Matyukevich <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: simplify firmware state trackingSergey Matyukevich4-15/+30
This patch streamlines firmware state tracking. In particular, state QTNF_FW_STATE_FW_DNLD_DONE is removed, states QTNF_FW_STATE_RESET and QTNF_FW_STATE_DETACHED are merged into a single state. Besides, new state QTNF_FW_STATE_RUNNING is introduced to distinguish between the following two cases: - firmware load succeeded, firmware init process is ongoing - firmware init succeeded, firmware is fully functional Signed-off-by: Sergey Matyukevich <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: fix core attach error path in pcie backendSergey Matyukevich4-39/+34
Report that firmware is up and running only for successful firmware download. Simplify qtnf_pcie_fw_boot_done: modify error path so that no need to pass firmware dowload result to this function. Finally, do not create debugfs entries if firmware download succeeded, but core attach failed. Signed-off-by: Sergey Matyukevich <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: update bands information on CHANGE_INTF commandIgor Mitsyanko1-2/+19
In some regions, different regulatory limits (like max Tx power) may be defined for different operating modes. As an example: in ETSI regions DFS master devices may use higher transmit powers compared to DFS slave devices. Update bands information in CHANGE_INTF command if mode of operation changes. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: pass DFS region to firmware on region updateIgor Mitsyanko2-2/+19
Pass DFS region as requested by regulatory core directly to firmware so it can initialize radar detection block accordingly. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: allow each MAC to specify its own regulatory rulesIgor Mitsyanko7-156/+156
Currently driver uses the same regulatory rules to register all wiphy instances. This is not logically correct since each wiphy may have different capabilities (different supported bands, EIRP etc). Allow firmware to pass regulatory rules for each MAC separately. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: flexible regulatory domain registration logicIgor Mitsyanko1-5/+14
Use REGULATORY_CUSTOM_REG flag only if firmware advertised a custom regulatory domain prior to wiphy registration. Use REGULATORY_STRICT_REG flag only if firmware knows its regulatory domain. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: pass complete channel info in regulatory notifierIgor Mitsyanko3-31/+76
Currently only a portion of per-channel information is passed to firmware. Extend logic to pass all useful per-channel data. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: include full channels info to regulatory notifierIgor Mitsyanko2-1/+27
Before regulatory notifier is invoked by a wireless core, it will update band information for the wiphy. Pass this information to firmware together with new region alpha2 code. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: simplify error reporting in regulatory notifierIgor Mitsyanko1-10/+2
Error reporting in qtnf_cfg80211_reg_notifier only requires to print one type of message and an error code. Firmware will report success for an attempt to set regulatory region to the same value, so no special handling is required for this case. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-04qtnfmac: make regulatory notifier work on per-phy basisIgor Mitsyanko3-30/+13
Wireless core calls regulatory notifier for each wiphy and it only guarantees that bands info is updated for this particular wiphy prior to calling a notifier. Hence updating all wiphy which belong to driver in a single notifier callback is redundant and incorrect. Signed-off-by: Igor Mitsyanko <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-04-03net: phy: fix autoneg mismatch case in genphy_read_statusHeiner Kallweit1-5/+3
The original patch didn't consider the case that autoneg process finishes successfully but both link partners have no mode in common. In this case there's no link, nevertheless we may be interested in what the link partner advertised. Like phydev->link we set phydev->autoneg_complete in genphy_update_link() and use the stored value in genphy_read_status(). This way we don't have to read register BMSR again. Fixes: b6163f194c69 ("net: phy: improve genphy_read_status") Signed-off-by: Heiner Kallweit <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-03net: phy: marvell10g: add the suspend/resume callbacks for the 88x2210Antoine Tenart1-0/+2
When the 88x2110 PHY support was added, the suspend and resume callbacks were forgotten. This patch adds them to the 88x2110 PHY callback definition. Signed-off-by: Antoine Tenart <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-03net: phy: marvell10g: implement suspend/resume callbacksAntoine Tenart1-1/+11
This patch adds the suspend/resume callbacks for Marvell 10G PHYs. The three PCS (base-t, base-r and 1000base-x) are set in low power (the PCS are powered down) when the PHY isn't used. Signed-off-by: Antoine Tenart <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-03net: dsa: microchip: mark expected switch fall-throughGustavo A. R. Silva1-0/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/net/dsa/microchip/ksz9477.c: In function ‘ksz9477_get_interface’: drivers/net/dsa/microchip/ksz9477.c:1145:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (gbit) ^ drivers/net/dsa/microchip/ksz9477.c:1147:2: note: here case 0: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-03scsi: lpfc: Fix missing wakeups on abort threadsJames Smart1-4/+3
Abort thread wakeups, on some wqe types, are not happening. The thread wakeup logic is dependent upon the LPFC_DRIVER_ABORTED flag. However, on these wqes, the completion handler running prior to the io completion routine ends up clearing the flag. Rework the wakeup logic to look at a non-null waitq element which must be set if the abort thread is waiting. This is reverting the change in the indicated patch. Fixes: c2017260eea2d ("scsi: lpfc: Rework locking on SCSI io completion") Signed-off-by: Dick Kennedy <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-04-03scsi: storvsc: Reduce default ring buffer size to 128 KbytesMichael Kelley1-1/+1
Reduce the default VMbus channel ring buffer size for storvsc SCSI devices from 1 Mbyte to 128 Kbytes. Measurements show that ring buffer sizes above 128 Kbytes do not increase performance even at very high IOPS rates, so don't waste the memory. Also remove the dependence on PAGE_SIZE, since the ring buffer size should not change on architectures where PAGE_SIZE is not 4 Kbytes. Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Haiyang Zhang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-04-03scsi: storvsc: Fix calculation of sub-channel countMichael Kelley1-2/+11
When the number of sub-channels offered by Hyper-V is >= the number of CPUs in the VM, calculate the correct number of sub-channels. The current code produces one too many. This scenario arises only when the number of CPUs is artificially restricted (for example, with maxcpus=<n> on the kernel boot line), because Hyper-V normally offers a sub-channel count < number of CPUs. While the current code doesn't break, the extra sub-channel is unbalanced across the CPUs (for example, a total of 5 channels on a VM with 4 CPUs). Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Long Li <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-04-03scsi: core: add new RDAC LENOVO/DE_Series deviceXose Vazquez Perez2-0/+2
Blacklist "Universal Xport" LUN. It's used for in-band storage array management. Also add model to the rdac dh family. Cc: Martin Wilck <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: NetApp RDAC team <[email protected]> Cc: Christophe Varoqui <[email protected]> Cc: James E.J. Bottomley <[email protected]> Cc: Martin K. Petersen <[email protected]> Cc: SCSI ML <[email protected]> Cc: DM ML <[email protected]> Signed-off-by: Xose Vazquez Perez <[email protected]> Reviewed-by: Martin Wilck <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-04-03Merge tag 'gvt-fixes-2019-04-04' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi4-10/+7
drm-intel-fixes gvt-fixes-2019-04-04 - Fix shadow mm pin count (Yan) - Fix cmd parser error path recover (Yan) - Fix vGPU display plane size calculation (Xiong) - Fix kerneldoc (Chris) Signed-off-by: Rodrigo Vivi <[email protected]> From: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-04drm/i915/gvt: Fix kerneldoc typo for intel_vgpu_emulate_hotplugChris Wilson1-1/+1
drivers/gpu/drm/i915/gvt/display.c:457: warning: Function parameter or member 'connected' not described in 'intel_vgpu_emulate_hotplug' drivers/gpu/drm/i915/gvt/display.c:457: warning: Excess function parameter 'conncted' description in 'intel_vgpu_emulate_hotplug' Fixes: 1ca20f33df42 ("drm/i915/gvt: add hotplug emulation") Signed-off-by: Chris Wilson <[email protected]> Cc: Hang Yuan <[email protected]> Cc: Zhenyu Wang <[email protected]> Cc: Zhi Wang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2019-04-04drm/i915/gvt: Correct the calculation of plane sizeXiong Zhang1-6/+2
stride isn't in unit of pixel, it is bytes, so calculation of plane size doesn't need to multiple bpp. Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Signed-off-by: Xiong Zhang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
2019-04-03Input: snvs_pwrkey - initialize necessary driver data before enabling IRQAnson Huang1-3/+3
SNVS IRQ is requested before necessary driver data initialized, if there is a pending IRQ during driver probe phase, kernel NULL pointer panic will occur in IRQ handler. To avoid such scenario, just initialize necessary driver data before enabling IRQ. This patch is inspired by NXP's internal kernel tree. Fixes: d3dc6e232215 ("input: keyboard: imx: add snvs power key driver") Signed-off-by: Anson Huang <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2019-04-03vfio/type1: Limit DMA mappings per containerAlex Williamson1-0/+14
Memory backed DMA mappings are accounted against a user's locked memory limit, including multiple mappings of the same memory. This accounting bounds the number of such mappings that a user can create. However, DMA mappings that are not backed by memory, such as DMA mappings of device MMIO via mmaps, do not make use of page pinning and therefore do not count against the user's locked memory limit. These mappings still consume memory, but the memory is not well associated to the process for the purpose of oom killing a task. To add bounding on this use case, we introduce a limit to the total number of concurrent DMA mappings that a user is allowed to create. This limit is exposed as a tunable module option where the default value of 64K is expected to be well in excess of any reasonable use case (a large virtual machine configuration would typically only make use of tens of concurrent mappings). This fixes CVE-2019-3882. Reviewed-by: Eric Auger <[email protected]> Tested-by: Eric Auger <[email protected]> Reviewed-by: Peter Xu <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.