linux-kernel - Re: [PATCH v5 5/5] usb: host: enable sideband transfer during system sleep

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] [day] [month] [year] [list]

Message-ID: <cc900c5b-32e6-4147-a5c7-923bfa13686a@rowland.harvard.edu>
Date: Fri, 18 Oct 2024 10:41:03 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Guan-Yu Lin <guanyulin@...gle.com>
Cc: Thinh.Nguyen@...opsys.com, gregkh@...uxfoundation.org,
	mathias.nyman@...el.com, yajun.deng@...ux.dev,
	sumit.garg@...aro.org, kekrby@...il.com, oneukum@...e.com,
	dianders@...omium.org, perex@...ex.cz, tiwai@...e.com,
	niko.mauno@...sala.com, andreyknvl@...il.com,
	christophe.jaillet@...adoo.fr, tj@...nel.org,
	stanley_chang@...ltek.com, quic_jjohnson@...cinc.com,
	ricardo@...liere.net, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org,
	badhri@...gle.com, albertccwang@...gle.com, quic_wcheng@...cinc.com,
	pumahsu@...gle.com
Subject: Re: [PATCH v5 5/5] usb: host: enable sideband transfer during system
 sleep

On Fri, Oct 18, 2024 at 07:59:00PM +0800, Guan-Yu Lin wrote:
> Thanks for the suggestions, let me address them in the next version.
> After some local development, our experiments suggest it may be
> necessary to skip usb_suspend_interface() & usb_hcd_flush_endpoint()
> for connection changes behind a hub and HID events in our scenario.
> 
> Typically, when the system sleeps, the hub uses remote wakeup to
> reactivate upstream devices and resume the interface to handle
> connection changes. However, our current conclusion is to maintain the
> device in an active state while suspending the interface. This
> deviates from the norm, as remote wakeup is designed to function when
> devices and links are suspended. We're concerned that this discrepancy
> might interfere with the remote wakeup mechanism.
> To address this, we're currently bypassing usb_suspend_interface() and
> usb_hcd_flush_endpoint(). This effectively simulates an "active
> system" state, allowing the USB controller to notify the kernel about
> connection changes via interrupts. This workaround applies to HID
> events as well.
> 
> Which approach do you recommend? Should we invest in integrating with
> the remote wakeup framework, or is it acceptable to keep necessary
> components active, mirroring an "active system" state?

It's hard to answer those questions because I don't have a clear idea of 
how the sideband system is meant to work.  For instance, what does the 
sideband system do when a port-connect change is detected in a hub that 
sits between the computer and the audio device?  If the sideband system 
decides to change the audio device's settings, how does the regular 
audio driver learn about the change?  And so on.

It's worth pointing out that allowing two different drivers to control 
the same device is generally not a good idea.  More likely than not they 
will end up interfering with each other at some stage.

Alan Stern