[PATCH v3] usb: ohci: add check for host controller functional states

[PATCH v3] usb: ohci: add check for host controller functional states

[Yinbo Zhu]

The usb states of ohci controller include UsbOperational, UsbReset,
UsbSuspend and UsbResume. Among them, only the UsbOperational state
supports launching the start of frame for host controller according
the ohci protocol spec, but in S3/S4 press test procedure, it may
happen that the start of frame was launched in other usb states and
cause ohci works abnormally then kernel will allways report rcu
call trace. This patch was to add check for host controller
functional states and if it is not UsbOperational state that need
set INTR_SF in intrdisable register to ensure SOF Token generation
was been disabled.

Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
---
Change in v3:
		Rework the commit information.
		Move the patch code change to lower down position in ohci_irq.


 drivers/usb/host/ohci-hcd.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 1f5e693..87aa9bb 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -879,7 +879,8 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
 {
 	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
 	struct ohci_regs __iomem *regs = ohci->regs;
-	int			ints;
+	int			ints, ctl;
+
 
 	/* Read interrupt status (and flush pending writes).  We ignore the
 	 * optimization of checking the LSB of hcca->done_head; it doesn't
@@ -969,9 +970,15 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
 	 * when there's still unlinking to be done (next frame).
 	 */
 	ohci_work(ohci);
-	if ((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
-			&& ohci->rh_state == OHCI_RH_RUNNING)
+
+	ctl = ohci_readl(ohci, &regs->control);
+
+	if (((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
+			&& ohci->rh_state == OHCI_RH_RUNNING) ||
+			((ctl & OHCI_CTRL_HCFS) != OHCI_USB_OPER)) {
 		ohci_writel (ohci, OHCI_INTR_SF, &regs->intrdisable);
+		(void)ohci_readl(ohci, &regs->intrdisable);
+	}
 
 	if (ohci->rh_state == OHCI_RH_RUNNING) {
 		ohci_writel (ohci, ints, &regs->intrstatus);
-- 
1.8.3.1

Re: [PATCH v3] usb: ohci: add check for host controller functional states

[Alan Stern]

On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
> The usb states of ohci controller include UsbOperational, UsbReset,
> UsbSuspend and UsbResume. Among them, only the UsbOperational state
> supports launching the start of frame for host controller according
> the ohci protocol spec, but in S3/S4 press test procedure, it may

Nobody reading this will know what "S3/S4 press test procedure" means.  
You have to explain it, or use a different name that people will 
understand.

> happen that the start of frame was launched in other usb states and
> cause ohci works abnormally then kernel will allways report rcu
> call trace. This patch was to add check for host controller
> functional states and if it is not UsbOperational state that need
> set INTR_SF in intrdisable register to ensure SOF Token generation
> was been disabled.

This doesn't make sense.  You already mentioned that only the 
UsbOperational state supports sending start-of-frame packets.  So if the 
controller is in a different state then it won't send these packets, 
whether INTR_SF is enabled or not.

What problem are you really trying to solve?

> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
> ---
> Change in v3:
> 		Rework the commit information.
> 		Move the patch code change to lower down position in ohci_irq.
> 
> 
>  drivers/usb/host/ohci-hcd.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 1f5e693..87aa9bb 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -879,7 +879,8 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
>  {
>  	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
>  	struct ohci_regs __iomem *regs = ohci->regs;
> -	int			ints;
> +	int			ints, ctl;
> +

Extra blank line not needed.

>  
>  	/* Read interrupt status (and flush pending writes).  We ignore the
>  	 * optimization of checking the LSB of hcca->done_head; it doesn't
> @@ -969,9 +970,15 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
>  	 * when there's still unlinking to be done (next frame).
>  	 */
>  	ohci_work(ohci);
> -	if ((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
> -			&& ohci->rh_state == OHCI_RH_RUNNING)
> +
> +	ctl = ohci_readl(ohci, &regs->control);
> +

Blank lines not needed.

> +	if (((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
> +			&& ohci->rh_state == OHCI_RH_RUNNING) ||
> +			((ctl & OHCI_CTRL_HCFS) != OHCI_USB_OPER)) {
>  		ohci_writel (ohci, OHCI_INTR_SF, &regs->intrdisable);
> +		(void)ohci_readl(ohci, &regs->intrdisable);
> +	}

This is definitely wrong.  You must not turn off SF interrupts when 
ed_rm_list is non-NULL.  If you do, the driver will not be able to 
finish unlinking URBs.

Alan Stern

Re: [PATCH v3] usb: ohci: add check for host controller functional states

[zhuyinbo]

在 2021/10/8 下午10:26, Alan Stern 写道:
> On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
>> The usb states of ohci controller include UsbOperational, UsbReset,
>> UsbSuspend and UsbResume. Among them, only the UsbOperational state
>> supports launching the start of frame for host controller according
>> the ohci protocol spec, but in S3/S4 press test procedure, it may
> Nobody reading this will know what "S3/S4 press test procedure" means.
> You have to explain it, or use a different name that people will
> understand.
okay, I got it.
>> happen that the start of frame was launched in other usb states and
>> cause ohci works abnormally then kernel will allways report rcu
>> call trace. This patch was to add check for host controller
>> functional states and if it is not UsbOperational state that need
>> set INTR_SF in intrdisable register to ensure SOF Token generation
>> was been disabled.
> This doesn't make sense.  You already mentioned that only the
> UsbOperational state supports sending start-of-frame packets.  So if the
> controller is in a different state then it won't send these packets,
> whether INTR_SF is enabled or not.
>
> What problem are you really trying to solve?

Only UsbOperational state supports sending start-of-frame packets, but 
in fact, in S3/S4 press test procedure,

usb in non-UsbOperational state that send start-of-frame packets but hc 
driver doesn't deal with this frame. and hc will

allways lauched the SOF for finishing the frame, the cpu will hand this 
sof interrupt and doesn't deal with time interrupt

that will cause rcu call trace then system doesn't suspend to memory/disk.

>> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
>> ---
>> Change in v3:
>> 		Rework the commit information.
>> 		Move the patch code change to lower down position in ohci_irq.
>>
>>
>>   drivers/usb/host/ohci-hcd.c | 13 ++++++++++---
>>   1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> index 1f5e693..87aa9bb 100644
>> --- a/drivers/usb/host/ohci-hcd.c
>> +++ b/drivers/usb/host/ohci-hcd.c
>> @@ -879,7 +879,8 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
>>   {
>>   	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
>>   	struct ohci_regs __iomem *regs = ohci->regs;
>> -	int			ints;
>> +	int			ints, ctl;
>> +
> Extra blank line not needed.
>
>>   
>>   	/* Read interrupt status (and flush pending writes).  We ignore the
>>   	 * optimization of checking the LSB of hcca->done_head; it doesn't
>> @@ -969,9 +970,15 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
>>   	 * when there's still unlinking to be done (next frame).
>>   	 */
>>   	ohci_work(ohci);
>> -	if ((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
>> -			&& ohci->rh_state == OHCI_RH_RUNNING)
>> +
>> +	ctl = ohci_readl(ohci, &regs->control);
>> +
> Blank lines not needed.
>
>> +	if (((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
>> +			&& ohci->rh_state == OHCI_RH_RUNNING) ||
>> +			((ctl & OHCI_CTRL_HCFS) != OHCI_USB_OPER)) {
>>   		ohci_writel (ohci, OHCI_INTR_SF, &regs->intrdisable);
>> +		(void)ohci_readl(ohci, &regs->intrdisable);
>> +	}
> This is definitely wrong.  You must not turn off SF interrupts when
> ed_rm_list is non-NULL.  If you do, the driver will not be able to
> finish unlinking URBs.
>
> Alan Stern

Hi Alan Stern,

     even though ed_rm_list is non-NULL, if hc in non-UsbOperation state 
set SoF status in usbsts register that is illegal,

at this time hcd doesn't need care URB whether finished,  because hc had 
into a wrong state. even thoug it doesn't has this patch,

URB was not be able to finish when hc in above worng state. except 
software can intervence this wrong state. but the SoF bit of usbsts

register was set by HC, and this action will happen always !!! software 
clear SoF state I think it isn't make sense. software only disable SoF

interrupt to fix HC wrong state.

       In additon, when kernel include my patch, that it does't happen 
about what you descriped that driver will not be able to finish 
unlinging URBs.

Because above issue happen in S3/S4(Suspend to disk/Suspend to mem) test 
procedure, if ed_rm_lis is no-NULL but my patch disable SoF interrupt.

then when S3/S4 recovery to cpu idle state that usb resume will be 
called, reume function has following logic, URB will continue to be 
processed.

       static int ohci_rh_resume (struct ohci_hcd *ohci)

      {

         ...

         242         if (ohci->ed_rm_list)
         243                 ohci_writel (ohci, OHCI_INTR_SF, 
&ohci->regs->intrenable);

        ...

       }

BRS,

Yinbo Zhu.

Re: [PATCH v3] usb: ohci: add check for host controller functional states

[Alan Stern]

On Sat, Oct 09, 2021 at 10:01:25AM +0800, zhuyinbo wrote:
> 
> 在 2021/10/8 下午10:26, Alan Stern 写道:
> > On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
> > > The usb states of ohci controller include UsbOperational, UsbReset,
> > > UsbSuspend and UsbResume. Among them, only the UsbOperational state
> > > supports launching the start of frame for host controller according
> > > the ohci protocol spec, but in S3/S4 press test procedure, it may
> > Nobody reading this will know what "S3/S4 press test procedure" means.
> > You have to explain it, or use a different name that people will
> > understand.
> okay, I got it.
> > > happen that the start of frame was launched in other usb states and
> > > cause ohci works abnormally then kernel will allways report rcu
> > > call trace. This patch was to add check for host controller
> > > functional states and if it is not UsbOperational state that need
> > > set INTR_SF in intrdisable register to ensure SOF Token generation
> > > was been disabled.
> > This doesn't make sense.  You already mentioned that only the
> > UsbOperational state supports sending start-of-frame packets.  So if the
> > controller is in a different state then it won't send these packets,
> > whether INTR_SF is enabled or not.
> > 
> > What problem are you really trying to solve?
> 
> Only UsbOperational state supports sending start-of-frame packets, but in
> fact, in S3/S4 press test procedure,
> 
> usb in non-UsbOperational state that send start-of-frame packets but hc
> driver doesn't deal with this frame. and hc will
> 
> allways lauched the SOF for finishing the frame, the cpu will hand this sof
> interrupt and doesn't deal with time interrupt
> 
> that will cause rcu call trace then system doesn't suspend to memory/disk.

I still don't understand.

Are you saying that your OHCI controller behaves badly because it sends 
SOF packets even when the state is different from UsbOperational?

> Hi Alan Stern,
> 
>     even though ed_rm_list is non-NULL, if hc in non-UsbOperation state set
> SoF status in usbsts register that is illegal,
> 
> at this time hcd doesn't need care URB whether finished,  because hc had
> into a wrong state. even thoug it doesn't has this patch,
> 
> URB was not be able to finish when hc in above worng state. except software
> can intervence this wrong state. but the SoF bit of usbsts
> 
> register was set by HC, and this action will happen always !!! software
> clear SoF state I think it isn't make sense. software only disable SoF
> 
> interrupt to fix HC wrong state.

This problem happens when you go into S3 or S4 suspend, right?  So you 
should fix the problem by disabling INTR_SF when the root hub is 
suspended.  Try adding

	/* All ED unlinks should be finished, no need for SOF interrupts */
	ohci_writel(ohci, OHCI_INTR_SF, &ohci->regs->intrdisable);

into ohci_rh_suspend(), just before the update_done_list() call.  If you 
add this then INTR_SF will not be enabled during S3 or S4 suspend, so 
the problem shouldn't occur.  Does that work for you?

>       In additon, when kernel include my patch, that it does't happen about
> what you descriped that driver will not be able to finish unlinging URBs.
> 
> Because above issue happen in S3/S4(Suspend to disk/Suspend to mem) test
> procedure, if ed_rm_lis is no-NULL but my patch disable SoF interrupt.
> 
> then when S3/S4 recovery to cpu idle state that usb resume will be called,
> reume function has following logic, URB will continue to be processed.
> 
>       static int ohci_rh_resume (struct ohci_hcd *ohci)
> 
>      {
> 
>         ...
> 
>         242         if (ohci->ed_rm_list)
>         243                 ohci_writel (ohci, OHCI_INTR_SF,
> &ohci->regs->intrenable);
> 
>        ...
> 
>       }

I'm worried that your patch may disable INTR_SF even when the controller 
has not gone into S3 or S4 suspend.  Maybe this won't cause problems, 
but it's better to be safe and do the disable _only_ when a suspend 
occurs.

Alan Stern

Re: [PATCH v3] usb: ohci: add check for host controller functional states

[zhuyinbo]

在 2021/10/10 上午3:39, Alan Stern 写道:
> On Sat, Oct 09, 2021 at 10:01:25AM +0800, zhuyinbo wrote:
>> 在 2021/10/8 下午10:26, Alan Stern 写道:
>>> On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
>>>> The usb states of ohci controller include UsbOperational, UsbReset,
>>>> UsbSuspend and UsbResume. Among them, only the UsbOperational state
>>>> supports launching the start of frame for host controller according
>>>> the ohci protocol spec, but in S3/S4 press test procedure, it may
>>> Nobody reading this will know what "S3/S4 press test procedure" means.
>>> You have to explain it, or use a different name that people will
>>> understand.
>> okay, I got it.
>>>> happen that the start of frame was launched in other usb states and
>>>> cause ohci works abnormally then kernel will allways report rcu
>>>> call trace. This patch was to add check for host controller
>>>> functional states and if it is not UsbOperational state that need
>>>> set INTR_SF in intrdisable register to ensure SOF Token generation
>>>> was been disabled.
>>> This doesn't make sense.  You already mentioned that only the
>>> UsbOperational state supports sending start-of-frame packets.  So if the
>>> controller is in a different state then it won't send these packets,
>>> whether INTR_SF is enabled or not.
>>>
>>> What problem are you really trying to solve?
>> Only UsbOperational state supports sending start-of-frame packets, but in
>> fact, in S3/S4 press test procedure,
>>
>> usb in non-UsbOperational state that send start-of-frame packets but hc
>> driver doesn't deal with this frame. and hc will
>>
>> allways lauched the SOF for finishing the frame, the cpu will hand this sof
>> interrupt and doesn't deal with time interrupt
>>
>> that will cause rcu call trace then system doesn't suspend to memory/disk.
> I still don't understand.
>
> Are you saying that your OHCI controller behaves badly because it sends
> SOF packets even when the state is different from UsbOperational?

HC will allways report the SoF interrupt in the all time when HC was not 
in NO-UsbOperation state.

and no WritebackDoneHead interrupt that is the issue phenomenon. and 
this situation is badly state for ohci.

>
>> Hi Alan Stern,
>>
>>      even though ed_rm_list is non-NULL, if hc in non-UsbOperation state set
>> SoF status in usbsts register that is illegal,
>>
>> at this time hcd doesn't need care URB whether finished,  because hc had
>> into a wrong state. even thoug it doesn't has this patch,
>>
>> URB was not be able to finish when hc in above worng state. except software
>> can intervence this wrong state. but the SoF bit of usbsts
>>
>> register was set by HC, and this action will happen always !!! software
>> clear SoF state I think it isn't make sense. software only disable SoF
>>
>> interrupt to fix HC wrong state.
> This problem happens when you go into S3 or S4 suspend, right?  So you
> should fix the problem by disabling INTR_SF when the root hub is
> suspended.  Try adding
>
> 	/* All ED unlinks should be finished, no need for SOF interrupts */
> 	ohci_writel(ohci, OHCI_INTR_SF, &ohci->regs->intrdisable);
>
> into ohci_rh_suspend(), just before the update_done_list() call.  If you
> add this then INTR_SF will not be enabled during S3 or S4 suspend, so
> the problem shouldn't occur.  Does that work for you?

The system doesn't suspend to disk completely by my test result and hc 
will always produce SoF interrupt.

I encountered SoF interrupt  issue when HC in UsbSuspend state. and I 
think when hc in

UsbResume/UsbRest/ SoF interrupt issue may be happen so I disable 
INTR_SF in ohci_irq.

So I think disable INTR_SF in suspend function which this way isn't good 
for me.

     In addition, I hope my patch was not only fix the bug i encountered 
and it can limit HC into badly state and it should be the

base limit condition and prevent more unknown problems.  In fact, HC 
doesn't deal with ed/td list and done list by the ohci spec, so

I think my patch has no risk for ohci.

       by the way, root hub state isn't completely same with HC, but the 
root hub reset and resume signaling are controlled by the hcfs bits.

and hcd can set hcfs to decide hc usb state, so I judge whether set 
SF_INT to interrupt disable register only depend on HC state.

>
>>        In additon, when kernel include my patch, that it does't happen about
>> what you descriped that driver will not be able to finish unlinging URBs.
>>
>> Because above issue happen in S3/S4(Suspend to disk/Suspend to mem) test
>> procedure, if ed_rm_lis is no-NULL but my patch disable SoF interrupt.
>>
>> then when S3/S4 recovery to cpu idle state that usb resume will be called,
>> reume function has following logic, URB will continue to be processed.
>>
>>        static int ohci_rh_resume (struct ohci_hcd *ohci)
>>
>>       {
>>
>>          ...
>>
>>          242         if (ohci->ed_rm_list)
>>          243                 ohci_writel (ohci, OHCI_INTR_SF,
>> &ohci->regs->intrenable);
>>
>>         ...
>>
>>        }
> I'm worried that your patch may disable INTR_SF even when the controller
> has not gone into S3 or S4 suspend.  Maybe this won't cause problems,
> but it's better to be safe and do the disable _only_ when a suspend
> occurs.
>
> Alan Stern

Hi  Alan Stern,

     According to the previous statement, I think my patch has no risk 
on ohci.

Re: [PATCH v3] usb: ohci: add check for host controller functional states

[zhuyinbo]

在 2021/10/11 下午1:10, zhuyinbo 写道:
>
> 在 2021/10/10 上午3:39, Alan Stern 写道:
>> On Sat, Oct 09, 2021 at 10:01:25AM +0800, zhuyinbo wrote:
>>> 在 2021/10/8 下午10:26, Alan Stern 写道:
>>>> On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
>>>>> The usb states of ohci controller include UsbOperational, UsbReset,
>>>>> UsbSuspend and UsbResume. Among them, only the UsbOperational state
>>>>> supports launching the start of frame for host controller according
>>>>> the ohci protocol spec, but in S3/S4 press test procedure, it may
>>>> Nobody reading this will know what "S3/S4 press test procedure" means.
>>>> You have to explain it, or use a different name that people will
>>>> understand.
>>> okay, I got it.
>>>>> happen that the start of frame was launched in other usb states and
>>>>> cause ohci works abnormally then kernel will allways report rcu
>>>>> call trace. This patch was to add check for host controller
>>>>> functional states and if it is not UsbOperational state that need
>>>>> set INTR_SF in intrdisable register to ensure SOF Token generation
>>>>> was been disabled.
>>>> This doesn't make sense.  You already mentioned that only the
>>>> UsbOperational state supports sending start-of-frame packets.  So 
>>>> if the
>>>> controller is in a different state then it won't send these packets,
>>>> whether INTR_SF is enabled or not.
>>>>
>>>> What problem are you really trying to solve?
>>> Only UsbOperational state supports sending start-of-frame packets, 
>>> but in
>>> fact, in S3/S4 press test procedure,
>>>
>>> usb in non-UsbOperational state that send start-of-frame packets but hc
>>> driver doesn't deal with this frame. and hc will
>>>
>>> allways lauched the SOF for finishing the frame, the cpu will hand 
>>> this sof
>>> interrupt and doesn't deal with time interrupt
>>>
>>> that will cause rcu call trace then system doesn't suspend to 
>>> memory/disk.
>> I still don't understand.
>>
>> Are you saying that your OHCI controller behaves badly because it sends
>> SOF packets even when the state is different from UsbOperational?
>
> HC will allways report the SoF interrupt in the all time when HC was 
> not in NO-UsbOperation state.
>
> and no WritebackDoneHead interrupt that is the issue phenomenon. and 
> this situation is badly state for ohci.
>
>>
>>> Hi Alan Stern,
>>>
>>>      even though ed_rm_list is non-NULL, if hc in non-UsbOperation 
>>> state set
>>> SoF status in usbsts register that is illegal,
>>>
>>> at this time hcd doesn't need care URB whether finished, because hc had
>>> into a wrong state. even thoug it doesn't has this patch,
>>>
>>> URB was not be able to finish when hc in above worng state. except 
>>> software
>>> can intervence this wrong state. but the SoF bit of usbsts
>>>
>>> register was set by HC, and this action will happen always !!! software
>>> clear SoF state I think it isn't make sense. software only disable SoF
>>>
>>> interrupt to fix HC wrong state.
>> This problem happens when you go into S3 or S4 suspend, right? So you
>> should fix the problem by disabling INTR_SF when the root hub is
>> suspended.  Try adding
>>
>>     /* All ED unlinks should be finished, no need for SOF interrupts */
>>     ohci_writel(ohci, OHCI_INTR_SF, &ohci->regs->intrdisable);
>>
>> into ohci_rh_suspend(), just before the update_done_list() call.  If you
>> add this then INTR_SF will not be enabled during S3 or S4 suspend, so
>> the problem shouldn't occur.  Does that work for you?
>
> The system doesn't suspend to disk completely by my test result and hc 
> will always produce SoF interrupt.
>
> I encountered SoF interrupt  issue when HC in UsbSuspend state. and I 
> think when hc in
>
> UsbResume/UsbRest/ SoF interrupt issue may be happen so I disable 
> INTR_SF in ohci_irq.
>
> So I think disable INTR_SF in suspend function which this way isn't 
> good for me.
>
>     In addition, I hope my patch was not only fix the bug i 
> encountered and it can limit HC into badly state and it should be the
>
> base limit condition and prevent more unknown problems.  In fact, HC 
> doesn't deal with ed/td list and done list by the ohci spec, so
>
> I think my patch has no risk for ohci.
>
>       by the way, root hub state isn't completely same with HC, but 
> the root hub reset and resume signaling are controlled by the hcfs bits.
>
> and hcd can set hcfs to decide hc usb state, so I judge whether set 
> SF_INT to interrupt disable register only depend on HC state.

And I have a test, ohci_rh_suspend was called that HC state as gerneral 
was also UsbOperational state whatever do s3/s4 test or power on to boot 
kernel.

but HCD record it as suspend state on root hub at this time.

>
>>
>>>        In additon, when kernel include my patch, that it does't 
>>> happen about
>>> what you descriped that driver will not be able to finish unlinging 
>>> URBs.
>>>
>>> Because above issue happen in S3/S4(Suspend to disk/Suspend to mem) 
>>> test
>>> procedure, if ed_rm_lis is no-NULL but my patch disable SoF interrupt.
>>>
>>> then when S3/S4 recovery to cpu idle state that usb resume will be 
>>> called,
>>> reume function has following logic, URB will continue to be processed.
>>>
>>>        static int ohci_rh_resume (struct ohci_hcd *ohci)
>>>
>>>       {
>>>
>>>          ...
>>>
>>>          242         if (ohci->ed_rm_list)
>>>          243                 ohci_writel (ohci, OHCI_INTR_SF,
>>> &ohci->regs->intrenable);
>>>
>>>         ...
>>>
>>>        }
>> I'm worried that your patch may disable INTR_SF even when the controller
>> has not gone into S3 or S4 suspend.  Maybe this won't cause problems,
>> but it's better to be safe and do the disable _only_ when a suspend
>> occurs.
>>
>> Alan Stern
>
> Hi  Alan Stern,
>
>     According to the previous statement, I think my patch has no risk 
> on ohci.
>
>
>
>

Re: [PATCH v3] usb: ohci: add check for host controller functional states

[Alan Stern]

On Mon, Oct 11, 2021 at 01:10:18PM +0800, zhuyinbo wrote:
> 
> 在 2021/10/10 上午3:39, Alan Stern 写道:
> > On Sat, Oct 09, 2021 at 10:01:25AM +0800, zhuyinbo wrote:
> > > 在 2021/10/8 下午10:26, Alan Stern 写道:
> > > > On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
> > > > > The usb states of ohci controller include UsbOperational, UsbReset,
> > > > > UsbSuspend and UsbResume. Among them, only the UsbOperational state
> > > > > supports launching the start of frame for host controller according
> > > > > the ohci protocol spec, but in S3/S4 press test procedure, it may
> > > > Nobody reading this will know what "S3/S4 press test procedure" means.
> > > > You have to explain it, or use a different name that people will
> > > > understand.
> > > okay, I got it.
> > > > > happen that the start of frame was launched in other usb states and
> > > > > cause ohci works abnormally then kernel will allways report rcu
> > > > > call trace. This patch was to add check for host controller
> > > > > functional states and if it is not UsbOperational state that need
> > > > > set INTR_SF in intrdisable register to ensure SOF Token generation
> > > > > was been disabled.
> > > > This doesn't make sense.  You already mentioned that only the
> > > > UsbOperational state supports sending start-of-frame packets.  So if the
> > > > controller is in a different state then it won't send these packets,
> > > > whether INTR_SF is enabled or not.
> > > > 
> > > > What problem are you really trying to solve?
> > > Only UsbOperational state supports sending start-of-frame packets, but in
> > > fact, in S3/S4 press test procedure,
> > > 
> > > usb in non-UsbOperational state that send start-of-frame packets but hc
> > > driver doesn't deal with this frame. and hc will
> > > 
> > > allways lauched the SOF for finishing the frame, the cpu will hand this sof
> > > interrupt and doesn't deal with time interrupt
> > > 
> > > that will cause rcu call trace then system doesn't suspend to memory/disk.
> > I still don't understand.
> > 
> > Are you saying that your OHCI controller behaves badly because it sends
> > SOF packets even when the state is different from UsbOperational?
> 
> HC will allways report the SoF interrupt in the all time when HC was not in
> NO-UsbOperation state.

How did your host controller get into the non-UsbOperational state?  
What part of the code is responsible for changing to a different state?

It looks like the only place where this could happen is in 
ohci_rh_suspend().  So if you disable SOF interrupts there, it should 
fix your problem.

> and no WritebackDoneHead interrupt that is the issue phenomenon. and this
> situation is badly state for ohci.
> 
> > 
> > > Hi Alan Stern,
> > > 
> > >      even though ed_rm_list is non-NULL, if hc in non-UsbOperation state set
> > > SoF status in usbsts register that is illegal,
> > > 
> > > at this time hcd doesn't need care URB whether finished,  because hc had
> > > into a wrong state. even thoug it doesn't has this patch,
> > > 
> > > URB was not be able to finish when hc in above worng state. except software
> > > can intervence this wrong state. but the SoF bit of usbsts
> > > 
> > > register was set by HC, and this action will happen always !!! software
> > > clear SoF state I think it isn't make sense. software only disable SoF
> > > 
> > > interrupt to fix HC wrong state.
> > This problem happens when you go into S3 or S4 suspend, right?  So you
> > should fix the problem by disabling INTR_SF when the root hub is
> > suspended.  Try adding
> > 
> > 	/* All ED unlinks should be finished, no need for SOF interrupts */
> > 	ohci_writel(ohci, OHCI_INTR_SF, &ohci->regs->intrdisable);
> > 
> > into ohci_rh_suspend(), just before the update_done_list() call.  If you
> > add this then INTR_SF will not be enabled during S3 or S4 suspend, so
> > the problem shouldn't occur.  Does that work for you?
> 
> The system doesn't suspend to disk completely by my test result and hc will
> always produce SoF interrupt.

Have you tried adding those two lines of code shown above?

If you haven't tested them, please don't write back until you have.

Alan Stern

Re: [PATCH v3] usb: ohci: add check for host controller functional states

[zhuyinbo]

在 2021/10/12 上午12:17, Alan Stern 写道:
> On Mon, Oct 11, 2021 at 01:10:18PM +0800, zhuyinbo wrote:
>> 在 2021/10/10 上午3:39, Alan Stern 写道:
>>> On Sat, Oct 09, 2021 at 10:01:25AM +0800, zhuyinbo wrote:
>>>> 在 2021/10/8 下午10:26, Alan Stern 写道:
>>>>> On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
>>>>>> The usb states of ohci controller include UsbOperational, UsbReset,
>>>>>> UsbSuspend and UsbResume. Among them, only the UsbOperational state
>>>>>> supports launching the start of frame for host controller according
>>>>>> the ohci protocol spec, but in S3/S4 press test procedure, it may
>>>>> Nobody reading this will know what "S3/S4 press test procedure" means.
>>>>> You have to explain it, or use a different name that people will
>>>>> understand.
>>>> okay, I got it.
>>>>>> happen that the start of frame was launched in other usb states and
>>>>>> cause ohci works abnormally then kernel will allways report rcu
>>>>>> call trace. This patch was to add check for host controller
>>>>>> functional states and if it is not UsbOperational state that need
>>>>>> set INTR_SF in intrdisable register to ensure SOF Token generation
>>>>>> was been disabled.
>>>>> This doesn't make sense.  You already mentioned that only the
>>>>> UsbOperational state supports sending start-of-frame packets.  So if the
>>>>> controller is in a different state then it won't send these packets,
>>>>> whether INTR_SF is enabled or not.
>>>>>
>>>>> What problem are you really trying to solve?
>>>> Only UsbOperational state supports sending start-of-frame packets, but in
>>>> fact, in S3/S4 press test procedure,
>>>>
>>>> usb in non-UsbOperational state that send start-of-frame packets but hc
>>>> driver doesn't deal with this frame. and hc will
>>>>
>>>> allways lauched the SOF for finishing the frame, the cpu will hand this sof
>>>> interrupt and doesn't deal with time interrupt
>>>>
>>>> that will cause rcu call trace then system doesn't suspend to memory/disk.
>>> I still don't understand.
>>>
>>> Are you saying that your OHCI controller behaves badly because it sends
>>> SOF packets even when the state is different from UsbOperational?
>> HC will allways report the SoF interrupt in the all time when HC was not in
>> NO-UsbOperation state.
> How did your host controller get into the non-UsbOperational state?
> What part of the code is responsible for changing to a different state?
>
> It looks like the only place where this could happen is in
> ohci_rh_suspend().  So if you disable SOF interrupts there, it should
> fix your problem.

in fact, I want to consider all non-UsbOperational state for my patch, 
as for UsbSuspend state and my issue that

your advice is the pefect solution, and apply for the change according 
to your advice, it can fix my problem by my test.

in addition, I got the non-UsbOperationnal state was by read hcfs bits 
in ohci control register, for the UsbSuspend status that

it is only changed in ohci_rh_suspend. and other states was changed in 
multiple place that seems disable sof interrupt was only

in ohci_irq. but if you still think it  has risk i want to following 
your advice and as it v5 version.

>
>> and no WritebackDoneHead interrupt that is the issue phenomenon. and this
>> situation is badly state for ohci.
>>
>>>> Hi Alan Stern,
>>>>
>>>>       even though ed_rm_list is non-NULL, if hc in non-UsbOperation state set
>>>> SoF status in usbsts register that is illegal,
>>>>
>>>> at this time hcd doesn't need care URB whether finished,  because hc had
>>>> into a wrong state. even thoug it doesn't has this patch,
>>>>
>>>> URB was not be able to finish when hc in above worng state. except software
>>>> can intervence this wrong state. but the SoF bit of usbsts
>>>>
>>>> register was set by HC, and this action will happen always !!! software
>>>> clear SoF state I think it isn't make sense. software only disable SoF
>>>>
>>>> interrupt to fix HC wrong state.
>>> This problem happens when you go into S3 or S4 suspend, right?  So you
>>> should fix the problem by disabling INTR_SF when the root hub is
>>> suspended.  Try adding
>>>
>>> 	/* All ED unlinks should be finished, no need for SOF interrupts */
>>> 	ohci_writel(ohci, OHCI_INTR_SF, &ohci->regs->intrdisable);
>>>
>>> into ohci_rh_suspend(), just before the update_done_list() call.  If you
>>> add this then INTR_SF will not be enabled during S3 or S4 suspend, so
>>> the problem shouldn't occur.  Does that work for you?
>> The system doesn't suspend to disk completely by my test result and hc will
>> always produce SoF interrupt.
> Have you tried adding those two lines of code shown above?
>
> If you haven't tested them, please don't write back until you have.
>
> Alan Stern

Hi Alan stern,

     I have a try that follow your advice and the s3/s4 test result is 
good for me.


Thanks,

Yinbo Zhu.