| Message ID | 20191102172606.26934-1-pbrobinson@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | usb: host: xhci-tegra: set MODULE_FIRMWARE for tegra186 | expand |
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@gmail.com> > --- > 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@nvidia.com> > 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 >
On Sat, Nov 2, 2019 at 5:43 PM Thierry Reding <thierry.reding@gmail.com> wrote: > > 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. It works for tegra124 and tegra210, the patches for tegra194 have it as well, I have no idea why it was left out for the tegra186. On Fedora the 124/210 firmwares get pulled into the initrd when the xhci_tegra and deps do but the 186 doesn't, if you "rmmod xhci_tegra; modprobe xhci_tegra" once booted it works fine. > > 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@gmail.com> > > --- > > 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@nvidia.com> > > > 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 > >
On Sat, Nov 02, 2019 at 06:39:45PM +0000, Peter Robinson wrote: > On Sat, Nov 2, 2019 at 5:43 PM Thierry Reding <thierry.reding@gmail.com> wrote: > > > > 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. > > It works for tegra124 and tegra210, the patches for tegra194 have it > as well, I have no idea why it was left out for the tegra186. On > Fedora the 124/210 firmwares get pulled into the initrd when the > xhci_tegra and deps do but the 186 doesn't, if you "rmmod xhci_tegra; > modprobe xhci_tegra" once booted it works fine. Sorry if I wasn't being clear. I'm not debating the correctness of the patch, it obviously was just left out and probably not noticed because nobody that tested this either wasn't building this into the kernel or manually added the firmware to the initial ramdisk. I was just trying to point out that merely adding MODULE_FIRMWARE does not cause the firmware to be installed in the initial ramdisk. You still need some tool looking at the information added by MODULE_FIRMWARE and then copying the corresponding image to the initial ramdisk at its creation. Thierry > > > 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@gmail.com> > > > --- > > > 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@nvidia.com> > > > > > 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 > > >
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: > > 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") There is no such git id in Linus's tree :( This also doesn't apply cleanly to the usb tree, so I don't know where you want it to go, sorry. greg k-h
On Mon, Nov 4, 2019 at 2:57 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > 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: > > > > 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") > > There is no such git id in Linus's tree :( Tha'ts in the tegra tree for 5.5. > This also doesn't apply cleanly to the usb tree, so I don't know where > you want it to go, sorry. Where is that? I can rebase against it, I'm guessing the tegra194 bits landed.
On Mon, Nov 04, 2019 at 03:07:48PM +0000, Peter Robinson wrote: > On Mon, Nov 4, 2019 at 2:57 PM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > 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: > > > > > > 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") > > > > There is no such git id in Linus's tree :( > > Tha'ts in the tegra tree for 5.5. > > > This also doesn't apply cleanly to the usb tree, so I don't know where > > you want it to go, sorry. > > Where is that? I can rebase against it, I'm guessing the tegra194 bits landed. usb.git on git.kernel.org. And yes, it did. But when I applied the above patch, my checks for valid fixes: ids failed so I can't take this as-is. thanks, greg k-h
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 },
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: 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@gmail.com> --- drivers/usb/host/xhci-tegra.c | 1 + 1 file changed, 1 insertion(+)