From: Jeffrey Hugo <[email protected]>
After the device has signaled the end of reset by clearing the reset bit,
it will automatically reinit MHI and the internal device structures. Once
That is done, the device will signal it has entered the ready state.
Signaling the ready state involves sending an interrupt (MSI) to the host
which might cause IOMMU faults if it occurs at the wrong time.
If the controller is being powered down, and possibly removed, then the
reset flow would only wait for the end of reset. At which point, the host
and device would start a race. The host may complete its reset work, and
remove the interrupt handler, which would cause the interrupt to be
disabled in the IOMMU. If that occurs before the device signals the ready
state, then the IOMMU will fault since it blocked an interrupt. While
harmless, the fault would appear like a serious issue has occurred so let's
silence it by making sure the device hits the ready state before the host
completes its reset processing.
Signed-off-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Hemant Kumar <[email protected]>
Signed-off-by: Jeffrey Hugo <[email protected]>
---
v3:
Rebase and use dev_err over dev_warn
v2:
Fix subject and remove use of cur_state
drivers/bus/mhi/host/pm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/bus/mhi/host/pm.c b/drivers/bus/mhi/host/pm.c
index a0e91bd..f46158e 100644
--- a/drivers/bus/mhi/host/pm.c
+++ b/drivers/bus/mhi/host/pm.c
@@ -483,6 +483,15 @@ static void mhi_pm_disable_transition(struct mhi_controller *mhi_cntrl)
* hence re-program it
*/
mhi_write_reg(mhi_cntrl, mhi_cntrl->bhi, BHI_INTVEC, 0);
+
+ if (!MHI_IN_PBL(mhi_get_exec_env(mhi_cntrl))) {
+ /* wait for ready to be set */
+ ret = mhi_poll_reg_field(mhi_cntrl, mhi_cntrl->regs,
+ MHISTATUS,
+ MHISTATUS_READY_MASK, 1, 25000);
+ if (ret)
+ dev_err(dev, "Device failed to enter READY state\n");
+ }
}
dev_dbg(dev,
--
2.7.4
On Wed, Apr 13, 2022 at 12:52:26PM -0600, Jeffrey Hugo wrote:
> From: Jeffrey Hugo <[email protected]>
>
> After the device has signaled the end of reset by clearing the reset bit,
> it will automatically reinit MHI and the internal device structures. Once
> That is done, the device will signal it has entered the ready state.
>
> Signaling the ready state involves sending an interrupt (MSI) to the host
> which might cause IOMMU faults if it occurs at the wrong time.
>
> If the controller is being powered down, and possibly removed, then the
> reset flow would only wait for the end of reset. At which point, the host
> and device would start a race. The host may complete its reset work, and
> remove the interrupt handler, which would cause the interrupt to be
> disabled in the IOMMU. If that occurs before the device signals the ready
> state, then the IOMMU will fault since it blocked an interrupt. While
> harmless, the fault would appear like a serious issue has occurred so let's
> silence it by making sure the device hits the ready state before the host
> completes its reset processing.
>
> Signed-off-by: Jeffrey Hugo <[email protected]>
> Reviewed-by: Hemant Kumar <[email protected]>
> Signed-off-by: Jeffrey Hugo <[email protected]>
I was about to apply this patch but wanted to check with you on using the
double signed-off by tags. If the patch get's handed over between multiple
developers then multiple signed-off by's make sense. But since it is you that
handled the earlier patch also, I think one tag is enough with your new domain.
One more thing is, using codeaurora domain will bounce now. So, please use the
quicinc domain for Hemant also.
Thanks,
Mani
> ---
>
> v3:
> Rebase and use dev_err over dev_warn
>
> v2:
> Fix subject and remove use of cur_state
>
> drivers/bus/mhi/host/pm.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/bus/mhi/host/pm.c b/drivers/bus/mhi/host/pm.c
> index a0e91bd..f46158e 100644
> --- a/drivers/bus/mhi/host/pm.c
> +++ b/drivers/bus/mhi/host/pm.c
> @@ -483,6 +483,15 @@ static void mhi_pm_disable_transition(struct mhi_controller *mhi_cntrl)
> * hence re-program it
> */
> mhi_write_reg(mhi_cntrl, mhi_cntrl->bhi, BHI_INTVEC, 0);
> +
> + if (!MHI_IN_PBL(mhi_get_exec_env(mhi_cntrl))) {
> + /* wait for ready to be set */
> + ret = mhi_poll_reg_field(mhi_cntrl, mhi_cntrl->regs,
> + MHISTATUS,
> + MHISTATUS_READY_MASK, 1, 25000);
> + if (ret)
> + dev_err(dev, "Device failed to enter READY state\n");
> + }
> }
>
> dev_dbg(dev,
> --
> 2.7.4
>
On Wed, Apr 13, 2022 at 12:52:26PM -0600, Jeffrey Hugo wrote:
> From: Jeffrey Hugo <[email protected]>
>
> After the device has signaled the end of reset by clearing the reset bit,
> it will automatically reinit MHI and the internal device structures. Once
> That is done, the device will signal it has entered the ready state.
>
> Signaling the ready state involves sending an interrupt (MSI) to the host
> which might cause IOMMU faults if it occurs at the wrong time.
>
> If the controller is being powered down, and possibly removed, then the
> reset flow would only wait for the end of reset. At which point, the host
> and device would start a race. The host may complete its reset work, and
> remove the interrupt handler, which would cause the interrupt to be
> disabled in the IOMMU. If that occurs before the device signals the ready
> state, then the IOMMU will fault since it blocked an interrupt. While
> harmless, the fault would appear like a serious issue has occurred so let's
> silence it by making sure the device hits the ready state before the host
> completes its reset processing.
>
> Signed-off-by: Jeffrey Hugo <[email protected]>
> Reviewed-by: Hemant Kumar <[email protected]>
> Signed-off-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Thanks,
Mani
> ---
>
> v3:
> Rebase and use dev_err over dev_warn
>
> v2:
> Fix subject and remove use of cur_state
>
> drivers/bus/mhi/host/pm.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/bus/mhi/host/pm.c b/drivers/bus/mhi/host/pm.c
> index a0e91bd..f46158e 100644
> --- a/drivers/bus/mhi/host/pm.c
> +++ b/drivers/bus/mhi/host/pm.c
> @@ -483,6 +483,15 @@ static void mhi_pm_disable_transition(struct mhi_controller *mhi_cntrl)
> * hence re-program it
> */
> mhi_write_reg(mhi_cntrl, mhi_cntrl->bhi, BHI_INTVEC, 0);
> +
> + if (!MHI_IN_PBL(mhi_get_exec_env(mhi_cntrl))) {
> + /* wait for ready to be set */
> + ret = mhi_poll_reg_field(mhi_cntrl, mhi_cntrl->regs,
> + MHISTATUS,
> + MHISTATUS_READY_MASK, 1, 25000);
> + if (ret)
> + dev_err(dev, "Device failed to enter READY state\n");
> + }
> }
>
> dev_dbg(dev,
> --
> 2.7.4
>
>
On Mon, Apr 18, 2022 at 07:53:24AM -0600, Jeffrey Hugo wrote:
> On 4/18/2022 12:26 AM, Manivannan Sadhasivam wrote:
> > On Wed, Apr 13, 2022 at 12:52:26PM -0600, Jeffrey Hugo wrote:
> > > From: Jeffrey Hugo <[email protected]>
> > >
> > > After the device has signaled the end of reset by clearing the reset bit,
> > > it will automatically reinit MHI and the internal device structures. Once
> > > That is done, the device will signal it has entered the ready state.
> > >
> > > Signaling the ready state involves sending an interrupt (MSI) to the host
> > > which might cause IOMMU faults if it occurs at the wrong time.
> > >
> > > If the controller is being powered down, and possibly removed, then the
> > > reset flow would only wait for the end of reset. At which point, the host
> > > and device would start a race. The host may complete its reset work, and
> > > remove the interrupt handler, which would cause the interrupt to be
> > > disabled in the IOMMU. If that occurs before the device signals the ready
> > > state, then the IOMMU will fault since it blocked an interrupt. While
> > > harmless, the fault would appear like a serious issue has occurred so let's
> > > silence it by making sure the device hits the ready state before the host
> > > completes its reset processing.
> > >
> > > Signed-off-by: Jeffrey Hugo <[email protected]>
> > > Reviewed-by: Hemant Kumar <[email protected]>
> > > Signed-off-by: Jeffrey Hugo <[email protected]>
> >
> > I was about to apply this patch but wanted to check with you on using the
> > double signed-off by tags. If the patch get's handed over between multiple
> > developers then multiple signed-off by's make sense. But since it is you that
> > handled the earlier patch also, I think one tag is enough with your new domain.
> >
> > One more thing is, using codeaurora domain will bounce now. So, please use the
> > quicinc domain for Hemant also.
>
> I'm aware of the bouncing. Git send-email however is not, and its default
> behavior can be a bit annoying in this edge case.
>
> I've seen the dual SoB by the same developer elsewhere in the community, but
> if you want things "cleaned up" to the new quic ids, I'll do that.
Double s-o-b's are common but in this case you handled the patch all the way and
you are still employed by the same employer. Only thing that changed is your
domain, so this makes me feel that single s-o-b is enough.
Thanks,
Mani
On 4/18/2022 12:26 AM, Manivannan Sadhasivam wrote:
> On Wed, Apr 13, 2022 at 12:52:26PM -0600, Jeffrey Hugo wrote:
>> From: Jeffrey Hugo <[email protected]>
>>
>> After the device has signaled the end of reset by clearing the reset bit,
>> it will automatically reinit MHI and the internal device structures. Once
>> That is done, the device will signal it has entered the ready state.
>>
>> Signaling the ready state involves sending an interrupt (MSI) to the host
>> which might cause IOMMU faults if it occurs at the wrong time.
>>
>> If the controller is being powered down, and possibly removed, then the
>> reset flow would only wait for the end of reset. At which point, the host
>> and device would start a race. The host may complete its reset work, and
>> remove the interrupt handler, which would cause the interrupt to be
>> disabled in the IOMMU. If that occurs before the device signals the ready
>> state, then the IOMMU will fault since it blocked an interrupt. While
>> harmless, the fault would appear like a serious issue has occurred so let's
>> silence it by making sure the device hits the ready state before the host
>> completes its reset processing.
>>
>> Signed-off-by: Jeffrey Hugo <[email protected]>
>> Reviewed-by: Hemant Kumar <[email protected]>
>> Signed-off-by: Jeffrey Hugo <[email protected]>
>
> I was about to apply this patch but wanted to check with you on using the
> double signed-off by tags. If the patch get's handed over between multiple
> developers then multiple signed-off by's make sense. But since it is you that
> handled the earlier patch also, I think one tag is enough with your new domain.
>
> One more thing is, using codeaurora domain will bounce now. So, please use the
> quicinc domain for Hemant also.
I'm aware of the bouncing. Git send-email however is not, and its
default behavior can be a bit annoying in this edge case.
I've seen the dual SoB by the same developer elsewhere in the community,
but if you want things "cleaned up" to the new quic ids, I'll do that.