From: Hemant Kumar <hemantk@codeaurora.org>
To: Jeffrey Hugo <quic_jhugo@quicinc.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
mhi@lists.linux.dev
Cc: aleksander@aleksander.es, loic.poulain@linaro.org,
thomas.perrot@bootlin.com, bbhatt@codeaurora.org,
linux-arm-msm@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] bus: mhi: Fix race while handling SYS_ERR at power up
Date: Wed, 17 Nov 2021 12:20:34 -0800 [thread overview]
Message-ID: <53240ad1-06e0-fdec-c8f6-33a83e6ae2af@codeaurora.org> (raw)
In-Reply-To: <c6fd34ff-7f19-2ab1-ee3c-f6be178bf9a2@quicinc.com>
On 11/17/2021 9:24 AM, Jeffrey Hugo wrote:
> 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).
Dmesg log was showing first sys err was triggered by device, as part of
sys error handling host was setting MHI_RESET and expecting to get BHI
Intvec. When BHI intvec was triggered by device, host handled it by
checking the MHI status register. MHi status was still showing SYS_ERR
being set (which was supposed to get cleared after host issuing MHI
RESET). Due to that host side bhi intvec threaded handler took diff path
to handle sys error again. This is what we are trying to avoid as we
think for some reason device is not behaving as per spec and either
setting sys err again or not clearing it by the time bhi intvec (for
reset clear) is handled by host.
>
> I was going to add my reviewed-by, but I'm confused by your comment.
>
[..]
Thanks,
Hemant
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2021-11-17 20:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 17:49 [PATCH v2] bus: mhi: Fix race while handling SYS_ERR at power up Manivannan Sadhasivam
2021-11-08 19:01 ` Bhaumik Bhatt
2021-11-08 19:06 ` Hemant Kumar
2021-11-17 17:24 ` Jeffrey Hugo
2021-11-17 20:20 ` Hemant Kumar [this message]
2021-11-18 5:36 ` Manivannan Sadhasivam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53240ad1-06e0-fdec-c8f6-33a83e6ae2af@codeaurora.org \
--to=hemantk@codeaurora.org \
--cc=aleksander@aleksander.es \
--cc=bbhatt@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mhi@lists.linux.dev \
--cc=quic_jhugo@quicinc.com \
--cc=stable@vger.kernel.org \
--cc=thomas.perrot@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).