On Sat, Nov 02, 2019 at 05:26:06PM +0000, Peter Robinson wrote:
> Set the MODULE_FIRMWARE for tegra186, it's registered for 124/210 and
> ensures the firmware is available at the appropriate time such as in
> the initrd, else if the firmware is unavailable the driver fails with
> the following errors:
So the MODULE_FIRMWARE macro alone does not ensure that the firmware is
in the correct location, right? Rather, it's the tools that construct
the initial ramdisk that make use of the information added by the
MODULE_FIRMWARE macro to determine whether or not the firmware needs to
be included in the initial ramdisk or not.
> tegra-xusb 3530000.usb: Direct firmware load for nvidia/tegra186/xusb.bin failed with error -2
> tegra-xusb 3530000.usb: failed to request firmware: -2
> tegra-xusb 3530000.usb: failed to load firmware: -2
> tegra-xusb: probe of 3530000.usb failed with error -2
>
> Fixes: 5f9be5f3f899 ("usb: host: xhci-tegra: Add Tegra186 XUSB support")
> Fixes: 488a04d4bb2f ("arm64: tegra: Enable XUSB host controller on Jetson TX2")
> Signed-off-by: Peter Robinson <pbrobinson@xxxxxxxxx>
> ---
> drivers/usb/host/xhci-tegra.c | 1 +
> 1 file changed, 1 insertion(+)
The commit message is slightly misleading, but I guess it's ultimately
correct if you run standard tools to generate the initial ramdisk, so:
Acked-by: Thierry Reding <treding@xxxxxxxxxx>
> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> index 2ff7c911fbd0..d25aba8fa219 100644
> --- a/drivers/usb/host/xhci-tegra.c
> +++ b/drivers/usb/host/xhci-tegra.c
> @@ -1433,6 +1433,7 @@ static const struct tegra_xusb_soc tegra186_soc = {
> .scale_ss_clock = false,
> .has_ipfs = false,
> };
> +MODULE_FIRMWARE("nvidia/tegra186/xusb.bin");
>
> static const struct of_device_id tegra_xusb_of_match[] = {
> { .compatible = "nvidia,tegra124-xusb", .data = &tegra124_soc },
> --
> 2.23.0
>
Attachment:
signature.asc
Description: PGP signature
