From: Oliver Neukum <oliver@neukum.org>
To: linux-usb-devel@lists.sourceforge.net
Cc: David Liontooth <liontooth@cogweb.net>, Greg KH <greg@kroah.com>,
Andrew Morton <akpm@osdl.org>,
Alan Stern <stern@rowland.harvard.edu>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] USB devices fail unnecessarily on unpowered hubs
Date: Fri, 2 Jun 2006 09:12:37 +0200 [thread overview]
Message-ID: <200606020912.37832.oliver@neukum.org> (raw)
In-Reply-To: <447F8057.4000109@cogweb.net>
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
next prev parent reply other threads:[~2006-06-02 7:12 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-01 9:18 David Liontooth
2006-05-30 20:01 ` Pavel Machek
2006-06-03 9:29 ` Oliver Neukum
2006-06-05 14:32 ` [linux-usb-devel] " David Brownell
2006-06-06 7:43 ` Oliver Neukum
2006-06-08 7:01 ` Pavel Machek
2006-06-08 8:34 ` [PATCH] limit power budget on spitz Pavel Machek
2006-06-08 8:50 ` Richard Purdie
2006-06-08 9:02 ` Pavel Machek
2006-06-08 9:22 ` Richard Purdie
2006-06-08 17:09 ` Russell King
2006-06-08 18:26 ` David Brownell
2006-06-08 20:06 ` Richard Purdie
2006-06-08 20:38 ` [linux-usb-devel] " David Brownell
2006-06-08 21:22 ` Richard Purdie
2006-06-08 21:40 ` David Brownell
2006-06-08 21:49 ` Richard Purdie
2006-06-08 23:44 ` David Brownell
2006-06-09 1:25 ` Nicolas Pitre
2006-06-09 2:03 ` David Brownell
2006-06-09 2:34 ` Nicolas Pitre
2006-06-01 10:01 ` USB devices fail unnecessarily on unpowered hubs Andrew Morton
2006-06-01 11:42 ` Daniel Drake
2006-06-01 14:58 ` Alan Stern
2006-06-01 15:09 ` linux-os (Dick Johnson)
2006-06-01 15:23 ` Lennart Sorensen
2006-06-01 21:39 ` Dagfinn Ilmari Mannsåker
2006-06-01 15:53 ` Oliver Neukum
2006-06-01 17:24 ` linux-os (Dick Johnson)
2006-06-01 16:57 ` Alan Stern
2006-06-01 16:43 ` [linux-usb-devel] " Greg KH
2006-06-02 0:03 ` David Liontooth
2006-06-02 1:53 ` [linux-usb-devel] " David Brownell
2006-06-02 7:12 ` Oliver Neukum [this message]
2006-06-02 15:11 ` Alan Stern
2006-06-02 19:49 ` David Liontooth
2006-06-01 16:59 ` Andrew Morton
2006-06-01 17:08 ` Alan Stern
2006-06-01 17:34 ` Mark Lord
2006-06-01 17:47 ` Alan Stern
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=200606020912.37832.oliver@neukum.org \
--to=oliver@neukum.org \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=liontooth@cogweb.net \
--cc=stern@rowland.harvard.edu \
/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
all inboxes | Powered by JetHome®