[PATCH] USB: Only enable autosuspend by default on certain device classes

[PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

We're seeing a large number of problems with devices not appreciating 
USB autosuspend, especially printers and scanners. According to 
http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx only a 
subset of drivers support it in Windows XP, meaning that most devices 
are probably untested in this situation. This patch alters the behaviour 
to match that of Windows. Userspace can still whitelist devices as 
appropriate, and the set of classes supporting autosuspend probably 
covers pretty much every driver likely to be found on any portable 
device.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>

---

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index caaa46f..12ba789 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1278,6 +1278,22 @@ int usb_new_device(struct usb_device *udev)
 {
 	int err;
 
+#ifdef CONFIG_USB_SUSPEND
+	/* Disable autosuspend for most devices - Windows only enables it
+	   for a small subset of classes, so most hardware hasn't been tested
+	   with it. Userspace can always reenable at a later point */
+
+	switch (udev->descriptor.bDeviceClass) {
+	case USB_CLASS_HID:
+	case USB_CLASS_COMM:
+	case USB_CLASS_WIRELESS_CONTROLLER:
+	case USB_CLASS_HUB:
+		break;
+	default:
+		udev->autosuspend_disabled = 1;
+	}
+#endif
+
 	/* Determine quirks */
 	usb_detect_quirks(udev);


-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Greg KH]

On Fri, Aug 03, 2007 at 12:56:13AM +0100, Matthew Garrett wrote:
> We're seeing a large number of problems with devices not appreciating 
> USB autosuspend, especially printers and scanners. According to 
> http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx only a 
> subset of drivers support it in Windows XP, meaning that most devices 
> are probably untested in this situation. This patch alters the behaviour 
> to match that of Windows. Userspace can still whitelist devices as 
> appropriate, and the set of classes supporting autosuspend probably 
> covers pretty much every driver likely to be found on any portable 
> device.
> 
> Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>

Well, if you do this, then you can pretty much delete the whole quirk
table we have, right?

And personally, I want to do better than Windows XP when it comes to
power management.  This patch is only going to suspend a very tiny
subset of devices, including a whole bunch of ones that do not even have
drivers in Linux, causing our power footprint to be bigger than needed.

Also, we have udev rules for SANE that disables their autosuspend
settings, which handles the majority of the devices we have seen with
problems.

So I really don't want to accept this patch.  But, what problems are you
seeing with our current suspend logic that you feel we need to be this
harsh?

thanks,

greg k-h

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote:

> Well, if you do this, then you can pretty much delete the whole quirk
> table we have, right?

At the moment, yes.

> And personally, I want to do better than Windows XP when it comes to
> power management.  This patch is only going to suspend a very tiny
> subset of devices, including a whole bunch of ones that do not even have
> drivers in Linux, causing our power footprint to be bigger than needed.

I agree. I'd much rather see us suspending devices whenever possible - 
it's just that I have concerns over the scalability of the blacklist, 
given the number of devices that seem to have issues.

> Also, we have udev rules for SANE that disables their autosuspend
> settings, which handles the majority of the devices we have seen with
> problems.

Several printers seem to have the issue as well, and the blacklist seems 
to contain some odd miscellaneous devices like the Blackberry. The main 
concern I have is that kernel developers just don't tend to be the sort 
of people that use webcams, printers or scanners, so we're relying on 
normal users to go to the effort of reporting that their device has 
stopped working.

> So I really don't want to accept this patch.  But, what problems are you
> seeing with our current suspend logic that you feel we need to be this
> harsh?

It's definitely a brute force approach, but it's one that means that we 
get the low hanging fruit (ie, pretty much anything that's likely to be 
plugged into a laptop) while massively reducing the probability of 
breaking anyone's system. Saving some power is a nice win, but breaking 
someone's printer is a pretty big loss.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Alan Stern]

On Fri, 3 Aug 2007, Matthew Garrett wrote:

> On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote:
> 
> > Well, if you do this, then you can pretty much delete the whole quirk
> > table we have, right?
> 
> At the moment, yes.
> 
> > And personally, I want to do better than Windows XP when it comes to
> > power management.  This patch is only going to suspend a very tiny
> > subset of devices, including a whole bunch of ones that do not even have
> > drivers in Linux, causing our power footprint to be bigger than needed.
> 
> I agree. I'd much rather see us suspending devices whenever possible - 
> it's just that I have concerns over the scalability of the blacklist, 
> given the number of devices that seem to have issues.

While I agree in general, perhaps a different approach would work
better.  For instance, we could blacklist a few known-bad device
classes (maybe even using the existing blacklist) rather than
whitelisting a few known-good ones -- or trying to blacklist each 
member of the bad classes!

Also, building something this sweeping into a kernel driver feels like
a mistake.  It ought to be more easily configurable from userspace, say
via a sysfs file.  Although this wouldn't be so important if we take
the blacklist-classes route.

Alan Stern

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

[David Brownell]

On Thursday 02 August 2007, Alan Stern wrote:
> Also, building something this sweeping into a kernel driver feels like
> a mistake.  It ought to be more easily configurable from userspace, say
> via a sysfs file.

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

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

[Matthew Garrett]

On Thu, Aug 02, 2007 at 11:01:08PM -0700, David Brownell wrote:

> 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'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 | mjg59@srcf.ucam.org

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

[Oliver Neukum]

Am Freitag 03 August 2007 schrieb Matthew Garrett:
> On Thu, Aug 02, 2007 at 11:01:08PM -0700, David Brownell wrote:
> 
> > 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'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.

	Regards
		Oliver

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

[Matthew Garrett]

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

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Rogan Dawes]

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.

FWIW.

Rogan

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:

> Compare that to:
> 
> "My USB printer broke, guess I'd better report it to LKML".

But while this is still a likely probability, the chances are no 
distribution is going to ship with CONFIG_USB_SUSPEND enabled. Breaking 
people's hardware (even if, at a fundamental level, it's the hardware 
that's broken) generally irritates users - and I suspect that the users 
it'll irritate the most are the ones who won't report it to LKML.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[David Brownell]

On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
>
> > Which one is more likely to conclude at some point?

Good question ... though "how will it conclude" is also relevant.


> > Compare that to:
> > 
> > "My USB printer broke, guess I'd better report it to LKML".

Which is, as I pointed out, the wrong response.  Desktoppy
people should be making their tools do more intelligent things
with new USB devices they see ... like updating databases of
broken devices, and configuring *this* system to know that of
the devices it regularly deals with, this handful is broken.

Remember, these are the same users who wouldn't know what an
LKML is (do you plug them into the USB port??) if it bit them.


> But while this is still a likely probability, the chances are no 
> distribution is going to ship with CONFIG_USB_SUSPEND enabled.

So you're saying all the distros want to make PM problems worse?

And that with all the other desktoppy stuff they're doing, not one
of them is willing to help make things better?

Pardon me if I want to hear distro vendors agree with you before I
believe that.


> Breaking  
> people's hardware (even if, at a fundamental level, it's the hardware 
> that's broken) generally irritates users - and I suspect that the users 
> it'll irritate the most are the ones who won't report it to LKML.

Having a laptop drain its battery an hour before it needs to is
also irritating.  (As are the extortionate prices for each model's
unique batteries, but that's a different issue.)

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

On Fri, Aug 03, 2007 at 07:01:11AM -0700, David Brownell wrote:

> Which is, as I pointed out, the wrong response.  Desktoppy
> people should be making their tools do more intelligent things
> with new USB devices they see ... like updating databases of
> broken devices, and configuring *this* system to know that of
> the devices it regularly deals with, this handful is broken.

Popping up a box saying "Is your device broken?" isn't good UI. 

> > But while this is still a likely probability, the chances are no 
> > distribution is going to ship with CONFIG_USB_SUSPEND enabled.
> 
> So you're saying all the distros want to make PM problems worse?

No. But given a choice between working hardware or marginally better 
runtime PM, they're going to choose working hardware.

> And that with all the other desktoppy stuff they're doing, not one
> of them is willing to help make things better?

This patch is exactly that - a way of getting most of the benefits of 
autosuspend without any real probability of breaking hardware. If you 
mean "Are the distributions willing to pop up dialogs asking users to 
start caring about obscure aspects of the USB spec", then I don't think 
that's actually making things better.

> Pardon me if I want to hear distro vendors agree with you before I
> believe that.

I'm speaking as part of the Ubuntu kernel team, and I've been discussing 
this with Fedora people.

> 
> > Breaking  
> > people's hardware (even if, at a fundamental level, it's the hardware 
> > that's broken) generally irritates users - and I suspect that the users 
> > it'll irritate the most are the ones who won't report it to LKML.
> 
> Having a laptop drain its battery an hour before it needs to is
> also irritating.  (As are the extortionate prices for each model's
> unique batteries, but that's a different issue.)

You commonly run a laptop off battery while having a printer plugged in?
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Alan Stern]

On Fri, 3 Aug 2007, Matthew Garrett wrote:

> This patch is exactly that - a way of getting most of the benefits of 
> autosuspend without any real probability of breaking hardware. If you 
> mean "Are the distributions willing to pop up dialogs asking users to 
> start caring about obscure aspects of the USB spec", then I don't think 
> that's actually making things better.

Quite aside from issues involving desktop ease-of-use and distribution 
intentions, there is a technical matter to consider.  With the default 
autosuspend timeout set to 2 seconds, as it is now, it can often happen 
that userspace isn't able to respond in time to prevent a device from 
being suspended.  At bootup especially, the system is so busy running 
lots of tasks that response to a newly-detected device can be delayed 
for tens of seconds.  Even loading the device driver's module can take 
so long that the device gets autosuspended first.

There are two possible solutions, both involving the kernel (since
userspace can't respond in time).  One is to change the default timeout
to something larger, or even disable it completely.  Then people would
need to rely on userspace tools to enable autosuspend on known-good
devices.  The other possibility is to have a fairly reliable blacklist
or whitelist and again rely on userspace to manage edge cases.  This is 
of course more flexible than a blanket default setting, but it's still 
pretty rigid.  On the other hand, a blacklist can't be changed without 
rebuilding the kernel whereas the default timeout can be adjusted on 
the boot command line.

I don't know what the "best" approach is, but I can't see any
alternative to these two.  Furthermore, whatever approach we settle on
_has_ to be able to handle devices which simply die upon being 
suspended.

Alan Stern

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

On Fri, Aug 03, 2007 at 10:28:19AM -0400, Alan Stern wrote:
> On Fri, 3 Aug 2007, Matthew Garrett wrote:

> There are two possible solutions, both involving the kernel (since
> userspace can't respond in time).  One is to change the default timeout
> to something larger, or even disable it completely.  Then people would
> need to rely on userspace tools to enable autosuspend on known-good
> devices.  The other possibility is to have a fairly reliable blacklist
> or whitelist and again rely on userspace to manage edge cases.  This is 
> of course more flexible than a blanket default setting, but it's still 
> pretty rigid.  On the other hand, a blacklist can't be changed without 
> rebuilding the kernel whereas the default timeout can be adjusted on 
> the boot command line.

Windows will autosuspend hubs, bluetooth devices, HID devices and CDC 
devices, so I think we're safe suspending those by default. I'm not so 
enthusiastic about the "Increase the timeout case" - it doesn't avoid 
any races, just makes them less likely. USB is likely to get loaded in 
the initramfs, but we may not have a full set of udev rules until the 
root fs is up and that can take an effectively arbitrarily large amount 
of time.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Alan Stern]

On Fri, 3 Aug 2007, Matthew Garrett wrote:

> Windows will autosuspend hubs, bluetooth devices, HID devices and CDC 
> devices, so I think we're safe suspending those by default.

And we know that we're not safe suspending scanners and many printers 
by default.  But that leaves plenty of other device classes unaccounted 
for.

> I'm not so 
> enthusiastic about the "Increase the timeout case" - it doesn't avoid 
> any races, just makes them less likely. USB is likely to get loaded in 
> the initramfs, but we may not have a full set of udev rules until the 
> root fs is up and that can take an effectively arbitrarily large amount 
> of time.

If it takes longer than 15 minutes, something is wrong.  At that point 
the user will have worse things to worry about than whether some USB 
devices got suspended.

And 15 minutes is a perfectly reasonable autosuspend timeout for 
devices that might be plugged in all day long.

Alan Stern

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

On Fri, Aug 03, 2007 at 10:41:13AM -0400, Alan Stern wrote:
> On Fri, 3 Aug 2007, Matthew Garrett wrote:
> > I'm not so 
> > enthusiastic about the "Increase the timeout case" - it doesn't avoid 
> > any races, just makes them less likely. USB is likely to get loaded in 
> > the initramfs, but we may not have a full set of udev rules until the 
> > root fs is up and that can take an effectively arbitrarily large amount 
> > of time.
> 
> If it takes longer than 15 minutes, something is wrong.  At that point 
> the user will have worse things to worry about than whether some USB 
> devices got suspended.

Imagine cases where / is fscked from initramfs?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Jiri Kosina]

On Fri, 3 Aug 2007, Matthew Garrett wrote:

> Windows will autosuspend hubs, bluetooth devices, HID devices

Hi Matthew,

are you sure about windows suspending the HID devices in runtime? I have 
never seen LEDs of USB keyboard connected to windows host to go off after 
some time of not using it.

We have been playing with runtime autosuspend of HID devices, are 
currently postponed the full support, as it turns out that many devices 
don't support this feature properly (probably due to not being tested in 
Windows).

-- 
Jiri Kosina

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

[Dave Jones]

On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
 > On Fri, 3 Aug 2007, Matthew Garrett wrote:
 > 
 > > Windows will autosuspend hubs, bluetooth devices, HID devices
 > 
 > Hi Matthew,
 > 
 > are you sure about windows suspending the HID devices in runtime? I have 
 > never seen LEDs of USB keyboard connected to windows host to go off after 
 > some time of not using it.

