USB devices fail unnecessarily on unpowered hubs

USB devices fail unnecessarily on unpowered hubs

[David Liontooth]

Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
hubs. Alan Stern explains,

"The idea is that the kernel now keeps track of USB power budgets.  When a 
bus-powered device requires more current than its upstream hub is capable 
of providing, the kernel will not configure it.

Computers' USB ports are capable of providing a full 500 mA, so devices
plugged directly into the computer will work okay.  However unpowered hubs
can provide only 100 mA to each port.  Some devices require (or claim they
require) more current than that.  As a result, they don't get configured
when plugged into an unpowered hub."

http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html

This is generating a lot of grief and appears to be unnecessarily
strict. Common USB sticks with a MaxPower value just above 100mA, for
instance, typically work fine on unpowered hubs supplying 100mA.

Is a more user-friendly solution possible? Could the shortfall
information be passed to udev, which would allow rules to be written per
device?

David

Re: USB devices fail unnecessarily on unpowered hubs

[Pavel Machek]

Hi!

> Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
> hubs. Alan Stern explains,
> 
> "The idea is that the kernel now keeps track of USB power budgets.  When a 
> bus-powered device requires more current than its upstream hub is capable 
> of providing, the kernel will not configure it.
> 
> Computers' USB ports are capable of providing a full 500 mA, so devices
> plugged directly into the computer will work okay.  However unpowered hubs
> can provide only 100 mA to each port.  Some devices require (or claim they
> require) more current than that.  As a result, they don't get configured
> when plugged into an unpowered hub."

Actually I have exactly opposite problem: my computer (spitz) can't
supply full 500mA on its root hub, and linux tries to power up
'hungry' devices, anyway, leading to very weird behaviour.

-- 
Thanks for all the (sleeping) penguins.

Re: USB devices fail unnecessarily on unpowered hubs

[Oliver Neukum]

Am Dienstag, 30. Mai 2006 22:01 schrieb Pavel Machek:
> Hi!
> 
> > Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
> > hubs. Alan Stern explains,
> > 
> > "The idea is that the kernel now keeps track of USB power budgets.  When a 
> > bus-powered device requires more current than its upstream hub is capable 
> > of providing, the kernel will not configure it.
> > 
> > Computers' USB ports are capable of providing a full 500 mA, so devices
> > plugged directly into the computer will work okay.  However unpowered hubs
> > can provide only 100 mA to each port.  Some devices require (or claim they
> > require) more current than that.  As a result, they don't get configured
> > when plugged into an unpowered hub."
> 
> Actually I have exactly opposite problem: my computer (spitz) can't
> supply full 500mA on its root hub, and linux tries to power up
> 'hungry' devices, anyway, leading to very weird behaviour.


You could lower the obvious values in this code from drivers/usb/core/hub.c

	if (hdev == hdev->bus->root_hub) {
		if (hdev->bus_mA == 0 || hdev->bus_mA >= 500)
			hub->mA_per_port = 500;
		else {
			hub->mA_per_port = hdev->bus_mA;
			hub->limited_power = 1;
		}

If that does the job we need to somehow inherit the power supply maximum from
PCI when we allocate the root hub's device structure.

	Regards
		Oliver

Re: [linux-usb-devel] USB devices fail unnecessarily on unpowered hubs

[David Brownell]

On Saturday 03 June 2006 2:29 am, Oliver Neukum wrote:
> Am Dienstag, 30. Mai 2006 22:01 schrieb Pavel Machek:

> > Actually I have exactly opposite problem: my computer (spitz) can't
> > supply full 500mA on its root hub, and linux tries to power up
> > 'hungry' devices, anyway, leading to very weird behaviour.
> 
> 
> You could lower the obvious values in this code from drivers/usb/core/hub.c
> 
> 	if (hdev == hdev->bus->root_hub) {
> 		if (hdev->bus_mA == 0 || hdev->bus_mA >= 500)
> 			hub->mA_per_port = 500;
> 		else {
> 			hub->mA_per_port = hdev->bus_mA;
> 			hub->limited_power = 1;
> 		}
> 
> If that does the job we need to somehow inherit the power supply maximum from
> PCI when we allocate the root hub's device structure.

I don't think there is such a convention that's generic for PCI.  There might
be ACPI-specific tables holding that value, but on embedded hardware the model
is often that the arch/.../board-ZZZ.c file just "knows" things like how much
power the regulator powering that port can provide, and arranges bus_mA to match.
Just like it knows all sorts of other details about how that board works.

- Dave

Re: [linux-usb-devel] USB devices fail unnecessarily on unpowered hubs

[Oliver Neukum]

Am Montag, 5. Juni 2006 16:32 schrieb David Brownell:
> On Saturday 03 June 2006 2:29 am, Oliver Neukum wrote:

> > If that does the job we need to somehow inherit the power supply maximum from
> > PCI when we allocate the root hub's device structure.
> 
> I don't think there is such a convention that's generic for PCI.  There might
> be ACPI-specific tables holding that value, but on embedded hardware the model
> is often that the arch/.../board-ZZZ.c file just "knows" things like how much
> power the regulator powering that port can provide, and arranges bus_mA to match.
> Just like it knows all sorts of other details about how that board works.

Yes, I am afraid it cannot be done on the fly. But we might use a symbolic
define which a subarch can override instead of a literal "500".
If it turns out that this problem is one of power and not some other
deficiency of this system's root hub.

	Regards
		Oliver

Re: [linux-usb-devel] USB devices fail unnecessarily on unpowered hubs

[Pavel Machek]

Hi!

> > > If that does the job we need to somehow inherit the power supply maximum from
> > > PCI when we allocate the root hub's device structure.
> > 
> > I don't think there is such a convention that's generic for PCI.  There might
> > be ACPI-specific tables holding that value, but on embedded hardware the model
> > is often that the arch/.../board-ZZZ.c file just "knows" things like how much
> > power the regulator powering that port can provide, and arranges bus_mA to match.
> > Just like it knows all sorts of other details about how that board works.
> 
> Yes, I am afraid it cannot be done on the fly. But we might use a symbolic
> define which a subarch can override instead of a literal "500".
> If it turns out that this problem is one of power and not some other
> deficiency of this system's root hub.

That's bad... because we don't know exact model until runtime (ARM
tries to support many machines with single binary kernel, AFAICS), and
this is very likely going to be model-dependend.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] limit power budget on spitz

[Pavel Machek]

This limits power budget on spitz to 250mA. I'm not sure if it is the
right value, but it is certainly better than default 500mA, and
prevents nasty failure mode with zd1201.

Signed-off-by: Pavel Machek <pavel@suse.cz>

PATCH FOLLOWS
KernelVersion: 2.6.17-rc6-git

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index acde886..1d8b58c 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
 	/* Select Power Management Mode */
 	pxa27x_ohci_select_pmm(inf->port_mode);
 
+	if (machine_is_spitz()) {
+		/* Warning, not coming from any official docs. But
+		 * spitz is unable to properly power wireless card
+		 * claiming 500mA -- usb interface work but wireless
+		 * does not. */
+		hcd->power_budget = 250;
+	}
 	ohci_hcd_init(hcd_to_ohci(hcd));
 
 	retval = usb_add_hcd(hcd, pdev->resource[1].start, SA_INTERRUPT);

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] limit power budget on spitz

