Re: [PATCH v3] USB: hub.c: decrease the number of attempts of enumeration scheme

[yasushi asano]

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