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.
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.
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.
My old Xperias were capable to "boot" into a minimal bootloader (just enough to negotiate USB power, charge battery, and light the charging LED) and refused to boot further. I now see how it was done; great article.
> 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.
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.
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).
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.
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.
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.