[lkml]   [2007]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6
On Thu, Sep 13, 2007 at 11:20:42AM -0400, Alan Stern wrote:
> On Thu, 13 Sep 2007, Adrian Bunk wrote:
> > > These two patches address the need today to have users machines still
> > > work, even if they might draw more power than they possibly could (which
> > > is not any more than they did in 2.6.22.)
> > >
> > > These patches do two things:
> > > - disable USB autosuspend on all devices except for USB hubs. This
> > > can be easily overridden by userspace to turn on autosuspend for
> > > devices that a user wants to. HAL will use a whitelist in the
> > > future for these types of devices.
> > >...
> >
> > Not related to the patch for 2.6.23, but I have a gut feeling that
> > something might be done the wrong way later:
> >
> > If I understand you correctly, you are saying that I will have to
> > install HAL for getting a whitelist for in-kernel functionality?
> Your meaning isn't entirely clear. Presumably HAL will contain such a
> whitelist. But there's nothing to stop you from setting up your own
> whitelist via udev scripts, or even turning autosuspend on or off by
> hand.
> > It is a good thing if userspace can add currently missing devices to
> > whitelists, but the whitelist itself should be in the kernel.
> It's not clear that this sort of approach will turn out to be workable.
> Whitelists/blacklists do okay in the kernel when they refer to a
> relatively small subset of devices. However in this case I have the
> impression that we're talking about roughly a 50/50 split. Keeping an
> in-kernel list with even 10% of all existing USB devices simply isn't
> feasible.

What about this is not feasible?

The amount of work for maintaining the list is the same:

No matter whether it's in-kernel or in the userspace, you need a list of
working devices in some machine readable format.

Whether this gets used by the kernel, by userspace, or both, shouldn't
make any difference.

Kernel image size can be a problem in some cases, but an in-kernel list
doesn't have to be mandatory but could be made selectable in kconfig.

> Besides, is it really that much harder for userspace to modify device
> settings as the devices are detected than for it to modify an in-kernel
> whitelist just once? Don't forget about possible races: Devices may
> already have been detected and configured before userspace was able to
> modify the whitelist.

Above you said "there's nothing to stop you from ... even turning
autosuspend on or off by hand".

If this will already be supported race-free, which races will still be

> Alan Stern



"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-09-13 17:43    [W:0.252 / U:1.664 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site