Messages in this thread | | | Date | Thu, 22 Jan 2015 01:54:49 +0100 | From | Sebastian Reichel <> | Subject | Re: [RFC PATCH 0/3] power: Generic interface to get battery specification. |
| |
Hi Jonghwa,
On Tue, Oct 07, 2014 at 07:58:35PM +0900, Jonghwa Lee wrote: > This patches contains supporting generic interface to get battery specification > and of-based battery driver which use the interface. > > Up to now, power supply subsystem assumes that battery's charartric data is > static and also often left as fuelgauge's role. However, fuelgauge driver or > any power_supply driver can be worked with different battery with different > implementation and battery also can be changed even in runtime. > If so, it needs to notify its change to all related power_supply drivers not > let them notice all with private way. Thus, it tries to introduce generic > interface for management of the battery specification. > > In addition to, for the smart battery, this'll help to abstract battery > interface which can be varied with different batteries. (SDQ, MIPI BIF..)
Sorry it took me so long. Here are my thoughts regarding this patchset:
1. Please introduce drivers/power/battery/*
As far as I understand it we will get another driver for getting the information dynamically via MIPI BIF, SDQ, ... and drivers/power is already quite messy. Next step is moving battery gauges and battery chargers into their own directories, but than can come after cleaning up the core.
2. Please use "-" instead of "_" in DT property names
3. We should add a compatible string for the battery. Maybe something like "simple-battery"
4. I suggest to rename charge_full/empty to current_full/empty, so that its about generic battery metadata and not charging metadata.
5. I assume temperature_max/temperature_min is used for non-charging related safety trips (e.g. battery over temperature_max starts an emergency shutdown).
6. Temperature based charging is most likely something we need in the future. There are at least 3 temperature zones normally (too cold for charging [but ok for general use]), (normal mode) and (too hot for charging [but ok for general use]). Having a slow charging mode before complete turnoff seems logic to me :)
Since its kind of hard to keep working on big patchsets (and also not very nice for reviewing) I suggest to start with the basic battery stuff and add the charging information afterwards.
-- Sebastian [unhandled content-type:application/pgp-signature] | |