Not so sure about keyboards, but I've seen the LEDs on USB mice dim or go off
after a few seconds of inactivity under Windows, but under Linux they stay on.

 > We have been playing with runtime autosuspend of HID devices, are 
 > currently postponed the full support, as it turns out that many devices 
 > don't support this feature properly (probably due to not being tested in 
 > Windows).

Interesting.  Which devices did you notice failing?
Was it a case that they would sleep and not come back out of that state?

	Dave

-- 
http://www.codemonkey.org.uk

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

[Jiri Kosina]

On Fri, 3 Aug 2007, Dave Jones wrote:

> Interesting.  Which devices did you notice failing? Was it a case that 
> they would sleep and not come back out of that state?

Random keyboards, even connection to EHCI/OHCI seemed to make difference. 
We have been doing some experiments with Alan during OLS and it seemed 
quite hopeless.

A few keyboards we have been testing with seemed to be losing keypressess 
when coming out of suspend (if and only if the root hub wasn't suspended 
too, etc. Magic).

-- 
Jiri Kosina

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

[David Brownell]

On Friday 03 August 2007, Dave Jones wrote:
>  > We have been playing with runtime autosuspend of HID devices, are 
>  > currently postponed the full support, as it turns out that many devices 
>  > don't support this feature properly (probably due to not being tested in 
>  > Windows).
> 
> Interesting.  Which devices did you notice failing?
> Was it a case that they would sleep and not come back out of that state?

And could you elaborate on "many"?  What proportion of HID devices
(by volume, model, etc) seem to have problems?

I'd certainly expect there to be some HID devices which misbehave
(I have one, a cheap MacAlly trackball).  Early testing seemed to
indicate such misbehavior was the exception to the rule ... folk
kept disbelieving me when I pointed out some HID devices misbehaved,
since nobody else had seen such a thing!

The specific failure I saw was that the device advertised itself as
supporting remote wakeup, but it couldn't issue that signaling. It
came back from suspend just fine ... but moving or clicking would
not do what it should.

- Dave

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

[Jiri Kosina]

On Fri, 3 Aug 2007, David Brownell wrote:

> And could you elaborate on "many"?  What proportion of HID devices (by 
> volume, model, etc) seem to have problems?

Last time I tried with two random USB keyboards - one from Logitech and 
one from Chicony, I don't remember the exact PIDs, but could look them up 
if it is interesting for someone.

> The specific failure I saw was that the device advertised itself as 
> supporting remote wakeup, but it couldn't issue that signaling. It came 
> back from suspend just fine ... but moving or clicking would not do what 
> it should.

What I have been seeing with both these keyboards was: if connected to 
UHCI controller, root hub not auto-suspended, as soon as they got 
autosuspended, and keys were pressed on them rapidly, very often some 
keypressess got lost. I didn't experience this on OHCI, but I remember 
Alan saying that he triggered it on OHCI too, right?

Seemed like a timing issue - by lowering the polling timeout we were able 
to make things much better, but that of course costs us more power etc. 
and it's even not sure if it is an ultimate solution.

-- 
Jiri Kosina

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

[Alan Stern]

On Fri, 3 Aug 2007, Jiri Kosina wrote:

> What I have been seeing with both these keyboards was: if connected to 
> UHCI controller, root hub not auto-suspended, as soon as they got 
> autosuspended, and keys were pressed on them rapidly, very often some 
> keypressess got lost. I didn't experience this on OHCI, but I remember 
> Alan saying that he triggered it on OHCI too, right?
> 
> Seemed like a timing issue - by lowering the polling timeout we were able 
> to make things much better, but that of course costs us more power etc. 
> and it's even not sure if it is an ultimate solution.

Jiri and I ran a few tests at OLS, and we each did additional testing
on our own.  We looked at a small selection of keyboards; the ones I
tested were by Apple and HP.  Some keyboards had embedded hubs and
others didn't.  Some of our testing was with the keyboard behind an
external hub.  Sometimes only the keyboard controller was suspended,
sometimes the controller and the embedded hub were, sometimes the
external hub and everything downstream of it were, and sometimes the
root hub was.  We tested with both UHCI and OHCI -- I may even have
done some tests with EHCI and a high-speed hub, I don't remember now.

The end result was that some scenarios worked more reliably than 
others.  There were lots of variables and it was hard to tie overall 
behavior with system settings.  It did seem that in situations where 
the topmost suspended device was plugged into a UHCI root hub, 
increasing the the root hub's polling rate helped.  But it didn't 
always help, and in any case we certainly don't want to change a kernel 
timer from 250 ms to 32 ms whenever a device is suspended!

