> This driver used to stop code/logic duplication through different > machines we porting at handhelds.org. pda_power register machs' power > supplies, and will take care about notifying batteries about power > changes through external power interface.
It gets USB power management wrong though. Have a look at two I2C drivers in drivers/i2c/chips: tps65010.c (which would talk to this API) and then isp1301_omap.c (which would talk to the tps65010 driver). The tps65010 chip accepts the same two power sources you're addressing here, as part of its battery charging responsibilities. [1] Key points: - The API needs to say *how much power* can be drawn. Common values are 8 mA (OTG peripherals before configuration), 100 mA (non-OTG ones before configuration), 500 mA (high power configurations) ... but the exact value depends on what's listed in the configuration descriptor for the chosen configuration, any value 0..500 mA (increments of two) could be appropriate. - Sensing VBUS power is not the same thing as being allowed to consume it. Again, USB OTG devices are different: OTG hosts **SUPPLY** the current, so you really don't want to be telling the OTG transceiver to fire up its charge pump (say, 3.0V VBAT converted to 5V VBUS) while at the same time telling the battery manager to use that battery-derived VBUS current to recharge its battery! Not only would that waste power, but it also deprives the peripheral of the power it needs to draw. In general, no component other than the USB peripheral (or host) controller driver has any business trying to control how VBUS power is used. It's likely to get it wrong ... as shown by this patch. ;) And that's exactly why the USB gadget API has had calls to manage the USB power consumption since mid-2004. And I wonder why H5000 code evidently doesn't implement those calls. - Dave [1] You may find http://www.linux-usb.org/gadget/h2-otg.html useful too. It gives a high level map of the complicated OTG case, including those drivers, and points out how simpler peripheral-only systems could behave with the same drivers. However it does turn out to be useful if USB peripheral drivers have a "transciever" notion that can receive "VBUS present" interrupts, letting the peripheral controller driver power down almost *everything* to save power, and that otg_transceiver interface does that job. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/