kernel/linux.git/drivers/staging, branch linux-5.9.y

staging: ralink-gdma: fix kconfig dependency bug for DMA_RALINK

2020-12-02T07:51:48+00:00

[ Upstream commit 06ea594051707c6b8834ef5b24e9b0730edd391b ] When DMA_RALINK is enabled and DMADEVICES is disabled, it results in the following Kbuild warnings: WARNING: unmet direct dependencies detected for DMA_ENGINE Depends on [n]: DMADEVICES [=n] Selected by [y]: - DMA_RALINK [=y] && STAGING [=y] && RALINK [=y] && !SOC_RT288X [=n] WARNING: unmet direct dependencies detected for DMA_VIRTUAL_CHANNELS Depends on [n]: DMADEVICES [=n] Selected by [y]: - DMA_RALINK [=y] && STAGING [=y] && RALINK [=y] && !SOC_RT288X [=n] The reason is that DMA_RALINK selects DMA_ENGINE and DMA_VIRTUAL_CHANNELS without depending on or selecting DMADEVICES while DMA_ENGINE and DMA_VIRTUAL_CHANNELS are subordinate to DMADEVICES. This can also fail building the kernel as demonstrated in a bug report. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Link: https://bugzilla.kernel.org/show_bug.cgi?id=210055 Signed-off-by: Necip Fazil Yildiran Link: https://lore.kernel.org/r/20201104181522.43567-1-fazilyildiran@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

staging: mt7621-pci: avoid to request pci bus resources

2020-11-24T12:39:09+00:00

commit e2b2e4386cb7a5e935dff388cf8961317daf39ce upstream. After upgrading kernel to version 5.9.x the driver was not working anymore showing the following kernel trace: ... mt7621-pci 1e140000.pcie: resource collision: [mem 0x60000000-0x6fffffff] conflicts with pcie@1e140000 [mem 0x60000000-0x6fffffff] ------------[ cut here ]------------ WARNING: CPU: 2 PID: 73 at kernel/resource.c:1400 devm_request_resource+0xfc/0x10c Modules linked in: CPU: 2 PID: 73 Comm: kworker/2:1 Not tainted 5.9.2 #0 Workqueue: events deferred_probe_work_func Stack : 00000000 81590000 807d0a1c 808a0000 8fd49080 807d0000 00000009 808ac820 00000001 808338d0 7fff0001 800839dc 00000049 00000001 8fe51b00 367204ab 00000000 00000000 807d0a1c 807c0000 00000001 80082358 8fe50000 00559000 00000000 8fe519f1 ffffffff 00000005 00000000 00000001 00000000 807d0000 00000009 808ac820 00000001 808338d0 00000001 803bf1b0 00000008 81390008 Call Trace: [<8000d018>] show_stack+0x30/0x100 [<8032e66c>] dump_stack+0xa4/0xd4 [<8002db1c>] __warn+0xc0/0x134 [<8002dbec>] warn_slowpath_fmt+0x5c/0xac [<80033b34>] devm_request_resource+0xfc/0x10c [<80365ff8>] devm_request_pci_bus_resources+0x58/0xdc [<8048e13c>] mt7621_pci_probe+0x8dc/0xe48 [<803d2140>] platform_drv_probe+0x40/0x94 [<803cfd94>] really_probe+0x108/0x4ec [<803cd958>] bus_for_each_drv+0x70/0xb0 [<803d0388>] __device_attach+0xec/0x164 [<803cec8c>] bus_probe_device+0xa4/0xc0 [<803cf1c4>] deferred_probe_work_func+0x80/0xc4 [<80048444>] process_one_work+0x260/0x510 [<80048a4c>] worker_thread+0x358/0x5cc [<8004f7d0>] kthread+0x134/0x13c [<80007478>] ret_from_kernel_thread+0x14/0x1c ---[ end trace a9dd2e37537510d3 ]--- mt7621-pci 1e140000.pcie: Error requesting resources mt7621-pci: probe of 1e140000.pcie failed with error -16 ... With commit 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated into resources when the host bridge is allocated. The resources are requested as well, but that happens a 2nd time for this driver in mt7621_pcie_request_resources(). Hence we should avoid this second request. Also, the bus ranges was also populated by default, so we can remove it from mt7621_pcie_request_resources() to avoid the following trace if we don't avoid it: pci_bus 0000:00: busn_res: can not insert [bus 00-ff] under domain [bus 00-ff] (conflicts with (null) [bus 00-ff]) Function 'mt7621_pcie_request_resources' has been renamed into 'mt7621_pcie_add_resources' which now is a more accurate name for this function. Cc: stable@vger.kernel.org #5.9.x- Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20201102202515.19073-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman

staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-ids

2020-11-24T12:39:09+00:00

commit aee9dccc5b64e878cf1b18207436e73f66d74157 upstream. Add 024c:0627 to the list of SDIO device-ids, based on hardware found in the wild. This hardware exists on at least some Acer SW1-011 tablets. Signed-off-by: Brian O'Keefe Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/b9e1523f-2ba7-fb82-646a-37f095b4440e@alum.wpi.edu Cc: stable Signed-off-by: Greg Kroah-Hartman

staging: mmal-vchiq: Fix memory leak for vchiq_instance

2020-11-10T11:39:06+00:00

[ Upstream commit b6ae84d648954fae096d94faea1ddb6518b27841 ] The vchiq_instance is allocated with vchiq_initialise() but never freed properly. Fix memory leak for the vchiq_instance. Reported-by: Jaehoon Chung Signed-off-by: Seung-Woo Kim Link: https://lore.kernel.org/r/1603706150-10806-1-git-send-email-sw0312.kim@samsung.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

