[PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[Adrien Vergé]

On OMAP4 platforms, EHCI HCD needs the physical layer signalling
activated, along with the NOP USB Transceiver driver. Otherwise, the
kernel boots without registering any USB device.

This patch applies to Linux 3.10-rc2.

Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
---
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index de94f26..47959d7 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -44,6 +44,8 @@ endif # USB_XHCI_HCD
 config USB_EHCI_HCD
 	tristate "EHCI HCD (USB 2.0) support"
 	depends on USB_ARCH_HAS_EHCI
+	select USB_PHY if ARCH_OMAP4
+	select NOP_USB_XCEIV if ARCH_OMAP4
 	---help---
 	  The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0
 	  "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware.

Re: [PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[Arnd Bergmann]

On Saturday 25 May 2013, Adrien Vergé wrote:
> On OMAP4 platforms, EHCI HCD needs the physical layer signalling
> activated, along with the NOP USB Transceiver driver. Otherwise, the
> kernel boots without registering any USB device.

This does not actually sound like a critical error: If a user forgets
to enable a driver, that driver will not be loaded. Of course the
kernel should not just crash when a non-essential driver is missing,
and it should not fail to build, but your description sounds harmless.

Am I missing something?

> This patch applies to Linux 3.10-rc2.
> 
> Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
> ---
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index de94f26..47959d7 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -44,6 +44,8 @@ endif # USB_XHCI_HCD
>  config USB_EHCI_HCD
>         tristate "EHCI HCD (USB 2.0) support"

This is the wrong place: it should be in USB_EHCI_HCD_OMAP
if any.

>         depends on USB_ARCH_HAS_EHCI
> +       select USB_PHY if ARCH_OMAP4
> +       select NOP_USB_XCEIV if ARCH_OMAP4
>         ---help---
>           The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0
>           "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware.

'select'ing USB_PHY sounds wrong too, I think you mean 'depends on'.

Also note that Roger Quadros has just removed the 'select NOP_USB_XCEIV'
there, I think you should coordinate with him.

	Arnd

Re: [PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[Roger Quadros]

On 05/27/2013 09:23 PM, Arnd Bergmann wrote:
> On Saturday 25 May 2013, Adrien Vergé wrote:
>> On OMAP4 platforms, EHCI HCD needs the physical layer signalling
>> activated, along with the NOP USB Transceiver driver. Otherwise, the
>> kernel boots without registering any USB device.
> 
> This does not actually sound like a critical error: If a user forgets
> to enable a driver, that driver will not be loaded. Of course the
> kernel should not just crash when a non-essential driver is missing,
> and it should not fail to build, but your description sounds harmless.
> 
> Am I missing something?

Right, there is no crash or anything if the PHY drivers are not selected,
just that OMAP USB host will not work.

> 
>> This patch applies to Linux 3.10-rc2.
>>
>> Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
>> ---
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index de94f26..47959d7 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -44,6 +44,8 @@ endif # USB_XHCI_HCD
>>  config USB_EHCI_HCD
>>         tristate "EHCI HCD (USB 2.0) support"
> 
> This is the wrong place: it should be in USB_EHCI_HCD_OMAP
> if any.

Right.
> 
>>         depends on USB_ARCH_HAS_EHCI
>> +       select USB_PHY if ARCH_OMAP4
>> +       select NOP_USB_XCEIV if ARCH_OMAP4
>>         ---help---
>>           The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0
>>           "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware.
> 
> 'select'ing USB_PHY sounds wrong too, I think you mean 'depends on'.
> 
> Also note that Roger Quadros has just removed the 'select NOP_USB_XCEIV'
> there, I think you should coordinate with him.

Selecting NOP_USB_XCEIV is wrong as it in turn depends on USB_PHY.

I'm not for depends as it would hide USB_EHCI_HCD_OMAP in menuconfig.
I'm for explicitly selecting both, as it makes the user's life much easier.
But I'm afraid maintainers might object to that.

The other option is to enable the required drivers in omap2plus_defconfig.
http://comments.gmane.org/gmane.linux.ports.arm.omap/97899

Maybe you could just resend that patch after addressing Kevin's comments?

cheers,
-roger

Re: [PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[Arnd Bergmann]

On Tuesday 28 May 2013 11:14:37 Roger Quadros wrote:
> >>         depends on USB_ARCH_HAS_EHCI
> >> +       select USB_PHY if ARCH_OMAP4
> >> +       select NOP_USB_XCEIV if ARCH_OMAP4
> >>         ---help---
> >>           The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0
> >>           "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware.
> > 
> > 'select'ing USB_PHY sounds wrong too, I think you mean 'depends on'.
> > 
> > Also note that Roger Quadros has just removed the 'select NOP_USB_XCEIV'
> > there, I think you should coordinate with him.
> 
> Selecting NOP_USB_XCEIV is wrong as it in turn depends on USB_PHY.
> 
> I'm not for depends as it would hide USB_EHCI_HCD_OMAP in menuconfig.
> I'm for explicitly selecting both, as it makes the user's life much easier.
> But I'm afraid maintainers might object to that.

My preferred option would be to turn the 'menuconfig PHY' into 'menu',
which is what we did to solve a similar problem in drivers/mfd: It lets
us 'select' specific PHY drivers without turning on the entire
menu. Using 'select PHY' has the nasty side-effect of creating an
incorrect dependency between the OMAP EHCI driver and all the
non-OMAP phy drivers that become visible once the usb-phy directory
gets enabled.

	Arnd

Re: [PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[Roger Quadros]

On 05/28/2013 11:40 AM, Arnd Bergmann wrote:
> On Tuesday 28 May 2013 11:14:37 Roger Quadros wrote:
>>>>         depends on USB_ARCH_HAS_EHCI
>>>> +       select USB_PHY if ARCH_OMAP4
>>>> +       select NOP_USB_XCEIV if ARCH_OMAP4
>>>>         ---help---
>>>>           The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0
>>>>           "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware.
>>>
>>> 'select'ing USB_PHY sounds wrong too, I think you mean 'depends on'.
>>>
>>> Also note that Roger Quadros has just removed the 'select NOP_USB_XCEIV'
>>> there, I think you should coordinate with him.
>>
>> Selecting NOP_USB_XCEIV is wrong as it in turn depends on USB_PHY.
>>
>> I'm not for depends as it would hide USB_EHCI_HCD_OMAP in menuconfig.
>> I'm for explicitly selecting both, as it makes the user's life much easier.
>> But I'm afraid maintainers might object to that.
> 
> My preferred option would be to turn the 'menuconfig PHY' into 'menu',
> which is what we did to solve a similar problem in drivers/mfd: It lets
> us 'select' specific PHY drivers without turning on the entire
> menu. Using 'select PHY' has the nasty side-effect of creating an
> incorrect dependency between the OMAP EHCI driver and all the
> non-OMAP phy drivers that become visible once the usb-phy directory
> gets enabled.
>

Good idea, thanks. I will give this a try.

cheers,
-roger

Re: [PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[Adrien Vergé]

Dear Arnd and Roger, thank you for your answers.

2013/5/28 Roger Quadros <rogerq@ti.com>
> Selecting NOP_USB_XCEIV is wrong as it in turn depends on USB_PHY.
>
> I'm not for depends as it would hide USB_EHCI_HCD_OMAP in menuconfig.
> I'm for explicitly selecting both, as it makes the user's life much
> easier.
> But I'm afraid maintainers might object to that.
>
> The other option is to enable the required drivers in omap2plus_defconfig.
> http://comments.gmane.org/gmane.linux.ports.arm.omap/97899

This seems a good idea to me, since many OMAP users boot with NFS and
need USB directly working (Ethernet over USB).

> Maybe you could just resend that patch after addressing Kevin's comments?

It's sad that USB_EHCI_HCD is too instable to be added in omap2plus_defconfig.
Still, USB_PHY and NOP_USB_XCEIV are needed since v3.10 for USB
support (and harmless): should I send a patch adding those two in
omap2plus_defconfig?

Cheers,
Adrien

Re: [PATCH] ARM: OMAP4: USB_EHCI_HCD needs USB_PHY and NOP_USB_XCEIV

[Roger Quadros]

Adrien,

On 05/28/2013 04:30 PM, Adrien Vergé wrote:
> Dear Arnd and Roger, thank you for your answers.
> 
> 2013/5/28 Roger Quadros <rogerq@ti.com>
>> Selecting NOP_USB_XCEIV is wrong as it in turn depends on USB_PHY.
>>
>> I'm not for depends as it would hide USB_EHCI_HCD_OMAP in menuconfig.
>> I'm for explicitly selecting both, as it makes the user's life much
>> easier.
>> But I'm afraid maintainers might object to that.
>>
>> The other option is to enable the required drivers in omap2plus_defconfig.
>> http://comments.gmane.org/gmane.linux.ports.arm.omap/97899
> 
> This seems a good idea to me, since many OMAP users boot with NFS and
> need USB directly working (Ethernet over USB).
> 
>> Maybe you could just resend that patch after addressing Kevin's comments?
> 
> It's sad that USB_EHCI_HCD is too instable to be added in omap2plus_defconfig.

This is not true as of today. A lot has changed since 2012 and most of the issues that Kevin
had pointed out then have been fixed. The only piece that is missing is allowing the system
to hit lower power states (e.g. RETention) when USB host is suspended. This feature
will eventually be supported when we have IO daisy chaining working with device tree.

> Still, USB_PHY and NOP_USB_XCEIV are needed since v3.10 for USB
> support (and harmless): should I send a patch adding those two in
> omap2plus_defconfig?

Yes please. Thanks :). I'm working on the approach Arnd suggested as well.

cheers,
-roger