On Tue, Sep 15, 2020 at 01:01:11PM +0200, Greg KH wrote: > On Tue, Sep 15, 2020 at 11:45:31AM +0200, Eugeniu Rosca wrote: > > Dear Alan, > > Dear Greg, > > > > On Fri, Sep 11, 2020 at 11:12:28AM -0400, Alan Stern wrote: > > > > > The thing is, I'm afraid that without these retry loops, some devices > > > will stop working. If that happens, we will not be able to keep this > > > patch in place; we will just have to accept that we fail the PET test. > > > > > > Alan Stern > > > > Does this mean that Linux community leaves no choice but to ship a > > forked kernel (with no chance of alignment to upstream) for > > organizations which design embedded devices where USB plays a key > > role, hence requires passing the USB-IF Compliance Program [*]? > > We are saying that if you ship such a kernel, we _KNOW_ that it will > fail to work in a number of known systems. I doubt you want that to > happen if you care about shipping a device, right? > > > Is there hope to give users a knob (build-time or run-time) which would > > enable the behavior expected and thoroughly described in compliance > > docs, particularly chapter "6.7.22 A-UUT Device No Response for > > connection timeout" of "USB On-The-Go and Embedded Host Automated > > Compliance Plan" [**]? > > Given that the USB-IF has explicitly kicked-out the Linux community from > its specification work and orginization, I personally don't really care > what they say here. If you are a member of the USB-IF, please work with > them to fix the test to reflect real-world systems and not an idealized > system. Last I heard, they wanted nothing to do with Linux systems at > all :( <irony>If the USB-IF were the final authority regarding USB devices, we wouldn't have this problem in the first place.</irony> Every device would respond properly to the very first port initialization attempt and no retries would be needed. But real hardware doesn't always follow the official spec. And then when it fails to work with Linux, _we_ are the people who get blamed. Alan Stern
