From: Mathias Nyman <firstname.lastname@example.org> To: Dennis Wassenberg <email@example.com>, Alan Stern <firstname.lastname@example.org> Cc: Mathias Nyman <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, Ravi Chandra Sadineni <email@example.com>, Kuppuswamy Sathyanarayanan <firstname.lastname@example.org>, Bin Liu <email@example.com>, Maxim Moseychuk <firstname.lastname@example.org>, Mike Looijmans <email@example.com>, Dominik Bozek <firstname.lastname@example.org>, USB list <email@example.com>, Kernel development list <firstname.lastname@example.org> Subject: Re: USB-C device hotplug issue Date: Fri, 9 Nov 2018 15:47:17 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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
next prev parent reply other threads:[~2018-11-09 13:43 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-25 12:20 Dennis Wassenberg 2018-10-25 12:28 ` Greg Kroah-Hartman 2018-10-25 12:38 ` Dennis Wassenberg 2018-10-25 14:46 ` Alan Stern 2018-10-26 9:44 ` Dennis Wassenberg 2018-10-26 14:07 ` Alan Stern 2018-11-05 15:35 ` Mathias Nyman 2018-11-07 9:08 ` Dennis Wassenberg 2018-11-09 13:47 ` Mathias Nyman [this message] 2018-11-13 13:38 ` Dennis Wassenberg 2018-11-13 13:40 ` [PATCH] usb: core: Fix hub port connection events lost Dennis Wassenberg 2018-11-13 13:55 ` Mathias Nyman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: USB-C device hotplug issue' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).