linux-kernel - Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers.

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

Date:	Tue, 28 May 2013 13:58:42 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Shawn Nematbakhsh <shawnn@...gle.com>
Cc:	Alan Stern <stern@...land.harvard.edu>, linux-usb@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Julius Werner <jwerner@...omium.org>
Subject: Re: [PATCH] usb: xhci: Disable runtime PM suspend for quirky
 controllers.

On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote:
> Hi Sarah and Alan,
> 
> Thanks for the comments. I will make the following revisions:
> 
> 1. Call pm_runtime_get_noresume only when the first device is connected,
> and call pm_runtime_put when the last device is disconnected.
> 2. Wrap the calls in an ifdef CONFIG_USB_DEFAULT_PERSIST.
> 3. Make sure that all pm_runtime_get_noresume calls have a corresponding
> pm_runtime_put somewhere (originally the intent was to disable runtime
> suspend "forever", but no longer).
> 
> In principle, would the patch be acceptable with these revisions?

Maybe, but I still don't like this approach, because it's too
heavy-handed.

I was considering whether userspace could do something similar to this
approach, but with udev rules instead of within the kernel.   You could
add a udev rule to trigger on USB device insertion, that would disable
runtime PM for the host, and a corresponding rule that re-enabled
runtime PM when the last USB device was disconnected.

I think it could be possible if userspace can get to the DMI information
for the system.  However, then we open the other can of worms by needing
to keep the userspace quirks list in sync with the kernel quirks list.

What if we exposed the xHCI quirks through a new quirks file in
/sys/bus/usb/devices/usbN/?  That would mean userspace doesn't need to
keep the quirks list separately.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/