[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by David Brow » Sat, 04 Aug 2007 15:10:08



True, that rather suggests that some more desktoppy (that's now a word!)
people should get involved. Folk who know how to minimize that pain.

Sometimes when I plug in a USB device I get a dialog asking if I want to
configure it ... surely it would be possible to have that mechanism also
consult a database (part of a distro, or on some web server) fpr info
about the device, and offer the option for to poke at the device a bit to
see if it behaves. That stuff works for music CDs; why not USB devices?

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by David Brow » Sat, 04 Aug 2007 15:10:11


Yeah, I could have sworn there was extensive discussion over the
creation of a sysfs .../power/autususpend attribute which can enable
or disable autosuspend on a per-device basis.

Seems to me it ought to be practical to organize a database that can
be consulted by an outcall from udev, disabling autosuspend on devices
which are known to be broken. The "modules.usbmap" syntax is an obvious
place to start (painful though it is), and I'm sure there are folk who
would prefer web-accessible/updatable databases.

It'd need people to maintain that, of course, along with whatever
tools consult it. But that's a solvable problem, and it would keep
the problem properly outside of the kernel.

Long term, of course, this is just a pile of bugs for device vendors
to fix in their next revisions ... so they don't end up on the list
of "devices to avoid buying" for use with Linux systems.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Oliver Neu » Sat, 04 Aug 2007 17:00:13

Am Freitag 03 August 2007 schrieb Matthew Garrett:

Then make autosuspend support for the printer driver a config option.
This is not a reason to change the core usb code. The core code needs
to be involved only for device that are driven through usbfs. The major types
are:

- scanners
- PTP devices
- OBEX

Scanners are covered by SANE's latest CVS
PTP are a class and could be covered by a single udev rule
Obex is comm, so the patch wouldn't help.


Kernel developers are a diverser lot than you think ;-)
We don't enable autosuspend in drivers we can't test, except where
the lack of a kernel driver forces us to use a broad swipe. Printers
were tested, too, and most printers seem to work.

Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Matthew Ga » Sat, 04 Aug 2007 20:40:07


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".

--
Matthew Garrett | XXXX@XXXXX.COM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Oliver Neu » Sat, 04 Aug 2007 20:50:12

Am Freitag 03 August 2007 schrieb Matthew Garrett:


If both options have drawbacks, IMHO we follow the standard, which
says that devices must support suspension.

Regards
Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Matthew Ga » Sat, 04 Aug 2007 21:10:13


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".

--
Matthew Garrett | XXXX@XXXXX.COM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Felipe Bal » Sat, 04 Aug 2007 21:40:06


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.



--
Best Regards,

Felipe Balbi
XXXX@XXXXX.COM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by David Brow » Sat, 04 Aug 2007 23:40:08

n Friday 03 August 2007, Matthew Garrett wrote:

Which is why I didn't suggest doing that, of course. The only
one making that kind of straw man argument seems to be you.



However, you've strongly implied that you want to see a short term
patch, of the type which will (as Rogan Dawes implied) prevent solving
the problem in the long term ...



Evidently you were reading someone else's message and blaming its
content on me ... since the focus of what I wrote was having a
database *OUTSIDE THE KERNEL* which would obviate the need for
any user interaction in most cases.

If I were to describe any dialog users would see, it would be more
like "I don't recognize this device, help me set it up right...".
As with music CDs, that help might update the database for the next
person. (Assuming this were done well, of course.)



And has the discussion included the userspace people? (I don't
know how Ubuntu or Fedora folk structure such platform-scope
tasks. By inference, there's not enough cross-pollination...)

Speaking of which, what's this /dev/bus/usb/* crap on Ubuntu?
I had to undo all that on my Feisty system before any normal
/proc/bus/usb stuff would work again.



Unfortunately I need to run laptop off AC since its battery life is
painfully short, and since Linux behaves so incredibly rudely when
the battery power goes down to almost-zero: it lets it go to zero
rather than hibernating. (And doesn't automatically enter suspend
when it idles, either...)

Note by the way that if you were -- for the sake of argument -- accept
my premise that this should all be handled in userspace ... it's very
easy to make userspace code do what you want. It doesn't need to be
done inside the kernel.

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

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by David Brow » Sun, 05 Aug 2007 00:00:16


True, but for desktop users there doesn't seem to be any
real counter-argument to my point.



Right. Remotely operated systems (like servers) might
need some kind of "default assume-broken" setting.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Matthew Ga » Sun, 05 Aug 2007 00:10:10

n Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:

But however you phrase it, that's effectively what it is. "Does your
device work?" just makes users wonder why the damn computer doesn't know
already. "This option may prevent your device from working. Click here
to switch it off" results in them wondering why it was switched on in
the first place. Many of our users aren't technical - they don't care
about saving 200mW, they just care about their printer working when they
plug it in.

And, frankly, if I got a requestor like that every time I plugged in a
new USB device I'd be fairly unhappy.


Because I don't believe we'll ever identify every device that gets
broken, and so as a result I think it's better to disable the
functionality by default for anything that might be broken.


Users understand CDs. They don't understand runtime power management.


I also handle a lot of the desktop/kernel integration.


"Usbfs files can't handle Access Control Lists (ACL), which are the
default way to grant access to USB devices for untrusted users of a
desktop system. The usbfs functionality is replaced by real device-nodes
managed by udev. These nodes live in /dev/bus/usb and are used by
libusb."

(From Kconfig)


System/Preferences/Power Management


It can be, but I'd prefer to have userspace enable functionality than
have the kernel break things.
--
Matthew Garrett | XXXX@XXXXX.COM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Adam Krope » Sun, 05 Aug 2007 00:30:19


Although I have no proof immediately at hand, I suspect at a minimum HID
power class devices should be blacklisted from autosuspend. Given the
spotty USB implementations on many such devices I'd be surprised if
suspend worked reliably. Plus if you're connected to such a device for
monitoring purposes you're probably powered by it as well, so you have
little to gain from suspend even if it works.

--Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Oliver Neu » Sun, 05 Aug 2007 01:10:11

Am Freitag 03 August 2007 schrieb Matthew Garrett:

Devices rarely simply crash. Although Windows doesn't do runtime power
management, it certainly will suspend all devices when the system goes
into suspension. Buggy devices typically disconnect and reconnect when
resumed. This is testable for in software without user intervention.

Regards
Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by David Brow » Sun, 05 Aug 2007 01:40:09

n Friday 03 August 2007, Matthew Garrett wrote:

As http://en.wikipedia.org/wiki/Straw_Man phrases it,
"A straw man argument is an informal fallacy based on
misrepresentation of an opponent's position ... the
opponent's actual argument has not been refuted."

That's clearly what you've been doing by proposing some
specific -- and obviously bad -- user interfaces, none
of which have the fundamental characteristic I described.



Which is why my comment was about something else entirely!

That is, having an out-of-kernel database which could preclude
the need for such requestors for devices already known.



A new straw man! Because power management isn't the relevant point.

All they'd ever have to understand is: is it working correctly right
now? That's after an experimental autosuspend, and after poking the
hardware to verify that, from the kernel perspective, it acts OK.

Oliver pointed out that the typical failure mode is easily detected
in software. So when the user says "OK, I'll help set it up", the
worst case would be that the device is NOT recorded already in that
database, the user might need to be ready to unplug then replug the
device (when that experiment fails).



That's shortly after the explanation that the relevant Kconfig
option is for ** /proc/bus/usb ** files ... note that despite the
strangeness in that text (usbfs still hasn't been "replaced", so
that should say "will eventually be replaced" not "is replaced"),
it's clear that /proc/bus/usb/ and /dev/bus/usb/ are two different
things. And thus: that Ubuntu's /dev/bus/usb/ setup is flakey.



There's no option there to affect what happens when it's running
on battery power. Though I'm curious what it means when it has
a "suspend" option (not "hibernate") ... I wouldn't mind STR.



That side of things has been absent from the discussion so far.

When something is wrongly blacklisted (by whatever), how are you
proposing that it get un-blacklisted? Seems to me that whatever
mechanism resolves that issue should also work the other way around...

- Dave

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

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by David Brow » Sun, 05 Aug 2007 01:50:07


> >> Plus if you're connected to such a device for monitoring purposes you're >> gt; > probably powered by it as well, so you have little to gain from suspend > > >> > even if it works>
> gt;
> I currently don't have any HID UPS by hand to verify, but I'd be surpris>d
> if they would advertise remote wakeup capability .>. ?> >
> Looks like mine does..

Makes sense. You don't want to force the host to ignore all
power events. As with a laptop, you might want servers to
cleanly hibernate before the (UPS) battery runs out...

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

Post by Matthew Ga » Sun, 05 Aug 2007 02:00:14

n Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:

Plus a mechanism for pushing data into it, plus a mechanism for ensuring
that inaccurate data doesn't get in there, plus some what of pushing
updates out to users, plus privilege escalation for setting the value,
plus policy management to ensure that normal users can't mess with the
autosuspend values for other users? No, this isn't trivial - especially
when there's a straightforward in-kernel mechanism (only enable it when
it's known to be safe)


Both /proc/bus/usb and /dev/bus/usb are provided. Anything that fails to
work with /dev/bus/usb is buggy - libusb copes fine. We're in the
process of transitioning away from the legacy interface. It could be
worse - we could have just removed it on the grounds that it doesn't
work properly.


That's odd. In the "On battery power" tab I see an option to choose the
action when the battery power is critically low.


The worst case scenario in the "Disable by default, allow userspace to
whitelist" case is that some machines draw slightly more power. The
worst case scenario in the "Enable by default, allow userspace to
blacklist" case is that some hardware doesn't work because of race
conditions between autosuspend and userspace having the opportunity to
disable it, or devices not being in the blacklist, or somebody not
having adequately new usrspace, or...
--
Matthew Garrett | XXXX@XXXXX.COM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/