
Linux USB charging, part 1: requirements - sohkamyung
https://lwn.net/Articles/693027/
======
niftich
It's a well-written, in-depth article about a very technical topic that
affects a lot of us daily, but few of us are aware of its implementation
details.

Specifically, there is a fascinating section about how to actually charge a
phone with a dead battery; there is nasty catch-22 where you have to boot up
the OS to negotiate the amount of current you want to draw, but since your
batteries are dead and the default un-negotiated current isn't enough to boot,
you have to get creative.

~~~
derefr
I'm confused as to why we haven't cut all this mess out by standardizing a
dedicated microcontroller in the charging path, that handles AC/battery
switching, battery recharging and discharging, etc. without getting the CPU
involved. As if you could boot an AT computer so only its southbridge and BIOS
were active, without the CPU coming up.

I _think_ recent Apple machines—e.g. the retina Macbooks—might have something
like this, given the "Power Nap" feature and the fact that plugging them into
power temporarily flashes a charging indicator on the screen even if the
computer is "off." But it might really just be that the computer is never
really "off" but just in a really deep CPU sleep-state. The test would be to
kill the battery of one flat-dead, and then see if the charging indicator
still appears on AC-in.

~~~
niftich
I don't know for sure, but I'm hypothesizing that Qualcomm's Quick Charge
actually works this way, as the presence of their hardware/firmware/secret
sauce is required in both the charger and the device end to negotiate the
upped voltage.

------
fpgaminer
> BC-1.2 defines a Dead Battery Provision (DBP) which allows for an extremely
> simple handshake to request that 100mA be available for a longer term — up
> to 45 minutes.

45 minutes is such a long time, what is the practical difference between
always providing 100ma and only providing 100ma for 45 minutes? A device can
be plugged in at any time, even right after a previous device had used the
port for 45 minutes, so this rule seems to me to de facto say that a port must
provide at least 100ma. If my understanding is correct, then why have the rule
at all? Just make 100ma the unnegotiated power instead of 2.5ma.

------
userbinator
I don't think I've come across any USB ports (even on laptops) that don't just
always have the full 500mA --- or more --- available, because doing that is
easy and cheap. Adding the software negotiation is another layer of complexity
that no one really wants.

~~~
majewsky
1\. As far I as saw from the article, this is mostly for negotiating more
power, not less. I just skimmed it, though.

2\. A USB hub might have less than the full 500 mA to offer to each of its
ports if its host only offers 500 mA and it does not have a separate power
supply (which four-port hubs usually don't).

~~~
dfox
In USB terms, "more power" is technically anything over 2.5mA, realistically
over 100mA.

The original intention of USB was for host to actively limit the current
available. But before it started to be reasonably cheap to do so, everyone
went with the simpler implementation of connecting VBUS to whatever +5V rail
the device has (in more sane implementations thru some kind of (poly)fuse),
with some standards that include USB even making it technically impossible to
limit current by software (AGP, various late 90's "single cable to display"
interfaces and so on) by not including any wires to do so. Even bus powered
hubs typically just connect the VBUS together and when some downstream device
does not obey the current limit, the whole thing just fails randomly.

------
jhoechtl
What is the purpose of this article? An outline for future work in the Linux
USB stack for implementation? The beginning of the article are not
encouraging:

> [...] will conclude in the second part by looking at how Linux does, or more
> often doesn't, make use of this information.

~~~
ashitlerferad
[https://news.ycombinator.com/item?id=12157568](https://news.ycombinator.com/item?id=12157568)

