| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <56493D02.8020204@linux.intel.com> Date: Mon, 16 Nov 2015 10:18:42 +0800 From: Lu Baolu <baolu.lu@...ux.intel.com> To: Dmitry Malkin <DMalkin@...ecurity.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org> Subject: Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk Hi, On 11/13/2015 11:34 PM, Dmitry Malkin wrote: > On Mon, 9 Nov 2015 15:38:33 +0800, Lu Baolu wrote: >> On Intel platform, if the debug target is connected with debug >> host, enabling DCE bit in command register leads to a hung bus >> state. In the hung state, the host system will not see a port >> connected status bit set. Hence debug target fails to be probed. >> >> The state could be resolved by performing a port reset to the >> debug port from the host xHCI. This patch introduces this work >> around. > Is it correct to call this a "hung bus state"? Wouldn't calling it > "hung port state" more appropriate? Yes, "hung port state" is more appropriate. > > I have observed this DCE-enable-related hung port state, > but the reason seemed to be different in my case: > > Citing a note (sic!) from The Holy XHCI Spec, section 7.6.4.1: >> If a Debug Host attempts to attach to a Debug Target before the DCE flag is set, >> both ends of the link shall transition to the Inactive state. >> So a Debug Host should periodically issue a Warm Reset >> to ports that are Inactive to enable a connection to the DbC of the Debug Target. Exactly. A formal workaround is to periodically issue Warm Resets to ports from debug host. > Indeed, the inactive state is what I have observed (PLS field of port register PORTSC) > when the DCE bit is set to 1 with the cable already plugged in. > > Now, according to my interpretation of The Hole USB 3.1 spec, section 7.5.2, > which says: >> eSS.Inactive is a state where a link has failed Enhanced SuperSpeed operation. >> A downstream port can only exit from this state when directed, or upon detection of >> an absence of a far-end receiver termination (R RX-DC ) specified in Table 6-21, >> or upon a Warm Reset. > It follows, that since hosts without DBC cannot listen to upstream requests, > the debug target-originated port reset requests (both hot and warm) will be ignored > by the debug host. As above, a formal workaround is to issue Warm Reset periodically from debug host, but that could cause much complexity. My quirk is to issue port reset just *before* setting DCE bit. This quirk seems to work on several platforms. (My debug host doesn't have DBC.) > > This is the essence of the "hung port state" that I was able to observe. > > Note, that this roadblock doesn't appear if you attach the cable /after/ enabling the DCE bit, Yes. > or, alternatively, if the host has DBC. Really? I haven't tried it yet. > > And indeed, your quirk will work in the latter case, since the debug host hub > will be able to see the upstream reset request. This quirk works as well if debug host doesn't have DBC. I didn't try a DBC-capable debug host yet. > > -- > with best regards, > Dmitry Malkin Thank you. -Baolu > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists