Re: USB-C device hotplug issue

[Mathias Nyman]

On 07.11.2018 11:08, Dennis Wassenberg wrote:
> On 05.11.18 16:35, Mathias Nyman wrote:
> > On 26.10.2018 17:07, Alan Stern wrote:
> > > On Fri, 26 Oct 2018, Dennis Wassenberg wrote:
> > >
> > > > > > --- a/drivers/usb/core/hub.c
> > > > > > +++ b/drivers/usb/core/hub.c
> > > > > > @@ -2815,7 +2815,9 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
> > > > > >  ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ USB_PORT_FEAT_C_BH_PORT_RESET);
> > > > > >  ÂÂÂÂÂÂÂÂÂÂÂÂÂ usb_clear_port_feature(hub->hdev, port1,
> > > > > >  ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ USB_PORT_FEAT_C_PORT_LINK_STATE);
> > > > > > -ÂÂÂÂÂÂÂÂÂÂÂ usb_clear_port_feature(hub->hdev, port1,
> > > > > > +
> > > > > > +ÂÂÂÂÂÂÂÂÂÂÂ if (!warm)
> > > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ usb_clear_port_feature(hub->hdev, port1,
> > > > > >  ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ USB_PORT_FEAT_C_CONNECTION);
> > > > > >  Â ÂÂÂÂÂÂÂÂÂÂÂÂÂ /*
> > > > >
> > > > > The key fact is that connection events can get lost if they happen to
> > > > > occur during a port reset.
> > > > Yes.
> > > > > I'm not entirely certain of the logic here, but it looks like the
> > > > > correct test to add should be "if (udev != NULL)", not "if (!warm)".
> > > > > Perhaps Mathias can confirm this
> >
> > Sorry about the late response, got distracted while performing git
> > archeology.
> >
> > "if (udev != NULL)" would seem more reasonable.
> >
> > Logs show that clearing the FEAT_C_CONNECTION was originally added
> > after a hot reset failed, and before issuing a warm reset to a SS.Inactive
> > link. (see 10d674a USB: When hot reset for USB3 fails, try warm reset.)
> >
> > Apparently all the change flags needed to be cleared for some specific
> > host + device combination before issuing a warm reset for the enumeration
> > to work properly.
> >
> > The change to always clear FEAT_C_CONNECTION for USB3 was done later in patch:
> > a24a607 USB: Rip out recursive call on warm port reset.
> >
> > Motivation was:
> >
> > "In hub_port_finish_reset, unconditionally clear the connect status
> >  Âchange (CSC) bit for USB 3.0 hubs when the port reset is done. If we
> >  Âhad to issue multiple warm resets for a device, that bit may have been
> >  Âset if the device went into SS.Inactive and then was successfully warm
> >  Âreset."
> >
> > > > I don't know if clearing the USB_PORT_FEAT_C_CONNECTION bit is
> > > > correct in case of a non warm reset. In my case I always observed a
> > > > warm reset because of the link state change.
> > > > Thats why I checked the warm variable to not change the behavoir for
> > > > cases a didn't checked for the first shot.
> > >
> > > (The syntax of that last sentence is pretty mangled; I can't understand
> > > it.)
> > >
> > > Think of it this way:
> > >
> > >  ÂÂÂÂIf a device was not attached before the reset, we don't want
> > >  ÂÂÂÂto clear the connect-change status because then we wouldn't
> > >  ÂÂÂÂrecognize a device that was plugged in during the reset.
> > >
> > >  ÂÂÂÂIf a device was attached before the reset, we don't want any
> > >  ÂÂÂÂconnect-change status which might be provoked by the reset to
> > >  ÂÂÂÂlast, because we don't want the core to think that the device
> > >  ÂÂÂÂwas unplugged and replugged when all that happened was a reset.
> > >
> > > So the important criterion is whether or not a device was attached to
> > > the port when the reset started. It's something of a coincidence that
> > > you only observe warm resets when there's nothing attached.
> > >
> > > > During the first run of usb_hub_reset the udev is NULL because in
> > > > this situation the device is not attached logically.
> > > >
> > > > [Â 112.889810] usb 4-1-port1: XXX: port_event: portstatus: 0x2c0, portchange: 0x40!
> > > > [Â 113.201192] usb 4-1-port1: XXX: hub_port_reset: udev:ÂÂÂÂÂÂÂÂÂÂÂ (nil)!
> > > > [Â 113.201198] usb 4-1-port1: XXX: hub_port_reset (not clearing USB_PORT_FEAT_C_CONNECTION): 0x203, portchange: 0x1!
> > > > [Â 113.253612] usb 4-1-port1: XXX: port_event: portstatus: 0x203, portchange: 0x1!
> > > > [Â 113.377208] usb 4-1-port1: XXX: hub_port_reset: udev: ffff88046b302800!
> > > > [Â 113.377214] usb 4-1-port1: XXX: hub_port_reset (not clearing USB_PORT_FEAT_C_CONNECTION): 0x203, portchange: 0x0!
> > > > [Â 113.429478] usb 4-1.1: new SuperSpeed USB device number 7 using xhci_hcd
> > > > [Â 113.442370] usb 4-1.1: New USB device found, idVendor=0781, idProduct=5596
> > > > [Â 113.442376] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > > > [Â 113.442381] usb 4-1.1: Product: Ultra T C
> > > > [Â 113.442385] usb 4-1.1: Manufacturer: SanDisk
> > > > [Â 113.442388] usb 4-1.1: SerialNumber: 4C530001131013121031
> > > >
> > > > Or maybe we can skip clearing the USB_PORT_FEAT_C_CONNECTION bit in
> > > > case of hub_port_reset completely without any other check?
> > >
> > > See above.
> >
> > Checking for udev sounds reasonable to me.
> > Not sure if we should worry about the specific host+device combo that needed flags
> > cleared before warm reset. See patch:
> >
> > 10d674a USB: When hot reset for USB3 fails, try warm reset.
> > https://marc.info/?l=linux-usb&m=131603549603799&w=2
> >
> > -Mathias
> Checking for udev works well too in my case. So there is no need to check the warm flag.
>
> Regarding the other point about the specific host+device combo which needs the flags cleared, I don't know how to proceed.

I support just adding a udev check patch, want to send one?

Current hub port reset code is wrong, causing real life issues today.

The issue with the specific host+device is from 2011,
The port reset code has changed completely since then.
If it turns out to still be a issue we can make a host/device specific quirk.

-Mathias