On Tue, Nov 03, 2015 at 09:51:11PM -0600, Felipe Balbi wrote: > > Hi, > > Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: > > On Tue, Nov 03, 2015 at 07:56:55AM -0600, Felipe Balbi wrote: > >> > >> Hi, > >> > >> Nathan Sullivan <nathan.sullivan@xxxxxx> writes: > >> > The USB OTG support currently depends on power management > >> > (CONFIG_PM) being enabled, but does not actually need it enabled. > >> > Remove this dependency. > >> > > >> > Tested on Bay Trail hardware with dwc3 USB. > >> > > >> > Signed-off-by: Nathan Sullivan <nathan.sullivan@xxxxxx> > >> > --- > >> > drivers/usb/core/Kconfig | 1 - > >> > 1 file changed, 1 deletion(-) > >> > > >> > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig > >> > index a99c89e..9c5cdf3 100644 > >> > --- a/drivers/usb/core/Kconfig > >> > +++ b/drivers/usb/core/Kconfig > >> > @@ -43,7 +43,6 @@ config USB_DYNAMIC_MINORS > >> > > >> > config USB_OTG > >> > bool "OTG support" > >> > - depends on PM > >> > >> I don't think this is correct. OTG depends on USB bus suspend, which is > >> only available on PM builds. Care to further detail why you think PM is > >> not needed on OTG ? > >> > > > > OTG depends on USB bus suspend is not a must, the hardware controlled OTG > > design do HNP when the bus goes to suspend; but if the software > > implements OTG FSM, it is the user option whether do HNP, and bus > > suspend is controlled by OTG FSM software (stop SOF), but not by host > > stack (eg, ehci). > > > > I am sorry I did not consider the legacy OTG design, this patch should > > be dropped. > > there is no "legacy" OTG design. OTG requires a bus suspend to enter > HNP, and that's achieved by stopping all transfers and avoid new URB > submission so usbcore can put the bus in suspend (by means of USB > autosuspend). If you're bypassing that in the OTG FSM thing, that needs > to be fixed ASAP as that makes it a lot harder for any generic changes > in usbcore to be validated. Specially when you consider not many will > have whatever special HW which, likely, doesn't even work with mainline > to validate a change. > > Please, make sure to fix that design so that HNP *always* goes through > the proper code path. If you have devices which would prevent HNP > because their class driver (host side driver) would never autosuspend, > fix that as well. > Hi Felipe I am going to fix this as you suggested, for those interface drivers which do not support autosuspend, should we - Fix its driver by enable autosuspend and adding suspend()&resume()? or - Unbind its interface before autosuspend the usb device? thanks Li Jun > cheers > > -- > balbi -- 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
