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]

Message-ID: <CAEt1Rjop72j8Hb8s+yW5edfF0+dSV2DQHtqsPoK65QQ-+HRwZg@mail.gmail.com>
Date:   Wed, 16 Sep 2020 19:16:44 +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
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