linux-stable.git/drivers/bus, branch v5.10.71

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

2021-09-18T11:40:20+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: ti-sysc: Fix error handling for sysc_check_active_timer()

2021-08-26T12:35:42+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:22:16+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:22:01+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: core: Validate channel ID when processing command completions

2021-07-28T12:35:45+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: Wait for M2 state during system resume

2021-07-14T14:55:42+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

bus: ti-sysc: Fix flakey idling of uarts and stop using swsup_sidle_act

2021-06-10T11:39:22+00:00

[ Upstream commit c8692ad416dcc420ce1b403596a425c8f4c2720b ]

Looks like the swsup_sidle_act quirk handling is unreliable for serial
ports. The serial ports just eventually stop idling until woken up and
re-idled again. As the serial port not idling blocks any deeper SoC idle
states, it's adds an annoying random flakeyness for power management.

Let's just switch to swsup_sidle quirk instead like we already do for
omap3 uarts. This means we manually idle the port instead of trying to
use the hardware autoidle features when not in use.

For more details on why the serial ports have been using swsup_idle_act,
see commit 66dde54e978a ("ARM: OMAP2+: hwmod-data: UART IP needs software
control to manage sidle modes"). It seems that the swsup_idle_act quirk
handling is not enough though, and for example the TI Android kernel
changed to using swsup_sidle with commit 77c34c84e1e0 ("OMAP4: HWMOD:
UART1: disable smart-idle.").

Fixes: b4a9a7a38917 ("bus: ti-sysc: Handle swsup idle mode quirks")
Cc: Carl Philipp Klemm 
Cc: Ivan Jelincic 
Cc: Merlijn Wajer 
Cc: Pavel Machek 
Cc: Sebastian Reichel 
Cc: Sicelo A. Mhlongo 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: ti-sysc: Fix am335x resume hang for usb otg module

2021-06-10T11:39:21+00:00

[ Upstream commit 4d7b324e231366ea772ab10df46be31273ca39af ]

On am335x, suspend and resume only works once, and the system hangs if
suspend is attempted again. However, turns out suspend and resume works
fine multiple times if the USB OTG driver for musb controller is loaded.

The issue is caused my the interconnect target module losing context
during suspend, and it needs a restore on resume to be reconfigure again
as debugged earlier by Dave Gerlach .

There are also other modules that need a restore on resume, like gpmc as
noted by Dave. So let's add a common way to restore an interconnect
target module based on a quirk flag. For now, let's enable the quirk for
am335x otg only to fix the suspend and resume issue.

As gpmc is not causing hangs based on tests with BeagleBone, let's patch
gpmc separately. For gpmc, we also need a hardware reset done before
restore according to Dave.

To reinit the modules, we decouple system suspend from PM runtime. We
replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume()
with direct calls to internal functions and rely on the driver internal
state. There no point trying to handle complex system suspend and resume
quirks via PM runtime.

This is issue should have already been noticed with commit 1819ef2e2d12
("bus: ti-sysc: Use swsup quirks also for am335x musb") when quirk
handling was added for am335x otg for swsup. But the issue went unnoticed
as having musb driver loaded hides the issue, and suspend and resume works
once without the driver loaded.

Fixes: 1819ef2e2d12 ("bus: ti-sysc: Use swsup quirks also for am335x musb")
Suggested-by: Dave Gerlach 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: qcom: Put child node before return

2021-05-14T07:50:13+00:00

[ Upstream commit ac6ad7c2a862d682bb584a4bc904d89fa7721af8 ]

Put child node before return to fix potential reference count leak.
Generally, the reference count of child is incremented and decremented
automatically in the macro for_each_available_child_of_node() and should
be decremented manually if the loop is broken in loop body.

Reviewed-by: Linus Walleij 
Fixes: 335a12754808 ("bus: qcom: add EBI2 driver")
Signed-off-by: Pan Bian 
Link: https://lore.kernel.org/r/20210121114907.109267-1-bianpan2016@163.com
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin

bus: mhi: core: Clear context for stopped channels from remove()

2021-05-11T12:47:19+00:00

[ Upstream commit 4e44ae3d6d9c2c2a6d9356dd279c925532d5cd8c ]

If a channel was explicitly stopped but not reset and a driver
remove is issued, clean up the channel context such that it is
reflected on the device. This move is useful if a client driver
module is unloaded or a device crash occurs with the host having
placed the channel in a stopped state.

Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Hemant Kumar 
Reviewed-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/1617311778-1254-3-git-send-email-bbhatt@codeaurora.org
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Sasha Levin