Skip to contentSkip to conversation

USB: ehci-omap: Select USB_PHY

PATCH In review Roger Quadros 3 participants 15 messages Apr 11, 2013 – Apr 12, 2013 USB

lore
Share & tools
lore

Roger Quadros

author
#0 lore raw

PATCH 1/1 USB: ehci-omap: Select USB_PHY

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 <[email protected]>
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 <[email protected]>
---
 drivers/usb/host/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/usb/host/Kconfig +1 -0
index c0be25c..931b437 100644
@@ -150,6 +150,7 @@ config USB_EHCI_MXC
 config USB_EHCI_HCD_OMAP
 	tristate "EHCI support for OMAP3 and later chips"
 	depends on ARCH_OMAP
+	select USB_PHY
 	select NOP_USB_XCEIV
 	default y
 	---help---
Signature · 1 line
1.7.4.1
#1 lore raw

Hi,

Quoted 14 lines · Roger Quadros

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 <[email protected]>
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.

Quoted 7 lines

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 <[email protected]>

Ideally, however, we wouldn't select any PHY in particular as different boards might need a different PHY driver, even on OMAP ;-)

Signature · 1 line
balbi
author
#2 lore raw
Quoted 20 lines · Felipe Balbi

Hi,

Quoted 17 lines · Roger Quadros

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 <[email protected]>
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.

Quoted 8 lines
Quoted 4 lines

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 <[email protected]>

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.

cheers,
-roger

#3 lore raw

Hi,

Quoted 26 lines · Roger Quadros
Quoted 25 lines · Felipe Balbi

Hi,

Quoted 21 lines · Roger Quadros

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 <[email protected]>
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 <[email protected]>
Quoted 7 lines
Quoted 3 lines

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.

cheers

Signature · 1 line
balbi
author
#4 lore raw
Quoted 32 lines · Felipe Balbi

Hi,

Quoted 29 lines · Roger Quadros
Quoted 28 lines · Felipe Balbi

Hi,

Quoted 14 lines · Roger Quadros

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 <[email protected]>
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.

Quoted 7 lines

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 <[email protected]>

Ideally, however, we wouldn't select any PHY in particular as different boards might need a different PHY driver, even on OMAP ;-)

Quoted 8 lines
Quoted 4 lines

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".

cheers,
-roger

#5 lore raw

Am 11.04.2013 14:42, schrieb Roger Quadros:

Quoted 7 lines · Felipe Balbi
Quoted 4 lines

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".

Sorry, but this just will end up with many users having broken configs because of disabled stuff they don't know why they have to enable them. And thus with a never ending stream of questions and thus with a needed FAQ entry.

Regards,

Alexander

author
#6 lore raw

Felipe,

Quoted 5 lines · Alexander Holler

Am 11.04.2013 14:42, schrieb Roger Quadros:

Quoted 4 lines · Felipe Balbi
Quoted 3 lines

I would avoid 'select' completely and just update omap2plus_defconfig adding those two as modules.

Setting USB_PHY as a module gives rise to these problems

arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
/work/linux-2.6/arch/arm/mach-omap2/usb-host.c:652: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function omap_2430sdp_init':
/work/linux-2.6/arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function omap3_beagle_init':
/work/linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function devkit8000_init':
/work/linux-2.6/arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function omap_ldp_init':
/work/linux-2.6/arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy'

So USB_PHY shouldn't be tristate IMO or at least the platform registration stuff as the usb_bind_phy() part is used by platform code.

Quoted 9 lines
Quoted 3 lines
Quoted 1 line

OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV".

Sorry, but this just will end up with many users having broken configs because of disabled stuff they don't know why they have to enable them. And thus with a never ending stream of questions and thus with a needed FAQ entry.

Alexander,

I agree with you that it can get difficult with users. But it is best for users do not disable anything they are not familiar with.

As the USB_PHY option doesn't depend on anything, it is safe to select it from USB_EHCI_HCD_OMAP.

However, the PHY drivers themselves must be selected from the board configs.

cheers,
-roger

#7 lore raw

Hi,

Quoted 22 lines · Roger Quadros

Felipe,

Quoted 5 lines · Alexander Holler

Am 11.04.2013 14:42, schrieb Roger Quadros:

Quoted 4 lines · Felipe Balbi
Quoted 3 lines

I would avoid 'select' completely and just update omap2plus_defconfig adding those two as modules.

Setting USB_PHY as a module gives rise to these problems

arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
/work/linux-2.6/arch/arm/mach-omap2/usb-host.c:652: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function omap_2430sdp_init':
/work/linux-2.6/arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function omap3_beagle_init':
/work/linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function devkit8000_init':
/work/linux-2.6/arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function omap_ldp_init':
/work/linux-2.6/arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy'

Quoted 2 lines

So USB_PHY shouldn't be tristate IMO or at least the platform registration stuff as the usb_bind_phy() part is used by platform code.

alright, let's send a patch to fix the check in the header. We should be using IS_ENABLED() anyway.

Signature · 1 line
balbi
#8 lore raw
In reply to Roger Quadros

Am 11.04.2013 16:44, schrieb Roger Quadros:

Quoted 8 lines
Quoted 5 lines

Sorry, but this just will end up with many users having broken configs because of disabled stuff they don't know why they have to enable them. And thus with a never ending stream of questions and thus with a needed FAQ entry.

Alexander,

Quoted 7 lines

I agree with you that it can get difficult with users. But it is best for users do not disable anything they are not familiar with.

As the USB_PHY option doesn't depend on anything, it is safe to select it from USB_EHCI_HCD_OMAP.

However, the PHY drivers themselves must be selected from the board configs.

Maybe I understood something wrong, but if the OMAP USB driver requires CONFIG_USB_PHY (or similiar), it should be selected automatically and not just enabled in the board config.

I just had it to often, that I needed to search around why a driver doesn't work (or even compiles), just to find out that I need to enable some strange config option which wasn't selected automatically. Especially with OMAPs. ;)

And this not only occured when disabling options, it often occured by just updating the kernel. Suddenly some obscur option was needed too, it wasn't selected automatically by make oldconfig, bang. So the argument to not remove anything from a board config doesn't help much.

Sorry for the rant. ;)

Regards,

Alexander

#9 lore raw

Hi,

Quoted 11 lines · Alexander Holler
Quoted 11 lines
Quoted 5 lines

Sorry, but this just will end up with many users having broken configs because of disabled stuff they don't know why they have to enable them. And thus with a never ending stream of questions and thus with a needed FAQ entry.

Alexander,

I agree with you that it can get difficult with users. But it is best for users do not disable anything they are not familiar with.

Quoted 8 lines
Quoted 4 lines

As the USB_PHY option doesn't depend on anything, it is safe to select it from USB_EHCI_HCD_OMAP.

However, the PHY drivers themselves must be selected from the board configs.

Maybe I understood something wrong, but if the OMAP USB driver requires CONFIG_USB_PHY (or similiar), it should be selected automatically and not just enabled in the board config.

and who said OMAP USB depends on CONFIG_USB_PHY ? Some platforms need to control a PHY and some don't.

Quoted 4 lines

I just had it to often, that I needed to search around why a driver doesn't work (or even compiles), just to find out that I need to enable some strange config option which wasn't selected automatically. Especially with OMAPs. ;)

so ? Send a patch fixing it, those are really welcome. You see, it's very difficult to get all of this perfectly right and if people continue to rant rather than fix, we will get nowhere.

Quoted 5 lines

And this not only occured when disabling options, it often occured by just updating the kernel. Suddenly some obscur option was needed too, it wasn't selected automatically by make oldconfig, bang. So the argument to not remove anything from a board config doesn't help much.

blablabla, Kconfig changes are *always* necessary. Specially when we need to re-design an entire API because the previous one was just a *SINGLE* global pointer.

Go check out kernel 2.6.39 (maybe even 3.1 and 3.2) and you'll see that we're much better off today where we can actually have multiple PHY drivers and multiple UDC drivers enabled (either as modules or built-in), but the fact is that changing all of this over takes time and sometimes people make mistakes, but that's alright, since we have the -rc series to catch those unwanted errors.

Without the help of the rest of the community, though, it'll just get slower and slower. With the whole single zImage effort going on in the ARM land, things have gotten much more critical WRT getting rid of "selects" and turning legacy "drivers" into real drivers, not just a bunch of exported functions which a single architecture uses.

Add to that all the rework going on in the Gadget Framework, PHY layer and EHCI drivers (which now has a core re-usable library thanks to Alan Stern) and you have a lot of work to do.

Next time you consider ranting about something, use that 'frustration' and turn it into motivation to write patches, then we all win. Also consider that under drivers/usb/ alone we have 270K LOCs, and that's quite a lot of code to handle with only a few of us (Greg, Sarah, Alan, Alex and myself) being the gateway towards mainline.

