Re: [PATCH v5 2/3] Documentation: ABI: document DEVICE_ENUMERATION_FAILURE uevent

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Jul 27, 2026 at 01:32:32PM +0000, Akshay Gujar wrote:
> On Sat, Jul 25, 2026 at 07:21:30AM +0200, Greg KH wrote:
> > > > > +What:          DEVICE_ENUMERATION_FAILURE
> > > > > +Date:          July 2026
> > > > > +KernelVersion: 7.3
> > > > > +Description:
> > > > > +               Some devices may be detected but fail to enumerate
> > > > > +               due to protocol-level errors or invalid responses.
> > > > > +
> > > > > +               A KOBJ_CHANGE uevent includes the following environment
> > > > > +               variable when this occurs:
> > > > > +
> > > > > +                 DEVICE_ENUMERATION_FAILURE=<dev_name>
> > > > > +
> > > > > +               The value is the kernel device name of the device for
> > > > > +               which enumeration failed, as returned by dev_name().
> > > > > +
> > > > > +               Example (USB):
> > > > > +
> > > > > +               ACTION=change
> > > > > +               SUBSYSTEM=usb
> > > > > +               DEVTYPE=usb_interface
> > > > 
> > > > This will be the port device, not the usb interface, right?
> > > 
> > > No, DEVTYPE=usb_interface is correct, the example was captured on
> > > real hardware. The uevent is not emitted from the port device itself.
> > > usb_port devices have no bus or class, so dev_uevent_filter()
> > > drops any event from them.It is emitted from the port's parent, 
> > > the hub's usb_interface device, while the failing port is identified in the payload instead.
> 
> > So shouldn't we fix the fact that usb_ports are not on the bus and add
> > them to one?  Would that make things more obvious here as to what port
> > the issue is happening on, and potentially allow userspace to actually
> > figure out which physical port the problem is?
> 
> Adding usb_port devices to usb_bus_type does not fit. usb_device_match()
> only handles usb_device and usb_interface, so ports would fall through
> unmatched, and bus-managed binding would conflict with the existing
> usb_port_driver assignment.

We can change usb_device_match() to not do that :)

> Userspace can already resolve the physical port directly from the
> event today:
> 
>   DEVPATH=/devices/.../usb1/1-0:1.0
>   DEVICE_ENUMERATION_FAILURE=usb1-port1
> 
> which corresponds to:
>   -> /sys/devices/.../usb1/1-0:1.0/usb1-port1
> 
> Appending the payload name to DEVPATH gives the exact sysfs path to
> the failing port on the hub.

That feels odd, as the port is the device having the problem.

> I dropped the DEVPATH line from the documentation example by mistake.
> Will restore it in v6 so the emitter/payload relationship is clear.

Ok, maybe your next version will make more sense, as I'm confused now :)

thanks,

greg k-h