linux-kernel - Re: [PATCH 4/9] dt-bindings: power: supply: Add device-tree binding for Summit SMB3xx

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <687db60d-fea9-f157-d4ce-907189bb3cc7@gmail.com>
Date:   Wed, 15 Apr 2020 18:30:02 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Rob Herring <robh@...nel.org>, David Heidelberg <david@...t.cz>,
        Sebastian Reichel <sre@...nel.org>
Cc:     Jonghwa Lee <jonghwa3.lee@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Myungjoo Ham <myungjoo.ham@...sung.com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        Vinay Simha BN <simhavcs@...il.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        ramakrishna.pallala@...el.com,
        "open list:THERMAL" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org
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 <digetx@...il.com> 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).