lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Apr 2020 18:30:02 +0300
From:   Dmitry Osipenko <>
To:     Rob Herring <>, David Heidelberg <>,
        Sebastian Reichel <>
Cc:     Jonghwa Lee <>,
        Chanwoo Choi <>,
        Myungjoo Ham <>,
        Sumit Semwal <>,
        John Stultz <>,
        Vinay Simha BN <>,
        Mika Westerberg <>,,
        "open list:THERMAL" <>,
        "" <>,
Subject: Re: [PATCH 4/9] dt-bindings: power: supply: Add device-tree binding
 for Summit SMB3xx

15.04.2020 17:27, Rob Herring пишет:
> On Fri, Apr 10, 2020 at 2:02 PM Dmitry Osipenko <> 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).

Powered by blists - more mailing lists