[1/2] dt-bindings: power: supply: gpio-charger: add support for default charge current limit

From: Dimitri Fedrau <dimitri.fedrau@liebherr.com>

Add binding for default charge current limit.

Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
---
 Documentation/devicetree/bindings/power/supply/gpio-charger.yaml | 4 ++++
 1 file changed, 4 insertions(+)

On Wed, Dec 11, 2024 at 08:29:09AM +0100, Dimitri Fedrau wrote:
> Add binding for default charge current limit.

Why?

> 
> Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
> ---
>  Documentation/devicetree/bindings/power/supply/gpio-charger.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
> index 89f8e2bcb2d7836c6a4308aff51721bd83fa3ba1..545fdd7133daf67b5bc238c5af26d0cbd8b44eae 100644
> --- a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
> +++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
> @@ -58,6 +58,10 @@ properties:
>              charge-current-limit-gpios property. Bit 1 second to last
>              GPIO and so on.
>  
> +  charge-current-limit-default:

Use standard property suffixes - see other bindings how they define
charge current.
git grep charge -- Documentation/devicetree/bindings/power/supply/

But what I don't get is why GPIO chager needs it, since this is
non-configurable for GPIO charger.

You have entire commit msg or property description to explain such
things.

Best regards,
Krzysztof

Am Fri, Dec 13, 2024 at 12:00:46PM +0100 schrieb Krzysztof Kozlowski:
> On Wed, Dec 11, 2024 at 08:29:09AM +0100, Dimitri Fedrau wrote:
> > Add binding for default charge current limit.
> 
> Why?
> 
See below.

> > 
> > Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
> > ---
> >  Documentation/devicetree/bindings/power/supply/gpio-charger.yaml | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
> > index 89f8e2bcb2d7836c6a4308aff51721bd83fa3ba1..545fdd7133daf67b5bc238c5af26d0cbd8b44eae 100644
> > --- a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
> > +++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
> > @@ -58,6 +58,10 @@ properties:
> >              charge-current-limit-gpios property. Bit 1 second to last
> >              GPIO and so on.
> >  
> > +  charge-current-limit-default:
> 
> Use standard property suffixes - see other bindings how they define
> charge current.
> git grep charge -- Documentation/devicetree/bindings/power/supply/
>
Will fix it, thanks for the hint.

> But what I don't get is why GPIO chager needs it, since this is
> non-configurable for GPIO charger.
> 
With properties charge-current-limit-gpios and charge-current-limit-mapping
one can define charge current limits in uA using up to 32 GPIOs. At the
moment the driver defaults to smallest current limitation for safety
reasons. When disabling charging should be possible as in the example,
the charger defaults to non-charging. By having a default the charge
current limit can be setup on probe and charging is enabled.

> You have entire commit msg or property description to explain such
> things.
> 
Will explain it in more detail.

Best regards,
Dimitri Fedrau

On 13/12/2024 15:19, Dimitri Fedrau wrote:
> 
>> But what I don't get is why GPIO chager needs it, since this is
>> non-configurable for GPIO charger.
>>
> With properties charge-current-limit-gpios and charge-current-limit-mapping
> one can define charge current limits in uA using up to 32 GPIOs. At the
> moment the driver defaults to smallest current limitation for safety
> reasons. When disabling charging should be possible as in the example,
> the charger defaults to non-charging. By having a default the charge
> current limit can be setup on probe and charging is enabled.

OK, the commit msg should explain the intention and real use case you
are solving here. Plus you miss the dependency - this property depends
on charge-current-limit-mapping.

Best regards,
Krzysztof