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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 27 Jun 2015 08:29:16 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc:	Alan Stern <stern@...land.harvard.edu>,
	Tom Gundersen <teg@...m.no>, linux-usb@...r.kernel.org,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC] usbhid: enable autosuspend for internal devices

On Fri, 26 Jun 2015, Greg Kroah-Hartman wrote:

> > I thought udev used a whitelist of devices known to work okay with 
> > autosuspend.  Does it really turn on autosuspend for _every_ USB HID 
> > device that is marked as removable?
> 
> Yes, it had a tiny whitelist of 3-4 devices, and then would turn on
> autosuspend for anything not marked as removable or unknown.  Look at
> /usr/lib/udev/rules.d/42-usb-hid-pm.rules on your system for them, it's
> these lines:
> 	ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTR{../removable}=="removable", GOTO="usb_hid_pm_end"
> 	ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTR{../removable}=="unknown", GOTO="usb_hid_pm_end"
> 
> > (Come to think of it, given the bug in the hub driver, no device 
> > attached directly to the root hub will _ever_ be marked as removable 
> > AFAICS.  So maybe that bug is masking possible regressions.)
> 
> Maybe that's the issue, don't know, it would be good to figure out as
> upstream udev just deleted that whole rules file :)

Last time we were testing this, autosuspend for USB HID devices was quite 
a disaster.

Do you have any idea whether udev developers tested the "autosuspend on by 
default for USB HID devices" on reasonable set of devices?

The culrpits that I remember from top of my head (it's been long time 
ago):

- the LEDs for suspended device go off. This is very confusing at least on 
  keyboards, and brings really bad user experience

- many keyboards were losing first keystroke when waking up from suspend. 
  We've been debugging this with Alan, and never root-caused it to a 
  problem in our code, it seems to be the property of the HW

I really do want to keep the autosuspend disabled by default on USB HID 
devices (at least keyboards), and enable it based on whitelist. If udev is 
not going to do this any more, I am afraid we'll have to move the default 
into the kernel.

-- 
Jiri Kosina
SUSE Labs
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