[Richard Purdie]

On Thu, 2006-06-08 at 10:34 +0200, Pavel Machek wrote:
> diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> index acde886..1d8b58c 100644
> --- a/drivers/usb/host/ohci-pxa27x.c
> +++ b/drivers/usb/host/ohci-pxa27x.c
> @@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
>  	/* Select Power Management Mode */
>  	pxa27x_ohci_select_pmm(inf->port_mode);
>  
> +	if (machine_is_spitz()) {
> +		/* Warning, not coming from any official docs. But
> +		 * spitz is unable to properly power wireless card
> +		 * claiming 500mA -- usb interface work but wireless
> +		 * does not. */
> +		hcd->power_budget = 250;
> +	}
>  	ohci_hcd_init(hcd_to_ohci(hcd));
>  
>  	retval = usb_add_hcd(hcd, pdev->resource[1].start, SA_INTERRUPT);

Should this value not be specified by the platform in the platform data
rather than a set of machine_is_xxx statements in the driver itself? I
already put most of the infrastructure for that into place.

I also strongly suspect the power supply on the device is limited to
150mA.

Richard

Re: [PATCH] limit power budget on spitz

[Pavel Machek]

Hi!

> > diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> > index acde886..1d8b58c 100644
> > --- a/drivers/usb/host/ohci-pxa27x.c
> > +++ b/drivers/usb/host/ohci-pxa27x.c
> > @@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
> >  	/* Select Power Management Mode */
> >  	pxa27x_ohci_select_pmm(inf->port_mode);
> >  
> > +	if (machine_is_spitz()) {
> > +		/* Warning, not coming from any official docs. But
> > +		 * spitz is unable to properly power wireless card
> > +		 * claiming 500mA -- usb interface work but wireless
> > +		 * does not. */
> > +		hcd->power_budget = 250;
> > +	}
> >  	ohci_hcd_init(hcd_to_ohci(hcd));
> >  
> >  	retval = usb_add_hcd(hcd, pdev->resource[1].start, SA_INTERRUPT);
> 
> Should this value not be specified by the platform in the platform data
> rather than a set of machine_is_xxx statements in the driver itself? I
> already put most of the infrastructure for that into place.

Well, it has quite few users now, and this is how it works in
ohci-omap. Yes, if we get more of such hooks, it probably needs to be
moved to platform data...

> I also strongly suspect the power supply on the device is limited to
> 150mA.

Thanks!
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] limit power budget on spitz

[Richard Purdie]

Hi,

On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
> > > +	if (machine_is_spitz()) {
> > > +		/* Warning, not coming from any official docs. But
> > > +		 * spitz is unable to properly power wireless card
> > > +		 * claiming 500mA -- usb interface work but wireless
> > > +		 * does not. */
> > > +		hcd->power_budget = 250;
> > > +	}
> >
> > 
> > Should this value not be specified by the platform in the platform data
> > rather than a set of machine_is_xxx statements in the driver itself? I
> > already put most of the infrastructure for that into place.
> 
> Well, it has quite few users now, and this is how it works in
> ohci-omap. Yes, if we get more of such hooks, it probably needs to be
> moved to platform data...

Just because the omap does it that way, doesn't mean it can't be done
better ;-). I've also just realised the above doesn't account for akita
or borzoi. Since the hardware is identical in this area, the same
changes should be applied for those machines. If we use the platform
device/data approach, we don't have this problem as they all use the
same platform device :)

I can't create a patch at the moment but I can have a look at this
later...

Cheers,

Richard

Re: [PATCH] limit power budget on spitz

[Russell King]

On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
> Hi,
> 
> On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
> > > > +	if (machine_is_spitz()) {
> > > > +		/* Warning, not coming from any official docs. But
> > > > +		 * spitz is unable to properly power wireless card
> > > > +		 * claiming 500mA -- usb interface work but wireless
> > > > +		 * does not. */
> > > > +		hcd->power_budget = 250;
> > > > +	}
> > >
> > > 
> > > Should this value not be specified by the platform in the platform data
> > > rather than a set of machine_is_xxx statements in the driver itself? I
> > > already put most of the infrastructure for that into place.
> > 
> > Well, it has quite few users now, and this is how it works in
> > ohci-omap. Yes, if we get more of such hooks, it probably needs to be
> > moved to platform data...
> 
> Just because the omap does it that way, doesn't mean it can't be done
> better ;-). I've also just realised the above doesn't account for akita
> or borzoi. Since the hardware is identical in this area, the same
> changes should be applied for those machines. If we use the platform
> device/data approach, we don't have this problem as they all use the
> same platform device :)

So what do folk want me to do?  Blindly merge the patch (hint: it's still
in the incoming queue...)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [PATCH] limit power budget on spitz

[David Brownell]

On Thursday 08 June 2006 10:09 am, Russell King wrote:
> On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
> > Hi,
> > 
> > On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
> > > > > +	if (machine_is_spitz()) {
> > > > > +		/* Warning, not coming from any official docs. But
> > > > > +		 * spitz is unable to properly power wireless card
> > > > > +		 * claiming 500mA -- usb interface work but wireless
> > > > > +		 * does not. */
> > > > > +		hcd->power_budget = 250;
> > > > > +	}
> > > >
> > > > 
> > > > Should this value not be specified by the platform in the platform data
> > > > rather than a set of machine_is_xxx statements in the driver itself? I
> > > > already put most of the infrastructure for that into place.
> > > 
> > > Well, it has quite few users now, and this is how it works in
> > > ohci-omap. Yes, if we get more of such hooks, it probably needs to be
> > > moved to platform data...
> > 
> > Just because the omap does it that way, doesn't mean it can't be done
> > better ;-).

Agreed that platform_data is a better approach overall for holding that
power budget.  OMAP and AT91 should do so too.


> > I've also just realised the above doesn't account for akita 
> > or borzoi. Since the hardware is identical in this area, the same
> > changes should be applied for those machines. If we use the platform
> > device/data approach, we don't have this problem as they all use the
> > same platform device :)
> 
> So what do folk want me to do?  Blindly merge the patch (hint: it's still
> in the incoming queue...)

