linux-kernel - Re: [PATCH 5.13 024/800] usb: renesas-xhci: Fix handling of unknown ROM state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 17 Jul 2021 08:39:19 -0500
From:   Justin Forbes <jmforbes@...uxtx.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Stable <stable@...r.kernel.org>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Vinod Koul <vkoul@...nel.org>, Moritz Fischer <mdf@...nel.org>
Subject: Re: [PATCH 5.13 024/800] usb: renesas-xhci: Fix handling of unknown
 ROM state

On Mon, Jul 12, 2021 at 2:31 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> From: Moritz Fischer <mdf@...nel.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@...r.kernel.org
> Cc: Mathias Nyman <mathias.nyman@...el.com>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Vinod Koul <vkoul@...nel.org>
> Tested-by: Vinod Koul <vkoul@...nel.org>
> Reviewed-by: Vinod Koul <vkoul@...nel.org>
> Signed-off-by: Moritz Fischer <mdf@...nel.org>
> Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.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
>
>