[PATCH 1/1] uboot-pcf50633-default-curr-lim-1A.patch

[Andy Green]

-----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-----