[PATCH v2 0/2] ARM: shmobile: add USB3.0 device node on r8a7790

[PATCH v2 0/2] ARM: shmobile: add USB3.0 device node on r8a7790

[Yoshihiro Shimoda]

 This series is based on Simon's renesas.git branch and
renesas-devel-20141024-v3.18-rc1 tag. If we use the generic phy
driver for R-Car Gen2 (drivers/phy/phy-rcar-gen2.c), we can use
the USB3.0 on lager.

Changes from v1:
 - rebase the repository.

Yoshihiro Shimoda (2):
  ARM: shmobile: r8a7790: add USB3.0 device node
  ARM: shmobile: lager: enable USB3.0

 arch/arm/boot/dts/r8a7790-lager.dts |    6 ++++++
 arch/arm/boot/dts/r8a7790.dtsi      |   10 ++++++++++
 2 files changed, 16 insertions(+)

-- 
1.7.9.5

[PATCH v2 1/2] ARM: shmobile: r8a7790: add USB3.0 device node

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
 arch/arm/boot/dts/r8a7790.dtsi |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 3f1e4b3..776f1c4 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1147,6 +1147,16 @@
 		status = "disabled";
 	};
 
+	xhci: usb@ee000000 {
+		compatible = "renesas,xhci-r8a7790";
+		reg = <0 0xee000000 0 0xc00>;
+		interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7790_CLK_SSUSB>;
+		phys = <&usb2 1>;
+		phy-names = "usb";
+		status = "disabled";
+	};
+
 	pci0: pci@ee090000 {
 		compatible = "renesas,pci-r8a7790";
 		device_type = "pci";
-- 
1.7.9.5

[PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[Yoshihiro Shimoda]

Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0
driver cannot use the phy driver when the EHCI/OHCI ch2 already used it:

phy phy-e6590100.usb-phy.3: phy init failed --> -16
xhci-hcd: probe of ee000000.usb failed with error -16

If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind
the USB3.0 driver as the following:

  echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind
  echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind
  echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind

Note that there will be pinctrl-related error messages if both
internal PCI and USB3.0 are enabled but they should be just ignored:

sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb
sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22
ata1: SATA link down (SStatus 0 SControl 300)
sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2  on device sh-pfc

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
 arch/arm/boot/dts/r8a7790-lager.dts |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 2115de2..b48173b 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -419,6 +419,12 @@
 	pinctrl-names = "default";
 };
 
+&xhci {
+	status = "okay";
+	pinctrl-0 = <&usb2_pins>;
+	pinctrl-names = "default";
+};
+
 &pci2 {
 	status = "okay";
 	pinctrl-0 = <&usb2_pins>;
-- 
1.7.9.5

Re: [PATCH v2 0/2] ARM: shmobile: add USB3.0 device node on r8a7790

[Simon Horman]

On Fri, Oct 24, 2014 at 07:41:45PM +0900, Yoshihiro Shimoda wrote:
>  This series is based on Simon's renesas.git branch and
> renesas-devel-20141024-v3.18-rc1 tag. If we use the generic phy
> driver for R-Car Gen2 (drivers/phy/phy-rcar-gen2.c), we can use
> the USB3.0 on lager.

Thanks, I have queued these up.

> 
> Changes from v1:
>  - rebase the repository.
> 
> Yoshihiro Shimoda (2):
>   ARM: shmobile: r8a7790: add USB3.0 device node
>   ARM: shmobile: lager: enable USB3.0
> 
>  arch/arm/boot/dts/r8a7790-lager.dts |    6 ++++++
>  arch/arm/boot/dts/r8a7790.dtsi      |   10 ++++++++++
>  2 files changed, 16 insertions(+)
> 
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[Magnus Damm]

On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0
> driver cannot use the phy driver when the EHCI/OHCI ch2 already used it:
>
> phy phy-e6590100.usb-phy.3: phy init failed --> -16
> xhci-hcd: probe of ee000000.usb failed with error -16
>
> If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind
> the USB3.0 driver as the following:
>
>   echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind
>   echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind
>   echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind
>
> Note that there will be pinctrl-related error messages if both
> internal PCI and USB3.0 are enabled but they should be just ignored:
>
> sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb
> sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22
> ata1: SATA link down (SStatus 0 SControl 300)
> sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2  on device sh-pfc
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
>  arch/arm/boot/dts/r8a7790-lager.dts |    6 ++++++
>  1 file changed, 6 insertions(+)

Hi Shimoda-san,

Thanks for your patch. I'm fine with this patch as a first step, but
I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?

Is the current order just based on device init order? In my mind the
expected behavior would be to always use USB 3.0 if it happens to be
available in the hardware, specified in the DTS, enabled by the kernel
configuration and firmware is loadable. Or does some case exist where
it is better to use USB 2.0? I suspect no.

So I wonder if you have any plans how to make USB 3.0 enabled by
default on Lager?

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[Yoshihiro Shimoda]

Hi Magnus-san,

(2014/10/29 15:53), Magnus Damm wrote:
> On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
>> Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0
>> driver cannot use the phy driver when the EHCI/OHCI ch2 already used it:
>>
>> phy phy-e6590100.usb-phy.3: phy init failed --> -16
>> xhci-hcd: probe of ee000000.usb failed with error -16
>>
>> If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind
>> the USB3.0 driver as the following:
>>
>>   echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind
>>   echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind
>>   echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind
>>
>> Note that there will be pinctrl-related error messages if both
>> internal PCI and USB3.0 are enabled but they should be just ignored:
>>
>> sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb
>> sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22
>> ata1: SATA link down (SStatus 0 SControl 300)
>> sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2  on device sh-pfc
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> ---
>>  arch/arm/boot/dts/r8a7790-lager.dts |    6 ++++++
>>  1 file changed, 6 insertions(+)
> 
> Hi Shimoda-san,
> 
> Thanks for your patch. I'm fine with this patch as a first step, but
> I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?

I investigated this reason today, and I found the reason is request_firmware().
I checked the following environments:

 Case 1: xHCI and EHCI and OHCI are enabled "=y"
 Case 2: xHCI and EHCI and OHCI are loadable modules "=m"
 Case 3: xHCI and EHCI and OHCI are enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled

The results are:
 - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware.
 - In "Case 2" and "Case 3", xHCI is probed first.

> Is the current order just based on device init order? In my mind the
> expected behavior would be to always use USB 3.0 if it happens to be
> available in the hardware, specified in the DTS, enabled by the kernel
> configuration and firmware is loadable. Or does some case exist where
> it is better to use USB 2.0? I suspect no.

I agree with you.

> So I wonder if you have any plans how to make USB 3.0 enabled by
> default on Lager?

It depends on a kernel config. I'm not sure of the shmobile_defconfig strategy.
But, in my opinion, one of a solution is kernel modules (this means the "Case 2".)

Best regards,
Yoshihiro Shimoda

> Thanks,
> 
> / magnus
> 

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[Simon Horman]

On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote:
> Hi Magnus-san,
> 
> (2014/10/29 15:53), Magnus Damm wrote:
> > On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda
> > <yoshihiro.shimoda.uh@renesas.com> wrote:
> >> Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0
> >> driver cannot use the phy driver when the EHCI/OHCI ch2 already used it:
> >>
> >> phy phy-e6590100.usb-phy.3: phy init failed --> -16
> >> xhci-hcd: probe of ee000000.usb failed with error -16
> >>
> >> If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind
> >> the USB3.0 driver as the following:
> >>
> >>   echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind
> >>   echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind
> >>   echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind
> >>
> >> Note that there will be pinctrl-related error messages if both
> >> internal PCI and USB3.0 are enabled but they should be just ignored:
> >>
> >> sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb
> >> sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22
> >> ata1: SATA link down (SStatus 0 SControl 300)
> >> sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2  on device sh-pfc
> >>
> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >> ---
> >>  arch/arm/boot/dts/r8a7790-lager.dts |    6 ++++++
> >>  1 file changed, 6 insertions(+)
> > 
> > Hi Shimoda-san,
> > 
> > Thanks for your patch. I'm fine with this patch as a first step, but
> > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?
> 
> I investigated this reason today, and I found the reason is
> request_firmware().  I checked the following environments:
> 
>  Case 1: xHCI and EHCI and OHCI are enabled "=y" Case 2: xHCI and EHCI
>  and OHCI are loadable modules "=m" Case 3: xHCI and EHCI and OHCI are
>  enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled
> 
> The results are: - In "Case 1", EHCI and OHCI are probed first because
> xHCI didn't find the firmware.  - In "Case 2" and "Case 3", xHCI is
> probed first.
> 
> > Is the current order just based on device init order? In my mind the
> > expected behavior would be to always use USB 3.0 if it happens to be
> > available in the hardware, specified in the DTS, enabled by the kernel
> > configuration and firmware is loadable. Or does some case exist where
> > it is better to use USB 2.0? I suspect no.
> 
> I agree with you.
> 
> > So I wonder if you have any plans how to make USB 3.0 enabled by
> > default on Lager?
> 
> It depends on a kernel config. I'm not sure of the shmobile_defconfig
> strategy.  But, in my opinion, one of a solution is kernel modules (this
> means the "Case 2".)

It sounds like we should enable CONFIG_EXTRA_FIRMWARE in
shmobile_defconfig. I wonder what if any fallout we can foresee occurring
if we do that.

RE: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[yoshihiro shimoda]

Hi Simon-san,

> On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote:
> > Hi Magnus-san,
> >
> > (2014/10/29 15:53), Magnus Damm wrote:
< snip >
> > >
> > > Hi Shimoda-san,
> > >
> > > Thanks for your patch. I'm fine with this patch as a first step, but
> > > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?
> >
> > I investigated this reason today, and I found the reason is
> > request_firmware().  I checked the following environments:
> >
> >  Case 1: xHCI and EHCI and OHCI are enabled "=y" Case 2: xHCI and EHCI
> > and OHCI are loadable modules "=m" Case 3: xHCI and EHCI and OHCI are
> > enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled
> >
> > The results are: - In "Case 1", EHCI and OHCI are probed first because
> > xHCI didn't find the firmware.  - In "Case 2" and "Case 3", xHCI is
> > probed first.
> >
> > > Is the current order just based on device init order? In my mind the
> > > expected behavior would be to always use USB 3.0 if it happens to be
> > > available in the hardware, specified in the DTS, enabled by the
> > > kernel configuration and firmware is loadable. Or does some case
> > > exist where it is better to use USB 2.0? I suspect no.
> >
> > I agree with you.
> >
> > > So I wonder if you have any plans how to make USB 3.0 enabled by
> > > default on Lager?
> >
> > It depends on a kernel config. I'm not sure of the shmobile_defconfig
> > strategy.  But, in my opinion, one of a solution is kernel modules
> > (this means the "Case 2".)
> 
> It sounds like we should enable CONFIG_EXTRA_FIRMWARE in shmobile_defconfig. I wonder what if any fallout we can foresee
> occurring if we do that.

According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory now.
So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't exist in the linux.git.

=== from  firmware/README.AddingFirmware =====================================
This directory is _NOT_ for adding arbitrary new firmware images. The
place to add those is the separate linux-firmware repository:

    git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
==============================================================================

Best regards,
Yoshihiro Shimoda

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[Simon Horman]

On Fri, Oct 31, 2014 at 02:06:14AM +0000, yoshihiro shimoda wrote:
> Hi Simon-san,
> 
> > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote:
> > > Hi Magnus-san,
> > >
> > > (2014/10/29 15:53), Magnus Damm wrote:
> < snip >
> > > >
> > > > Hi Shimoda-san,
> > > >
> > > > Thanks for your patch. I'm fine with this patch as a first step, but
> > > > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?
> > >
> > > I investigated this reason today, and I found the reason is
> > > request_firmware().  I checked the following environments:
> > >
> > > Case 1: xHCI and EHCI and OHCI are enabled "=y"
> > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m"
> > > Case 3: xHCI and EHCI and OHCI are enabled "=y",
> > >         and CONFIG_EXTRA_FIRMWARE is enabled
> > >
> > > The results are:
> > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware. 
> > > - In "Case 2" and "Case 3", xHCI is probed first.
> > >
> > > > Is the current order just based on device init order? In my mind the
> > > > expected behavior would be to always use USB 3.0 if it happens to be
> > > > available in the hardware, specified in the DTS, enabled by the
> > > > kernel configuration and firmware is loadable. Or does some case
> > > > exist where it is better to use USB 2.0? I suspect no.
> > >
> > > I agree with you.
> > >
> > > > So I wonder if you have any plans how to make USB 3.0 enabled by
> > > > default on Lager?
> > >
> > > It depends on a kernel config. I'm not sure of the shmobile_defconfig
> > > strategy.  But, in my opinion, one of a solution is kernel modules
> > > (this means the "Case 2".)
> > 
> > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in shmobile_defconfig. I wonder what if any fallout we can foresee
> > occurring if we do that.
> 
> According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory now.
> So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't exist in the linux.git.
> 
> === from  firmware/README.AddingFirmware =====================================
> This directory is _NOT_ for adding arbitrary new firmware images. The
> place to add those is the separate linux-firmware repository:
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> ==============================================================================

Thanks. It seems that EXTRA_FIRMWARE is not an option from
a mainline point of view after all.

Is the problem in case 1 that the firmware can't be found because
userspace does exist yet and thus can't be loaded from there?

RE: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[yoshihiro shimoda]

Hi Simon-san,

> On Fri, Oct 31, 2014 at 02:06:14AM +0000, yoshihiro shimoda wrote:
> > Hi Simon-san,
> >
> > > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote:
> > > > Hi Magnus-san,
> > > >
> > > > (2014/10/29 15:53), Magnus Damm wrote:
> > < snip >
> > > > >
> > > > > Hi Shimoda-san,
> > > > >
> > > > > Thanks for your patch. I'm fine with this patch as a first step,
> > > > > but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?
> > > >
> > > > I investigated this reason today, and I found the reason is
> > > > request_firmware().  I checked the following environments:
> > > >
> > > > Case 1: xHCI and EHCI and OHCI are enabled "=y"
> > > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m"
> > > > Case 3: xHCI and EHCI and OHCI are enabled "=y",
> > > >         and CONFIG_EXTRA_FIRMWARE is enabled
> > > >
> > > > The results are:
> > > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware.
> > > > - In "Case 2" and "Case 3", xHCI is probed first.
> > > >
> > > > > Is the current order just based on device init order? In my mind
> > > > > the expected behavior would be to always use USB 3.0 if it
> > > > > happens to be available in the hardware, specified in the DTS,
> > > > > enabled by the kernel configuration and firmware is loadable. Or
> > > > > does some case exist where it is better to use USB 2.0? I suspect no.
> > > >
> > > > I agree with you.
> > > >
> > > > > So I wonder if you have any plans how to make USB 3.0 enabled by
> > > > > default on Lager?
> > > >
> > > > It depends on a kernel config. I'm not sure of the
> > > > shmobile_defconfig strategy.  But, in my opinion, one of a
> > > > solution is kernel modules (this means the "Case 2".)
> > >
> > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in
> > > shmobile_defconfig. I wonder what if any fallout we can foresee occurring if we do that.
> >
> > According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory
> now.
> > So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't
> exist in the linux.git.
> >
> > === from  firmware/README.AddingFirmware
> > =====================================
> > This directory is _NOT_ for adding arbitrary new firmware images. The
> > place to add those is the separate linux-firmware repository:
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.
> > git
> > ======================================================================
> > ========
> 
> Thanks. It seems that EXTRA_FIRMWARE is not an option from a mainline point of view after all.
> 
> Is the problem in case 1 that the firmware can't be found because userspace does exist yet and thus can't be loaded from
> there?

That's correct.
If EXTRA_FIRMWARE is not set, the following error happens:

xhci-hcd ee000000.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed with error -2
xhci-hcd ee000000.usb: can't setup: -2
xhci-hcd ee000000.usb: USB bus 1 deregistered
xhci-hcd: probe of ee000000.usb failed with error -2

Best regards,
Yoshihiro Shimoda

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

[Simon Horman]

On Fri, Oct 31, 2014 at 01:22:22PM +0000, yoshihiro shimoda wrote:
> Hi Simon-san,
> 
> > On Fri, Oct 31, 2014 at 02:06:14AM +0000, yoshihiro shimoda wrote:
> > > Hi Simon-san,
> > >
> > > > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote:
> > > > > Hi Magnus-san,
> > > > >
> > > > > (2014/10/29 15:53), Magnus Damm wrote:
> > > < snip >
> > > > > >
> > > > > > Hi Shimoda-san,
> > > > > >
> > > > > > Thanks for your patch. I'm fine with this patch as a first step,
> > > > > > but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0?
> > > > >
> > > > > I investigated this reason today, and I found the reason is
> > > > > request_firmware().  I checked the following environments:
> > > > >
> > > > > Case 1: xHCI and EHCI and OHCI are enabled "=y"
> > > > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m"
> > > > > Case 3: xHCI and EHCI and OHCI are enabled "=y",
> > > > >         and CONFIG_EXTRA_FIRMWARE is enabled
> > > > >
> > > > > The results are:
> > > > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware.
> > > > > - In "Case 2" and "Case 3", xHCI is probed first.
> > > > >
> > > > > > Is the current order just based on device init order? In my mind
> > > > > > the expected behavior would be to always use USB 3.0 if it
> > > > > > happens to be available in the hardware, specified in the DTS,
> > > > > > enabled by the kernel configuration and firmware is loadable. Or
> > > > > > does some case exist where it is better to use USB 2.0? I suspect no.
> > > > >
> > > > > I agree with you.
> > > > >
> > > > > > So I wonder if you have any plans how to make USB 3.0 enabled by
> > > > > > default on Lager?
> > > > >
> > > > > It depends on a kernel config. I'm not sure of the
> > > > > shmobile_defconfig strategy.  But, in my opinion, one of a
> > > > > solution is kernel modules (this means the "Case 2".)
> > > >
> > > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in
> > > > shmobile_defconfig. I wonder what if any fallout we can foresee occurring if we do that.
> > >
> > > According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory
> > now.
> > > So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't
> > exist in the linux.git.
> > >
> > > === from  firmware/README.AddingFirmware
> > > =====================================
> > > This directory is _NOT_ for adding arbitrary new firmware images. The
> > > place to add those is the separate linux-firmware repository:
> > >
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.
> > > git
> > > ======================================================================
> > > ========
> > 
> > Thanks. It seems that EXTRA_FIRMWARE is not an option from a mainline point of view after all.
> > 
> > Is the problem in case 1 that the firmware can't be found because userspace does exist yet and thus can't be loaded from
> > there?
> 
> That's correct.
> If EXTRA_FIRMWARE is not set, the following error happens:
> 
> xhci-hcd ee000000.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed with error -2
> xhci-hcd ee000000.usb: can't setup: -2
> xhci-hcd ee000000.usb: USB bus 1 deregistered
> xhci-hcd: probe of ee000000.usb failed with error -2

At the risk of adding noise to this discussion:
It seems like case 2 with a fallback to case 3 is the way to go.