kernel/git/stable/linux.git/drivers/bus, branch linux-5.13.y

bus: fsl-mc: fix mmio base address for child DPRCs

2021-09-18T11:42:02+00:00

[ Upstream commit 8990f96a012f42543005b07d9e482694192e9309 ] Some versions of the MC firmware wrongly report 0 for register base address of the DPMCP associated with child DPRC objects thus rendering them unusable. This is particularly troublesome in ACPI boot scenarios where the legacy way of extracting this base address from the device tree does not apply. Given that DPMCPs share the same base address, workaround this by using the base address extracted from the root DPRC container. Signed-off-by: Laurentiu Tudor Link: https://lore.kernel.org/r/20210715140718.8513-8-laurentiu.tudor@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

bus: fsl-mc: fix arg in call to dprc_scan_objects()

2021-09-18T11:42:02+00:00

[ Upstream commit aa0a1ae020e2d24749e9f8085f12ca6d46899c94 ] Second parameter of dprc_scan_objects() is a bool not a pointer so change from NULL to false. Signed-off-by: Laurentiu Tudor Link: https://lore.kernel.org/r/20210715140718.8513-1-laurentiu.tudor@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

bus: ti-sysc: Fix error handling for sysc_check_active_timer()

2021-08-26T12:35:04+00:00

[ Upstream commit 06a089ef644934372a3062528244fca3417d3430 ] We have changed the return type for sysc_check_active_timer() from -EBUSY to -ENXIO, but the gpt12 system timer fix still checks for -EBUSY. We are also not returning on other errors like we did earlier as noted by Pavel Machek . Commit 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") should have been updated for commit 65fb73676112 ("bus: ti-sysc: suppress err msg for timers used as clockevent/source"). Let's fix the issue by checking for -ENXIO and returning on any other errors as suggested by Pavel Machek . Fixes: 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") Depends-on: 65fb73676112 ("bus: ti-sysc: suppress err msg for timers used as clockevent/source") Reported-by: Pavel Machek Reviewed-by: Pavel Machek (CIP) Cc: Grygorii Strashko Cc: Jarkko Nikula Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin

bus: ti-sysc: AM3: RNG is GP only

2021-08-12T11:32:22+00:00

commit a6d90e9f22328f07343e49e08a4ca483ae8e8abb upstream. Make the RNG on AM3 GP only. Based on this patch from TI v5.4 tree which is based on hwmod data which are now removed: | ARM: AM43xx: hwmod: Move RNG to a GP only links table | | On non-GP devices the RNG is controlled by the secure-side software, | like in DRA7xx hwmod we should not control this IP when we are not | a GP device. | | Signed-off-by: Andrew F. Davis Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Kevin Hilman Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman

bus: ti-sysc: Fix gpt12 system timer issue with reserved status

2021-08-12T11:32:02+00:00

[ Upstream commit 3ff340e24c9dd5cff9fc07d67914c5adf67f80d6 ] Jarkko Nikula reported that Beagleboard revision c2 stopped booting. Jarkko bisected the issue down to commit 6cfcd5563b4f ("clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4"). Let's fix the issue by tagging system timers as reserved rather than ignoring them. And let's not probe any interconnect target module child devices for reserved modules. This allows PM runtime to keep track of clocks and clockdomains for the interconnect target module, and prevent the system timer from idling as we already have SYSC_QUIRK_NO_IDLE and SYSC_QUIRK_NO_IDLE_ON_INIT flags set for system timers. Fixes: 6cfcd5563b4f ("clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4") Reported-by: Jarkko Nikula Tested-by: Jarkko Nikula Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin

bus: mhi: pci_generic: Fix inbound IPCR channel

2021-07-28T12:37:39+00:00

commit b8a97f2a65388394f433bf0730293a94f7d49046 upstream. The qrtr-mhi client driver assumes that inbound buffers are automatically allocated and queued by the MHI core, but this doesn't happen for mhi pci devices since IPCR inbound channel is not flagged with auto_queue, causing unusable IPCR (qrtr) feature. Fix that. Link: https://lore.kernel.org/r/1625736749-24947-1-git-send-email-loic.poulain@linaro.org [mani: fixed a spelling mistake in commit description] Fixes: 855a70c12021 ("bus: mhi: Add MHI PCI support for WWAN modems") Cc: stable@vger.kernel.org #5.10 Reviewed-by: Hemant kumar Reviewed-by: Manivannan Sadhasivam Signed-off-by: Loic Poulain Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210716075106.49938-4-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman

