(Thanks for Cc'ing me.)
On Thu, Sep 13, 2012 at 02:37:38PM +0000, Arnd Bergmann wrote: [...]
If this is true, I don't understand what makes the 'supplied-to' properties you list in the device tree binding board specific. Are they not always done the same way? If so, you could just leave them out.
Precisely 'supplied-to' is not board specific, it was maintained as platform_data which i migrated to dt-node. It is meant to establish dependency across bm drivers based on power_supply property and runtime battery attributes. Basically, 'supplied-to' provides a way of exporting change in power_supply_property and runtime batter characteristics so that other bm devs shall make use or refer the updated values. Ref: external_power_changed(...) call back api. Note: all the bm drivers handles subset of power_supply property and battery attributes, ref: include/linux/power_supply.h and get_property(...) call back api across bm drivers.
Ok, so you want to just remove the property from the device tree, or do you want to establish a different method to specify these connections?
Power supply subsystem's supplied_to describes not just how driver should notify other devices, supplied_to is more generic stuff, in terms that it describes power supply hierarchy. It's like a directed graph, e.g.:
<AC power> supplied_to <main battery> and <backup battery> <USB power> supplied_to <main battery> and <backup battery> <main battery> supplied_to <system> <backup battery> supplied_to <system> <cmos battery> supplied_to <southbridge pci device> <mice battery> supplied_to <mice wireless hid>
How things interact in linux are just implementations details. So, device tree is surely a perfect place to describe these things.
Although, in current bindings I see this:
+ ab8500-fg { + /* Other enery management module */ + supplied_to = "ab8500_chargalg", "ab8500_usb"; + num_supplicants = <2>; + };
Instead of addressing supplicants by name, it's better to address via phandles. And, of course, num_supplicants is not needed, it can be derived.
[...]
possible batteries and require a property such as
st-ericsson,battery-type: A string identifier for the type of battery, which impacts how an operating system interpret the sensor readings. Possible values include:
- "none" -- no battery connected
- "li-ion-9100" -- Type 9100 Li-ION battery
<add any others that apply here>
Can do this, not precisely as "st-ericsson,battery-type", it will be as battery-type = [unknown|NiMH|LION|...|]], reason being allowable battery type is based on technology, as you can see the possible types as: POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0, POWER_SUPPLY_TECHNOLOGY_NiMH, POWER_SUPPLY_TECHNOLOGY_LION, POWER_SUPPLY_TECHNOLOGY_LIPO, POWER_SUPPLY_TECHNOLOGY_LiFe, POWER_SUPPLY_TECHNOLOGY_NiCd, POWER_SUPPLY_TECHNOLOGY_LiMn Ref: include/linux/power_supply.h Note: doing this will impact my of_probe(...), may slightly bloat the code.
Ok.
If you want to make the battery type a generic property, it's probably best to start a separate binding document for this in Documentation/devicetree/bindings/power-supply/common.txt and document a string for each of these.
Fully agree. We need to document generic DT bindings for power supplies.
Thanks, Anton.