On 11/8/2021 12:06 PM, Hemant Kumar wrote:
Adding same comment in v2
On 11/8/2021 9:49 AM, Manivannan Sadhasivam wrote:
Some devices tend to trigger SYS_ERR interrupt while the host handling
SYS_ERR state of the device during power up. This creates a race
condition and causes a failure in booting up the device.
The issue is seen on the Sierra Wireless EM9191 modem during SYS_ERR
handling in mhi_async_power_up(). Once the host detects that the device
is in SYS_ERR state, it issues MHI_RESET and waits for the device to
process the reset request. During this time, the device triggers SYS_ERR
Device is not triggering the SYS_ERR interrupt, interrupt was triggered
due to MHI RESET was getting cleared by device.
Shouldn't the device state be RESET and not SYS_ERR at that point?
The device will enter SYS_ERR (and trigger an interrupt for that). Host
issues MHI_RESET. Device is expected to clear SYS_ERR and enter the
RESET state. Then the device clears MHI_RESET. Device can then trigger
an interrupt to signal the state change (per the updated spec).
I was going to add my reviewed-by, but I'm confused by your comment.
interrupt to the host and host starts handling SYS_ERR execution.
"As interrupts are setup, MHI reset results in device clearing the reset
and it sends incoming BHI interrupt with state still seen as SYS_ERROR
instead of READY."
So by the time the device has completed reset, host starts SYS_ERR
handling. This causes the race condition and the modem fails to boot.
Hence, register the IRQ handler only after handling the SYS_ERR check
to avoid getting spurious IRQs from the device.
Cc: stable@xxxxxxxxxxxxxxx
Fixes: e18d4e9fa79b ("bus: mhi: core: Handle syserr during power_up")
Reported-by: Aleksander Morgado <aleksander@xxxxxxxxxxxxx>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx>
---
[..]
