All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 30 Aug 2022 15:56:59 +0200	[thread overview]
Message-ID: <d1a5f149-50a1-49fc-9a6d-eceffa23311b@gmx.com> (raw)
In-Reply-To: <31aeee3c-f4f1-16a8-272b-96da5d4a565e@suse.com>


On 30/08/2022 13.54, Oliver Neukum wrote:
> On 24.08.22 18:09, JFLF wrote:
>
>> By process of elimination the controllers themselves were identified as
>> the cause of the problem. Through trial and error the issue was solved
>> by using USB_QUIRK_RESET_RESUME for both chips.
>
> Hi,
>
>
> aside from the aspects of getting this properly signed off and merged,
> this opens up a question. What does resetting a hub do to its children?
> That is if the request to wake up comes from a child, do we
>
> a) lose state in the child?
> b) retain the knowledge which port requested the wakeup?
>
> How far has this patch been tested?
>
> 	Regards
> 		Oliver


Hi Oliver,

Partial answer for now: I have been using those quirks via the kernel command line for about a year now. I have been meaning to send in the patch long ago, but kept forgetting about it.

I agree that USB_QUIRK_RESET_RESUME seems fishy with a hub. It's pretty much the last quirk I tried, and the only one that worked. I can't say I understand what it does exactly. The hubs themselves don't seem to reset (or at least not fully), as there is no re-enumeration of existing children.

I have not experienced a single problem or side effect since using those quirks. I use a mix of USB 2.0 and 3.0 devices, some bus- and some self-powered, some permanently connected (including ethernet and audio in the hub itself) and some not.

Thanks!
JF

  reply	other threads:[~2022-08-30 13:59 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 [this message]
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

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=d1a5f149-50a1-49fc-9a6d-eceffa23311b@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.