The bad behavior we observed, as Jiri described, was that rapid typing 
on a suspended keyboard would often cause one or more of the keystrokes 
to be lost.  The probability of this happening varied with the 
circumstances, but I don't think I ever found a combination that was 
100% reliable.  It could well be a timing issue, or buffering -- 
there's no real way to know.

An additional drawback to autosuspend for keyboards is the fact that 
the NumLock, CapsLock, etc. LEDs go out.

We didn't test any mice (at least, I didn't).  However it has been
reported that while some suspended mice will send wakeup requests when
they are moved, others won't.  Certainly an optical mouse won't.

All in all, it appears that the simplest and most user-friendly
approach is just not to autosuspend keyboards and mice.

Alan Stern

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

[Adam Kropelin]

Dave Jones wrote:
> On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
>> On Fri, 3 Aug 2007, Matthew Garrett wrote:
>>
>>> Windows will autosuspend hubs, bluetooth devices, HID devices
>>
>> Hi Matthew,
>>
>> are you sure about windows suspending the HID devices in runtime? I
>> have never seen LEDs of USB keyboard connected to windows host to go
>> off after some time of not using it.
>
> Not so sure about keyboards, but I've seen the LEDs on USB mice dim
> or go off after a few seconds of inactivity under Windows, but under
> Linux they stay on.
>
>> We have been playing with runtime autosuspend of HID devices, are
>> currently postponed the full support, as it turns out that many
>> devices don't support this feature properly (probably due to not
>> being tested in Windows).
>
> Interesting.  Which devices did you notice failing?
> Was it a case that they would sleep and not come back out of that
> state?

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

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

[Jiri Kosina]

On Fri, 3 Aug 2007, Adam Kropelin wrote:

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

I agree here.

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

I currently don't have any HID UPS by hand to verify, but I'd be surprised 
if they would advertise remote wakeup capability ... ?

Thanks,

-- 
Jiri Kosina

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

[Dave Jones]

On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:

 > > 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.
 > 
 > I currently don't have any HID UPS by hand to verify, but I'd be surprised 
 > if they would advertise remote wakeup capability ... ?

Looks like mine does..

Bus 001 Device 004: ID 051d:0002 American Power Conversion Back-UPS Pro 500/1000/1500
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x051d American Power Conversion
  idProduct          0x0002 Back-UPS Pro 500/1000/1500
  bcdDevice            1.06
  iManufacturer           3 APC
  iProduct                1 Back-UPS ES 500 FW:801.e6.D USB FW:e6
  iSerial                 2 AB0530291763  
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA

...

	Dave


-- 
http://www.codemonkey.org.uk

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

[David Brownell]

On Friday 03 August 2007, Dave Jones wrote:
>  > > 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.
>  > 
>  > I currently don't have any HID UPS by hand to verify, but I'd be surprised 
>  > 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

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

[Adam Kropelin]

Dave Jones wrote:
> On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:
>
>>> 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.
>>
>> I currently don't have any HID UPS by hand to verify, but I'd be
>> surprised if they would advertise remote wakeup capability ... ?
>
> Looks like mine does..
> [...]
>  idVendor           0x051d American Power Conversion
>  idProduct          0x0002 Back-UPS Pro 500/1000/1500

*notes to self to send pci.ids patch again*

>  bcdDevice            1.06
>  iManufacturer           3 APC
>  iProduct                1 Back-UPS ES 500 FW:801.e6.D USB FW:e6

Yup, I have one of those in my arsenal and see the same thing.

>  iSerial                 2 AB0530291763
>  bNumConfigurations      1
>  Configuration Descriptor:
>    bLength                 9
>    bDescriptorType         2
>    wTotalLength           34
>    bNumInterfaces          1
>    bConfigurationValue     1
>    iConfiguration          0
>    bmAttributes         0xe0
>      Self Powered
>      Remote Wakeup

I have reports of APC UPS remote wakeup working properly on "recent" 
PowerMac G5s running OS X, but was never able to duplicate that success 
on my cruddy old G3. I never figured out if it was a deficiency of the 
UPS, the G3, or the OS. So it is possible that with appropriate OS 
support this feature may actually work on certain UPSes (APC has a habit 
of messing up the firmware differently on each model, so it's likely 
hit-or-miss, but they are improving).

--Adam

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:

> are you sure about windows suspending the HID devices in runtime? I have 
> never seen LEDs of USB keyboard connected to windows host to go off after 
> some time of not using it.

Ah, sorry - on reading more closely, HID devices will only be 
autosuspended if they're whitelisted.

> We have been playing with runtime autosuspend of HID devices, are 
> currently postponed the full support, as it turns out that many devices 
> don't support this feature properly (probably due to not being tested in 
> Windows).

This doesn't surprise me...
-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[David Brownell]

