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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 19 Sep 2020 00:00:10 +0900
From:   yasushi asano <yazzep@...il.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Eugeniu Rosca <erosca@...adit-jv.com>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        andrew_gabbasov@...tor.com, Baxter Jim <jim_baxter@...tor.com>,
        "Natsume, Wataru (ADITJ/SWG)" <wnatsume@...adit-jv.com>,
        "Nishiguchi, Naohiro (ADITJ/SWG)" <nnishiguchi@...adit-jv.com>,
        浅野恭史 <yasano@...adit-jv.com>,
        kernel test robot <rong.a.chen@...el.com>,
        Martin Mueller <Martin.Mueller5@...bosch.com>,
        Eugeniu Rosca <roscaeugeniu@...il.com>
Subject: Re: [PATCH v3] USB: hub.c: decrease the number of attempts of
 enumeration scheme

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@...il.com>:
>
> 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@...land.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