Hi,

Alan Stern [off-list ref] writes:

quoted

Greg Kroah-Hartman [off-list ref] writes:

quoted

On Thu, Jun 06, 2019 at 10:55:24AM -0400, Alan Stern wrote:

quoted

On Thu, 6 Jun 2019, Greg Kroah-Hartman wrote:

quoted

On Thu, Jun 06, 2019 at 10:24:18AM -0400, Alan Stern wrote:

quoted

On Thu, 6 Jun 2019, David Howells wrote:

quoted

Add a USB subsystem notification mechanism whereby notifications about
hardware events such as device connection, disconnection, reset and I/O
errors, can be reported to a monitoring process asynchronously.

USB I/O errors covers an awfully large and vague field.  Do we really
want to include them?  I'm doubtful.

See the other patch on the linux-usb list that wanted to start adding
KOBJ_CHANGE notifications about USB "i/o errors".

That patch wanted to add notifications only for enumeration failures
(assuming you're talking about the patch from Eugeniu Rosca), not I/O
errors in general.

Yes, sorry, I was thinking that as a "I/O failed in enumeration" :)

quoted

quoted

So for "severe" issues, yes, we should do this, but perhaps not for all
of the "normal" things we see when a device is yanked out of the system
and the like.

Then what counts as a "severe" issue?  Anything besides enumeration 
failure?

Not that I can think of at the moment, other than the other recently
added KOBJ_CHANGE issue.  I'm sure we have other "hard failure" issues
in the USB stack that people will want exposed over time.

From an XHCI standpoint, Transaction Errors might be one thing. They
happen rarely and are a strong indication that the bus itself is
bad. Either bad cable, misbehaving PHYs, improper power management, etc.

Don't you also get transaction errors if the user unplugs a device in 
the middle of a transfer?  That's not the sort of thing we want to sent 
notifications about.

Mathias, do we get Transaction Error if user removes cable during a
transfer? I thought we would just get Port Status Change with CC bit
cleared, no?

-- 
balbi