Dear Alan Dear Greg Thank you very much for your feedback. I understood that there is a gap between real system and ideal specification, and the Linux community stands on the real system side.(of course).
I really appreciate your proposal(Kconfig option). > But let's start with > testing the patch I sent you. After all, the first step is to get > something that does what you want correctly. The patch you provided worked fine. https://marc.info/?l=linux-usb&m=159984230312068&w=4 An excerpt from dmesg is as follows. It detected the enumeration failure after 27.7seconds since the test started. so,the PET test passed. [2]-[1] =27.7seconds [ 111.482541] *** Setting Test Suite *** [ 130.226648] *** Ready OK Test Start*** [ 134.808206] usb 1-1.1: new full-speed USB device number 7 using ehci-platform ... [1] [ 140.034944] usb 1-1.1: device descriptor read/64, error -110 [ 140.118069] usb 1-1.1: new full-speed USB device number 8 using ehci-platform [ 145.155142] usb 1-1.1: device descriptor read/64, error -110 [ 145.163074] usb 1-1-port1: attempt power cycle [ 147.037094] usb 1-1.1: new full-speed USB device number 9 using ehci-platform [ 152.323168] usb 1-1.1: device descriptor read/64, error -110 [ 152.407069] usb 1-1.1: new full-speed USB device number 10 using ehci-platform [ 157.442518] usb 1-1.1: device not accepting address 10, error -110 [ 157.527067] usb 1-1.1: new full-speed USB device number 11 using ehci-platform [ 162.563123] usb 1-1.1: device not accepting address 11, error -110 [ 162.571302] usb 1-1-port1: unable to enumerate USB device ... [2] [ 176.523060] *** End of Test *** 2020年9月15日(火) 23:52 Alan Stern <st...@rowland.harvard.edu>: > > 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
