| Message ID | 20210712060916.499546891@linuxfoundation.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | None | expand |
On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > From: Moritz Fischer <mdf@kernel.org> > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > The ROM load sometimes seems to return an unknown status > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > If the ROM load indeed failed this leads to failures when trying to > communicate with the controller later on. > > Attempt to load firmware using RAM load in those cases. > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > Cc: stable@vger.kernel.org > Cc: Mathias Nyman <mathias.nyman@intel.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Vinod Koul <vkoul@kernel.org> > Tested-by: Vinod Koul <vkoul@kernel.org> > Reviewed-by: Vinod Koul <vkoul@kernel.org> > Signed-off-by: Moritz Fischer <mdf@kernel.org> > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > After sending out 5.12.17 for testing, we had a user complain that all of their USB devices disappeared with the error: Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2 Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 After first assuming that something was missing in the backport to 5.12, I had the user try 5.13.2, and then 5.14-rc1. Both of those failed in the same way, so it is not working in the current Linus tree either. Reverting this patch fixed the issue. Justin > --- > drivers/usb/host/xhci-pci-renesas.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > --- a/drivers/usb/host/xhci-pci-renesas.c > +++ b/drivers/usb/host/xhci-pci-renesas.c > @@ -207,7 +207,8 @@ static int renesas_check_rom_state(struc > return 0; > > case RENESAS_ROM_STATUS_NO_RESULT: /* No result yet */ > - return 0; > + dev_dbg(&pdev->dev, "Unknown ROM status ...\n"); > + break; > > case RENESAS_ROM_STATUS_ERROR: /* Error State */ > default: /* All other states are marked as "Reserved states" */ > @@ -224,13 +225,12 @@ static int renesas_fw_check_running(stru > u8 fw_state; > int err; > > - /* Check if device has ROM and loaded, if so skip everything */ > - err = renesas_check_rom(pdev); > - if (err) { /* we have rom */ > - err = renesas_check_rom_state(pdev); > - if (!err) > - return err; > - } > + /* > + * Only if device has ROM and loaded FW we can skip loading and > + * return success. Otherwise (even unknown state), attempt to load FW. > + */ > + if (renesas_check_rom(pdev) && !renesas_check_rom_state(pdev)) > + return 0; > > /* > * Test if the device is actually needing the firmware. As most > >
On Sat, Jul 17, 2021 at 08:39:19AM -0500, Justin Forbes wrote: > On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > From: Moritz Fischer <mdf@kernel.org> > > > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > > > The ROM load sometimes seems to return an unknown status > > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > > > If the ROM load indeed failed this leads to failures when trying to > > communicate with the controller later on. > > > > Attempt to load firmware using RAM load in those cases. > > > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > > Cc: stable@vger.kernel.org > > Cc: Mathias Nyman <mathias.nyman@intel.com> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Vinod Koul <vkoul@kernel.org> > > Tested-by: Vinod Koul <vkoul@kernel.org> > > Reviewed-by: Vinod Koul <vkoul@kernel.org> > > Signed-off-by: Moritz Fischer <mdf@kernel.org> > > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > After sending out 5.12.17 for testing, we had a user complain that all > of their USB devices disappeared with the error: > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load > for renesas_usb_fw.mem failed with error -2 > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 > Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 > > After first assuming that something was missing in the backport to > 5.12, I had the user try 5.13.2, and then 5.14-rc1. Both of those > failed in the same way, so it is not working in the current Linus tree > either. Reverting this patch fixed the issue. Can you send a revert for this so I can get that into Linus's tree and then all stable releases as well? thanks, greg k-h
On Sat, Jul 17, 2021 at 07:34:51PM +0200, Greg Kroah-Hartman wrote: > On Sat, Jul 17, 2021 at 08:39:19AM -0500, Justin Forbes wrote: > > On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > > > > > > From: Moritz Fischer <mdf@kernel.org> > > > > > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > > > > > The ROM load sometimes seems to return an unknown status > > > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > > > > > If the ROM load indeed failed this leads to failures when trying to > > > communicate with the controller later on. > > > > > > Attempt to load firmware using RAM load in those cases. > > > > > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > > > Cc: stable@vger.kernel.org > > > Cc: Mathias Nyman <mathias.nyman@intel.com> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > Cc: Vinod Koul <vkoul@kernel.org> > > > Tested-by: Vinod Koul <vkoul@kernel.org> > > > Reviewed-by: Vinod Koul <vkoul@kernel.org> > > > Signed-off-by: Moritz Fischer <mdf@kernel.org> > > > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > After sending out 5.12.17 for testing, we had a user complain that all > > of their USB devices disappeared with the error: > > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load > > for renesas_usb_fw.mem failed with error -2 > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 > > Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 > > > > After first assuming that something was missing in the backport to > > 5.12, I had the user try 5.13.2, and then 5.14-rc1. Both of those > > failed in the same way, so it is not working in the current Linus tree > > either. Reverting this patch fixed the issue. > > Can you send a revert for this so I can get that into Linus's tree and > then all stable releases as well? > > thanks, > > greg k-h Me or Justin? I can do it. This is annoying my system doesn't work without this :-( Back to the drawing board I guess ... Justin, any idea if your customer had the eeprom populated and programmed or not, just as additional datapoint. - Moritz
Justin, On Sat, Jul 17, 2021 at 08:39:19AM -0500, Justin Forbes wrote: > On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > From: Moritz Fischer <mdf@kernel.org> > > > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > > > The ROM load sometimes seems to return an unknown status > > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > > > If the ROM load indeed failed this leads to failures when trying to > > communicate with the controller later on. > > > > Attempt to load firmware using RAM load in those cases. > > > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > > Cc: stable@vger.kernel.org > > Cc: Mathias Nyman <mathias.nyman@intel.com> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Vinod Koul <vkoul@kernel.org> > > Tested-by: Vinod Koul <vkoul@kernel.org> > > Reviewed-by: Vinod Koul <vkoul@kernel.org> > > Signed-off-by: Moritz Fischer <mdf@kernel.org> > > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > After sending out 5.12.17 for testing, we had a user complain that all > of their USB devices disappeared with the error: > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load > for renesas_usb_fw.mem failed with error -2 > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 > Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 This looks like it fails finding the actual firmware file (ENOENT). Any chance you could give this a whirl on top of the original patch? diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 18c2bbddf080..cde8f6f1ec5d 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -379,7 +379,11 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) driver_data = (struct xhci_driver_data *)id->driver_data; if (driver_data && driver_data->quirks & XHCI_RENESAS_FW_QUIRK) { retval = renesas_xhci_check_request_fw(dev, id); - if (retval) + /* + * If firmware wasn't found there's still a chance this might work without + * loading firmware on some systems, so let's try at least. + */ + if (retval && retval != -ENOENT) return retval; } Thanks, Moritz
On Sat, Jul 17, 2021 at 2:48 PM Moritz Fischer <mdf@kernel.org> wrote: > > On Sat, Jul 17, 2021 at 07:34:51PM +0200, Greg Kroah-Hartman wrote: > > On Sat, Jul 17, 2021 at 08:39:19AM -0500, Justin Forbes wrote: > > > On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman > > > <gregkh@linuxfoundation.org> wrote: > > > > > > > > From: Moritz Fischer <mdf@kernel.org> > > > > > > > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > > > > > > > The ROM load sometimes seems to return an unknown status > > > > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > > > > > > > If the ROM load indeed failed this leads to failures when trying to > > > > communicate with the controller later on. > > > > > > > > Attempt to load firmware using RAM load in those cases. > > > > > > > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > > > > Cc: stable@vger.kernel.org > > > > Cc: Mathias Nyman <mathias.nyman@intel.com> > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > Cc: Vinod Koul <vkoul@kernel.org> > > > > Tested-by: Vinod Koul <vkoul@kernel.org> > > > > Reviewed-by: Vinod Koul <vkoul@kernel.org> > > > > Signed-off-by: Moritz Fischer <mdf@kernel.org> > > > > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > > > After sending out 5.12.17 for testing, we had a user complain that all > > > of their USB devices disappeared with the error: > > > > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load > > > for renesas_usb_fw.mem failed with error -2 > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 > > > Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 > > > > > > After first assuming that something was missing in the backport to > > > 5.12, I had the user try 5.13.2, and then 5.14-rc1. Both of those > > > failed in the same way, so it is not working in the current Linus tree > > > either. Reverting this patch fixed the issue. > > > > Can you send a revert for this so I can get that into Linus's tree and > > then all stable releases as well? > > > > thanks, > > > > greg k-h > > Me or Justin? I can do it. This is annoying my system doesn't work > without this :-( > > Back to the drawing board I guess ... > > Justin, any idea if your customer had the eeprom populated and > programmed or not, just as additional datapoint. I am not sure, but I did have another user chime in on the bug saying the test kernel with the revert fixed their system as well. It was a T14s AMD Generation_1. The original reporter had a ASUS System Product Name/PRIME H370M-PLUS, BIOS 2801 04/13/2021. Justin > - Moritz
On Sat, Jul 17, 2021 at 5:33 PM Moritz Fischer <mdf@kernel.org> wrote: > > Justin, > > On Sat, Jul 17, 2021 at 08:39:19AM -0500, Justin Forbes wrote: > > On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > > > > > > From: Moritz Fischer <mdf@kernel.org> > > > > > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > > > > > The ROM load sometimes seems to return an unknown status > > > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > > > > > If the ROM load indeed failed this leads to failures when trying to > > > communicate with the controller later on. > > > > > > Attempt to load firmware using RAM load in those cases. > > > > > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > > > Cc: stable@vger.kernel.org > > > Cc: Mathias Nyman <mathias.nyman@intel.com> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > Cc: Vinod Koul <vkoul@kernel.org> > > > Tested-by: Vinod Koul <vkoul@kernel.org> > > > Reviewed-by: Vinod Koul <vkoul@kernel.org> > > > Signed-off-by: Moritz Fischer <mdf@kernel.org> > > > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > After sending out 5.12.17 for testing, we had a user complain that all > > of their USB devices disappeared with the error: > > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load > > for renesas_usb_fw.mem failed with error -2 > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 > > Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 > > This looks like it fails finding the actual firmware file (ENOENT). Any > chance you could give this a whirl on top of the original patch? > Sure. test kernel building now, will let you know when the user reports back. Justin > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > index 18c2bbddf080..cde8f6f1ec5d 100644 > --- a/drivers/usb/host/xhci-pci.c > +++ b/drivers/usb/host/xhci-pci.c > @@ -379,7 +379,11 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) > driver_data = (struct xhci_driver_data *)id->driver_data; > if (driver_data && driver_data->quirks & XHCI_RENESAS_FW_QUIRK) { > retval = renesas_xhci_check_request_fw(dev, id); > - if (retval) > + /* > + * If firmware wasn't found there's still a chance this might work without > + * loading firmware on some systems, so let's try at least. > + */ > + if (retval && retval != -ENOENT) > return retval; > } > > > Thanks, > Moritz
On Mon, Jul 19, 2021 at 10:33 AM Justin Forbes <jmforbes@linuxtx.org> wrote: > > On Sat, Jul 17, 2021 at 5:33 PM Moritz Fischer <mdf@kernel.org> wrote: > > > > Justin, > > > > On Sat, Jul 17, 2021 at 08:39:19AM -0500, Justin Forbes wrote: > > > On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman > > > <gregkh@linuxfoundation.org> wrote: > > > > > > > > From: Moritz Fischer <mdf@kernel.org> > > > > > > > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > > > > > > > The ROM load sometimes seems to return an unknown status > > > > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > > > > > > > If the ROM load indeed failed this leads to failures when trying to > > > > communicate with the controller later on. > > > > > > > > Attempt to load firmware using RAM load in those cases. > > > > > > > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > > > > Cc: stable@vger.kernel.org > > > > Cc: Mathias Nyman <mathias.nyman@intel.com> > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > Cc: Vinod Koul <vkoul@kernel.org> > > > > Tested-by: Vinod Koul <vkoul@kernel.org> > > > > Reviewed-by: Vinod Koul <vkoul@kernel.org> > > > > Signed-off-by: Moritz Fischer <mdf@kernel.org> > > > > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > > > After sending out 5.12.17 for testing, we had a user complain that all > > > of their USB devices disappeared with the error: > > > > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load > > > for renesas_usb_fw.mem failed with error -2 > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 > > > Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 > > > > This looks like it fails finding the actual firmware file (ENOENT). Any > > chance you could give this a whirl on top of the original patch? > > > > Sure. test kernel building now, will let you know when the user reports back. The original user reports success with this patch on top of the original patch. Justin > > Justin > > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > > index 18c2bbddf080..cde8f6f1ec5d 100644 > > --- a/drivers/usb/host/xhci-pci.c > > +++ b/drivers/usb/host/xhci-pci.c > > @@ -379,7 +379,11 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) > > driver_data = (struct xhci_driver_data *)id->driver_data; > > if (driver_data && driver_data->quirks & XHCI_RENESAS_FW_QUIRK) { > > retval = renesas_xhci_check_request_fw(dev, id); > > - if (retval) > > + /* > > + * If firmware wasn't found there's still a chance this might work without > > + * loading firmware on some systems, so let's try at least. > > + */ > > + if (retval && retval != -ENOENT) > > return retval; > > } > > > > > > Thanks, > > Moritz
On Mon, Jul 19, 2021 at 09:57:00PM -0500, Justin Forbes wrote: > On Mon, Jul 19, 2021 at 10:33 AM Justin Forbes <jmforbes@linuxtx.org> wrote: > > > > On Sat, Jul 17, 2021 at 5:33 PM Moritz Fischer <mdf@kernel.org> wrote: > > > > > > Justin, > > > > > > On Sat, Jul 17, 2021 at 08:39:19AM -0500, Justin Forbes wrote: > > > > On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman > > > > <gregkh@linuxfoundation.org> wrote: > > > > > > > > > > From: Moritz Fischer <mdf@kernel.org> > > > > > > > > > > commit d143825baf15f204dac60acdf95e428182aa3374 upstream. > > > > > > > > > > The ROM load sometimes seems to return an unknown status > > > > > (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. > > > > > > > > > > If the ROM load indeed failed this leads to failures when trying to > > > > > communicate with the controller later on. > > > > > > > > > > Attempt to load firmware using RAM load in those cases. > > > > > > > > > > Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") > > > > > Cc: stable@vger.kernel.org > > > > > Cc: Mathias Nyman <mathias.nyman@intel.com> > > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > Cc: Vinod Koul <vkoul@kernel.org> > > > > > Tested-by: Vinod Koul <vkoul@kernel.org> > > > > > Reviewed-by: Vinod Koul <vkoul@kernel.org> > > > > > Signed-off-by: Moritz Fischer <mdf@kernel.org> > > > > > Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > > > > > > After sending out 5.12.17 for testing, we had a user complain that all > > > > of their USB devices disappeared with the error: > > > > > > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: Direct firmware load > > > > for renesas_usb_fw.mem failed with error -2 > > > > Jul 15 23:18:53 kernel: xhci_hcd 0000:04:00.0: request_firmware failed: -2 > > > > Jul 15 23:18:53 kernel: xhci_hcd: probe of 0000:04:00.0 failed with error -2 > > > > > > This looks like it fails finding the actual firmware file (ENOENT). Any > > > chance you could give this a whirl on top of the original patch? > > > > > > > Sure. test kernel building now, will let you know when the user reports back. > > The original user reports success with this patch on top of the original patch. That's good news I guess. After reading through the datasheet once more I'm even more convinced that the original code with the early return in renesas_check_fw_running() is *very* shady. There are three statuses to be investigated - FW load status (fw_state) - ROM download status (rom_status) - Firmware version as reported by chip Currently there the code takes an early return if the latter says the external ROM is there and the 'write firmware to external ROM' worked out, which I think shouldn't be happening, since it doesn't tell us anything about the firmware state at all. In fact I think the early return should not exist at all (a path that the original patch made more likely to happen). The FW load status indicates whether firmware has been runtime loaded and returns 'No result yet' in your case, too I suspect, which *might* happen if the chip configured itself from external ROM? So the part that is unclear to me somewhat is should we use either of them at all in trying to determine whether we should load firmware? Maybe what we should do is: - Attempt to request_firmware() - If fail -> proceed and hope for the best - If success - Compare the firmware file version with the version reported by the controller - If they don't match, load firmware, otherwise leave it alone? - Moritz > > Justin > > > > > Justin > > > > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > > > index 18c2bbddf080..cde8f6f1ec5d 100644 > > > --- a/drivers/usb/host/xhci-pci.c > > > +++ b/drivers/usb/host/xhci-pci.c > > > @@ -379,7 +379,11 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) > > > driver_data = (struct xhci_driver_data *)id->driver_data; > > > if (driver_data && driver_data->quirks & XHCI_RENESAS_FW_QUIRK) { > > > retval = renesas_xhci_check_request_fw(dev, id); > > > - if (retval) > > > + /* > > > + * If firmware wasn't found there's still a chance this might work without > > > + * loading firmware on some systems, so let's try at least. > > > + */ > > > + if (retval && retval != -ENOENT) > > > return retval; > > > } > > > > > > > > > Thanks, > > > Moritz
--- a/drivers/usb/host/xhci-pci-renesas.c +++ b/drivers/usb/host/xhci-pci-renesas.c @@ -207,7 +207,8 @@ static int renesas_check_rom_state(struc return 0; case RENESAS_ROM_STATUS_NO_RESULT: /* No result yet */ - return 0; + dev_dbg(&pdev->dev, "Unknown ROM status ...\n"); + break; case RENESAS_ROM_STATUS_ERROR: /* Error State */ default: /* All other states are marked as "Reserved states" */ @@ -224,13 +225,12 @@ static int renesas_fw_check_running(stru u8 fw_state; int err; - /* Check if device has ROM and loaded, if so skip everything */ - err = renesas_check_rom(pdev); - if (err) { /* we have rom */ - err = renesas_check_rom_state(pdev); - if (!err) - return err; - } + /* + * Only if device has ROM and loaded FW we can skip loading and + * return success. Otherwise (even unknown state), attempt to load FW. + */ + if (renesas_check_rom(pdev) && !renesas_check_rom_state(pdev)) + return 0; /* * Test if the device is actually needing the firmware. As most