Sounds like someone should update the patch to (a) use a 150 mA budget,
and (b) test for those other machines.  As a near term patch, anyway.

Unless there's a patch to provide and use platform_data ... but that'd
be much more involved, since ISTR the PXA platforms don't yet have a
mechanism to provide board-specific platform_data.  (I'll suggest the
AT91 code as a model there; it's simpler hardware than OMAP, so the
code is more straightforward.)

- Dave

Re: [PATCH] limit power budget on spitz

[Richard Purdie]

On Thu, 2006-06-08 at 11:26 -0700, David Brownell wrote:
> On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
> > Just because the omap does it that way, doesn't mean it can't be done
> > better ;-).
> 
> Agreed that platform_data is a better approach overall for holding that
> power budget.  OMAP and AT91 should do so too.
>
> Sounds like someone should update the patch to (a) use a 150 mA budget,
> and (b) test for those other machines.  As a near term patch, anyway.
> 
> Unless there's a patch to provide and use platform_data ... but that'd
> be much more involved, since ISTR the PXA platforms don't yet have a
> mechanism to provide board-specific platform_data.  (I'll suggest the
> AT91 code as a model there; it's simpler hardware than OMAP, so the
> code is more straightforward.)

The PXA platform does have an existing mechanism to pass platform data
(I added it a while back). I've added
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
into the patch system replacing Pavel's version.

Cheers,

Richard

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[David Brownell]

> The PXA platform does have an existing mechanism to pass platform data
> (I added it a while back). I've added
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
> into the patch system replacing Pavel's version.

OK, I see now.  Simple enough, better than the original.  Go for it.

There was a PXA issue I was alluding to that's still open, though.
It's the way there's no selectivity about what platform devices are
registered ... even kernels running on boards where OHCI isn't hooked
up to anything will be registering an OHCI controller, as one of many
examples.  Won't affect this particular case, but in general that'd
be nice to see fixed.

- Dave

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[Richard Purdie]

On Thu, 2006-06-08 at 13:38 -0700, David Brownell wrote: 
> > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
> 
> OK, I see now.  Simple enough, better than the original.  Go for it.
> 
> There was a PXA issue I was alluding to that's still open, though.
> It's the way there's no selectivity about what platform devices are
> registered ... even kernels running on boards where OHCI isn't hooked
> up to anything will be registering an OHCI controller, as one of many
> examples.  Won't affect this particular case, but in general that'd
> be nice to see fixed.

As I understood the code, if you don't have platform_data set, it will
abort in the probe function so it depends what you mean by register. An
OHCI controller never gets created without platform_data.

You're right that the PXA platform device is always registered. FWIW,
there is no platform in mainline that doesn't have OHCI present so this
isn't a major problem at the moment.

The easiest solution might be to move the ohci device registration into
pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile
tested only so far).

Cheers,

Richard


Only register the PXA OHCI platform device on platforms which provide
the platform data.

Signed-off-by: Richard Purdie <rpurdie@rpsys.net>

Index: git/arch/arm/mach-pxa/pxa27x.c
===================================================================
--- git.orig/arch/arm/mach-pxa/pxa27x.c	2006-06-08 20:50:15.000000000 +0100
+++ git/arch/arm/mach-pxa/pxa27x.c	2006-06-08 22:08:49.000000000 +0100
@@ -200,15 +200,5 @@
 void __init pxa_set_ohci_info(struct pxaohci_platform_data *info)
 {
 	ohci_device.dev.platform_data = info;
+	platform_device_register(&ohci_device);
 }
-
-static struct platform_device *devices[] __initdata = {
-	&ohci_device,
-};
-
-static int __init pxa27x_init(void)
-{
-	return platform_add_devices(devices, ARRAY_SIZE(devices));
-}
-
-subsys_initcall(pxa27x_init);

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[David Brownell]

On Thursday 08 June 2006 2:22 pm, Richard Purdie wrote:
> On Thu, 2006-06-08 at 13:38 -0700, David Brownell wrote: 
> > > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
> > 
> > OK, I see now.  Simple enough, better than the original.  Go for it.
> > 
> > There was a PXA issue I was alluding to that's still open, though.
> > It's the way there's no selectivity about what platform devices are
> > registered ... even kernels running on boards where OHCI isn't hooked
> > up to anything will be registering an OHCI controller, as one of many
> > examples.  Won't affect this particular case, but in general that'd
> > be nice to see fixed.
> 
> As I understood the code, if you don't have platform_data set, it will
> abort in the probe function so it depends what you mean by register. An
> OHCI controller never gets created without platform_data.
> 
> You're right that the PXA platform device is always registered. FWIW,
> there is no platform in mainline that doesn't have OHCI present so this
> isn't a major problem at the moment.

Right.  OHCI was just an example though ... there are lots of other
platform drivers for PXA.  I'm not sure they all check for platform_data
before succeeding in their probe() methods.


> The easiest solution might be to move the ohci device registration into
> pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile
> tested only so far).

Looked OK to me.

That's the kind of approach now used with OMAP and AT91, and which IMO
would be appropriate to use for most platform devices ... that is, don't
register devices that the board doesn't have.  One additional nuance:  if
the kernel doesn't have that driver configured, that's another reason not
to bother registering its device.

- Dave

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[Richard Purdie]

On Thu, 2006-06-08 at 14:40 -0700, David Brownell wrote:
> Right.  OHCI was just an example though ... there are lots of other
> platform drivers for PXA.  I'm not sure they all check for platform_data
> before succeeding in their probe() methods.

The implementations in mainline generally use all the bits or they'd
have been fixed by now so its not really a problem. I'm sure Russell
would take patches :)

> > The easiest solution might be to move the ohci device registration into
> > pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile
> > tested only so far).
> 
> Looked OK to me.
> 
> That's the kind of approach now used with OMAP and AT91, and which IMO
> would be appropriate to use for most platform devices ... that is, don't
> register devices that the board doesn't have.  One additional nuance:  if
> the kernel doesn't have that driver configured, that's another reason not
> to bother registering its device.

This is where you start to add ugly ifdefs and generally start making
the code look horrible. The device model separated the drivers and the
devices to deal with this issue as I see it. Generally I'd say its
cleaner just to let the device register, then if a module comes along at
some later point, the device is there for it.

Cheers,

Richard

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[David Brownell]

