summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-02-08net: hns3: fix oops when unload drivers parallelingJian Shen
[ Upstream commit 92e5995773774a3e70257e9c95ea03518268bea5 ] When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process. Fixes: 0dd8a25f355b ("net: hns3: disable sriov before unload hclge layer") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20250118094741.3046663-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08net: airoha: Fix wrong GDM4 register definitionChristian Marangi
[ Upstream commit d31a49d37cb132b31cc6683eef2122f8609d6229 ] Fix wrong GDM4 register definition, in Airoha SDK GDM4 is defined at offset 0x2400 but this doesn't make sense as it does conflict with the CDM4 that is in the same location. Following the pattern where each GDM base is at the FWD_CFG, currently GDM4 base offset is set to 0x2500. This is correct but REG_GDM4_FWD_CFG and REG_GDM4_SRC_PORT_SET are still using the SDK reference with the 0x2400 offset. Fix these 2 define by subtracting 0x100 to each register to reflect the real address location. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250120154148.13424-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08regulator: core: Add missing newline characterAlexander Stein
[ Upstream commit 155c569fa4c3b340fbf8571a0e42dd415c025377 ] dev_err_probe() error messages need newline character. Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://patch.msgid.link/20250122072019.1926093-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08ubi: Revert "ubi: wl: Close down wear-leveling before nand is suspended"Zhihao Cheng
[ Upstream commit 844c6fdc13cf3d9d251533631988a58f8356a8c8 ] Commit 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") added a reboot notification in UBI layer to shutdown the wear-leveling subsystem, which imported an UAF problem[1]. Besides that, the method also brings other potential UAF problems, for example: reboot kworker ubi_wl_reboot_notifier ubi_wl_close ubi_fastmap_close kfree(ubi->fm) update_fastmap_work_fn ubi_update_fastmap old_fm = ubi->fm if (old_fm && old_fm->e[i]) // UAF! Actually, the problem fixed by commit 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") has been solved by commit 8cba323437a4 ("mtd: rawnand: protect access to rawnand devices while in suspend"), which was discussed in [2]. So we can revert the commit 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") directly. [1] https://lore.kernel.org/linux-mtd/20241208175211.9406-2-dennis.lamerice@gmail.com/ [2] https://lore.kernel.org/all/9bf76f5d-12a4-46ff-90d4-4a7f0f47c381@axis.com/ Fixes: 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") Reported-by: Dennis Lam <dennis.lamerice@gmail.com> Closes: https://lore.kernel.org/linux-mtd/20241208175211.9406-2-dennis.lamerice@gmail.com/ Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Acked-by: Mårten Lindahl <marten.lindahl@axis.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08rtc: loongson: clear TOY_MATCH0_REG in loongson_rtc_isr()Ming Wang
[ Upstream commit 09471d8f5b390883eaf21b917c4bf3ced1b8a1df ] The TOY_MATCH0_REG should be cleared to 0 in the RTC interrupt handler, otherwise the interrupt cannot be cleared, which will cause the loongson_rtc_isr() to be triggered multiple times. The previous code cleared TOY_MATCH0_REG in the loongson_rtc_handler(), which is an ACPI interrupt. This did not prevent loongson_rtc_isr() from being triggered multiple times. This commit moves the clearing of TOY_MATCH0_REG to the loongson_rtc_isr() to ensure that the interrupt is properly cleared. Fixes: 1b733a9ebc3d ("rtc: Add rtc driver for the Loongson family chips") Signed-off-by: Ming Wang <wangming01@loongson.cn> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Reviewed-by: Keguang Zhang <keguang.zhang@gmail.com> # on LS1B Tested-by: Keguang Zhang <keguang.zhang@gmail.com> Link: https://lore.kernel.org/r/20241205114307.1891418-1-wangming01@loongson.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM readOleksij Rempel
[ Upstream commit 3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c ] The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value. Fixes: fadfd092ee91 ("rtc: pcf85063: add nvram support") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20241218-rtc-pcf85063-stack-corruption-v1-1-12fd0ee0f046@pengutronix.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08rtc: tps6594: Fix integer overflow on 32bit systemsDan Carpenter
[ Upstream commit 09c4a610153286cef54d4f0c85398f4e32fc227e ] The problem is this multiply in tps6594_rtc_set_offset() tmp = offset * TICKS_PER_HOUR; The "tmp" variable is an s64 but "offset" is a long in the (-277774)-277774 range. On 32bit systems a long can hold numbers up to approximately two billion. The number of TICKS_PER_HOUR is really large, (32768 * 3600) or roughly a hundred million. When you start multiplying by a hundred million it doesn't take long to overflow the two billion mark. Probably the safest way to fix this is to change the type of TICKS_PER_HOUR to long long because it's such a large number. Fixes: 9f67c1e63976 ("rtc: tps6594: Add driver for TPS6594 RTC") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/1074175e-5ecb-4e3d-b721-347d794caa90@stanley.mountain Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08dmaengine: ti: edma: fix OF node reference leaks in edma_driverJoe Hattori
[ Upstream commit e883c64778e5a9905fce955681f8ee38c7197e0f ] The .probe() of edma_driver calls of_parse_phandle_with_fixed_args() but does not release the obtained OF nodes. Thus add a of_node_put() call. This bug was found by an experimental verification tool that I am developing. Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20241219020507.1983124-3-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08LoongArch: Fix warnings during S3 suspendHuacai Chen
[ Upstream commit 26c0a2d93af55d30a46d5f45d3e9c42cde730168 ] The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(), and the later one may call the preempt_schedule_common() function, resulting in a thread switch and causing the CPU to be in an interrupt enabled state after the enable_gpe_wakeup() function returns, leading to the warnings as follow. [ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]--- The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Since there is no longer concurrent execution during loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes() directly in enable_gpe_wakeup(). The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep()"). Fixes: 366bb35a8e48 ("LoongArch: Add suspend (ACPI S3) support") Signed-off-by: Qunqin Zhao <zhaoqunqin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08serial: 8250: Adjust the timeout for FIFO modeJohn Ogness
[ Upstream commit d91f98be26510f5f81ec66425bb0306d1ccd571a ] After a console has written a record into UART_TX, it uses wait_for_xmitr() to wait until the data has been sent out before returning. However, wait_for_xmitr() will timeout after 10ms, regardless if the data has been transmitted or not. For single bytes, this timeout is sufficient even at very slow baud rates, such as 1200bps. However, when FIFO mode is used, there may be 64 bytes pushed into the FIFO at once. At a baud rate of 115200bps, the 10ms timeout is still sufficient. But when using lower baud rates (such as 57600bps), the timeout is _not_ sufficient. This causes longer lines to be cut off, resulting in lost and horribly misformatted output on the console. When using FIFO mode, take the number of bytes into account to determine an appropriate maximum timeout. Increasing the timeout does not affect performance since ideally the timeout never occurs. Fixes: 8f3631f0f6eb ("serial/8250: Use fifo in 8250 console driver") Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Wander Lairson Costa <wander@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20250107212702.169493-2-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08tty: mips_ejtag_fdc: fix one more u8 warningJiri Slaby (SUSE)
[ Upstream commit 6dd1de91e7a62bfd3878992c1db6e1d443022c76 ] The LKP robot complains about: drivers/tty/mips_ejtag_fdc.c:1224:31: error: incompatible pointer types passing 'const char *[1]' to parameter of type 'const u8 **' (aka 'const unsigned char **') Fix this by turning the missing pieces (fetch from kgdbfdc_wbuf) to u8 too. Note the filling part (kgdbfdc_write_char()) already receives and stores u8 to kgdbfdc_wbuf. Fixes: ce7cbd9a6c81 ("tty: mips_ejtag_fdc: use u8 for character pointers") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501101327.oGdWbmuk-lkp@intel.com/ Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250110115228.603980-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()Zijun Hu
[ Upstream commit e128f82f7006991c99a58114f70ef61e937b1ac1 ] There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage: // All members of @iter are wild pointers. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...); // Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... }; // Also dereference these wild pointers here. class_dev_iter_exit(&iter); Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next(). Fixes: 7b884b7f24b4 ("driver core: class.c: convert to only use class_to_subsys") Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-1-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08firewire: test: Fix potential null dereference in firewire kunit testCharles Han
[ Upstream commit 352fafe97784e81a10a7c74bd508f71a19b53c2a ] kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. Fixes: 1c8506d62624 ("firewire: test: add test of device attributes for simple AV/C device") Signed-off-by: Charles Han <hanchunchao@inspur.com> Link: https://lore.kernel.org/r/20250110084237.8877-1-hanchunchao@inspur.com Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08scsi: mpi3mr: Fix possible crash when setting up bsg failsGuixin Liu
[ Upstream commit 295006f6e8c17212d3098811166e29627d19e05c ] If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value. Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)" will not be satisfied, preventing execution from entering bsg_remove_queue(), which could lead to the following crash: BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace: <TASK> mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr] mpi3mr_remove+0x6f/0x340 [mpi3mr] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19d/0x220 unbind_store+0xa4/0xb0 kernfs_fop_write_iter+0x11f/0x200 vfs_write+0x1fc/0x3e0 ksys_write+0x67/0xe0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Fixes: 4268fa751365 ("scsi: mpi3mr: Add bsg device support") Signed-off-by: Guixin Liu <kanie@linux.alibaba.com> Link: https://lore.kernel.org/r/20250107022032.24006-1-kanie@linux.alibaba.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08scsi: ufs: bsg: Delete bsg_dev when setting up bsg failsGuixin Liu
[ Upstream commit fcf247deb3c3e1c6be5774e3fa03bbd018eff1a9 ] We should remove the bsg device when bsg_setup_queue() fails to release the resources. Fixes: df032bf27a41 ("scsi: ufs: Add a bsg endpoint that supports UPIUs") Signed-off-by: Guixin Liu <kanie@linux.alibaba.com> Link: https://lore.kernel.org/r/20241218014214.64533-2-kanie@linux.alibaba.com Reviewed-by: Avri Altman <avri.altman@wdc.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08scsi: mpt3sas: Set ioc->manu_pg11.EEDPTagMode directly to 1Paul Menzel
[ Upstream commit ad7c3c0cb8f61d6d5a48b83e62ca4a9fd2f26153 ] Currently, the code does: if (x == 0) { x &= ~0x3; x |= 0x1; } Zeroing bits 0 and 1 of a variable that is 0 is not necessary. So directly set the variable to 1. Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/r/20241212221817.78940-2-pmenzel@molgen.mpg.de Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: microchip: Set inbound address translation for coherent or non-coherent ↵Daire McNamara
mode [ Upstream commit 1390a33b3d04fdf6ba4e3e7082107a12027fc188 ] On Microchip PolarFire SoC the PCIe Root Port can be behind one of three general purpose Fabric Interface Controller (FIC) buses that encapsulates an AXI-S bus. Depending on which FIC(s) the Root Port is connected through to CPU space, and what address translation is done by that FIC, the Root Port driver's inbound address translation may vary. For all current supported designs and all future expected designs, inbound address translation done by a FIC on PolarFire SoC varies depending on whether PolarFire SoC is operating in coherent DMA mode or noncoherent DMA mode. The setup of the outbound address translation tables in the Root Port driver only needs to handle these two cases. Setup the inbound address translation tables to one of two address translations, depending on whether the Root Port is being used with coherent DMA or noncoherent DMA. Link: https://lore.kernel.org/r/20241011140043.1250030-3-daire.mcnamara@microchip.com Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver") Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com> [bhelgaas: adapt for ac7f53b7e728 ("PCI: microchip: Add support for using either Root Port 1 or 2")] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: endpoint: pci-epf-test: Fix check for DMA MEMCPY testManivannan Sadhasivam
[ Upstream commit 235c2b197a8de2887f13990094a3343d2392155b ] Currently, if DMA MEMCPY test is requested by the host, and if the endpoint DMA controller supports DMA_PRIVATE, the test will fail. This is not correct since there is no check for DMA_MEMCPY capability and the DMA controller can support both DMA_PRIVATE and DMA_MEMCPY. Fix the check and also reword the error message. Link: https://lore.kernel.org/r/20250116171650.33585-2-manivannan.sadhasivam@linaro.org Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Reported-by: Niklas Cassel <cassel@kernel.org> Closes: https://lore.kernel.org/linux-pci/Z3QtEihbiKIGogWA@ryzen Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: endpoint: pci-epf-test: Set dma_chan_rx pointer to NULL on errorMohamed Khalfella
[ Upstream commit b1b1f4b12969130c0a6ec0cf0299460cb01e799c ] If dma_chan_tx allocation fails, set dma_chan_rx to NULL after it is freed. Link: https://lore.kernel.org/r/20241227160841.92382-1-khalfella@gmail.com Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Signed-off-by: Mohamed Khalfella <khalfella@gmail.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: dwc: Always stop link in the dw_pcie_suspend_noirqRichard Zhu
[ Upstream commit 86a016e278b78cc2281edd4ffaddbc011c87a593 ] On the i.MX8QM, PCIe link can't be re-established again in dw_pcie_resume_noirq(), if the LTSSM_EN bit is not cleared properly in dw_pcie_suspend_noirq(). So, add dw_pcie_stop_link() to dw_pcie_suspend_noirq() to fix this issue and to align the suspend/resume functions since there is dw_pcie_start_link() in dw_pcie_resume_noirq() already. Fixes: 4774faf854f5 ("PCI: dwc: Implement generic suspend/resume functionality") Link: https://lore.kernel.org/r/20241210081557.163555-2-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: qcom: Update ICC and OPP values after Link Up eventKrishna chaitanya chundru
[ Upstream commit f0639013d340580b72df95d012a93f35eeb0da64 ] 4581403f6792 ("PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt") added the Link Up-based enumeration support, but did not update the ICC/OPP vote once link is up. Before that, the update happened during probe and the endpoints may or may not be enumerated at that time, so the ICC/OPP vote was not guaranteed to be accurate. With Link Up-based enumeration support, the driver can request the accurate vote based on the PCIe link. Call qcom_pcie_icc_opp_update() in qcom_pcie_global_irq_thread() after enumerating the endpoints. Fixes: 4581403f6792 ("PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt") Link: https://lore.kernel.org/r/20241123-remove_wait2-v5-3-b5f9e6b794c2@quicinc.com Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: imx6: Add missing reference clock disable logicRichard Zhu
[ Upstream commit 93d883f89063744a92006fc356b1c767eb62d950 ] Ensure the *_enable_ref_clk() function is symmetric by addressing missing disable parts on some platforms. Fixes: d0a75c791f98 ("PCI: imx6: Factor out ref clock disable to match enable") Link: https://lore.kernel.org/r/20241126075702.4099164-7-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: imx6: Deassert apps_reset in imx_pcie_deassert_core_reset()Richard Zhu
[ Upstream commit ef61c7d8d032adb467f99d03ccfaa293b417ac75 ] Since the apps_reset is asserted in imx_pcie_assert_core_reset(), it should be deasserted in imx_pcie_deassert_core_reset(). Fixes: 9b3fe6796d7c ("PCI: imx6: Add code to support i.MX7D") Link: https://lore.kernel.org/r/20241126075702.4099164-6-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: imx6: Skip controller_id generation logic for i.MX7DRichard Zhu
[ Upstream commit f068ffdd034c93f0c768acdc87d4d2d7023c1379 ] The i.MX7D only has one PCIe controller, so controller_id should always be 0. The previous code is incorrect although yielding the correct result. Fix by removing "IMX7D" from the switch case branch. Fixes: 2d8ed461dbc9 ("PCI: imx6: Add support for i.MX8MQ") Link: https://lore.kernel.org/r/20241126075702.4099164-5-hongxing.zhu@nxp.com Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: imx6: Configure PHY based on Root Complex or Endpoint modeFrank Li
[ Upstream commit de22e20589b79f35f92543119c33051f8179dba0 ] Pass PHY_MODE_PCIE_EP if the PCI controller operates in Endpoint (EP) mode, and fix the Root Complex (RC) mode being hardcoded using a drvdata mode check. Fixes: 8026f2d8e8a9 ("PCI: imx6: Call common PHY API to set mode, speed, and submode") Link: https://lore.kernel.org/r/20241119-pci_fixup_addr-v8-6-c4bfa5193288@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: rockchip-ep: Fix error code in rockchip_pcie_ep_init_ob_mem()Dan Carpenter
[ Upstream commit 7ca288760007cab6588dc17f5b6fecf52c83a945 ] Return -ENOMEM if pci_epc_mem_alloc_addr() fails. Don't return success. Link: https://lore.kernel.org/r/Z014ylYz_xrrgI4W@stanley.mountain Fixes: 945648019466 ("PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() memory allocations") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: rockchip: Add missing fields descriptions for struct rockchip_pcie_epDamien Le Moal
[ Upstream commit fd46bc0e0bb3c6607363bd23f2b3c2a73dc75d66 ] When compiling the Rockchip endpoint driver with -W=1, the following warnings can be seen in the output: drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'perst_irq' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'perst_asserted' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'link_up' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'link_training' not described in 'rockchip_pcie_ep' Fix these warnings by adding the missing field descriptions in struct rockchip_pcie_ep kernel-doc comment. Fixes: a7137cbf6bd5 ("PCI: rockchip-ep: Handle PERST# signal in EP mode") Fixes: bd6e61df4b2e ("PCI: rockchip-ep: Improve link training") Link: https://lore.kernel.org/r/20241216133404.540736-1-dlemoal@kernel.org Reported-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()King Dix
[ Upstream commit 2d2da5a4c1b4509f6f7e5a8db015cd420144beb4 ] The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 Fixes: 2a6d0d63d999 ("PCI: rcar: Add endpoint mode support") Link: https://lore.kernel.org/r/tencent_DBDCC19D60F361119E76919ADAB25EC13C06@qq.com Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: King Dix <kingdix10@qq.com> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: dvb-usb-v2: af9035: fix ISO C90 compilation error on ↵Desnes Nunes
af9035_i2c_master_xfer [ Upstream commit c36b9ad1a8add3c114e25fe167efa217a813b0c7 ] This fixes a 'ISO C90 forbids mixed declarations and code' compilation error on af9035_i2c_master_xfer, which is caused by the sanity check added on user controlled msg[i], before declaring the demodulator register. Fixes: 7bf744f2de0a ("media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer") Signed-off-by: Desnes Nunes <desnesn@redhat.com> Link: https://lore.kernel.org/r/20240919172755.196907-1-desnesn@redhat.com Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()Joe Hattori
[ Upstream commit 094f5c315f756b19198e6c401aa821ac0e868750 ] imx_media_add_of_subdevs() calls of_parse_phandle() and passes the obtained node to imx_media_of_add_csi(). The passed node is used in v4l2_async_nf_add_fwnode(), which increments the refcount of the node. Therefore, while the current implementation only releases the node when imx_media_of_add_csi() fails, but should always release it. Call of_node_put() right after imx_media_of_add_csi(). Fixes: dee747f88167 ("media: imx: Don't register IPU subdevs/links if CSI port missing") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08watchdog: rti_wdt: Fix an OF node leak in rti_wdt_probe()Joe Hattori
[ Upstream commit 143981aa63f33d469a55a55fd9fb81cd90109672 ] rti_wdt_probe() does not release the OF node reference obtained by of_parse_phandle(). Add a of_node_put() call. This was found by an experimental verification tool that I am developing. Due to the lack of the actual device, no runtime test was able to be performed. Fixes: f20ca595ae23 ("watchdog:rit_wdt: Add support for WDIOF_CARDRESET") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20250105111718.4184192-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: nxp: imx8-isi: fix v4l2-compliance test errorsLaurentiu Palcu
[ Upstream commit 7b12ab055edef2f51733d155617a401a05237bcc ] Running the v4l2-compliance (1.27.0-5208, SHA: af114250d48d) on the m2m device fails on the MMAP streaming tests, with the following messages: fail: v4l2-test-buffers.cpp(240): g_field() == V4L2_FIELD_ANY fail: v4l2-test-buffers.cpp(1508): buf.qbuf(node) Apparently, the driver does not properly set the field member of vb2_v4l2_buffer struct, returning the default V4L2_FIELD_ANY value which is against the guidelines. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20240924103304.124085-1-laurentiu.palcu@oss.nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08mtd: hyperbus: hbmc-am654: fix an OF node reference leakJoe Hattori
[ Upstream commit bf5821909eb9c7f5d07d5c6e852ead2c373c94a0 ] In am654_hbmc_platform_driver, .remove() and the error path of .probe() do not decrement the refcount of an OF node obtained by of_get_next_child(). Fix this by adding of_node_put() calls. Fixes: aca31ce96814 ("mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08mtd: rawnand: brcmnand: fix status read of brcmnand_waitfuncdavid regan
[ Upstream commit 03271ea36ea7a58d30a4bde182eb2a0d46220467 ] This change fixes an issue where an error return value may be mistakenly used as NAND status. Fixes: f504551b7f15 ("mtd: rawnand: Propagate error and simplify ternary operators for brcmstb_nand_wait_for_completion()") Signed-off-by: david regan <dregan@broadcom.com> Reviewed-by: William Zhang <william.zhang@broadcom.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: uvcvideo: Propagate buf->error to userspaceRicardo Ribalda
[ Upstream commit 87ce177654e388451850905a1d376658aebe8699 ] Now we return VB2_BUF_STATE_DONE for valid and invalid frames. Propagate the correct value, so the user can know if the frame is valid or not via struct v4l2_buffer->flags. Reported-by: Hans de Goede <hdegoede@redhat.com> Closes: https://lore.kernel.org/linux-media/84b0f212-cd88-46bb-8e6f-b94ec3eccba6@redhat.com Fixes: 6998b6fb4b1c ("[media] uvcvideo: Use videobuf2-vmalloc") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241218-uvc-deprecate-v2-1-ab814139e983@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: uvcvideo: Fix deadlock during uvc_probeRicardo Ribalda
[ Upstream commit a67f75c2b5ecf534eab416ce16c11fe780c4f8f6 ] If uvc_probe() fails, it can end up calling uvc_status_unregister() before uvc_status_init() is called. Fix this by checking if dev->status is NULL or not in uvc_status_unregister(). Reported-by: syzbot+9446d5e0d25571e6a212@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-media/20241020160249.GD7770@pendragon.ideasonboard.com/T/#m506744621d72a2ace5dd2ab64055be9898112dbd Fixes: c5fe3ed618f9 ("media: uvcvideo: Avoid race condition during unregister") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20241022-race-unreg-v1-1-2212f364d9de@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: camif-core: Add check for clk_enable()Jiasheng Jiang
[ Upstream commit 77ed2470ac09c2b0a33cf3f98cc51d18ba9ed976 ] Add check for the return value of clk_enable() to gurantee the success. Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface") Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: mipi-csis: Add check for clk_enable()Jiasheng Jiang
[ Upstream commit 125ad1aeec77eb55273b420be6894b284a01e4b6 ] Add check for the return value of clk_enable() to gurantee the success. Fixes: b5f1220d587d ("[media] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers") Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: i2c: ov9282: Correct the exposure offsetDave Stevenson
[ Upstream commit feaf4154d69657af2bf96e6e66cca794f88b1a61 ] The datasheet lists that "Maximum exposure time is frame length -25 row periods, where frame length is set by registers {0x380E, 0x380F}". However this driver had OV9282_EXPOSURE_OFFSET set to 12 which allowed that restriction to be violated, and would result in very under-exposed images. Correct the offset. Fixes: 14ea315bbeb7 ("media: i2c: Add ov9282 camera sensor driver") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: i2c: imx412: Add missing newline to printsLuca Weiss
[ Upstream commit 33f4a7fba7229232e294f4794503283e44cd03f2 ] Add trailing \n to dev_dbg and dev_err prints where missing. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: i2c: imx290: Register 0x3011 varies between imx327 and imx290Dave Stevenson
[ Upstream commit f2055c1d62d6dfd25a31d1d1923883f21305aea5 ] Reviewing the datasheets, register 0x3011 is meant to be 0x02 on imx327 and 0x00 on imx290. Move it out of the common registers, and set it appropriately in the sensor specific sections. (Included for imx290 to be explicit, rather than relying on the default value). Fixes: 2d41947ec2c0 ("media: i2c: imx290: Add support for imx327 variant") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: marvell: Add check for clk_enable()Jiasheng Jiang
[ Upstream commit 11f68d2ba2e1521a608af773bf788e8cfa260f68 ] Add check for the return value of clk_enable() to guarantee the success. Fixes: 81a409bfd551 ("media: marvell-ccic: provide a clock for the sensor") Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> [Sakari Ailus: Fix spelling in commit message.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08remoteproc: mtk_scp: Only populate devices for SCP coresChen-Yu Tsai
[ Upstream commit dbb9c372555c0b2a5a9264418bfba6d017752808 ] When multi-core SCP support was added, the driver was made to populate platform devices for all the sub-nodes. This ended up adding platform devices for the rpmsg sub-nodes as well, which never actually get used, since rpmsg devices are registered through the rpmsg interface. Limit of_platform_populate() to just populating the SCP cores with a compatible string match list. Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP") Cc: Tinghan Shen <tinghan.shen@mediatek.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20241211072009.120511-1-wenst@chromium.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08PCI: endpoint: Destroy the EPC device in devm_pci_epc_destroy()Zijun Hu
[ Upstream commit d4929755e4d02bd3de3ae5569dab69cb9502c54f ] The devm_pci_epc_destroy() comment says destroys the EPC device, but it does not actually do that since devres_destroy() does not call devm_pci_epc_release(), and it also can not fully undo what the API devm_pci_epc_create() does, so it is faulty. Fortunately, the faulty API has not been used by current kernel tree. Use devres_release() instead of devres_destroy() so the EPC device will be released. Link: https://lore.kernel.org/r/20241210-pci-epc-core_fix-v3-1-4d86dd573e4b@quicinc.com Fixes: 5e8cb4033807 ("PCI: endpoint: Add EP core layer to enable EP controller and EP functions") Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: lmedm04: Handle errors for lme2510_int_readChen Ni
[ Upstream commit a2836d3fe220220ff8c495ca9722f89cea8a67e7 ] Add check for the return value of usb_pipe_endpoint() and usb_submit_urb() in order to catch the errors. Fixes: 15e1ce33182d ("[media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://lore.kernel.org/r/20240521091042.1769684-1-nichen@iscas.ac.cn Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08media: rc: iguanair: handle timeoutsOliver Neukum
[ Upstream commit b98d5000c50544f14bacb248c34e5219fbe81287 ] In case of a timeout the IO must be cancelled or the next IO using the URB will fail and/or overwrite an operational URB. The automatic bisection fails because it arrives at a commit that correctly lets the test case run without an error. Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: e99a7cfe93fd ("[media] iguanair: reuse existing urb callback for command responses") Reported-by: syzbot+ffba8e636870dac0e0c0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/66f5cc9a.050a0220.46d20.0004.GAE@google.com/ Tested-by: syzbot+ffba8e636870dac0e0c0@syzkaller.appspotmail.com Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08of/fdt: Restore possibility to use both ACPI and FDT from bootloaderDmytro Maluka
[ Upstream commit 14bce187d1600710623d81888da3501bbc470ba2 ] There are cases when the bootloader provides information to the kernel in both ACPI and DTB, not interchangeably. One such use case is virtual machines in Android. When running on x86, the Android Virtualization Framework (AVF) boots VMs with ACPI like it is usually done on x86 (i.e. the virtual LAPIC, IOAPIC, HPET, PCI MMCONFIG etc are described in ACPI) but also passes various AVF-specific boot parameters in DTB. This allows reusing the same implementations of various AVF components on both arm64 and x86. Commit 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware") removed the possibility to do that, since among other things it introduced forcing emptying the bootloader-provided DTB if ACPI is enabled (probably assuming that if ACPI is available, a DTB can only be useful for applying overlays to it afterwards, for testing purposes). So restore this possibility. Instead of completely preventing using ACPI and DT together, rely on arch-specific setup code to prevent using both to set up the same things (see various acpi_disabled checks under arch/). Fixes: 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware") Signed-off-by: Dmytro Maluka <dmaluka@chromium.org> Link: https://lore.kernel.org/r/20250105172741.3476758-3-dmaluka@chromium.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08spi: omap2-mcspi: Correctly handle devm_clk_get_optional() errorsMark Brown
[ Upstream commit a07eb4f67ed085f32002a1af2b6073546d67de3f ] devm_clk_get_optional() returns NULL for missing clocks and a PTR_ERR() if there is a clock but we fail to get it, but currently we only handle the latter case and do so as though the clock was missing. If we get an error back we should handle that as an error since the clock exists but we failed to get it, if we get NULL then the clock doesn't exist and we should handle that. Fixes: 4c6ac5446d06 ("spi: omap2-mcspi: Fix the IS_ERR() bug for devm_clk_get_optional_enabled()") Reported-by: Lars Pedersen <lapeddk@gmail.com> Link: https://patch.msgid.link/20250117-spi-fix-omap2-optional-v1-1-e77d4ac6db6e@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Tested-by: Lars Pedersen <lapeddk@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08mailbox: th1520: Fix memory corruption due to incorrect array sizeMichal Wilczynski
[ Upstream commit db049866943a38bf46a34fa120d526663339d7a5 ] The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are intended to save and restore the interrupt mask registers in the MBOX ICU0. However, the array used to store these registers was incorrectly sized, leading to memory corruption when accessing all four registers. This commit corrects the array size to accommodate all four interrupt mask registers, preventing memory corruption during suspend and resume operations. Fixes: 5d4d263e1c6b ("mailbox: Introduce support for T-head TH1520 Mailbox driver") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/a99e72be-8490-4960-ad26-cbfef6af238f@stanley.mountain/ Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08mailbox: mpfs: fix copy and paste bug in probeDan Carpenter
[ Upstream commit f055feb49c1c4333abb80ce1e9d93841cf74ea84 ] This code accidentally checks ->ctrl_base instead of ->mbox_base so the error handling can never be triggered. Fixes: a4123ffab9ec ("mailbox: mpfs: support new, syscon based, devicetree configuration") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>