On Wed, May 31, 2023 at 01:01:34AM +0000, Roy Luo wrote: > Expose usb device state to userland as the information is useful in > detecting non-compliant setups and diagnosing enumeration failures. > For example: > - End-to-end signal integrity issues: the device would fail port reset > repeatedly and thus be stuck in POWERED state. > - Charge-only cables (missing D+/D- lines): the device would never enter > POWERED state as the HC would not see any pullup. > > What's the status quo? > We do have error logs such as "Cannot enable. Maybe the USB cable is bad?" > to flag potential setup issues, but there's no good way to expose them to > userspace. > > Why add a sysfs entry in struct usb_port instead of struct usb_device? > The struct usb_device is not device_add() to the system until it's in > ADDRESS state hence we would miss the first two states. The struct > usb_port is a better place to keep the information because its life > cycle is longer than the struct usb_device that is attached to the port. > > Signed-off-by: Roy Luo <royluo@xxxxxxxxxx> > --- > Changes since v1: > * Address Greg Kroah-Hartman's comment: replace sysfs_notify with > sysfs_notify_dirent and remove the workqueue. > * Address Alan Stern's comment: replicate port_dev->child->state > in port_dev->state instead of using a pointer to link them. > --- Reviewed-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>