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@xxxxxx> > >>>>> 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@xxxxxx> > >>>> > >>>> 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:
signature.asc
Description: Digital signature
