-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > This message can safely be ignored, as the actual issue is being > handled as far as I can see - this is just about this single comment. > > Andy Green wrote: >> Actually I would ship the thing pulling a fixed 500mA perfectly happily. > > I've heard from multiple sources that some USB hosts burn out, if you > draw more than 100mA from them. I have not witnessed any of this first > hand, so this is still hearsay. But let's assume for the moment that > this is actually true - even if it concerns only a really small part > of any available devices.
There's no doubt the standard has this 100mA requirement, if we didn't meet it, it means we at least did not act properly in that region until it was fixed; in that fictional scenario it ships acting broken there. But this kind of playing fast and loose about USB power is not uncommon, eg http://en.wikipedia.org/wiki/USB_hub#Power But every USB host I ever saw has current limit and high-side switch. So I don't expect to find these kind of hosts, and those proposed (alleged) pathological hosts are at risk from other devices that just pull what they like, or a short, from the USB socket. > If this is the case, would you really ship a product, which when > plugged to a USB port may harm the device it was plugged in to? Would > you put a warning sticker somewhere about it? What would you do when > the customers would complain about a device harmed by OpenMoko? What > do you think the USB-IF would do hearing there's a device carrying the > USB label and still doing this? I ain't the guy that gets to decide what ships as I said. At a typical small manufacturer, if things did get to that point without this being fixed, or it couldn't be fixed (really: not believed the case here) there would typically be "debate" about what to do. If it did turn out the necessity was to ship with it like that, IIRC there is a USB descriptor that talks about 100mA consumption on our part as a fallback, one way to deal with what would be our inability to provide that would be comment out that descriptor (so we explain to the host we are 500mA-only, limiting the duration of the "violation" to between plugin and recognition by the host OS) and make a note the ships with the device explaining what kind of USB ports it could consider to work with in that case. No its not beautiful but the product gets shipped. If the port truly only provides 100mA it isn't enough to run our device, so it will very likely go into shutdown anyway removing the overcurrent. So the situation is not so dire, but would obviously suck until it was fixed. > It would be interesting to hear the answers to this. I gave some specific ideas above. But the general non-Openmoko issue is interesting to explore anyway. It is pretty much normal for a generic small technology company to overrun development and get pressure, sometimes completely unavoidable pressure, to ship from the costs from that. What should a generic manufacturer do if he sees he runs out of time for product development some time before? It isn't that uncommon, for software-only products it is so common that it doesn't raise eyebrows at all, you just ship the thing as far as it got and update it. What about when there is a physical hardware element? What he should do is triage and prioritize the bugs so that bugs that cannot be fixed later -- hardware related ones -- go to the head of the queue. This makes complete sense, serious hardware issues that can't be ignored or worked around later must get fixed or there is no point. But anything that can get cleaned up with an update begs the question can it just wait until the update and in the meanwhile the manufacturer doesn't implode. And the triage aspect is accepting early if anything planned for isn't going to make it and aborting it before it uselessly soaks up the valuable remaining development time to no useful end. Now consider the alternative, hardline "no ship until no bugs". That itself is a policy that has to go in the triage action, it will eat development effort to no result because the company will run out of money before ship since perfection is generally a pretty slow thing to attain. So between the two philosophies, it's clear to me I would ship a thing with fixable bugs rather than never ship anything because it never became quite good enough. > (As an aside, there are devices doing things like this. For example, > there's an MP3 player which removes the need for a specific USB Yeah this wouldn't be by design or a permanent issue though. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHvcuwOjLpvpq7dMoRAivTAJ4rKEZfTnDJWJ5aOyolJCeZKbUITQCfSZFU 7qIFvBAQl19Tq2AbpX6qAp4= =e6Lk -----END PGP SIGNATURE-----