On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 07:01:11AM -0700, David Brownell wrote:
> 
> > Which is, as I pointed out, the wrong response.  Desktoppy
> > people should be making their tools do more intelligent things
> > with new USB devices they see ... like updating databases of
> > broken devices, and configuring *this* system to know that of
> > the devices it regularly deals with, this handful is broken.
> 
> Popping up a box saying "Is your device broken?" isn't good UI. 

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.


> > > But while this is still a likely probability, the chances are no 
> > > distribution is going to ship with CONFIG_USB_SUSPEND enabled.
> > 
> > So you're saying all the distros want to make PM problems worse?
> 
> No. But given a choice between working hardware or marginally better 
> runtime PM, they're going to choose working hardware.

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


> > And that with all the other desktoppy stuff they're doing, not one
> > of them is willing to help make things better?
> 
> This patch is exactly that - a way of getting most of the benefits of 
> autosuspend without any real probability of breaking hardware. If you 
> mean "Are the distributions willing to pop up dialogs asking users to 
> start caring about obscure aspects of the USB spec", then I don't think 
> that's actually making things better.

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


> > Pardon me if I want to hear distro vendors agree with you before I
> > believe that.
> 
> I'm speaking as part of the Ubuntu kernel team, and I've been discussing 
> this with Fedora people.

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.


> > > Breaking  
> > > people's hardware (even if, at a fundamental level, it's the hardware 
> > > that's broken) generally irritates users - and I suspect that the users 
> > > it'll irritate the most are the ones who won't report it to LKML.
> >
> > Having a laptop drain its battery an hour before it needs to is
> > also irritating.  (As are the extortionate prices for each model's
> > unique batteries, but that's a different issue.)
> 
> You commonly run a laptop off battery while having a printer plugged in?

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

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

[Matthew Garrett]

On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > Popping up a box saying "Is your device broken?" isn't good UI. 
> 
> 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.

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.

> > No. But given a choice between working hardware or marginally better 
> > runtime PM, they're going to choose working hardware.
> 
> 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 ...

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.

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

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

> > I'm speaking as part of the Ubuntu kernel team, and I've been discussing 
> > this with Fedora people.
> 
> 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...)

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

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

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

> > You commonly run a laptop off battery while having a printer plugged in?
> 
> 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...)

System/Preferences/Power Management

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

It can be, but I'd prefer to have userspace enable functionality than 
have the kernel break things.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Oliver Neukum]

Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > 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.
> 
> 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.

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

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

[Alan Stern]

On Fri, 3 Aug 2007, Oliver Neukum wrote:

> Devices rarely simply crash.

It's rare, but it does happen.  I've seen a device get so messed up by 
suspend that it needed a reset; it wouldn't be surprising to find other 
devices requiring a power cycle.

Alan Stern

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

[Dave Jones]

On Fri, Aug 03, 2007 at 06:08:11PM +0200, Oliver Neukum wrote:
 > Am Freitag 03 August 2007 schrieb Matthew Garrett:
 > > > 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.
 > > 
 > > 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.
 > 
 > 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.

The printer I mentioned earlier this thread wouldn't work again
until I physically unplugged and replugged the usb cable.
It spewed descriptor read errors every time I tried to talk to it.
Even unloading and reloading the usb modules didn't bring it back
to life.

	Dave

-- 
http://www.codemonkey.org.uk

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

[David Brownell]

On Friday 03 August 2007, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
> > On Friday 03 August 2007, Matthew Garrett wrote:
> > > Popping up a box saying "Is your device broken?" isn't good UI. 
> > 
> > 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.
> 
> But however you phrase it, that's effectively what it is.

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.


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

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.


> > 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.)
> 
> Users understand CDs. They don't understand runtime power management.

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


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

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.


> > > You commonly run a laptop off battery while having a printer plugged in?
> > 
> > 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...)
> 
> System/Preferences/Power Management

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.


> > 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.
> 
> It can be, but I'd prefer to have userspace enable functionality than 
> have the kernel break things.

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

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

[Matthew Garrett]

On Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > And, frankly, if I got a requestor like that every time I plugged in a 
> > new USB device I'd be fairly unhappy.
> 
> 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.

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)

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

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.

> > System/Preferences/Power Management
> 
> 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's odd. In the "On battery power" tab I see an option to choose the 
action when the battery power is critically low.

> > It can be, but I'd prefer to have userspace enable functionality than 
> > have the kernel break things.
> 
> 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...

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 | mjg59@srcf.ucam.org

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

[Greg KH]

On Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:
> On Friday 03 August 2007, Matthew Garrett wrote:
> > > 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.
> > 
> > "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)
> 
> 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.

Hm, if you look at SuSE and Fedora, they too are putting usbfs in
/dev/bus/usb/ now, not mounting the filesystem, but using the device
nodes for access due to ACLs for local users.

