From: jflf_kernel@gmx.com
To: Oliver Neukum <oneukum@suse.com>,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: add quirks for Lenovo OneLink+ Dock
Date: Sun, 4 Sep 2022 23:38:31 +0200 [thread overview]
Message-ID: <0bdfdd52-4e73-0554-ef94-5da5af0ae01b@gmx.com> (raw)
In-Reply-To: <60a08cc9-a96d-9453-1cef-a440527a79f6@suse.com>
On 31/08/2022 11.16, Oliver Neukum wrote:
>> I'll run some more tests out of curiosity to see how things behave in corner cases.
>
> While you do so, which is a good idea, could you restate your current
> results in a more precise way? We should have 4 results for each hub.
> It is not the case that RESET_RESUME has no effect if you give
> usbcore.autosuspend=-1 if the system has been suspended. Hence we have
> the cases of
>
> no RESET_RESUME/default autosuspend
> no RESET_RESUME/autosuspend=-1
> with RESET_RESUME/default autosuspend
> with RESET_RESUME/autosuspend=-1
Hi Oliver,
Apologies for my last unclear message.
Both VL812 hubs behave the same way so I have a single table for both. The settings are applied to both hubs, on both USB2 and USB3.
I have separated USB2 and USB3 as they behave slightly differently.
=======================================================================================
Settings USB2 hotplug USB3 hotplug State after waking up
---------------------------------------------------------------------------------------
power/control=auto works (1) fails broken (2)
usbcore.autosuspend=-1 works works broken (2)
OR power/control=on
power/control=auto works (3) works (3) works
and USB_QUIRK_RESET_RESUME
power/control=on works works works
and USB_QUIRK_RESET_RESUME
HUB_QUIRK_DISABLE_AUTOSUSPEND works works works
and USB_QUIRK_RESET_RESUME
=======================================================================================
(1) I have yet to find a device that would be rejected by the USB2 side, while I have reliable reproducers for USB3. The problem appears with specific devices only, which otherwise work flawlessly on other hubs, other systems, etc.
(2) After a system wake-up the hubs are in a seemingly random state. Numerous errors appear in the syslog, and some ports may be dead (changes from wake-up to wake-up). This can affect both internal (to dock built-in devices) and external hub ports.
(3) With RESET_RESUME the hubs (both USB2 and USB3) stay active and don't autosuspend, even when power/control==auto.
In all situations above a keyboard and the integrated ethernet controller can wake up the laptop from suspend. In situations (2) they may not work anymore after waking up.
The bottom line is: we need USB_QUIRK_RESET_RESUME to deal with the spurious hub state after waking up, and we need to prevent the hubs from autosuspending to work around the USB3 issue. RESET_RESUME does all of that right now, but can its behaviour be considered stable? Is there any chance that some day it would no longer block autosuspend?
If RESET_RESUME is stable, then my current patch is enough and it can be re-merged. If not, I have an updated patch ready with HUB_QUIRK_DISABLE_AUTOSUSPEND.
Also, RESET_RESUME keeps the device nodes active, but not the hub interface nodes. HUB_QUIRK_DISABLE_AUTOSUSPEND and usbcore.autosuspend=-1 keep both of them active:
$ grep active /sys/bus/usb/devices/2*/power/runtime_status # USB_QUIRK_RESET_RESUME
/sys/bus/usb/devices/2-1.1/power/runtime_status:active
/sys/bus/usb/devices/2-1/power/runtime_status:active
$ grep active /sys/bus/usb/devices/2*/power/runtime_status # HUB_QUIRK_DISABLE_AUTOSUSPEND
/sys/bus/usb/devices/2-1:1.0/power/runtime_status:active
/sys/bus/usb/devices/2-1.1:1.0/power/runtime_status:active
/sys/bus/usb/devices/2-1.1/power/runtime_status:active
/sys/bus/usb/devices/2-1/power/runtime_status:active
I do not know what impact this could have. In my tests both accepted the hotplugged USB3 devices, so keeping the device nodes active is enough.
Thanks!
JF
prev parent reply other threads:[~2022-09-04 21:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 16:09 [PATCH] usb: add quirks for Lenovo OneLink+ Dock JFLF
2022-08-24 16:19 ` Greg KH
2022-08-30 11:54 ` Oliver Neukum
2022-08-30 13:56 ` jflf_kernel
2022-08-30 14:47 ` Oliver Neukum
2022-08-30 19:50 ` jflf_kernel
2022-08-31 7:31 ` Greg KH
2022-08-31 7:43 ` jflf_kernel
2022-08-31 8:35 ` Greg KH
2022-08-31 9:16 ` Oliver Neukum
2022-09-04 21:38 ` jflf_kernel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0bdfdd52-4e73-0554-ef94-5da5af0ae01b@gmx.com \
--to=jflf_kernel@gmx.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox