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

[Simon Horman <horms@verge.net.au>]

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?