On Thursday 08 June 2006 2:49 pm, Richard Purdie wrote:
> 
> > > The easiest solution might be to move the ohci device registration into
> > > pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile
> > > tested only so far).
> > 
> > Looked OK to me.
> > 
> > That's the kind of approach now used with OMAP and AT91, and which IMO
> > would be appropriate to use for most platform devices ... that is, don't
> > register devices that the board doesn't have.  One additional nuance:  if
> > the kernel doesn't have that driver configured, that's another reason not
> > to bother registering its device.
> 
> This is where you start to add ugly ifdefs and generally start making
> the code look horrible. The device model separated the drivers and the
> devices to deal with this issue as I see it. 

Enumeration is a separate issue.  You wouldn't argue that every potential
PCI or USB device must get registered, right?  Only the ones that are
actually _present_ get registered.

But here you argue that platform bus should not work that same way ... it
should register devices that can't be present.  If nothing else, that's
an inconsistent aproach.

Plus, consider the common situation that a given pin could potentially
be used with several different devices.  On a given board, only one of
those devices will be wired up.  It's counterproductive to register any
of the others ... error prone, waste-of-kernel-address-space, etc.


> Generally I'd say its 
> cleaner just to let the device register, then if a module comes along at
> some later point, the device is there for it.

Whether the device is there or not is a hardware issue.  Board schematics
will show which devices are relevant ... registering any others is just
wastage.  "Clean" is somewhat in the eye of the beholder; in mine, wasting
system resources is not clean.

- Dave

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[Nicolas Pitre]

On Thu, 8 Jun 2006, David Brownell wrote:

> On Thursday 08 June 2006 2:49 pm, Richard Purdie wrote:
> > 
> > > One additional nuance:  if
> > > the kernel doesn't have that driver configured, that's another reason not
> > > to bother registering its device.
> > 
> > This is where you start to add ugly ifdefs and generally start making
> > the code look horrible. The device model separated the drivers and the
> > devices to deal with this issue as I see it. 
> 
> Enumeration is a separate issue.  You wouldn't argue that every potential
> PCI or USB device must get registered, right?  Only the ones that are
> actually _present_ get registered.

You are both saying the same thing so far.

> But here you argue that platform bus should not work that same way ... it
> should register devices that can't be present.  If nothing else, that's
> an inconsistent aproach.

That's not what Richard is saying.

He replied to your assertion where you said: "if the kernel doesn't have 
that driver configured, that's another reason not to bother registering 
its device" to which he disagreed, and I disagree too.

> Plus, consider the common situation that a given pin could potentially
> be used with several different devices.  On a given board, only one of
> those devices will be wired up.  It's counterproductive to register any
> of the others ... error prone, waste-of-kernel-address-space, etc.

No one disagreed with that AFAICS.

> > Generally I'd say its 
> > cleaner just to let the device register, then if a module comes along at
> > some later point, the device is there for it.
> 
> Whether the device is there or not is a hardware issue.  Board schematics
> will show which devices are relevant ... registering any others is just
> wastage.

But you originally talked about _driver_ configuration dictating if a 
_device_ should be registered or not.

The _device_ should indeed be registered based on _hardware_ config, not 
_driver_ config.


Nicolas

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[David Brownell]

On Thursday 08 June 2006 6:25 pm, Nicolas Pitre wrote:
> 
> You are both saying the same thing so far.

Hey, violent agreement is half the fun!  :)


> > But here you argue that platform bus should not work that same way ... it
> > should register devices that can't be present.  If nothing else, that's
> > an inconsistent aproach.
> 
> That's not what Richard is saying.
> 
> He replied to your assertion where you said: "if the kernel doesn't have 
> that driver configured, that's another reason not to bother registering 
> its device" to which he disagreed, and I disagree too.

I see your point.  Yes, this is arguable ... there are multiple principles
that can be traded off against each other.


For example, "by default, make design choices that save memory" (what I was
using) versus:

> The _device_ should indeed be registered based on _hardware_ config, not 
> _driver_ config.

For a kernel without CONFIG_MODULES, that's pure wasted space.  Why bother?
Those are devices that "can't be present", so that's one of the cases where
that "ignore the driver config" policy will indeed register such devices.

Similarly, when the driver's not yet written, it can make trouble to try
sticking its config into the device tree ... it's very easy to get wrong!


It's clear to me there are some cases where software config will reasonably
be a subset of the hardware config.  Likewise, that memory usage should be
one of the factors considered when making design tradeoffs.

- Dave

Re: [linux-usb-devel] [PATCH] limit power budget on spitz

[Nicolas Pitre]

On Thu, 8 Jun 2006, David Brownell wrote:

> On Thursday 08 June 2006 6:25 pm, Nicolas Pitre wrote:
> > He replied to your assertion where you said: "if the kernel doesn't have 
> > that driver configured, that's another reason not to bother registering 
> > its device" to which he disagreed, and I disagree too.
> 
> I see your point.  Yes, this is arguable ... there are multiple principles
> that can be traded off against each other.
> 
> For example, "by default, make design choices that save memory" (what I was
> using) versus:
> 
> > The _device_ should indeed be registered based on _hardware_ config, not 
> > _driver_ config.
> 
> For a kernel without CONFIG_MODULES, that's pure wasted space.  Why bother?
> Those are devices that "can't be present", so that's one of the cases where
> that "ignore the driver config" policy will indeed register such devices.

But constrained hardware designs for which memory usage is important 
that have the device available are likely to make use of that device 
anyway.  So in those cases it is pretty unlikely that the kernel config 
won't include the corresponding driver.

The case where the hardware does support a device but someone decided 
not to use it may have its kernel config exclude the corresponding 
driver.  But since this is most probably not the common case I don't 
think we should go as far as uglifying the code with conditional device 
registrations based on #if !defined(CONFIG_MODULE) && !defined(CONFIG_FOO)
just for the sake of saving as many bytes as possible.  That someone may 
as well comment out that device registration in his own source tree 
himself.

It is more likely that some hardware design that is not 
expected to use a particular device will simply not register that device 
in the first place and its default kernel config won't have the driver 
selected either.  In that sense I think Richard's patch is all that is 
needed for mainline.


Nicolas

Re: USB devices fail unnecessarily on unpowered hubs

[Andrew Morton]

On Thu, 01 Jun 2006 02:18:20 -0700
David Liontooth <liontooth@cogweb.net> wrote:

> Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
> hubs. Alan Stern explains,
> 
> "The idea is that the kernel now keeps track of USB power budgets.  When a 
> bus-powered device requires more current than its upstream hub is capable 
> of providing, the kernel will not configure it.
> 
> Computers' USB ports are capable of providing a full 500 mA, so devices
> plugged directly into the computer will work okay.  However unpowered hubs
> can provide only 100 mA to each port.  Some devices require (or claim they
> require) more current than that.  As a result, they don't get configured
> when plugged into an unpowered hub."
> 
> http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html
> 
> This is generating a lot of grief and appears to be unnecessarily
> strict. Common USB sticks with a MaxPower value just above 100mA, for
> instance, typically work fine on unpowered hubs supplying 100mA.
> 
> Is a more user-friendly solution possible? Could the shortfall
> information be passed to udev, which would allow rules to be written per
> device?
> 

(added linux-usb cc)

Yes, it sounds like we're being non-real-worldly here.  This change
apparently broke things.  Did it actually fix anything as well?

Re: USB devices fail unnecessarily on unpowered hubs

[Daniel Drake]

Andrew Morton wrote:
> (added linux-usb cc)
> 
> Yes, it sounds like we're being non-real-worldly here.  This change
> apparently broke things.  Did it actually fix anything as well?

Gentoo recieved several reports of this. It appears that certain vendors 
are worse than others (Verbatim flash drives are a common culprit).

Some users tested and found that Windows has the same behaviour - it 
rejects these devices on unpowered hubs, and pops up a warning that not 
enough power is available.

I added a printk to point out when configurations are rejected due to 
power issues, this has been merged into Greg's tree. It's far from 
ideal, but better than silent failure...

Daniel

Re: USB devices fail unnecessarily on unpowered hubs

[Alan Stern]

On Thu, 1 Jun 2006, Andrew Morton wrote:

> On Thu, 01 Jun 2006 02:18:20 -0700
> David Liontooth <liontooth@cogweb.net> wrote:
> 
> > Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
> > hubs. Alan Stern explains,
> > 
> > "The idea is that the kernel now keeps track of USB power budgets.  When a 
> > bus-powered device requires more current than its upstream hub is capable 
> > of providing, the kernel will not configure it.
> > 
> > Computers' USB ports are capable of providing a full 500 mA, so devices
> > plugged directly into the computer will work okay.  However unpowered hubs
> > can provide only 100 mA to each port.  Some devices require (or claim they
> > require) more current than that.  As a result, they don't get configured
> > when plugged into an unpowered hub."
> > 
> > http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html
> > 
> > This is generating a lot of grief and appears to be unnecessarily
> > strict. Common USB sticks with a MaxPower value just above 100mA, for
> > instance, typically work fine on unpowered hubs supplying 100mA.
> > 
> > Is a more user-friendly solution possible? Could the shortfall
> > information be passed to udev, which would allow rules to be written per
> > device?

I'm not sure whether we create a udev event when a new USB device is
connected.  If we don't, we certainly could.  Although this event wouldn't
contain information about the power budget shortfall, it would contain
vendor and product IDs.  These would be sufficiently specific for a custom
udev script to install the desired configuration.

> Yes, it sounds like we're being non-real-worldly here.  This change
> apparently broke things.  Did it actually fix anything as well?

Yes.  At least, I think so.  The change directly addresses a complaint 
filed here:

http://marc.theaimsgroup.com/?l=linux-usb-users&m=112438431718562&w=2

I haven't checked back with the original poster to make sure that his
problem has been solved, but presumably it has been.

As an alternative, we could allow an "over-budget window" of say 10%.  
Configurations that exceed the power budget by less than that amount would
still be accepted.  I don't know whether this would be enough of a help,
however.  I've heard of devices that claim to require 200 mA, for
instance.  It just doesn't seem right to enable them when the upstream hub
can only provide 100 mA.

Alan Stern

Re: USB devices fail unnecessarily on unpowered hubs

[linux-os (Dick Johnson)]

On Thu, 1 Jun 2006, Alan Stern wrote:

> On Thu, 1 Jun 2006, Andrew Morton wrote:
>
>> On Thu, 01 Jun 2006 02:18:20 -0700
>> David Liontooth <liontooth@cogweb.net> wrote:
>>
>>> Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
>>> hubs. Alan Stern explains,
>>>
>>> "The idea is that the kernel now keeps track of USB power budgets.  When a
>>> bus-powered device requires more current than its upstream hub is capable
>>> of providing, the kernel will not configure it.
>>>
>>> Computers' USB ports are capable of providing a full 500 mA, so devices
>>> plugged directly into the computer will work okay.  However unpowered hubs
>>> can provide only 100 mA to each port.  Some devices require (or claim they
>>> require) more current than that.  As a result, they don't get configured
>>> when plugged into an unpowered hub."
>>>
>>> http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html
>>>
>>> This is generating a lot of grief and appears to be unnecessarily
>>> strict. Common USB sticks with a MaxPower value just above 100mA, for
>>> instance, typically work fine on unpowered hubs supplying 100mA.
>>>
>>> Is a more user-friendly solution possible? Could the shortfall
>>> information be passed to udev, which would allow rules to be written per
>>> device?
>
> I'm not sure whether we create a udev event when a new USB device is
> connected.  If we don't, we certainly could.  Although this event wouldn't
> contain information about the power budget shortfall, it would contain
> vendor and product IDs.  These would be sufficiently specific for a custom
> udev script to install the desired configuration.
>
>> Yes, it sounds like we're being non-real-worldly here.  This change
>> apparently broke things.  Did it actually fix anything as well?
>
> Yes.  At least, I think so.  The change directly addresses a complaint
> filed here:
>
> http://marc.theaimsgroup.com/?l=linux-usb-users&m=112438431718562&w=2
>
> I haven't checked back with the original poster to make sure that his
> problem has been solved, but presumably it has been.
>
> As an alternative, we could allow an "over-budget window" of say 10%.
> Configurations that exceed the power budget by less than that amount would
> still be accepted.  I don't know whether this would be enough of a help,
> however.  I've heard of devices that claim to require 200 mA, for
> instance.  It just doesn't seem right to enable them when the upstream hub
> can only provide 100 mA.
>
> Alan Stern
>

Many, most, perhaps all such devices don't take more power when they
are "enabled". Everything is already running and sucking up maximum
current when you plug it in! If the motherboard didn't smoke when
the device was plugged in, you might just as well let the user use
it! Perhaps a ** WARNING ** message somewhere, but by golly, they
got it running or else you wouldn't be able to read its parameters.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.73 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: USB devices fail unnecessarily on unpowered hubs

[Lennart Sorensen]

On Thu, Jun 01, 2006 at 11:09:46AM -0400, linux-os (Dick Johnson) wrote:
> Many, most, perhaps all such devices don't take more power when they
> are "enabled". Everything is already running and sucking up maximum
> current when you plug it in! If the motherboard didn't smoke when
> the device was plugged in, you might just as well let the user use
> it! Perhaps a ** WARNING ** message somewhere, but by golly, they
> got it running or else you wouldn't be able to read its parameters.

I imagine something like a harddisk might use more power while
reading/writing than when it is just spinning.  It might even start
powered down until sent some command that causes it to spin up.

A scanner certainly uses more power with the scanner light on than with
it off, and it starts out off until it is in use on most scanners.  Of
course I have never seen a usb powered scanner, so it doesn't seem to
matter.

Len Sorensen

Re: USB devices fail unnecessarily on unpowered hubs

[Dagfinn Ilmari Mannsåker]

Lennart Sorensen <lsorense@csclub.uwaterloo.ca> writes:

> A scanner certainly uses more power with the scanner light on than with
> it off, and it starts out off until it is in use on most scanners.  Of
> course I have never seen a usb powered scanner, so it doesn't seem to
> matter.

Oh, they've been around for years. The CanoScan LiDE 25 is an example:
<http://www.usa.canon.com/consumer/controller?act=ModelTechSpecsAct&fcategoryid=119&modelid=11463>

-- 
ilmari
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen

Re: USB devices fail unnecessarily on unpowered hubs

[Oliver Neukum]

Am Donnerstag, 1. Juni 2006 17:09 schrieb linux-os (Dick Johnson):
> Many, most, perhaps all such devices don't take more power when they
> are "enabled". Everything is already running and sucking up maximum
> current when you plug it in! If the motherboard didn't smoke when

If they do, they are violating the spec. A device in the unconfigured (state 0)
state must not draw more than 100mA.

	Regards
		Oliver

Re: USB devices fail unnecessarily on unpowered hubs

[linux-os (Dick Johnson)]

On Thu, 1 Jun 2006, Oliver Neukum wrote:

> Am Donnerstag, 1. Juni 2006 17:09 schrieb linux-os (Dick Johnson):
>> Many, most, perhaps all such devices don't take more power when they
>> are "enabled". Everything is already running and sucking up maximum
>> current when you plug it in! If the motherboard didn't smoke when
>
> If they do, they are violating the spec. A device in the unconfigured (state 0)
> state must not draw more than 100mA.
>
> 	Regards
> 		Oliver
>

Hmmm, the USB-IF recommends 100 mA per port, not requires.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.73 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: USB devices fail unnecessarily on unpowered hubs

[Alan Stern]

On Thu, 1 Jun 2006, linux-os (Dick Johnson) wrote:

> >> Yes, it sounds like we're being non-real-worldly here.  This change
> >> apparently broke things.  Did it actually fix anything as well?
> >
> > Yes.  At least, I think so.  The change directly addresses a complaint
> > filed here:
> >
> > http://marc.theaimsgroup.com/?l=linux-usb-users&m=112438431718562&w=2

> Many, most, perhaps all such devices don't take more power when they
> are "enabled". Everything is already running and sucking up maximum
> current when you plug it in! If the motherboard didn't smoke when
> the device was plugged in, you might just as well let the user use
> it! Perhaps a ** WARNING ** message somewhere, but by golly, they
> got it running or else you wouldn't be able to read its parameters.

Looks like you didn't bother to read that complaint and the follow-up
messages.  Robert Marquardt's device has two configurations, one using 100
mA and the other using 500 mA.  Before my patch, Linux would always
install the high-power config -- even if the device was behind a
bus-powered hub.  According to Robert:

	This can trigger the overcurrent protection of a bus powered 
	hub which usually then switches off completely dragging down
	three other innocent devices.

	Please tell me that Linux kernel programmers are not that idiotic.

I'll avoid speculations about which kernel programmers are or are not 
idiotic...

Alan Stern

Re: [linux-usb-devel] Re: USB devices fail unnecessarily on unpowered hubs

[Greg KH]

On Thu, Jun 01, 2006 at 10:58:43AM -0400, Alan Stern wrote:
> On Thu, 1 Jun 2006, Andrew Morton wrote:
> 
> > On Thu, 01 Jun 2006 02:18:20 -0700
> > David Liontooth <liontooth@cogweb.net> wrote:
> > 
> > > Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
> > > hubs. Alan Stern explains,
> > > 
> > > "The idea is that the kernel now keeps track of USB power budgets.  When a 
> > > bus-powered device requires more current than its upstream hub is capable 
> > > of providing, the kernel will not configure it.
> > > 
> > > Computers' USB ports are capable of providing a full 500 mA, so devices
> > > plugged directly into the computer will work okay.  However unpowered hubs
> > > can provide only 100 mA to each port.  Some devices require (or claim they
> > > require) more current than that.  As a result, they don't get configured
> > > when plugged into an unpowered hub."
> > > 
> > > http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html
> > > 
> > > This is generating a lot of grief and appears to be unnecessarily
> > > strict. Common USB sticks with a MaxPower value just above 100mA, for
> > > instance, typically work fine on unpowered hubs supplying 100mA.
> > > 
> > > Is a more user-friendly solution possible? Could the shortfall
> > > information be passed to udev, which would allow rules to be written per
> > > device?
> 
> I'm not sure whether we create a udev event when a new USB device is
> connected.

Yes we do.  It's of the class "usb_device" and you can write a single
udev rule to override the power test if you really want to.

Of course I don't recommend someone doing this, as it is violating the
USB power rules, and it is a good thing that we are finally testing for
them.

thanks,

greg k-h

Re: [linux-usb-devel] Re: USB devices fail unnecessarily on unpowered hubs

[David Liontooth]

Greg KH wrote:
> On Thu, Jun 01, 2006 at 10:58:43AM -0400, Alan Stern wrote:
>   
>> On Thu, 1 Jun 2006, Andrew Morton wrote:
>>
>>     
>>> On Thu, 01 Jun 2006 02:18:20 -0700
>>> David Liontooth <liontooth@cogweb.net> wrote:
>>>
>>>       
>>>> Starting with 2.6.16, some USB devices fail unnecessarily on unpowered
>>>> hubs. Alan Stern explains,
>>>>
>>>> "The idea is that the kernel now keeps track of USB power budgets.  When a 
>>>> bus-powered device requires more current than its upstream hub is capable 
>>>> of providing, the kernel will not configure it.
>>>>
>>>> Computers' USB ports are capable of providing a full 500 mA, so devices
>>>> plugged directly into the computer will work okay.  However unpowered hubs
>>>> can provide only 100 mA to each port.  Some devices require (or claim they
>>>> require) more current than that.  As a result, they don't get configured
>>>> when plugged into an unpowered hub."
>>>>
>>>> http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html
>>>>
>>>> This is generating a lot of grief and appears to be unnecessarily
>>>> strict. Common USB sticks with a MaxPower value just above 100mA, for
>>>> instance, typically work fine on unpowered hubs supplying 100mA.
>>>>
>>>> Is a more user-friendly solution possible? Could the shortfall
>>>> information be passed to udev, which would allow rules to be written per
>>>> device?
>>>>         
>> I'm not sure whether we create a udev event when a new USB device is
>> connected.
>>     
> Yes we do.  It's of the class "usb_device" and you can write a single
> udev rule to override the power test if you really want to.
>
> Of course I don't recommend someone doing this, as it is violating the
> USB power rules, and it is a good thing that we are finally testing for
> them.
>   
It's clearly a good thing to be testing for this. As Alan points out,
100mA is the maximum permitted pre-configuration draw, so what a device
draws when plugged in is not informative.

