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]
Message-ID: <31e679430708030534v5a8f1c9p3eb25c9e3db48f0a@mail.gmail.com>
Date:	Fri, 3 Aug 2007 08:34:06 -0400
From:	"Felipe Balbi" <felipebalbi@...rs.sourceforge.net>
To:	"Rogan Dawes" <lists@...es.za.net>
Cc:	"Matthew Garrett" <mjg59@...f.ucam.org>,
	"Greg KH" <gregkh@...e.de>, linux-usb-devel@...ts.sourceforge.net,
	"Oliver Neukum" <oliver@...kum.org>, linux-kernel@...r.kernel.org,
	"David Brownell" <david-b@...bell.net>,
	"Alan Stern" <stern@...land.harvard.edu>
Subject: Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

On 8/3/07, Rogan Dawes <lists@...es.za.net> wrote:
> Matthew Garrett wrote:
> > On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote:
> >> Am Freitag 03 August 2007 schrieb Matthew Garrett:
> >>> It's certainly possible to do that, but it's also possible to have a
> >>> userspace solution that whitelists devices. The question is whether the
> >>> default kernel behaviour should be "Save power, but potentially break
> >>> some of my devices" or "Don't break my devices, but use some more
> >>> powre".
> >> If both options have drawbacks, IMHO we follow the standard, which
> >> says that devices must support suspension.
> >
> > Except that lots of hardware doesn't follow the standard in this
> > respect, otherwise we wouldn't be having this discussion. Personally, I
> > think "Will break an unknown number of devices" is a significantly
> > larger drawback than "Will consume a small quantity of additional
> > power".
> >
>
> I guess the question could be phrased:
>
> Which one is more likely to conclude at some point?
>
> That is, if we blacklist by default, we consume that additional power
> indefinitely, because it is unlikely that people will report "my machine
> uses 200mW more than I think it should", and thus we are unlikely to
> build up knowledge of exactly which devices/classes should be blacklisted.
>
> Compare that to:
>
> "My USB printer broke, guess I'd better report it to LKML".
>
> The first option is unlikely to ever reach a satisfactory conclusion,
> whereas the second one is quite likely to flush out the guilty parties
> within a relatively short time.

Even though we should be following what the specs says and find other
ways of threating the "messy" devices. A sysfs entry for
enabling/disabling autosuspend and even to add devices to blacklist
seems quite nice to me.

>
> FWIW.
>
> Rogan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> linux-usb-devel@...ts.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>


-- 
Best Regards,

Felipe Balbi
felipebalbi@...rs.sourceforge.net
-
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