libusb works just fine with this, and I think that all other programs
that directly access the old /proc/bus/usb mount are fixed up, with the
exception of usbview (but I do have patches floating around for that to
solve it.)

thanks,

greg k-h

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Greg KH]

On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
> 
> > Compare that to:
> > 
> > "My USB printer broke, guess I'd better report it to LKML".
> 
> But while this is still a likely probability, the chances are no 
> distribution is going to ship with CONFIG_USB_SUSPEND enabled.

I wouldn't be so sure, I was thinking of doing just that based on an
internal conversation I had yesterday.

Let's see what breaks and what happens :)

thanks,

greg k-h

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Matthew Garrett]

On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
> On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
> > But while this is still a likely probability, the chances are no 
> > distribution is going to ship with CONFIG_USB_SUSPEND enabled.
> 
> I wouldn't be so sure, I was thinking of doing just that based on an
> internal conversation I had yesterday.

Well, we did - with hindsight it may not have been such a great plan :) 
I believe that Fedora did as well, but have disabled it in an update 
kernel.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Chuck Ebbert]

On 08/03/2007 01:48 PM, Matthew Garrett wrote:
> On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
>> On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
>>> But while this is still a likely probability, the chances are no 
>>> distribution is going to ship with CONFIG_USB_SUSPEND enabled.
>> I wouldn't be so sure, I was thinking of doing just that based on an
>> internal conversation I had yesterday.
> 
> Well, we did - with hindsight it may not have been such a great plan :) 
> I believe that Fedora did as well, but have disabled it in an update 
> kernel.

Yeah, autosuspend broke too many devices. Way too many.

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Pete Zaitcev]

On Fri, 03 Aug 2007 15:29:21 -0400, Chuck Ebbert <cebbert@redhat.com> wrote:

> > Well, we did - with hindsight it may not have been such a great plan :) 
> > I believe that Fedora did as well, but have disabled it in an update 
> > kernel.
> 
> Yeah, autosuspend broke too many devices. Way too many.

Glad you chimed in, Chuck. I was wondering about it... I saw something
like 3 reports about broken printers, two of them for the same printer,
Samsung ML-2010. It's on the installed base of 300,000 to 500,000.
People simply do not report squat. Today DaveJ said that none of his
printers work, which sounds bad, and was news to me. But the point is,
we are trying to extrapolate from too few cases.

I am wondering if Ubuntu has better user reporting, so if Matthew
complains, it really means something.

-- Pete

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Amit Kucheria]

On 8/3/07, Pete Zaitcev <zaitcev@redhat.com> wrote:

> I am wondering if Ubuntu has better user reporting, so if Matthew
> complains, it really means something.

https://bugs.launchpad.net/bugs/85488

Most of the current quirks list was assembled by Oliver from this thread IIRC.

/Amit

--
Amit Kucheria, Linux developer

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

[Dave Jones]

On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
 > On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
 > > On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
 > > 
 > > > Compare that to:
 > > > 
 > > > "My USB printer broke, guess I'd better report it to LKML".
 > > 
 > > But while this is still a likely probability, the chances are no 
 > > distribution is going to ship with CONFIG_USB_SUSPEND enabled.
 > 
 > I wouldn't be so sure, I was thinking of doing just that based on an
 > internal conversation I had yesterday.
 > 
 > Let's see what breaks and what happens :)

here's a head start for you.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359

That's just the ones that were handy..

	Dave

-- 
http://www.codemonkey.org.uk

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

[Alan Stern]

On Fri, 3 Aug 2007, Dave Jones wrote:

> here's a head start for you.
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359
> 
> That's just the ones that were handy..

The last report appears to be related more to the EHCI-cpufreq problem, 
for which a patch was recently posted.

Alan Stern

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

[Dave Jones]

On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote:
 > On Fri, 3 Aug 2007, Dave Jones wrote:
 > 
 > > here's a head start for you.
 > > 
 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953
 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359
 > > 
 > > That's just the ones that were handy..
 > 
 > The last report appears to be related more to the EHCI-cpufreq problem, 
 > for which a patch was recently posted.

I was a bit iffy about including that one, but decided to because
some of the reporters noted that the problem 'went away' after
we pushed out a kernel disabling usb suspend by default.
See comments 16 & 17.

Clearly not the problem everyone was seeing, but it looks like
a few people piled on one bug with the same symptom from multiple
problems.

	Dave

-- 
http://www.codemonkey.org.uk

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

[Matthew Garrett]

On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote:

> The last report appears to be related more to the EHCI-cpufreq problem, 
> for which a patch was recently posted.

There seem to be multiple issues there, with at least one of them being 
autosuspend related.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Felipe Balbi]

On 8/3/07, Rogan Dawes <lists@dawes.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@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>