With all that comes the responsibility of revieweing drivers for architectures we, most of the times, don't have access to with drivers that only compile in some ceratin ways.

Cleaning all of that takes time. Look at all the effort it's taking the Chipidea folks just to get rid of a couple copies of the chipidea driver. It takes time, it takes sweat and we can all use some help rather than some random rant.

Signature · 1 line
balbi
#10 lore raw

Am 11.04.2013 20:29, schrieb Felipe Balbi:

Quoted 2 lines

and who said OMAP USB depends on CONFIG_USB_PHY ? Some platforms need to control a PHY and some don't.

I've read that so.

Quoted 6 lines

Go check out kernel 2.6.39 (maybe even 3.1 and 3.2) and you'll see that we're much better off today where we can actually have multiple PHY drivers and multiple UDC drivers enabled (either as modules or built-in), but the fact is that changing all of this over takes time and sometimes people make mistakes, but that's alright, since we have the -rc series to catch those unwanted errors.

I'll still have to stick to 3.2 because nothing afterwards boots from EHCI on my beagleboard.

Quoted 7 lines

Without the help of the rest of the community, though, it'll just get slower and slower. With the whole single zImage effort going on in the ARM land, things have gotten much more critical WRT getting rid of "selects" and turning legacy "drivers" into real drivers, not just a bunch of exported functions which a single architecture uses.

Quoted 6 lines

Add to that all the rework going on in the Gadget Framework, PHY layer and EHCI drivers (which now has a core re-usable library thanks to Alan Stern) and you have a lot of work to do.

Next time you consider ranting about something, use that 'frustration' and turn it into motivation to write patches, then we all win. Also

I frequently tried and gave up. But thanks for the good suggestions.

Regards,

Alexander

author
#11 lore raw
In reply to Roger Quadros
Quoted 36 lines · Roger Quadros
Quoted 35 lines · Felipe Balbi

Hi,

Quoted 32 lines · Roger Quadros
Quoted 20 lines · Felipe Balbi

Hi,

Quoted 17 lines · Roger Quadros

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 <[email protected]>
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.

Quoted 8 lines
Quoted 4 lines

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 <[email protected]>

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.

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

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.

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

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

cheers,
-roger.

#12 lore raw

Hi,

Quoted 43 lines · Roger Quadros
Quoted 42 lines · Roger Quadros
Quoted 40 lines · Felipe Balbi

Hi,

Quoted 26 lines · Roger Quadros
Quoted 25 lines · Felipe Balbi

Hi,

Quoted 21 lines · Roger Quadros

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 <[email protected]>
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 <[email protected]>
Quoted 7 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 2 lines

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 ;-)

Quoted 2 lines

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.

Quoted 1 line

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.

Signature · 1 line
balbi
author
#13 lore raw
Quoted 54 lines · Felipe Balbi

Hi,

Quoted 43 lines · Roger Quadros
Quoted 42 lines · Roger Quadros
Quoted 40 lines · Felipe Balbi

Hi,

Quoted 26 lines · Roger Quadros
Quoted 25 lines · Felipe Balbi

Hi,

Quoted 21 lines · Roger Quadros

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 <[email protected]>
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 <[email protected]>
Quoted 7 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 2 lines

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.

Quoted 8 lines

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

Quoted 2 lines

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.

on second thoughts I agree with you. So the general understanding is that USB_PHY users without USB_PHY enabled is an error case.

This means we need to allow controller drivers to select USB_PHY and minimize this possibility.

Quoted 6 lines
Quoted 2 lines

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.

OK.

cheers,
-roger

#14 lore raw

Hi,

Quoted 44 lines · Roger Quadros
Quoted 35 lines
Quoted 27 lines
Quoted 27 lines
Quoted 26 lines
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines

From: Roger Quadros <[email protected]>
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 <[email protected]>
Quoted 7 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 2 lines

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.

Quoted 8 lines

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

Quoted 2 lines

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.

Quoted 5 lines

on second thoughts I agree with you. So the general understanding is that USB_PHY users without USB_PHY enabled is an error case.

This means we need to allow controller drivers to select USB_PHY and minimize this possibility.

perhaps but OTOH careless select will also cause lots of problems. distro-like kernels will just put all those as modules and product-like kernels will only enable exactly what they need, so it makes no difference if we select or not. Except that select will enable that PHY even in e.g. beaglebone derivative which is, for now, using the same DTS file.

Signature · 1 line
balbi