linux-kernel - Re: [PATCH v3] USB: Don't set USB_PORT_FEAT

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 20 Apr 2021 11:28:48 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Chris Chiu <chris.chiu@...onical.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>, m.v.b@...box.com,
        hadess@...ess.net, linux-usb@...r.kernel.org,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's
 Realtek Hub

On Tue, Apr 20, 2021 at 03:14:56PM +0800, Chris Chiu wrote:
> On Mon, Apr 19, 2021 at 10:19 PM Alan Stern <stern@...land.harvard.edu> wrote:
> >
> > On Mon, Apr 19, 2021 at 01:11:38AM -0400, Chris Chiu wrote:
> > > Sorry that I didn't make myself clear. I found that if I applied RESET_RESUME
> > > quirk on the problematic hub, the Set-Port-Feature(suspend) timeout error
> > > disappeared. SInce the timeout is not happening for each suspend by default,
> > > I suspect maybe reset-resume take everything back to clean state for the hub
> > > and the Set-Port-Feature(suspend) can be taken care of w/o problems.
> >
> > Okay, that's a good solution for system suspend.
> >
> > > I didn't like RESET_RESUME because runtime PM would not work on the quirked
> > > device.
> >
> > A more interesting question is whether it will work for devices plugged
> > into the hub.  Even though the hub won't be runtime suspended, the
> > things attached to it might be.
> >
> > >  But if the Set-Port-Feature(suspend) can't be handled and
> > > skipped, I can't
> > > expect the runtime PM to work for all devices connected to the hub either.
> > > Is that right? If what I proposed in the patch can not get better
> > > result than existing
> > > quirk, I think using the RESET_RESUME would be a better option. Any suggestions?
> >
> > Try the RESET_RESUME quirk and see how well it works with runtime
> > suspend.
> >
> > Alan Stern
> 
> [  453.064346] usb 3-4: finish reset-resume
> [  453.192387] usb 3-4: reset high-speed USB device number 2 using xhci_hcd
> [  453.339916] usb 3-4: USB quirks for this device: 2

Here 3-4 is problematic RealTek hub, right?

> Seems that even w/ the RESET_RESUME enabled, the connected device still
> can runtime suspend/resume. That's acceptable to me. I'll send the patch
> with the reset-resume quirk later.
> 
> [  626.081068] usb 3-4.3.1: usb auto-suspend, wakeup 0
> [  632.552071] usb 3-4.3.1: usb auto-resume
> [  632.617467] usb 3-4.3.1: Waited 0ms for CONNECT
> [  632.617471] usb 3-4.3.1: finish resume

Then 3-4.3 is another hub plugged into the Realtek hub, and 3-4.3.1 (the 
device being suspended and resumed) is plugged into that other hub.

I'm concerned about devices that are plugged directly into the Realtek 
hub.  For example, did you try allowing the 3-4.3 hub in the experiment 
above to suspend and resume?

Alan Stern