user/sven/linux.git/drivers/bus, branch v6.1.21

bus: mhi: ep: Change state_lock to mutex

2023-03-17T07:50:19Z

[ Upstream commit 1ddc7618294084fff8d673217a9479550990ee84 ] state_lock, the spinlock type is meant to protect race against concurrent MHI state transitions. In mhi_ep_set_m0_state(), while the state_lock is being held, the channels are resumed in mhi_ep_resume_channels() if the previous state was M3. This causes sleeping in atomic bug, since mhi_ep_resume_channels() use mutex internally. Since the state_lock is supposed to be held throughout the state change, it is not ideal to drop the lock before calling mhi_ep_resume_channels(). So to fix this issue, let's change the type of state_lock to mutex. This would also allow holding the lock throughout all state transitions thereby avoiding any potential race. Cc: # 5.19 Fixes: e4b7b5f0f30a ("bus: mhi: ep: Add support for suspending and resuming channels") Reported-by: Dan Carpenter Reviewed-by: Jeffrey Hugo Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin

bus: mhi: ep: Power up/down MHI stack during MHI RESET

2023-03-17T07:50:19Z

[ Upstream commit 47a1dcaea07367c84238e71c08244ae3ed48c1cc ] During graceful shutdown scenario, host will issue MHI RESET to the endpoint device before initiating shutdown. In that case, it makes sense to completely power down the MHI stack as sooner or later the access to MMIO registers will be prohibited. Also, the stack needs to be powered up in the case of SYS_ERR to recover the device. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Link: https://lore.kernel.org/r/20221228161704.255268-2-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Stable-dep-of: 1ddc76182940 ("bus: mhi: ep: Change state_lock to mutex") Signed-off-by: Sasha Levin

bus: mhi: ep: Fix the debug message for MHI_PKT_TYPE_RESET_CHAN_CMD cmd

2023-03-11T12:55:35Z

[ Upstream commit 8e697fcfdb9809634e268058ca743369c216b7ac ] The debug log incorrectly mentions that STOP command is received instead of RESET command. Fix that. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Link: https://lore.kernel.org/r/20221228161704.255268-5-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin

bus: mhi: ep: Save channel state locally during suspend and resume

2023-03-10T08:34:31Z

commit 8a1c24bb908f9ecbc4be0fea014df67d43161551 upstream. During suspend and resume, the channel state needs to be saved locally. Otherwise, the endpoint may access the channels while they were being suspended and causing access violations. Fix it by saving the channel state locally during suspend and resume. Cc: # 5.19 Fixes: e4b7b5f0f30a ("bus: mhi: ep: Add support for suspending and resuming channels") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Signed-off-by: Greg Kroah-Hartman

bus: mhi: ep: Move chan->lock to the start of processing queued ch ring

2023-03-10T08:34:31Z

commit 8d6a1fea53864cd9545741f48f4ae4df804db557 upstream. There is a good chance that while the channel ring gets processed, the STOP or RESET command for the channel might be received from the MHI host. In those cases, the entire channel ring processing needs to be protected by chan->lock to prevent the race where the corresponding channel ring might be reset. While at it, let's also add a sanity check to make sure that the ring is started before processing it. Because, if the STOP/RESET command gets processed while mhi_ep_ch_ring_worker() waited for chan->lock, the ring would've been reset. Cc: # 5.19 Fixes: 03c0bb8ec983 ("bus: mhi: ep: Add support for processing channel rings") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Link: https://lore.kernel.org/r/20221228161704.255268-6-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman

bus: mhi: ep: Only send -ENOTCONN status if client driver is available

2023-03-10T08:34:31Z

commit e6cebcc27519dcf1652e604c73b9fd4f416987c0 upstream. For the STOP and RESET commands, only send the channel disconnect status -ENOTCONN if client driver is available. Otherwise, it will result in null pointer dereference. Cc: # 5.19 Fixes: e827569062a8 ("bus: mhi: ep: Add support for processing command rings") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Link: https://lore.kernel.org/r/20221228161704.255268-4-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman

bus: sunxi-rsb: Fix error handling in sunxi_rsb_init()

2023-02-09T10:27:59Z

[ Upstream commit f71eaf2708be7831428eacae7db25d8ec6b8b4c5 ] The sunxi_rsb_init() returns the platform_driver_register() directly without checking its return value, if platform_driver_register() failed, the sunxi_rsb_bus is not unregistered. Fix by unregister sunxi_rsb_bus when platform_driver_register() failed. Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus") Signed-off-by: Yuan Can Reviewed-by: Jernej Skrabec Link: https://lore.kernel.org/r/20221123094200.12036-1-yuancan@huawei.com Signed-off-by: Jernej Skrabec Signed-off-by: Sasha Levin

bus: mhi: host: Fix race between channel preparation and M0 event

2023-01-07T10:11:54Z

commit 869a99907faea6d1835b0bd0d0422ae3519c6ea9 upstream. There is a race condition where mhi_prepare_channel() updates the read and write pointers as the base address and in parallel, if an M0 transition occurs, the tasklet goes ahead and rings doorbells for all channels with a delta in TRE rings assuming they are already enabled. This causes a null pointer access. Fix it by adding a channel enabled check before ringing channel doorbells. Cc: stable@vger.kernel.org # 5.19 Fixes: a6e2e3522f29 "bus: mhi: core: Add support for PM state transitions" Signed-off-by: Qiang Yu Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/1665889532-13634-1-git-send-email-quic_qianyu@quicinc.com [mani: CCed stable list] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman

bus: ixp4xx: Don't touch bit 7 on IXP42x

2022-11-22T22:12:18Z

We face some regressions on a few IXP42x systems when accessing flash, the following unrelated error prints appear from the PCI driver: ixp4xx-pci c0000000.pci: PCI: abort_handler addr = 0xff9ffb5f, isr = 0x0, status = 0x22a0 ixp4xx-pci c0000000.pci: imprecise abort (...) It turns out that while bit 7 is masked "reserved" it is not unused, so masking it off as zero is dangerous, and breaks flash access on some systems such as the NSLU2. Be more careful and avoid masking off any of the reserved bits 7, 8, 9 or 30. Only keep masking EXP_WORD (bit 2) on IXP43x which is necessary in some setups. Fixes: 1c953bda90ca ("bus: ixp4xx: Add a driver for IXP4xx expansion bus") Signed-off-by: Linus Walleij Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221122134411.2030372-1-linus.walleij@linaro.org Signed-off-by: Arnd Bergmann

bus: sunxi-rsb: Support atomic transfers

2022-11-16T18:28:48Z

When communicating with a PMIC during system poweroff (pm_power_off()), IRQs are disabled and we are in a RCU read-side critical section, so we cannot use wait_for_completion_io_timeout(). Instead, poll the status register for transfer completion. Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus") Signed-off-by: Samuel Holland Reviewed-by: Jernej Skrabec Link: https://lore.kernel.org/r/20221114015749.28490-3-samuel@sholland.org Signed-off-by: Jernej Skrabec