Re: [PATCH V4] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

[Li Jun <b47624@freescale.com>]

On Tue, Nov 03, 2015 at 09:51:11PM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen <peter.chen@freescale.com> writes:
> > On Tue, Nov 03, 2015 at 07:56:55AM -0600, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Nathan Sullivan <nathan.sullivan@ni.com> 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@ni.com>
> >> > ---
> >> >  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