On Tue, Dec 1, 2015 at 4:48 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 1 Dec 2015, Alan Cooper wrote: > >> On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> >> I'm now sure the host in "non-compliant". >> > >> > It is non-compliant if it turns off Vbus power during suspend. But >> > that may be caused by the platform more than by the controller itself. >> > >> >> I wasn't able to find any document that states that VBUS must be on in >> S3 mode. > > Hmmm, that's a little tricky. Were you able to find a document that > says Vbus must be on in S0? People tend to make assumptions about > these things without stating them clearly. > > The USB-2.0 spec says (section 7.2.1, the paragraph about root port > hubs): "Systems that obtain operating power externally, either AC or > DC, must supply at least five unit loads to each port." (A unit load > is 100 mA.) > > There's no mention of suspend, S3, or anything else. However, I think > we can assume this refers to the case where the root hub is not > suspended. > > Section 7.2.3 discusses power control during suspend/resume. Among > other things, it says: > > When a hub is in the Suspend state, it must still be able to > provide the maximum current per port (one unit load of current > per port for bus-powered hubs and five unit loads per port for > self-powered hubs). This is necessary to support remote > wakeup-capable devices that will power-up while the remainder > of the system is still suspended. > > Although it doesn't say so explicitly, this includes root hubs as well > as external hubs. The normal current draw during suspend will of > course be a lot smaller than this; the maximum is needed only during > the time that a downstream device is powering up because of a wakeup > event. > >> In our SoC, the USB controller is not in the AON block so it >> looses power in S3 and that disables the USB VBUS supply. If I can >> prove our SoC is out of spec, I can probably get it fixed in future >> chips. > > Maybe this reference will help. I agree that for USB suspend modes, VBUS must be on, and our hardware behaves that way for runtime suspend. The question is for system wide suspend (S3/STR) can the system shut down the USB hardware entirely. The ACPI spec and Linux Documents/power/states.txt seem to allow either design. From states.txt under S3 mode: "In many cases, all peripheral buses lose power when entering STR, so devices must be able to handle the transition back to the On state". Thanks for you input Al Cooper -- 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