Re: LTC3651 and other GPIO chargers

[Sebastian Reichel <sebastian.reichel@collabora.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

Hi,

On Mon, Jun 26, 2017 at 06:21:06PM +0200, Ladislav Michl wrote:
> A driver for LTC3651 was recently added to -next
> https://patchwork.kernel.org/patch/9717049/
> which brings a question whenever we want to add separate driver
> (or vendor specific bindings) for ever growing list of similar
> chargers. For example those using the same status output lines
> are: BQ24232HA, LTC4007, LTM8061, RT9502, LT3651, LT3650, TP4056,
> MAX1737...
> Others for example BQ24032A and LM3658 (which I have to support)
> are using different status encoding, ie. LM3658:
> 
> stat1	stat2		Condition
>   0	  0	Power-Down, charging is suspended or interrupted
>   1	  0	Pre-qualification mode, CC and CV charging
>   0	  1	Charge is completed
>   1	  1	Bad battery (Safety timer expired), or LDO mode
> 
> What about extending gpio-charger instead?
> - allow gpio list fdt subnode
>   - consider each gpio line to represent bit in a word
> - provide per property subnodes
>   - each subnode holds a mask and mapping to property values
> This way we should be able to cover most chargers providing status
> using gpios. Comments welcome and appreciated - those will turn into
> implementation.
> 
> Thank you,
> 	ladis

I think you mean something like this?

charger {
    compatible = "vendor,chip", "gpio-charger;

    status-gpios = <status-gpio1>, <status-gpio2>;

    status-mapping-0 {
        mask = <00>;
        type = "exploded";
    };

    status-mapping-1 {
        mask = <01>;
        type = "frozen";
    };

    ...
};

In that case: NAK. I like the general idea, but the DT binding looks
like a mess. Instead of providing the mapping in DT, it should be
provided by the driver and selected based on the compatible value.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]