bus: mhi: core: Validate channel ID when processing command completions

2021-07-28T12:37:39+00:00

commit 546362a9ef2ef40b57c6605f14e88ced507f8dd0 upstream. MHI reads the channel ID from the event ring element sent by the device which can be any value between 0 and 255. In order to prevent any out of bound accesses, add a check against the maximum number of channels supported by the controller and those channels not configured yet so as to skip processing of that event ring element. Link: https://lore.kernel.org/r/1624558141-11045-1-git-send-email-bbhatt@codeaurora.org Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device") Cc: stable@vger.kernel.org #5.10 Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Signed-off-by: Bhaumik Bhatt Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210716075106.49938-3-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman

bus: mhi: pci_generic: Apply no-op for wake using sideband wake boolean

2021-07-28T12:37:38+00:00

commit 56f6f4c4eb2a710ec8878dd9373d3d2b2eb75f5c upstream. Devices such as SDX24 do not have the provision for inband wake doorbell in the form of channel 127 and instead have a sideband GPIO for it. Newer devices such as SDX55 or SDX65 support inband wake method by default. Ensure the functionality is used based on this such that device wake stays held when a client driver uses mhi_device_get() API or the equivalent debugfs entry. Link: https://lore.kernel.org/r/1624560809-30610-1-git-send-email-bbhatt@codeaurora.org Fixes: e3e5e6508fc1 ("bus: mhi: pci_generic: No-Op for device_wake operations") Cc: stable@vger.kernel.org #5.12 Reviewed-by: Manivannan Sadhasivam Signed-off-by: Bhaumik Bhatt Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210716075106.49938-2-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman

bus: mhi: pci-generic: Add missing 'pci_disable_pcie_error_reporting()' calls

2021-07-14T15:06:11+00:00

commit a25d144fb883c73506ba384de476bbaff8220a95 upstream. If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call Add the missing call in the error handling path of the probe and in the remove function. Cc: Fixes: b012ee6bfe2a ("mhi: pci_generic: Add PCI error handlers") Signed-off-by: Christophe JAILLET Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/f70c14701f4922d67e717633c91b6c481b59f298.1623445348.git.christophe.jaillet@wanadoo.fr Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210621161616.77524-6-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman

bus: mhi: Wait for M2 state during system resume

2021-07-14T15:06:11+00:00

commit 02b49cd1174527e611768fc2ce0f75a74dfec7ae upstream. During system resume, MHI host triggers M3->M0 transition and then waits for target device to enter M0 state. Once done, the device queues a state change event into ctrl event ring and notifies MHI host by raising an interrupt, where a tasklet is scheduled to process this event. In most cases, the tasklet is served timely and wait operation succeeds. However, there are cases where CPU is busy and cannot serve this tasklet for some time. Once delay goes long enough, the device moves itself to M1 state and also interrupts MHI host after inserting a new state change event to ctrl ring. Later when CPU finally has time to process the ring, there will be two events: 1. For M3->M0 event, which is the first event to be processed queued first. The tasklet handler serves the event, updates device state to M0 and wakes up the task. 2. For M0->M1 event, which is processed later, the tasklet handler triggers M1->M2 transition and updates device state to M2 directly, then wakes up the MHI host (if it is still sleeping on this wait queue). Note that although MHI host has been woken up while processing the first event, it may still has no chance to run before the second event is processed. In other words, MHI host has to keep waiting till timeout causing the M0 state to be missed. kernel log here: ... Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.911251] mhi 0000:06:00.0: Entered with PM state: M3, MHI state: M3 Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917762] mhi 0000:06:00.0: State change event to state: M0 Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917767] mhi 0000:06:00.0: State change event to state: M1 Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4338.788231] mhi 0000:06:00.0: Did not enter M0 state, MHI state: M2, PM state: M2 ... Fix this issue by simply adding M2 as a valid state for resume. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Cc: stable@vger.kernel.org Fixes: 0c6b20a1d720 ("bus: mhi: core: Add support for MHI suspend and resume") Signed-off-by: Baochen Qiang Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210524040312.14409-1-bqiang@codeaurora.org [mani: slightly massaged the commit message] Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210621161616.77524-4-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman