[RFC 1/5] dt-bindings: mfd: ti,bq25703a: Add TI BQ25703A Charger

Sebastian Reichel sebastian.reichel at collabora.com
Mon Sep 16 02:42:55 PDT 2024


Hi,

On Fri, Aug 30, 2024 at 03:52:04PM GMT, Chris Morgan wrote:
> > > +
> > > +  ti,charge-current:
> > > +    description:
> > > +      maximum current to apply to charging the battery
> > > +    minimum: 0
> > > +    maximum: 8128000
> > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > 
> > I guess this is copied from other TI parts, but really this should move 
> > to a property with a unit suffix. Or these shared properties moved to a 
> > shared schema so we aren't redefining the type multiple times.
> > 
> > Same for the others here.
> 
> Correct, I tried to reuse the same TI specific properties. I suppose I
> could also eliminate ti,charge-current and ti,max-charge-voltage, and
> then just require a phandle to a simple-battery node which contains
> those two values in a vendor independent form. What do you think?

Yes. The bindings using vendor specific properties for this are from
before the simple battery binding existed.

> ti,current-limit and ti,minimum-system-voltage though are other
> possible questions I have. Basically I could also create a vsys
> regulator that represents the vsys coming off this device too (I
> currently omit this entirely). This regulator wouldn't be programable
> but would report the existing input current and input voltage for
> the system, which in my case I'm pretty sure is stepped down to 5v
> or less and then fed into an RK806 PMIC (I lack the schematics so
> I don't know for sure). Of course if I did that then I'd have a
> valid reason to add a "regulators" node since I'd have more than one
> regulator.

I like this approach, since it allows properly describing the
hardware setup in DT and avoids the vendor specific properties.

Greetings,

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20240916/498cffb7/attachment-0001.sig>


More information about the Linux-rockchip mailing list