-- 
Best Regards,

Felipe Balbi
felipebalbi@users.sourceforge.net

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

[David Brownell]

On Thursday 02 August 2007, Matthew Garrett wrote:
> The main 
> concern I have is that kernel developers just don't tend to be the sort 
> of people that use webcams, printers or scanners, so we're relying on 
> normal users to go to the effort of reporting that their device has 
> stopped working.

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

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

[Dave Jones]

On Thu, Aug 02, 2007 at 11:06:08PM -0700, David Brownell wrote:
 
 > 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?

Not everyone who uses USB devices uses X.
It's a bit difficult to pop up a "unscrew my printer" dialog when you're
on the console.

	Dave

-- 
http://www.codemonkey.org.uk

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

[David Brownell]

On Friday 03 August 2007, Dave Jones wrote:
> On Thu, Aug 02, 2007 at 11:06:08PM -0700, David Brownell wrote:
>  
>  > 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) for 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?
> 
> Not everyone who uses USB devices uses X.

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


> It's a bit difficult to pop up a "unscrew my printer" dialog when you're
> on the console.

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

- Dave

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

[Oliver Neukum]

Am Freitag 03 August 2007 schrieb Matthew Garrett:
> > Also, we have udev rules for SANE that disables their autosuspend
> > settings, which handles the majority of the devices we have seen with
> > problems.
> 
> Several printers seem to have the issue as well, and the blacklist seems 
> to contain some odd miscellaneous devices like the Blackberry. The main

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.

> concern I have is that kernel developers just don't tend to be the sort 
> of people that use webcams, printers or scanners, so we're relying on 
> normal users to go to the effort of reporting that their device has 
> stopped working.

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

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

[Dave Jones]

On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
 
 > 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.

My experience suggests the opposite.  Of the several I've tried so far,
none have worked with usb suspend.

	Dave

-- 
http://www.codemonkey.org.uk

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

[Oliver Neukum]

Am Freitag 03 August 2007 schrieb Dave Jones:
> On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
>  
>  > 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.
> 
> My experience suggests the opposite.  Of the several I've tried so far,
> none have worked with usb suspend.

vendor:product please.

In addition, I'll make a config option for usblp using autosuspend.

	Regards
		Oliver

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

[Dave Jones]

On Fri, Aug 03, 2007 at 04:32:07PM +0200, Oliver Neukum wrote:
 > Am Freitag 03 August 2007 schrieb Dave Jones:
 > > On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
 > >  
 > >  > 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.
 > > 
 > > My experience suggests the opposite.  Of the several I've tried so far,
 > > none have worked with usb suspend.
 > 
 > vendor:product please.

Here's one that I have handy..
Bus 002 Device 004: ID 04a9:1097 Canon, Inc. 

(The others aren't powered on right now, and I'm remote from them ;-)

	Dave

-- 
http://www.codemonkey.org.uk

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

[Pete Zaitcev]

On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones <davej@redhat.com> wrote:
> On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
>  
>  > 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.
> 
> My experience suggests the opposite.  Of the several I've tried so far,
> none have worked with usb suspend.

All of mine work. I'm wondering if this has something to do with
a hub or motherboard... How should we test it? Tried plugging elsewhere?

-- Pete

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

[Dave Jones]

On Fri, Aug 03, 2007 at 12:34:47PM -0700, Pete Zaitcev wrote:
 > On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones <davej@redhat.com> wrote:
 > > On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
 > >  
 > >  > 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.
 > > 
 > > My experience suggests the opposite.  Of the several I've tried so far,
 > > none have worked with usb suspend.
 > 
 > All of mine work. I'm wondering if this has something to do with
 > a hub or motherboard... How should we test it? Tried plugging elsewhere?

no hubs involved, directly plugged them into the mainboard.
Fairly recent Intel chipsets on all the systems I tested.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

[Pete Zaitcev]

On Fri, 3 Aug 2007 15:45:32 -0400, Dave Jones <davej@redhat.com> wrote:

>  > > My experience suggests the opposite.  Of the several I've tried so far,
>  > > none have worked with usb suspend.
>  > 
>  > All of mine work. I'm wondering if this has something to do with
>  > a hub or motherboard... How should we test it? Tried plugging elsewhere?
> 
> no hubs involved, directly plugged them into the mainboard.
> Fairly recent Intel chipsets on all the systems I tested.

Sounds bad.

BTW, when I took over from Vojtech, I looked at the suspend methods
for the printer and it seemed possible that they can only work
if the device is not open when suspend occurs. I was going to look
at that at the first opportunity.

So, I'd rather keep at least some kind of capability to suspend
printers, even if disabled by default. I thought Matthew's patch
was too harsh.

-- Pete