staging: octeon: Drop on uncorrectable alignment or FCS error

2020-11-05T10:51:57+00:00

commit 49d28ebdf1e30d806410eefc7de0a7a1ca5d747c upstream. Currently in case of alignment or FCS error if the packet cannot be corrected it's still not dropped. Report the error properly and drop the packet while making the code around a little bit more readable. Fixes: 80ff0fd3ab64 ("Staging: Add octeon-ethernet driver files.") Signed-off-by: Alexander Sverdlin Cc: stable Link: https://lore.kernel.org/r/20201016145630.41852-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman

staging: octeon: repair "fixed-link" support

2020-11-05T10:51:57+00:00

commit 179f5dc36b0a1aa31538d7d8823deb65c39847b3 upstream. The PHYs must be registered once in device probe function, not in device open callback because it's only possible to register them once. Fixes: a25e278020bf ("staging: octeon: support fixed-link phys") Signed-off-by: Alexander Sverdlin Cc: stable Link: https://lore.kernel.org/r/20201016101858.11374-1-alexander.sverdlin@nokia.com Signed-off-by: Greg Kroah-Hartman

staging: comedi: cb_pcidas: Allow 2-channel commands for AO subdevice

2020-11-05T10:51:57+00:00

commit 647a6002cb41d358d9ac5de101a8a6dc74748a59 upstream. The "cb_pcidas" driver supports asynchronous commands on the analog output (AO) subdevice for those boards that have an AO FIFO. The code (in `cb_pcidas_ao_check_chanlist()` and `cb_pcidas_ao_cmd()`) to validate and set up the command supports output to a single channel or to two channels simultaneously (the boards have two AO channels). However, the code in `cb_pcidas_auto_attach()` that initializes the subdevices neglects to initialize the AO subdevice's `len_chanlist` member, leaving it set to 0, but the Comedi core will "correct" it to 1 if the driver neglected to set it. This limits commands to use a single channel (either channel 0 or 1), but the limit should be two channels. Set the AO subdevice's `len_chanlist` member to be the same value as the `n_chan` member, which will be 2. Cc: Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20201021122142.81628-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman

staging: fieldbus: anybuss: jump to correct label in an error path

2020-11-05T10:51:56+00:00

commit 7e97e4cbf30026b49b0145c3bfe06087958382c5 upstream. In current code, controller_probe() misses to call ida_simple_remove() in an error path. Jump to correct label to fix it. Fixes: 17614978ed34 ("staging: fieldbus: anybus-s: support the Arcx anybus controller") Reviewed-by: Sven Van Asbroeck Signed-off-by: Jing Xiangfeng Cc: stable Link: https://lore.kernel.org/r/20201012132404.113031-1-jingxiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

staging: wfx: fix potential use before init

2020-11-05T10:51:18+00:00

[ Upstream commit ce3653a8d3db096aa163fc80239d8ec1305c81fa ] The trace below can appear: [83613.832200] INFO: trying to register non-static key. [83613.837248] the code is fine but needs lockdep annotation. [83613.842808] turning off the locking correctness validator. [83613.848375] CPU: 3 PID: 141 Comm: kworker/3:2H Tainted: G O 5.6.13-silabs15 #2 [83613.857019] Hardware name: BCM2835 [83613.860605] Workqueue: events_highpri bh_work [wfx] [83613.865552] Backtrace: [83613.868041] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [83613.881463] [] (show_stack) from [] (dump_stack+0xe8/0x114) [83613.888882] [] (dump_stack) from [] (register_lock_class+0x748/0x768) [83613.905035] [] (register_lock_class) from [] (__lock_acquire+0x88/0x13dc) [83613.924192] [] (__lock_acquire) from [] (lock_acquire+0xe8/0x274) [83613.942644] [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x58/0x6c) [83613.961714] [] (_raw_spin_lock_irqsave) from [] (skb_dequeue+0x24/0x78) [83613.974967] [] (skb_dequeue) from [] (wfx_tx_queues_get+0x96c/0x1294 [wfx]) [83613.989728] [] (wfx_tx_queues_get [wfx]) from [] (bh_work+0x454/0x26d8 [wfx]) [83614.009337] [] (bh_work [wfx]) from [] (process_one_work+0x23c/0x7ec) [83614.028141] [] (process_one_work) from [] (worker_thread+0x4c/0x55c) [83614.046861] [] (worker_thread) from [] (kthread+0x138/0x168) [83614.064876] [] (kthread) from [] (ret_from_fork+0x14/0x20) [83614.072200] Exception stack(0xecad3fb0 to 0xecad3ff8) [83614.077323] 3fa0: 00000000 00000000 00000000 00000000 [83614.085620] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [83614.093914] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Indeed, the code of wfx_add_interface() shows that the interface is enabled to early. So, the spinlock associated with some skb_queue may not yet initialized when wfx_tx_queues_get() is called. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200825085828.399505-8-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

staging: wfx: fix handling of MMIC error

2020-10-29T09:12:12+00:00

[ Upstream commit 8d350c14ee5eb62ecd40b0991248bfbce511954d ] As expected, when the device detect a MMIC error, it returns a specific status. However, it also strip IV from the frame (don't ask me why). So, with the current code, mac80211 detects a corrupted frame and it drops it before it handle the MMIC error. The expected behavior would be to detect MMIC error then to renegotiate the EAP session. So, this patch correctly informs mac80211 that IV is not available. So, mac80211 correctly takes into account the MMIC error. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20201007101943.749898-2-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin