From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: David Liontooth <liontooth@cogweb.net>
Subject: Re: [linux-usb-devel] Re: USB devices fail unnecessarily on unpowered hubs
Date: Thu, 01 Jun 2006 20:39:41 -0600 [thread overview]
Message-ID: <447FA4ED.8070204@shaw.ca> (raw)
In-Reply-To: <6j5oR-7Sw-11@gated-at.bofh.it>
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/
next prev parent reply other threads:[~2006-06-02 2:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6iS8y-35Z-5@gated-at.bofh.it>
[not found] ` <6iWP5-2gj-71@gated-at.bofh.it>
[not found] ` <6iX82-2UJ-3@gated-at.bofh.it>
2006-06-01 23:35 ` USB devices fail unnecessarily on unpowered hubs Robert Hancock
2006-06-01 23:46 ` Randy.Dunlap
[not found] ` <6iYxg-53W-29@gated-at.bofh.it>
[not found] ` <6j5oR-7Sw-11@gated-at.bofh.it>
2006-06-02 2:39 ` Robert Hancock [this message]
2006-06-01 10:01 Andrew Morton
2006-06-01 14:58 ` Alan Stern
2006-06-01 16:43 ` [linux-usb-devel] " Greg KH
2006-06-02 0:03 ` David Liontooth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=447FA4ED.8070204@shaw.ca \
--to=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=liontooth@cogweb.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox