Re: [PATCH] USB: ehci-omap: Select USB_PHY

[Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

Hi,

On Thu, Apr 11, 2013 at 04:18:33PM +0300, Roger Quadros wrote:
> On 04/11/2013 03:42 PM, Roger Quadros wrote:
> > On 04/11/2013 01:55 PM, Felipe Balbi wrote:
> >> Hi,
> >>
> >> On Thu, Apr 11, 2013 at 01:51:16PM +0300, Roger Quadros wrote:
> >>> On 04/11/2013 01:04 PM, Felipe Balbi wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote:
> >>>>> Hi Greg,
> >>>>>
> >>>>> The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP
> >>>>> is enabled.
> >>>>>
> >>>>> Patch is based on your usb-next branch and is needed for 3.10.
> >>>>>
> >>>>> From: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> >>>>> Date: Thu, 11 Apr 2013 12:08:19 +0300
> >>>>> Subject: [PATCH] USB: ehci-omap: Select USB_PHY
> >>>>>
> >>>>> As we need NOP_USB_XCEIV which depends on USB_PHY
> >>>>> we need to select USB_PHY as well.
> >>>>>
> >>>>> Gets rid of the below warnings when USB_EHCI_HCD_OMAP
> >>>>> is enabled.
> >>>>>
> >>>>> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT && USB_PHY)
> >>>>> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT && USB_PHY)
> >>>>>
> >>>>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> >>>>
> >>>> Ideally, however, we wouldn't select any PHY in particular as different
> >>>> boards might need a different PHY driver, even on OMAP ;-)
> >>>>
> >>> Right, but we need to select USB_PHY here as the driver uses
> >>> the USB_PHY APIs.
> >>>
> >>> The NOP_USB_XCEIV selection could be done by the board config.
> >>
> >> I would avoid 'select' completely and just update omap2plus_defconfig
> >> adding those two as modules.
> >>
> > 
> > OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV".
> > 
> 
> One more issue to clarify.
> 
> if USB_PHY is not enabled, then all phy_get() API's should return NULL and not
> -ENXIO as it does now.

ENXIO means "No such device or address", looks alright to me ;-)

> This way the drivers need not treat it as an error and all PHY ops can
> be NOPs.

drivers will already be using if (IS_ERR()) construction, returning
-ENXIO when the API is disabled gives them an oportunity to *not*
request probe deferral since the API isn't enabled anyway.

> This will make it behave like other frameworks. e.g. clk.

if we return NULL we will need IS_ERR_OR_NULL() which will cause
problems with people who aren't careful enough.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]