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
Attachment:
signature.asc
Description: PGP signature