However, obeying the USB power rules is not an end in itself -- the
relevant question is the minimum power the device requires to operate
correctly and without damage.

The MaxPower value does not appear to be a reliable index of this. My
USB stick has a MaxPower value of 178mA and works flawlessly off an
unpowered hub. Unfortunately devices don't seem to tell us what their
minimum power requirements are, so we need more flexibility in writing
rules for this.

udev could surely pick up on the MaxPower value and tolerate up to a
100% underrun on USB flash drives. That would likely still 90% of the
pain right there, maybe all of it.

What are the reasons not to do this? What happens if a USB stick is
underpowered to one unit? Nothing? Slower transmission? Data loss? Flash
memory destruction? If it's just speed, it's a price well worth paying.

This is a great opportunity for a small exercise in empathy, utilizing
that little long-neglected mirror neuron. Thousands of USB sticks
inexplicably go dead in people's familiar hubs on keyboards and desks;
Linux kernel coders dream sweet dreams of not violating USB power rules.
I appreciate Andrew's support for a real-worldly solution.

Dave

Re: [linux-usb-devel] USB devices fail unnecessarily on unpowered hubs

[David Brownell]

On Thursday 01 June 2006 5:03 pm, David Liontooth wrote:
> 
> However, obeying the USB power rules is not an end in itself -- the
> relevant question is the minimum power the device requires to operate
> correctly and without damage.

We don't know the minimum, or much care about it since the minimum is
generally not what gets drawn.

We know the maximum, which is declared in the configuration descriptor.
And we don't know how much of that maximum a given device uses at any
given moment ... ergo, power budgeting assumes the worst case.


> The MaxPower value does not appear to be a reliable index of this. My
> USB stick has a MaxPower value of 178mA and works flawlessly off an
> unpowered hub.

So you're saying that four of those can work off the same hub?  Or
just that one of them can draw two ports' worth of current, because
of the fact that current-limiting is usually on the upstream link,
not individual downstream ones?  (If indeed there is current limiting
and/or overcurrent handling in that hub ...)  Try that experiment,
and put four on one hub ... now write critical data to all of them
at the same time.


> What are the reasons not to do this? What happens if a USB stick is
> underpowered to one unit? Nothing? Slower transmission? Data loss? Flash
> memory destruction? If it's just speed, it's a price well worth paying.

You mis-understand what's going on.  There's a power budget, and if
it gets exceeded then "overcurrent" conditions can happen ... leading
to errors, disconnection, data loss, and yes potentially even memory
destruction; those are all device-specific failure modes, which are
by definition out-of-spec.

The reason to enforce the power budget is that devices guarantee they'll
behave to spec if they can draw that much current.  And if they can't
draw enough current, all those rude failure modes happen.  Devices
enter brown-out modes if you're lucky, or maybe the hub will cleanly shut
things down before much nastiness happens.  The budget is analagous
to a circuit breaker; exceed it and things shut off, which is safer 
than most alternatives.


> This is a great opportunity for a small exercise in empathy, utilizing
> that little long-neglected mirror neuron.

Exactly.  Preventing random glitchey failure modes makes everyone's
experience a lot better.  It's the same reason to fix driver races;
they may not happen all that often, but when they do happen the
result can be disastrous.

- Dave

Re: [linux-usb-devel] USB devices fail unnecessarily on unpowered hubs

[Oliver Neukum]

Am Freitag, 2. Juni 2006 02:03 schrieb David Liontooth:

> The MaxPower value does not appear to be a reliable index of this. My
> USB stick has a MaxPower value of 178mA and works flawlessly off an
> unpowered hub. Unfortunately devices don't seem to tell us what their

It works flawlessly on all hubs you tested, iff other ports are unused.
Unfortunately it needs to work on all hubs, even if all ports are used.

> udev could surely pick up on the MaxPower value and tolerate up to a
> 100% underrun on USB flash drives. That would likely still 90% of the
> pain right there, maybe all of it.

udev can do all it wants if it is running with sufficient priviledge level.
That doesn't change the need for a safe default. The system must run
safely even if udev has gone south or is not installed.
 
> What are the reasons not to do this? What happens if a USB stick is
> underpowered to one unit? Nothing? Slower transmission? Data loss? Flash
> memory destruction? If it's just speed, it's a price well worth paying.

Data loss. Possibly even on other devices and not reproducible.
 
> This is a great opportunity for a small exercise in empathy, utilizing
> that little long-neglected mirror neuron. Thousands of USB sticks
> inexplicably go dead in people's familiar hubs on keyboards and desks;
> Linux kernel coders dream sweet dreams of not violating USB power rules.
> I appreciate Andrew's support for a real-worldly solution.

Maybe we should generate a specific "over power budget" event.

Sympathy is well and good, but partial here. Any option will screw one
group. In this case we go with the standard.

	Regards
		Oliver

Re: [linux-usb-devel] USB devices fail unnecessarily on unpowered hubs

[Alan Stern]

On Thu, 1 Jun 2006, David Liontooth wrote:

> What are the reasons not to do this? What happens if a USB stick is
> underpowered to one unit? Nothing? Slower transmission? Data loss? Flash
> memory destruction? If it's just speed, it's a price well worth paying.

I do wish people would read the earlier messages in this thread before 
posting.  Go back and look at this one:

http://marc.theaimsgroup.com/?l=linux-kernel&m=114918113822427&w=2

Trying to draw too much current from an unpowered hub can and does cause 
data loss.

Alan Stern

Re: USB devices fail unnecessarily on unpowered hubs

[David Liontooth]

Alan Stern wrote:
> Trying to draw too much current from an unpowered hub can and does cause 
> data loss.
>   
I consider this issue closed; thank you for looking at it. The
workaround is reasonably simple for the common situation of mounting a
USB stick on a keyboard, perhaps with a mouse attached in a second port:

NUM="$(dmesg | tail -n 3 | grep -r 'new full speed USB device' | cut -b
5-9)"
echo -n 1 >/sys/bus/usb/devices/$NUM/bConfigurationValue

with the understanding this breaks USB power rules and can lead to data
loss.

Dave

Re: USB devices fail unnecessarily on unpowered hubs

[Andrew Morton]

On Thu, 1 Jun 2006 10:58:43 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> As an alternative, we could allow an "over-budget window" of say 10%.  

That, plus we should provide a suitable i-know-what-im-doing user override,
with the appropriate warnings, as well as a printk which directs users to
this option when we decided to disable their device.

> Configurations that exceed the power budget by less than that amount would
> still be accepted.  I don't know whether this would be enough of a help,
> however.  I've heard of devices that claim to require 200 mA, for
> instance.  It just doesn't seem right to enable them when the upstream hub
> can only provide 100 mA.

The power supply spec is a conservative minimum, whereas the device spec is
a worst-case maximum.  One would expect a lot of devices will work OK when
run "out of spec".

(Goes away and pats all his 240V plugpacks which are happily working off 110V).

Re: USB devices fail unnecessarily on unpowered hubs

[Alan Stern]

On Thu, 1 Jun 2006, Andrew Morton wrote:

> On Thu, 1 Jun 2006 10:58:43 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > As an alternative, we could allow an "over-budget window" of say 10%.  
> 
> That, plus we should provide a suitable i-know-what-im-doing user override,
> with the appropriate warnings, as well as a printk which directs users to
> this option when we decided to disable their device.

The user override already exists, as do the appropriate warnings.  Daniel 
Drake just added a printk explaining why the device was not configured, 
although it doesn't tell how to configure the device by hand.  Perhaps a 
FAQ entry at www.linux-usb.org would be appropriate.

> The power supply spec is a conservative minimum, whereas the device spec is
> a worst-case maximum.  One would expect a lot of devices will work OK when
> run "out of spec".
> 
> (Goes away and pats all his 240V plugpacks which are happily working off 110V).

They probably will.  The question is, how far out-of-spec should the 
kernel allow by default?  200% is likely to be too far (your plugpacks 
notwithstanding).

Alan Stern

Re: USB devices fail unnecessarily on unpowered hubs

[Mark Lord]

Andrew Morton wrote:
> On Thu, 01 Jun 2006 02:18:20 -0700
> ..
>> This is generating a lot of grief and appears to be unnecessarily
>> strict. Common USB sticks with a MaxPower value just above 100mA, for
>> instance, typically work fine on unpowered hubs supplying 100mA.
>>
>> Is a more user-friendly solution possible? Could the shortfall
>> information be passed to udev, which would allow rules to be written per
>> device?
..
> Yes, it sounds like we're being non-real-worldly here.  This change
> apparently broke things.  Did it actually fix anything as well?

I think a far more sensible approach would be to just ensure that the
total current draw for the (unpowered) hub and all connected devices,
stays below the 500mA allowed.  So a 200mA device could coexist with
a 100mA device on a hub which itself steals 100mA.

Cheers

Re: USB devices fail unnecessarily on unpowered hubs

[Alan Stern]

On Thu, 1 Jun 2006, linux-os (Dick Johnson) wrote:

> > If they do, they are violating the spec. A device in the unconfigured (state 0)
> > state must not draw more than 100mA.
...
> Hmmm, the USB-IF recommends 100 mA per port, not requires.

See section 7.2.1 of the USB 2.0 specification (p. 177):

	Devices must also ensure that the maximum operating current drawn 
	by a device is one unit load, until configured.

Note that a unit load is defined as to be 100 mA.  This is a requirement, 
not a recommendation.


On Thu, 1 Jun 2006, Mark Lord wrote:

> I think a far more sensible approach would be to just ensure that the
> total current draw for the (unpowered) hub and all connected devices,
> stays below the 500mA allowed.  So a 200mA device could coexist with
> a 100mA device on a hub which itself steals 100mA.

On that same page the specification says:

	Bus-powered hubs: Draw all of their power for any internal
	functions and downstream facing ports from VBUS on the hub s
	upstream facing port.  Bus-powered hubs may only draw up to one
	unit load upon power-up and five unit loads after configuration.
	The configuration power is split between allocations to the hub,
	any non-removable functions and the external ports. External ports
	in a bus-powered hub can supply only one unit load per port
	regardless of the current draw on the other ports of that hub.

This clearly states that a bus-powered hub cannot supply 200 mA on one
port, even if another port is unoccupied.

Alan Stern

Re: [linux-usb-devel] Re: USB devices fail unnecessarily on unpowered hubs

[Robert Hancock]

David Liontooth wrote:
> It's clearly a good thing to be testing for this. As Alan points out,
> 100mA is the maximum permitted pre-configuration draw, so what a device
> draws when plugged in is not informative.
> 
> However, obeying the USB power rules is not an end in itself -- the
> relevant question is the minimum power the device requires to operate
> correctly and without damage.
> 
> The MaxPower value does not appear to be a reliable index of this. My
> USB stick has a MaxPower value of 178mA and works flawlessly off an
> unpowered hub. Unfortunately devices don't seem to tell us what their
> minimum power requirements are, so we need more flexibility in writing
> rules for this.

The fact it appears to work on an unpowered hub doesn't mean anything. 
Why would the manufacturer specify it can consume 178 mA if it couldn't 
consume that much under some conditions? Have you measured it? What 
makes you think that the hub can supply that much power on all ports at 
the same time despite not being specified to do so?

Trying to say "Well, it says it needs this much, but it probably doesn't 
really NEED that much.." is an unreliable guessing game.

> 
> udev could surely pick up on the MaxPower value and tolerate up to a
> 100% underrun on USB flash drives. That would likely still 90% of the
> pain right there, maybe all of it.
> 
> What are the reasons not to do this? What happens if a USB stick is
> underpowered to one unit? Nothing? Slower transmission? Data loss? Flash
> memory destruction? If it's just speed, it's a price well worth paying.

If the device can't get enough power, all kinds of bad stuff can happen. 
  This is the reason why USB power budgeting is part of the standard in 
the first place. The kernel has no business ignoring such restrictions, 
not without a clearly-marked-as-dangerous user choice.

> This is a great opportunity for a small exercise in empathy, utilizing
> that little long-neglected mirror neuron. Thousands of USB sticks
> inexplicably go dead in people's familiar hubs on keyboards and desks;
> Linux kernel coders dream sweet dreams of not violating USB power rules.
> I appreciate Andrew's support for a real-worldly solution.

Keep in mind that Windows will not permit the USB device to work in such 
configurations either. Windows always did the right thing here. Linux 
did not do the right thing before, and now it does.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/