Hi Alan,
> From: Alan Stern, Sent: Tuesday, January 21, 2020 12:12 AM
>
> On Mon, 20 Jan 2020, Yoshihiro Shimoda wrote:
>
> > > > +static void ehci_platform_quirk_poll_work(struct work_struct *work)
> > > > +{
> > > > + struct ehci_platform_priv *priv =
> > > > + container_of(work, struct ehci_platform_priv, poll_work);
> > > > + struct ehci_hcd *ehci = container_of((void *)priv, struct ehci_hcd,
> > > > + priv);
> > > > + int i;
> > > > +
> > > > + usleep_range(4000, 8000);
> > >
> > > You have just waited 1000 ms for the timer. Why will sleeping an
> > > additional 4 - 8 ms make any difference?
> >
> > This sleeping can avoid a misdetection between this work function and
> > reconnection. If user reconnects the usb within 4 ms, the PORTSC
> > condition is possible to be the same as the issue's condition.
> > I think I should have described this information into the code.
> >
> > However, if I used schedule_delayed_work() instead, we can remove
> > the usleep_range().
>
> Why not just make the timer delay be 1004 or 1008 ms instead of adding
> this extra delay here?
My concern is a race condition when the issue doesn't happen. If
the workaround code has an extra delay, we can detect misdetection like below.
This is related to the EHCI/OHCI controllers on R-Car Gen3 SoCs though,
updating the CCS status is possible to be delayed. To be clear of the reason,
I should have described this CCS status behavior too.
Timer routine workqueue EHCI PORTSC USB connection
disconnect
CCS=0 connect (within 4 ms)
condition = true (misdetection) CCS=0
usleep_range(4000,8000) CCS=1
condition = false
Best regards,
Yoshihiro Shimoda
> Alan Stern
