On Fri, Apr 10, 2020 at 2:02 PM Dmitry Osipenko <digetx@xxxxxxxxx> wrote: > > 10.04.2020 19:49, Rob Herring пишет: > ... > >> + summit,max-chg-curr: > >> + description: Maximum current for charging (in uA) > >> + allOf: > >> + - $ref: /schemas/types.yaml#/definitions/uint32 > >> + > >> + summit,max-chg-volt: > >> + description: Maximum voltage for charging (in uV) > >> + allOf: > >> + - $ref: /schemas/types.yaml#/definitions/uint32 > >> + minimum: 3500000 > >> + maximum: 4500000 > >> + > >> + summit,pre-chg-curr: > >> + description: Pre-charging current for charging (in uA) > >> + allOf: > >> + - $ref: /schemas/types.yaml#/definitions/uint32 > >> + > >> + summit,term-curr: > >> + description: Charging cycle termination current (in uA) > >> + allOf: > >> + - $ref: /schemas/types.yaml#/definitions/uint32 > ... > > These are all properties of the battery attached and we have standard > > properties for some/all of these. > > Looks like only four properties seem to be matching the properties of > the battery.txt binding. > > Are you suggesting that these matching properties should be renamed > after the properties in battery.txt? Yes, and that there should be a battery node. Possibly you should add new properties battery.txt. It's curious that different properties are needed. Ultimately, for a given battery technology I would expect there's a fixed set of properties needed to describe how to charge them. Perhaps some of these properties can just be derived from other properties and folks are just picking what a specific charger wants. Unfortunately, we have just a mess of stuff made up for each charger out there. I don't have the time nor the experience in this area to do much more than say do better. Rob