linux-kernel - Re: [PATCH v2 3/3] usb: hub: send enumeration failure uevent

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: <2026010740-rotunda-squirt-921f@gregkh>
Date: Wed, 7 Jan 2026 16:03:46 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Akshay Gujar <Akshay.Gujar@...man.com>
Cc: linux-usb@...r.kernel.org, stern@...land.harvard.edu, oneukum@...e.com,
	linux-kernel@...r.kernel.org, naveen.v@...man.com,
	sankarkumar.krishnasamy@...man.com
Subject: Re: [PATCH v2 3/3] usb: hub: send enumeration failure uevent

On Wed, Dec 24, 2025 at 11:58:08AM +0000, Akshay Gujar wrote:
> Use the device_enumeration_failure_notify() helper when USB device
> enumeration fails. This supplements the existing kernel log message with
> a structured userspace-visible notification identifying the affected
> port.
> 
> Signed-off-by: Akshay Gujar <Akshay.Gujar@...man.com>
> ---
>  drivers/usb/core/hub.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index be50d03034a9..c1963b1bb9fb 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -5613,9 +5613,12 @@ static void hub_port_connect(struct usb_hub *hub, int port1, u16 portstatus,
>  	if (hub->hdev->parent ||
>  			!hcd->driver->port_handed_over ||
>  			!(hcd->driver->port_handed_over)(hcd, port1)) {
> -		if (status != -ENOTCONN && status != -ENODEV)
> +		if (status != -ENOTCONN && status != -ENODEV) {
>  			dev_err(&port_dev->dev,
>  					"unable to enumerate USB device\n");
> +			device_enumeration_failure_notify(port_dev->dev.parent,

Why use the parent here?  Normally devices can NOT access their parent
pointer "safely" so this feels odd.  Why not have the device itself be
the one that emits this, as that's what dev_err() just gave us.

> +							  dev_name(&port_dev->dev));

Why not just get the name directly from the device you are going to pass
in?  It shouldn't then be needed again, right?

thanks,

greg k-h