Re: [PATCH] musb: fix remote wakeup racing with suspend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, May 01, 2018 at 08:48:11AM -0500, Bin Liu wrote:
> On Fri, Apr 27, 2018 at 03:00:05PM +0200, Daniel Glöckner wrote:
> > It has been observed that writing 0xF2 to the power register while it
> > reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
> > RESUME and setting SUSPENDM in one go does not work. It might also violate
> > the USB spec to transition directly from resume to suspend, especially
> > when not taking T_DRSMDN into account. But this is what happens when a
> > remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the
> > root hub and musb_bus_suspend being called.
> > 
> > This commit returns -EBUSY when musb_bus_suspend is called while remote
> > wakeup is signalled and thus avoids to reset the RESUME bit. Remember that
> > resume can be signalled only when the bus was already suspended, so it is
> > safe to skip the following steps even when musb_hub_control ignores the
> 
> what do you mean by "skip the following steps"?

Setting USB_PORT_STAT_SUSPEND in musb->port1_status, changing
musb->xceiv->otg->state, setting musb->is_active, etc.

> > error returned by musb_port_suspend.
> > 
> > The resume part of musb_port_suspend is modified to also accept a pending
> > remote wakeup, to bring it to the end after T_DRSMDN has passed.
> 
> Can you please explain more here? I am not sure when musb_port_suspend()
> is involved in resume by remote wakeup, and what case is a 'pending'
> remote wakeup?

With 'pending' I was referring to the situation when MUSB_POWER_RESUME
has been set by the controller in the power register as a result of
of a detected remote wakeup.

I see... finish_resume_work is already scheduled by musb_stage0_irq.
So the condition of the if statement probably does not need to be
changed. I'll test without that part and make a v2 patch if it works.

Btw., do you know why that 10000 iterations while loop is needed in
musb_port_suspend to pass the OTG Protocol Test as indicated by the
comment?


Best regards,

  Daniel


-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11,
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke
Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux