Dear Alan, Could you please proceed with your proposal(Kconfig option)? After all, Customer products need to get USB certification. Thank you for considering my request. 2020年9月16日(水) 19:16 yasushi asano <yazzep@xxxxxxxxx>: > > 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 <stern@xxxxxxxxxxxxxxxxxxx>: > > > > 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
