Date: Tue, 1 Dec 2015 18:50:06 +0800
From: Li Jun <b47624@freescale.com>
To: Felipe Balbi <balbi@ti.com>
CC: Peter Chen <peter.chen@freescale.com>,
        Nathan Sullivan <nathan.sullivan@ni.com>, <gregkh@linuxfoundation.org>,
        <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V4] usb: remove unnecessary CONFIG_PM dependency from
 USB_OTG
Message-ID: <20151201104932.GA23133@shlinux2>
References: <1446126743-31892-1-git-send-email-nathan.sullivan@ni.com>
 <8737wnnq3c.fsf@saruman.tx.rr.com>
 <20151104030056.GA20460@shlinux2>
 <87r3k6mngw.fsf@saruman.tx.rr.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87r3k6mngw.fsf@saruman.tx.rr.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2015 10:53:31.4723
 (UTC)
X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d;Ip=[192.88.158.2];Helo=[az84smr01.freescale.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0857
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2897
Lines: 81

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/