From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: USB-C device hotplug issue From: Mathias Nyman Message-Id: Date: Mon, 5 Nov 2018 17:35:25 +0200 To: Alan Stern , Dennis Wassenberg Cc: Mathias Nyman , Greg Kroah-Hartman , Ravi Chandra Sadineni , Kuppuswamy Sathyanarayanan , Bin Liu , Maxim Moseychuk , Mike Looijmans , Dominik Bozek , USB list , Kernel development list List-ID: T24gMjYuMTAuMjAxOCAxNzowNywgQWxhbiBTdGVybiB3cm90ZToKPiBPbiBGcmksIDI2IE9jdCAy MDE4LCBEZW5uaXMgV2Fzc2VuYmVyZyB3cm90ZToKPiAKPj4+PiAtLS0gYS9kcml2ZXJzL3VzYi9j b3JlL2h1Yi5jCj4+Pj4gKysrIGIvZHJpdmVycy91c2IvY29yZS9odWIuYwo+Pj4+IEBAIC0yODE1 LDcgKzI4MTUsOSBAQCBzdGF0aWMgaW50IGh1Yl9wb3J0X3Jlc2V0KHN0cnVjdCB1c2JfaHViICpo dWIsIGludCBwb3J0MSwKPj4+PiAgIAkJCQkJVVNCX1BPUlRfRkVBVF9DX0JIX1BPUlRfUkVTRVQp Owo+Pj4+ICAgCQkJdXNiX2NsZWFyX3BvcnRfZmVhdHVyZShodWItPmhkZXYsIHBvcnQxLAo+Pj4+ ICAgCQkJCQlVU0JfUE9SVF9GRUFUX0NfUE9SVF9MSU5LX1NUQVRFKTsKPj4+PiAtCQkJdXNiX2Ns ZWFyX3BvcnRfZmVhdHVyZShodWItPmhkZXYsIHBvcnQxLAo+Pj4+ICsKPj4+PiArCQkJaWYgKCF3 YXJtKQo+Pj4+ICsJCQkJdXNiX2NsZWFyX3BvcnRfZmVhdHVyZShodWItPmhkZXYsIHBvcnQxLAo+ Pj4+ICAgCQkJCQlVU0JfUE9SVF9GRUFUX0NfQ09OTkVDVElPTik7Cj4+Pj4gICAKPj4+PiAgIAkJ CS8qCj4+Pgo+Pj4gVGhlIGtleSBmYWN0IGlzIHRoYXQgY29ubmVjdGlvbiBldmVudHMgY2FuIGdl dCBsb3N0IGlmIHRoZXkgaGFwcGVuIHRvCj4+PiBvY2N1ciBkdXJpbmcgYSBwb3J0IHJlc2V0Lgo+ PiBZZXMuCj4+Pgo+Pj4gSSdtIG5vdCBlbnRpcmVseSBjZXJ0YWluIG9mIHRoZSBsb2dpYyBoZXJl LCBidXQgaXQgbG9va3MgbGlrZSB0aGUKPj4+IGNvcnJlY3QgdGVzdCB0byBhZGQgc2hvdWxkIGJl ICJpZiAodWRldiAhPSBOVUxMKSIsIG5vdCAiaWYgKCF3YXJtKSIuCj4+PiBQZXJoYXBzIE1hdGhp YXMgY2FuIGNvbmZpcm0gdGhpcwoKU29ycnkgYWJvdXQgdGhlIGxhdGUgcmVzcG9uc2UsIGdvdCBk aXN0cmFjdGVkIHdoaWxlIHBlcmZvcm1pbmcgZ2l0CmFyY2hlb2xvZ3kuCgoiaWYgKHVkZXYgIT0g TlVMTCkiIHdvdWxkIHNlZW0gbW9yZSByZWFzb25hYmxlLgoKTG9ncyBzaG93IHRoYXQgY2xlYXJp bmcgdGhlIEZFQVRfQ19DT05ORUNUSU9OIHdhcyBvcmlnaW5hbGx5IGFkZGVkCmFmdGVyIGEgaG90 IHJlc2V0IGZhaWxlZCwgYW5kIGJlZm9yZSBpc3N1aW5nIGEgd2FybSByZXNldCB0byBhIFNTLklu YWN0aXZlCmxpbmsuICAoc2VlIDEwZDY3NGEgVVNCOiBXaGVuIGhvdCByZXNldCBmb3IgVVNCMyBm YWlscywgdHJ5IHdhcm0gcmVzZXQuKQoKQXBwYXJlbnRseSBhbGwgdGhlIGNoYW5nZSBmbGFncyBu ZWVkZWQgdG8gYmUgY2xlYXJlZCBmb3Igc29tZSBzcGVjaWZpYwpob3N0ICsgZGV2aWNlIGNvbWJp bmF0aW9uIGJlZm9yZSBpc3N1aW5nIGEgd2FybSByZXNldCBmb3IgdGhlIGVudW1lcmF0aW9uCnRv IHdvcmsgcHJvcGVybHkuCgpUaGUgY2hhbmdlIHRvIGFsd2F5cyBjbGVhciBGRUFUX0NfQ09OTkVD VElPTiBmb3IgVVNCMyB3YXMgZG9uZSBsYXRlciBpbiBwYXRjaDoKYTI0YTYwNyBVU0I6IFJpcCBv dXQgcmVjdXJzaXZlIGNhbGwgb24gd2FybSBwb3J0IHJlc2V0LgoKTW90aXZhdGlvbiB3YXM6Cgoi SW4gaHViX3BvcnRfZmluaXNoX3Jlc2V0LCB1bmNvbmRpdGlvbmFsbHkgY2xlYXIgdGhlIGNvbm5l Y3Qgc3RhdHVzCiAgY2hhbmdlIChDU0MpIGJpdCBmb3IgVVNCIDMuMCBodWJzIHdoZW4gdGhlIHBv cnQgcmVzZXQgaXMgZG9uZS4gIElmIHdlCiAgaGFkIHRvIGlzc3VlIG11bHRpcGxlIHdhcm0gcmVz ZXRzIGZvciBhIGRldmljZSwgdGhhdCBiaXQgbWF5IGhhdmUgYmVlbgogIHNldCBpZiB0aGUgZGV2 aWNlIHdlbnQgaW50byBTUy5JbmFjdGl2ZSBhbmQgdGhlbiB3YXMgc3VjY2Vzc2Z1bGx5IHdhcm0K ICByZXNldC4iCgo+PiBJIGRvbid0IGtub3cgaWYgY2xlYXJpbmcgdGhlIFVTQl9QT1JUX0ZFQVRf Q19DT05ORUNUSU9OIGJpdCBpcwo+PiBjb3JyZWN0IGluIGNhc2Ugb2YgYSBub24gd2FybSByZXNl dC4gSW4gbXkgY2FzZSBJIGFsd2F5cyBvYnNlcnZlZCBhCj4+IHdhcm0gcmVzZXQgYmVjYXVzZSBv ZiB0aGUgbGluayBzdGF0ZSBjaGFuZ2UuCj4+IFRoYXRzIHdoeSBJIGNoZWNrZWQgdGhlIHdhcm0g dmFyaWFibGUgdG8gbm90IGNoYW5nZSB0aGUgYmVoYXZvaXIgZm9yCj4+IGNhc2VzIGEgZGlkbid0 IGNoZWNrZWQgZm9yIHRoZSBmaXJzdCBzaG90Lgo+IAo+IChUaGUgc3ludGF4IG9mIHRoYXQgbGFz dCBzZW50ZW5jZSBpcyBwcmV0dHkgbWFuZ2xlZDsgSSBjYW4ndCB1bmRlcnN0YW5kCj4gaXQuKQo+ IAo+IFRoaW5rIG9mIGl0IHRoaXMgd2F5Ogo+IAo+IAlJZiBhIGRldmljZSB3YXMgbm90IGF0dGFj aGVkIGJlZm9yZSB0aGUgcmVzZXQsIHdlIGRvbid0IHdhbnQKPiAJdG8gY2xlYXIgdGhlIGNvbm5l Y3QtY2hhbmdlIHN0YXR1cyBiZWNhdXNlIHRoZW4gd2Ugd291bGRuJ3QKPiAJcmVjb2duaXplIGEg ZGV2aWNlIHRoYXQgd2FzIHBsdWdnZWQgaW4gZHVyaW5nIHRoZSByZXNldC4KPiAKPiAJSWYgYSBk ZXZpY2Ugd2FzIGF0dGFjaGVkIGJlZm9yZSB0aGUgcmVzZXQsIHdlIGRvbid0IHdhbnQgYW55Cj4g CWNvbm5lY3QtY2hhbmdlIHN0YXR1cyB3aGljaCBtaWdodCBiZSBwcm92b2tlZCBieSB0aGUgcmVz ZXQgdG8KPiAJbGFzdCwgYmVjYXVzZSB3ZSBkb24ndCB3YW50IHRoZSBjb3JlIHRvIHRoaW5rIHRo YXQgdGhlIGRldmljZQo+IAl3YXMgdW5wbHVnZ2VkIGFuZCByZXBsdWdnZWQgd2hlbiBhbGwgdGhh dCBoYXBwZW5lZCB3YXMgYSByZXNldC4KPiAKPiBTbyB0aGUgaW1wb3J0YW50IGNyaXRlcmlvbiBp cyB3aGV0aGVyIG9yIG5vdCBhIGRldmljZSB3YXMgYXR0YWNoZWQgdG8KPiB0aGUgcG9ydCB3aGVu IHRoZSByZXNldCBzdGFydGVkLiAgSXQncyBzb21ldGhpbmcgb2YgYSBjb2luY2lkZW5jZSB0aGF0 Cj4geW91IG9ubHkgb2JzZXJ2ZSB3YXJtIHJlc2V0cyB3aGVuIHRoZXJlJ3Mgbm90aGluZyBhdHRh Y2hlZC4KPiAKPj4gRHVyaW5nIHRoZSBmaXJzdCBydW4gb2YgdXNiX2h1Yl9yZXNldCB0aGUgdWRl diBpcyBOVUxMIGJlY2F1c2UgaW4KPj4gdGhpcyBzaXR1YXRpb24gdGhlIGRldmljZSBpcyBub3Qg YXR0YWNoZWQgbG9naWNhbGx5Lgo+Pgo+PiBbICAxMTIuODg5ODEwXSB1c2IgNC0xLXBvcnQxOiBY WFg6IHBvcnRfZXZlbnQ6IHBvcnRzdGF0dXM6IDB4MmMwLCBwb3J0Y2hhbmdlOiAweDQwIQo+PiBb ICAxMTMuMjAxMTkyXSB1c2IgNC0xLXBvcnQxOiBYWFg6IGh1Yl9wb3J0X3Jlc2V0OiB1ZGV2OiAg ICAgICAgICAgIChuaWwpIQo+PiBbICAxMTMuMjAxMTk4XSB1c2IgNC0xLXBvcnQxOiBYWFg6IGh1 Yl9wb3J0X3Jlc2V0IChub3QgY2xlYXJpbmcgVVNCX1BPUlRfRkVBVF9DX0NPTk5FQ1RJT04pOiAw eDIwMywgcG9ydGNoYW5nZTogMHgxIQo+PiBbICAxMTMuMjUzNjEyXSB1c2IgNC0xLXBvcnQxOiBY WFg6IHBvcnRfZXZlbnQ6IHBvcnRzdGF0dXM6IDB4MjAzLCBwb3J0Y2hhbmdlOiAweDEhCj4+IFsg IDExMy4zNzcyMDhdIHVzYiA0LTEtcG9ydDE6IFhYWDogaHViX3BvcnRfcmVzZXQ6IHVkZXY6IGZm ZmY4ODA0NmIzMDI4MDAhCj4+IFsgIDExMy4zNzcyMTRdIHVzYiA0LTEtcG9ydDE6IFhYWDogaHVi X3BvcnRfcmVzZXQgKG5vdCBjbGVhcmluZyBVU0JfUE9SVF9GRUFUX0NfQ09OTkVDVElPTik6IDB4 MjAzLCBwb3J0Y2hhbmdlOiAweDAhCj4+IFsgIDExMy40Mjk0NzhdIHVzYiA0LTEuMTogbmV3IFN1 cGVyU3BlZWQgVVNCIGRldmljZSBudW1iZXIgNyB1c2luZyB4aGNpX2hjZAo+PiBbICAxMTMuNDQy MzcwXSB1c2IgNC0xLjE6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wNzgxLCBpZFBy b2R1Y3Q9NTU5Ngo+PiBbICAxMTMuNDQyMzc2XSB1c2IgNC0xLjE6IE5ldyBVU0IgZGV2aWNlIHN0 cmluZ3M6IE1mcj0xLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0zCj4+IFsgIDExMy40NDIzODFd IHVzYiA0LTEuMTogUHJvZHVjdDogVWx0cmEgVCBDCj4+IFsgIDExMy40NDIzODVdIHVzYiA0LTEu MTogTWFudWZhY3R1cmVyOiBTYW5EaXNrCj4+IFsgIDExMy40NDIzODhdIHVzYiA0LTEuMTogU2Vy aWFsTnVtYmVyOiA0QzUzMDAwMTEzMTAxMzEyMTAzMQo+Pgo+PiBPciBtYXliZSB3ZSBjYW4gc2tp cCBjbGVhcmluZyB0aGUgVVNCX1BPUlRfRkVBVF9DX0NPTk5FQ1RJT04gYml0IGluCj4+IGNhc2Ug b2YgaHViX3BvcnRfcmVzZXQgY29tcGxldGVseSB3aXRob3V0IGFueSBvdGhlciBjaGVjaz8KPiAK PiBTZWUgYWJvdmUuCgpDaGVja2luZyBmb3IgdWRldiBzb3VuZHMgcmVhc29uYWJsZSB0byBtZS4K Tm90IHN1cmUgaWYgd2Ugc2hvdWxkIHdvcnJ5IGFib3V0IHRoZSBzcGVjaWZpYyBob3N0K2Rldmlj ZSBjb21ibyB0aGF0IG5lZWRlZCBmbGFncwpjbGVhcmVkIGJlZm9yZSB3YXJtIHJlc2V0LiBTZWUg cGF0Y2g6CgoxMGQ2NzRhIFVTQjogV2hlbiBob3QgcmVzZXQgZm9yIFVTQjMgZmFpbHMsIHRyeSB3 YXJtIHJlc2V0LgpodHRwczovL21hcmMuaW5mby8/bD1saW51eC11c2ImbT0xMzE2MDM1NDk2MDM3 OTkmdz0yCgotTWF0aGlhcwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54415C46475 for ; Mon, 5 Nov 2018 15:31:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1C1782081D for ; Mon, 5 Nov 2018 15:31:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C1782081D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730107AbeKFAwH (ORCPT ); Mon, 5 Nov 2018 19:52:07 -0500 Received: from mga06.intel.com ([134.134.136.31]:6649 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729960AbeKFAwH (ORCPT ); Mon, 5 Nov 2018 19:52:07 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 07:31:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,468,1534834800"; d="scan'208";a="84112992" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.164]) ([10.237.72.164]) by fmsmga008.fm.intel.com with ESMTP; 05 Nov 2018 07:31:48 -0800 Subject: Re: USB-C device hotplug issue To: Alan Stern , Dennis Wassenberg Cc: Mathias Nyman , Greg Kroah-Hartman , Ravi Chandra Sadineni , Kuppuswamy Sathyanarayanan , Bin Liu , Maxim Moseychuk , Mike Looijmans , Dominik Bozek , USB list , Kernel development list References: From: Mathias Nyman Message-ID: Date: Mon, 5 Nov 2018 17:35:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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