On 09/16/2014 04:51 PM, Andrew Bresticker wrote:

On Tue, Sep 16, 2014 at 3:40 PM, Stephen Warren [off-list ref] wrote:

quoted

On 09/16/2014 10:57 AM, Andrew Bresticker wrote:

quoted

On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren [off-list ref] wrote:

quoted

The XHCI driver can't load its firmware unless it's a module; if I make it
built-in, it fails immediately with error -2 during "Direct firmware
loading". The driver needs to work with either immediate or deferred
firmware loading.

If you want the driver to be built-in, you'll either need to build the
firmware in as well (i.e. EXTRA_FIRMWARE) or enable
FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though
apparently this is deprecated).

Hmm. I didn't have to do that for the Atmel touchpad driver to work, but
perhaps it's just ignoring a firmware loading error, and continuing with
whatever is in the device's flash already.

It seems odd that such a fundamental feature would require a deprecated
Kconfig option. Is there some replacement that does the same thing that
isn't deprecated? The Kconfig help for the option doesn't say anything
useful...

Oh, this option doesn't actually seem to work. I see the following in dmesg:

quoted

[root at swarren-dt ~]# dmesg|grep -i -e xhci -e firmware
[    1.461773] xhci-tegra 70090000.usb: Failed to get supply 'avddio-pex':
-517
[    1.468930] platform 70090000.usb: Driver xhci-tegra requests probe
deferral
[    2.567966] xhci-tegra 70090000.usb: Direct firmware load for
nvidia/tegra124/xusb.bin failed with error -2
[    2.577786] xhci-tegra 70090000.usb: Falling back to user helper

... but:

[root at swarren-dt ~]# lsusb
unable to initialize libusb: -99

Perhaps systemd-udevd doesn't implement firmware loading; is it user-space
udev that's deprecated implementing user-space firmware loading, rather than
the kernel deprecating support for calling out to user space?

I believe it is userspace udev that has deprecated user firmware
loading.  The kernel still does call out to userspace.  Alternatively,
you could use the firmware_class loading interface described in
Documentation/firmware_class/README, but that kind of sucks too.

quoted

This sucks, because now I can't just TFTP boot kernels but somehow have to
get updated kernel modules onto my device every time before testing a new
kernel build.

Yeah... it does.  I get around this by building the firmware into the
kernel image (i.e. CONFIG_EXTRA_FIRMWARE), which is also your only
option if the root device happens to be on USB.  Unfortunately, I'm
not aware of any other alternatives.

Ah right, CONFIG_EXTRA_FIRMWARE does work, although it's not something I 
can put into tegra_defconfig for people. I suppose we'll have to make it 
=m in tegra_defconfig, and anyone who wants to build it in will have to 
carry a local patch to add the firmware to their kernel source tree. At 
least with "git add" of the firmware, it won't disappear from disk upon 
"git clean ...".