15.04.2020 17:27, Rob Herring пишет: > 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. Usually, it's a battery that has a phandle to the power-supply. Isn't it? > Possibly you should add > new properties battery.txt. It's curious that different properties are > needed. I guess it should be possible to make all these properties generic. Sebastian, will you be okay if we will add all the required properties to the power_supply_core? > Ultimately, for a given battery technology I would expect > there's a fixed set of properties needed to describe how to charge > them. Please notice that the charger doesn't "only charge" the battery, usually it also supplies power to the whole device. For example, when battery is fully-charged and charger is connected to the power source (USB or mains), then battery may not draw any current at all. > Perhaps some of these properties can just be derived from other > properties and folks are just picking what a specific charger wants. Could be so, but I don't know for sure. Even if some properties could be derived from the others, it won't hurt if we will specify everything explicitly in the device-tree. > 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. I don't think it's a mess in the kernel. For example, it's common that embedded controllers are exposed to the system as "just a battery", while in fact it's a combined charger + battery controller and the charger parameters just couldn't be changed by SW. In a case of the Nexus 7 devices, the battery controller and charger controller are two separate entities in the system. The battery controller (bq27541) only monitors status of the battery (charge level, temperature and etc).
