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@vger.kernel.org Fixes: e18d4e9fa79b ("bus: mhi: core: Handle syserr during power_up") Reported-by: Aleksander Morgado aleksander@aleksander.es Signed-off-by: Manivannan Sadhasivam manivannan.sadhasivam@linaro.org
[..]