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: <0427ea9d-a04c-61bf-9f64-5f2a42ab0072@linux.intel.com> Date: Fri, 9 Nov 2018 15:47:17 +0200 To: Dennis Wassenberg , Alan Stern 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: T24gMDcuMTEuMjAxOCAxMTowOCwgRGVubmlzIFdhc3NlbmJlcmcgd3JvdGU6Cj4gCj4gT24gMDUu MTEuMTggMTY6MzUsIE1hdGhpYXMgTnltYW4gd3JvdGU6Cj4+IE9uIDI2LjEwLjIwMTggMTc6MDcs IEFsYW4gU3Rlcm4gd3JvdGU6Cj4+PiBPbiBGcmksIDI2IE9jdCAyMDE4LCBEZW5uaXMgV2Fzc2Vu YmVyZyB3cm90ZToKPj4+Cj4+Pj4+PiAtLS0gYS9kcml2ZXJzL3VzYi9jb3JlL2h1Yi5jCj4+Pj4+ PiArKysgYi9kcml2ZXJzL3VzYi9jb3JlL2h1Yi5jCj4+Pj4+PiBAQCAtMjgxNSw3ICsyODE1LDkg QEAgc3RhdGljIGludCBodWJfcG9ydF9yZXNldChzdHJ1Y3QgdXNiX2h1YiAqaHViLCBpbnQgcG9y dDEsCj4+Pj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFVT Ql9QT1JUX0ZFQVRfQ19CSF9QT1JUX1JFU0VUKTsKPj4+Pj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB1c2JfY2xlYXJfcG9ydF9mZWF0dXJlKGh1Yi0+aGRldiwgcG9ydDEsCj4+Pj4+PiAg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFVTQl9QT1JUX0ZFQVRf Q19QT1JUX0xJTktfU1RBVEUpOwo+Pj4+Pj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdXNiX2Ns ZWFyX3BvcnRfZmVhdHVyZShodWItPmhkZXYsIHBvcnQxLAo+Pj4+Pj4gKwo+Pj4+Pj4gK8KgwqDC oMKgwqDCoMKgwqDCoMKgwqAgaWYgKCF3YXJtKQo+Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCB1c2JfY2xlYXJfcG9ydF9mZWF0dXJlKGh1Yi0+aGRldiwgcG9ydDEsCj4+Pj4+ PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFVTQl9QT1JUX0ZF QVRfQ19DT05ORUNUSU9OKTsKPj4+Pj4+ICDCoCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAv Kgo+Pj4+Pgo+Pj4+PiBUaGUga2V5IGZhY3QgaXMgdGhhdCBjb25uZWN0aW9uIGV2ZW50cyBjYW4g Z2V0IGxvc3QgaWYgdGhleSBoYXBwZW4gdG8KPj4+Pj4gb2NjdXIgZHVyaW5nIGEgcG9ydCByZXNl dC4KPj4+PiBZZXMuCj4+Pj4+Cj4+Pj4+IEknbSBub3QgZW50aXJlbHkgY2VydGFpbiBvZiB0aGUg bG9naWMgaGVyZSwgYnV0IGl0IGxvb2tzIGxpa2UgdGhlCj4+Pj4+IGNvcnJlY3QgdGVzdCB0byBh ZGQgc2hvdWxkIGJlICJpZiAodWRldiAhPSBOVUxMKSIsIG5vdCAiaWYgKCF3YXJtKSIuCj4+Pj4+ IFBlcmhhcHMgTWF0aGlhcyBjYW4gY29uZmlybSB0aGlzCj4+Cj4+IFNvcnJ5IGFib3V0IHRoZSBs YXRlIHJlc3BvbnNlLCBnb3QgZGlzdHJhY3RlZCB3aGlsZSBwZXJmb3JtaW5nIGdpdAo+PiBhcmNo ZW9sb2d5Lgo+Pgo+PiAiaWYgKHVkZXYgIT0gTlVMTCkiIHdvdWxkIHNlZW0gbW9yZSByZWFzb25h YmxlLgo+Pgo+PiBMb2dzIHNob3cgdGhhdCBjbGVhcmluZyB0aGUgRkVBVF9DX0NPTk5FQ1RJT04g d2FzIG9yaWdpbmFsbHkgYWRkZWQKPj4gYWZ0ZXIgYSBob3QgcmVzZXQgZmFpbGVkLCBhbmQgYmVm b3JlIGlzc3VpbmcgYSB3YXJtIHJlc2V0IHRvIGEgU1MuSW5hY3RpdmUKPj4gbGluay7CoCAoc2Vl IDEwZDY3NGEgVVNCOiBXaGVuIGhvdCByZXNldCBmb3IgVVNCMyBmYWlscywgdHJ5IHdhcm0gcmVz ZXQuKQo+Pgo+PiBBcHBhcmVudGx5IGFsbCB0aGUgY2hhbmdlIGZsYWdzIG5lZWRlZCB0byBiZSBj bGVhcmVkIGZvciBzb21lIHNwZWNpZmljCj4+IGhvc3QgKyBkZXZpY2UgY29tYmluYXRpb24gYmVm b3JlIGlzc3VpbmcgYSB3YXJtIHJlc2V0IGZvciB0aGUgZW51bWVyYXRpb24KPj4gdG8gd29yayBw cm9wZXJseS4KPj4KPj4gVGhlIGNoYW5nZSB0byBhbHdheXMgY2xlYXIgRkVBVF9DX0NPTk5FQ1RJ T04gZm9yIFVTQjMgd2FzIGRvbmUgbGF0ZXIgaW4gcGF0Y2g6Cj4+IGEyNGE2MDcgVVNCOiBSaXAg b3V0IHJlY3Vyc2l2ZSBjYWxsIG9uIHdhcm0gcG9ydCByZXNldC4KPj4KPj4gTW90aXZhdGlvbiB3 YXM6Cj4+Cj4+ICJJbiBodWJfcG9ydF9maW5pc2hfcmVzZXQsIHVuY29uZGl0aW9uYWxseSBjbGVh ciB0aGUgY29ubmVjdCBzdGF0dXMKPj4gIMKgY2hhbmdlIChDU0MpIGJpdCBmb3IgVVNCIDMuMCBo dWJzIHdoZW4gdGhlIHBvcnQgcmVzZXQgaXMgZG9uZS7CoCBJZiB3ZQo+PiAgwqBoYWQgdG8gaXNz dWUgbXVsdGlwbGUgd2FybSByZXNldHMgZm9yIGEgZGV2aWNlLCB0aGF0IGJpdCBtYXkgaGF2ZSBi ZWVuCj4+ICDCoHNldCBpZiB0aGUgZGV2aWNlIHdlbnQgaW50byBTUy5JbmFjdGl2ZSBhbmQgdGhl biB3YXMgc3VjY2Vzc2Z1bGx5IHdhcm0KPj4gIMKgcmVzZXQuIgo+Pgo+Pj4+IEkgZG9uJ3Qga25v dyBpZiBjbGVhcmluZyB0aGUgVVNCX1BPUlRfRkVBVF9DX0NPTk5FQ1RJT04gYml0IGlzCj4+Pj4g Y29ycmVjdCBpbiBjYXNlIG9mIGEgbm9uIHdhcm0gcmVzZXQuIEluIG15IGNhc2UgSSBhbHdheXMg b2JzZXJ2ZWQgYQo+Pj4+IHdhcm0gcmVzZXQgYmVjYXVzZSBvZiB0aGUgbGluayBzdGF0ZSBjaGFu Z2UuCj4+Pj4gVGhhdHMgd2h5IEkgY2hlY2tlZCB0aGUgd2FybSB2YXJpYWJsZSB0byBub3QgY2hh bmdlIHRoZSBiZWhhdm9pciBmb3IKPj4+PiBjYXNlcyBhIGRpZG4ndCBjaGVja2VkIGZvciB0aGUg Zmlyc3Qgc2hvdC4KPj4+Cj4+PiAoVGhlIHN5bnRheCBvZiB0aGF0IGxhc3Qgc2VudGVuY2UgaXMg cHJldHR5IG1hbmdsZWQ7IEkgY2FuJ3QgdW5kZXJzdGFuZAo+Pj4gaXQuKQo+Pj4KPj4+IFRoaW5r IG9mIGl0IHRoaXMgd2F5Ogo+Pj4KPj4+ICDCoMKgwqDCoElmIGEgZGV2aWNlIHdhcyBub3QgYXR0 YWNoZWQgYmVmb3JlIHRoZSByZXNldCwgd2UgZG9uJ3Qgd2FudAo+Pj4gIMKgwqDCoMKgdG8gY2xl YXIgdGhlIGNvbm5lY3QtY2hhbmdlIHN0YXR1cyBiZWNhdXNlIHRoZW4gd2Ugd291bGRuJ3QKPj4+ ICDCoMKgwqDCoHJlY29nbml6ZSBhIGRldmljZSB0aGF0IHdhcyBwbHVnZ2VkIGluIGR1cmluZyB0 aGUgcmVzZXQuCj4+Pgo+Pj4gIMKgwqDCoMKgSWYgYSBkZXZpY2Ugd2FzIGF0dGFjaGVkIGJlZm9y ZSB0aGUgcmVzZXQsIHdlIGRvbid0IHdhbnQgYW55Cj4+PiAgwqDCoMKgwqBjb25uZWN0LWNoYW5n ZSBzdGF0dXMgd2hpY2ggbWlnaHQgYmUgcHJvdm9rZWQgYnkgdGhlIHJlc2V0IHRvCj4+PiAgwqDC oMKgwqBsYXN0LCBiZWNhdXNlIHdlIGRvbid0IHdhbnQgdGhlIGNvcmUgdG8gdGhpbmsgdGhhdCB0 aGUgZGV2aWNlCj4+PiAgwqDCoMKgwqB3YXMgdW5wbHVnZ2VkIGFuZCByZXBsdWdnZWQgd2hlbiBh bGwgdGhhdCBoYXBwZW5lZCB3YXMgYSByZXNldC4KPj4+Cj4+PiBTbyB0aGUgaW1wb3J0YW50IGNy aXRlcmlvbiBpcyB3aGV0aGVyIG9yIG5vdCBhIGRldmljZSB3YXMgYXR0YWNoZWQgdG8KPj4+IHRo ZSBwb3J0IHdoZW4gdGhlIHJlc2V0IHN0YXJ0ZWQuwqAgSXQncyBzb21ldGhpbmcgb2YgYSBjb2lu Y2lkZW5jZSB0aGF0Cj4+PiB5b3Ugb25seSBvYnNlcnZlIHdhcm0gcmVzZXRzIHdoZW4gdGhlcmUn cyBub3RoaW5nIGF0dGFjaGVkLgo+Pj4KPj4+PiBEdXJpbmcgdGhlIGZpcnN0IHJ1biBvZiB1c2Jf aHViX3Jlc2V0IHRoZSB1ZGV2IGlzIE5VTEwgYmVjYXVzZSBpbgo+Pj4+IHRoaXMgc2l0dWF0aW9u IHRoZSBkZXZpY2UgaXMgbm90IGF0dGFjaGVkIGxvZ2ljYWxseS4KPj4+Pgo+Pj4+IFvCoCAxMTIu ODg5ODEwXSB1c2IgNC0xLXBvcnQxOiBYWFg6IHBvcnRfZXZlbnQ6IHBvcnRzdGF0dXM6IDB4MmMw LCBwb3J0Y2hhbmdlOiAweDQwIQo+Pj4+IFvCoCAxMTMuMjAxMTkyXSB1c2IgNC0xLXBvcnQxOiBY WFg6IGh1Yl9wb3J0X3Jlc2V0OiB1ZGV2OsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKG5pbCkhCj4+ Pj4gW8KgIDExMy4yMDExOThdIHVzYiA0LTEtcG9ydDE6IFhYWDogaHViX3BvcnRfcmVzZXQgKG5v dCBjbGVhcmluZyBVU0JfUE9SVF9GRUFUX0NfQ09OTkVDVElPTik6IDB4MjAzLCBwb3J0Y2hhbmdl OiAweDEhCj4+Pj4gW8KgIDExMy4yNTM2MTJdIHVzYiA0LTEtcG9ydDE6IFhYWDogcG9ydF9ldmVu dDogcG9ydHN0YXR1czogMHgyMDMsIHBvcnRjaGFuZ2U6IDB4MSEKPj4+PiBbwqAgMTEzLjM3NzIw OF0gdXNiIDQtMS1wb3J0MTogWFhYOiBodWJfcG9ydF9yZXNldDogdWRldjogZmZmZjg4MDQ2YjMw MjgwMCEKPj4+PiBbwqAgMTEzLjM3NzIxNF0gdXNiIDQtMS1wb3J0MTogWFhYOiBodWJfcG9ydF9y ZXNldCAobm90IGNsZWFyaW5nIFVTQl9QT1JUX0ZFQVRfQ19DT05ORUNUSU9OKTogMHgyMDMsIHBv cnRjaGFuZ2U6IDB4MCEKPj4+PiBbwqAgMTEzLjQyOTQ3OF0gdXNiIDQtMS4xOiBuZXcgU3VwZXJT cGVlZCBVU0IgZGV2aWNlIG51bWJlciA3IHVzaW5nIHhoY2lfaGNkCj4+Pj4gW8KgIDExMy40NDIz NzBdIHVzYiA0LTEuMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTA3ODEsIGlkUHJv ZHVjdD01NTk2Cj4+Pj4gW8KgIDExMy40NDIzNzZdIHVzYiA0LTEuMTogTmV3IFVTQiBkZXZpY2Ug c3RyaW5nczogTWZyPTEsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTMKPj4+PiBbwqAgMTEzLjQ0 MjM4MV0gdXNiIDQtMS4xOiBQcm9kdWN0OiBVbHRyYSBUIEMKPj4+PiBbwqAgMTEzLjQ0MjM4NV0g dXNiIDQtMS4xOiBNYW51ZmFjdHVyZXI6IFNhbkRpc2sKPj4+PiBbwqAgMTEzLjQ0MjM4OF0gdXNi IDQtMS4xOiBTZXJpYWxOdW1iZXI6IDRDNTMwMDAxMTMxMDEzMTIxMDMxCj4+Pj4KPj4+PiBPciBt YXliZSB3ZSBjYW4gc2tpcCBjbGVhcmluZyB0aGUgVVNCX1BPUlRfRkVBVF9DX0NPTk5FQ1RJT04g Yml0IGluCj4+Pj4gY2FzZSBvZiBodWJfcG9ydF9yZXNldCBjb21wbGV0ZWx5IHdpdGhvdXQgYW55 IG90aGVyIGNoZWNrPwo+Pj4KPj4+IFNlZSBhYm92ZS4KPj4KPj4gQ2hlY2tpbmcgZm9yIHVkZXYg c291bmRzIHJlYXNvbmFibGUgdG8gbWUuCj4+IE5vdCBzdXJlIGlmIHdlIHNob3VsZCB3b3JyeSBh Ym91dCB0aGUgc3BlY2lmaWMgaG9zdCtkZXZpY2UgY29tYm8gdGhhdCBuZWVkZWQgZmxhZ3MKPj4g Y2xlYXJlZCBiZWZvcmUgd2FybSByZXNldC4gU2VlIHBhdGNoOgo+Pgo+PiAxMGQ2NzRhIFVTQjog V2hlbiBob3QgcmVzZXQgZm9yIFVTQjMgZmFpbHMsIHRyeSB3YXJtIHJlc2V0Lgo+PiBodHRwczov L21hcmMuaW5mby8/bD1saW51eC11c2ImbT0xMzE2MDM1NDk2MDM3OTkmdz0yCj4+Cj4+IC1NYXRo aWFzCj4gQ2hlY2tpbmcgZm9yIHVkZXYgd29ya3Mgd2VsbCB0b28gaW4gbXkgY2FzZS4gU28gdGhl cmUgaXMgbm8gbmVlZCB0byBjaGVjayB0aGUgd2FybSBmbGFnLgo+IAo+IFJlZ2FyZGluZyB0aGUg b3RoZXIgcG9pbnQgYWJvdXQgdGhlIHNwZWNpZmljIGhvc3QrZGV2aWNlIGNvbWJvIHdoaWNoIG5l ZWRzIHRoZSBmbGFncyBjbGVhcmVkLCBJIGRvbid0IGtub3cgaG93IHRvIHByb2NlZWQuCj4gCgpJ IHN1cHBvcnQganVzdCBhZGRpbmcgYSB1ZGV2IGNoZWNrIHBhdGNoLCB3YW50IHRvIHNlbmQgb25l PwoKQ3VycmVudCBodWIgcG9ydCByZXNldCBjb2RlIGlzIHdyb25nLCBjYXVzaW5nIHJlYWwgbGlm ZSBpc3N1ZXMgdG9kYXkuCgpUaGUgaXNzdWUgd2l0aCB0aGUgc3BlY2lmaWMgaG9zdCtkZXZpY2Ug aXMgZnJvbSAyMDExLApUaGUgcG9ydCByZXNldCBjb2RlIGhhcyBjaGFuZ2VkIGNvbXBsZXRlbHkg c2luY2UgdGhlbi4KSWYgaXQgdHVybnMgb3V0IHRvIHN0aWxsIGJlIGEgaXNzdWUgd2UgY2FuIG1h a2UgYSBob3N0L2RldmljZSBzcGVjaWZpYyBxdWlyay4KCi1NYXRoaWFzCg== 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 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 8A475C43441 for ; Fri, 9 Nov 2018 13:43:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3AB3120840 for ; Fri, 9 Nov 2018 13:43:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AB3120840 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 S1728099AbeKIXYX (ORCPT ); Fri, 9 Nov 2018 18:24:23 -0500 Received: from mga05.intel.com ([192.55.52.43]:63678 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727794AbeKIXYX (ORCPT ); Fri, 9 Nov 2018 18:24:23 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 05:43:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,483,1534834800"; d="scan'208";a="107262960" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.164]) ([10.237.72.164]) by orsmga002.jf.intel.com with ESMTP; 09 Nov 2018 05:43:38 -0800 Subject: Re: USB-C device hotplug issue To: Dennis Wassenberg , Alan Stern 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: <4140fee5-8935-daed-8438-d04d7f1198b2@secunet.com> From: Mathias Nyman Message-ID: <0427ea9d-a04c-61bf-9f64-5f2a42ab0072@linux.intel.com> Date: Fri, 9 Nov 2018 15:47:17 +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: <4140fee5-8935-daed-8438-d04d7f1198b2@secunet.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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