linux-kernel - Re: [PATCH] usb: xhci: Restore Renesas uPD72020x support in xhci-pci

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]

Message-ID: <2025020307-charity-snowfield-c975@gregkh>
Date: Mon, 3 Feb 2025 13:46:41 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: nb@...i-net.de
Cc: Mathias Nyman <mathias.nyman@...el.com>,
	Ben Hutchings <ben@...adent.org.uk>, n.buchwitz@...bus.com,
	l.sanfilippo@...bus.com, stable@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: xhci: Restore Renesas uPD72020x support in xhci-pci

On Mon, Feb 03, 2025 at 01:00:26PM +0100, nb@...i-net.de wrote:
> From: Nicolai Buchwitz <nb@...i-net.de>
> 
> Before commit 25f51b76f90f1 ("xhci-pci: Make xhci-pci-renesas a proper
> modular driver"), the xhci-pci driver handled the Renesas uPD72020x USB3
> PHY and only utilized features of xhci-pci-renesas when no external
> firmware EEPROM was attached. This allowed devices with a valid firmware
> stored in EEPROM to function without requiring xhci-pci-renesas.
> 
> That commit changed the behavior, making xhci-pci-renesas responsible for
> handling these devices entirely, even when firmware was already present
> in EEPROM. As a result, unnecessary warnings about missing firmware files
> appeared, and more critically, USB functionality broke whens
> CONFIG_USB_XHCI_PCI_RENESAS was not enabled—despite previously workings
> without it.
> 
> Fix this by ensuring that devices are only handed over to xhci-pci-renesas
> if the config option is enabled. Otherwise, restore the original behavior
> and handle them as standard xhci-pci devices.
> 
> Signed-off-by: Nicolai Buchwitz <nb@...i-net.de>
> Fixes: 25f51b76f90f ("xhci-pci: Make xhci-pci-renesas a proper modular driver")
> ---
>  drivers/usb/host/xhci-pci.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 2d1e205c14c60..4ce80d8ac603e 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -654,9 +654,11 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id)
>  EXPORT_SYMBOL_NS_GPL(xhci_pci_common_probe, "xhci");
>  
>  static const struct pci_device_id pci_ids_reject[] = {
> +#if IS_ENABLED(CONFIG_USB_XHCI_PCI_RENESAS)
>  	/* handled by xhci-pci-renesas */
>  	{ PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0014) },
>  	{ PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0015) },
> +#endif
>  	{ /* end: all zeroes */ }
>  };

Have you seen:
	https://lore.kernel.org/r/20250128104529.58a79bfc@foxbook
?

Which one is correct?

thanks,

greg k-h