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: <ee36d7d1-ef47-4a35-9aff-baa6ed32105a@gmail.com>
Date: Fri, 14 Nov 2025 11:04:27 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: "Rob Herring (Arm)" <robh@...nel.org>,
 Matti Vaittinen <matti.vaittinen@...ux.dev>
Cc: Krzysztof Kozlowski <krzk+dt@...nel.org>, Mark Brown
 <broonie@...nel.org>, Linus Walleij <linus.walleij@...aro.org>,
 linux-kernel@...r.kernel.org, Sebastian Reichel <sre@...nel.org>,
 Bartosz Golaszewski <brgl@...ev.pl>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 linux-clk@...r.kernel.org, Michael Turquette <mturquette@...libre.com>,
 Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
 linux-leds@...r.kernel.org, Pavel Machek <pavel@...nel.org>,
 Liam Girdwood <lgirdwood@...il.com>, linux-gpio@...r.kernel.org,
 linux-pm@...r.kernel.org, Andreas Kemnade <andreas@...nade.info>,
 Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 linux-rtc@...r.kernel.org, Lee Jones <lee@...nel.org>,
 Stephen Boyd <sboyd@...nel.org>
Subject: Re: [PATCH v4 04/16] dt-bindings: power: supply: BD72720 managed
 battery

On 13/11/2025 12:53, Rob Herring (Arm) wrote:
> 
> On Thu, 13 Nov 2025 10:52:19 +0200, Matti Vaittinen wrote:
>> From: Matti Vaittinen <mazziesaccount@...il.com>
>>
>> The BD72720 PMIC has a battery charger + coulomb counter block. These
>> can be used to manage charging of a lithium-ion battery and to do fuel
>> gauging.
>>
>> ROHM has developed a so called "zero-correction" -algorithm to improve
>> the fuel-gauging accuracy close to the point where battery is depleted.
>> This relies on battery specific "VDR" tables, which are measured from
>> the battery, and which describe the voltage drop rate. More thorough
>> explanation about the "zero correction" and "VDR" parameters is here:
>> https://lore.kernel.org/all/676253b9-ff69-7891-1f26-a8b5bb5a421b@fi.rohmeurope.com/
>>
>> Document the VDR zero-correction specific battery properties used by the
>> BD72720 and some other ROHM chargers.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
>> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
>>
>> ---
>> NOTE:
>> Linus' rb-tag holds only if there's no further comments from Rob.
>>
>> Revision history:
>>   v3 =>:
>>   - No changes
>>
>>   v2 => v3:
>>   - Constrain VDR threshold voltage to 48V
>>   - Use standard '-bp' -suffix for the rohm,volt-drop-soc
>>
>>   RFCv1 => v2:
>>   - Add units to rohm,volt-drop-soc (tenths of %)
>>   - Give real temperatures matching the VDR tables, instead of vague
>>     'high', 'normal', 'low', 'very low'. (Add table of temperatures and
>>     use number matching the right temperature index in the VDR table name).
>>   - Fix typoed 'algorithm' in commit message.
>>
>> The parameters are describing the battery voltage drop rates - so they
>> are properties of the battery, not the charger. Thus they do not belong
>> in the charger node.
>>

// snip

> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.example.dtb: battery (simple-battery): 'degrade-cycle-microamp-hours', 'rohm,volt-drop-0-microvolt', 'rohm,volt-drop-1-microvolt', 'rohm,volt-drop-2-microvolt', 'rohm,volt-drop-3-temp-microvolt', 'rohm,volt-drop-soc-bp', 'rohm,volt-drop-temperatures-millicelsius', 'rohm,voltage-vdr-thresh-microvolt' do not match any of the regexes: '^ocv-capacity-table-[0-9]+$', '^pinctrl-[0-9]+$'
> 	from schema $id: http://devicetree.org/schemas/power/supply/battery.yaml
> 

Odd. I am pretty sure I didn't see this when I ran the make 
dt_binding_check. Not 100% sure what happened there. I get this error 
now though when including all the bindings to the check.

Do I get this right - these errors result from the properties used in 
example not being included in the battery.yaml? So, this means that the 
check is done based on the binding (battery.yaml) where the compatible 
(simple-battery) is defined - not based on the properties which are 
present in this file where the example resides, (and which references 
the battery.yaml)?

...

Oh... Now that I wrote it I feel like an idiot.

This approach couldn't work for the validation, right? Let's assume I 
had a VDR battery, and I added a static-battery -node for it. Running 
the validation would pick the battery.yaml based on the compatible (just 
as it does here), and be completely unaware of this vdr-battery.yaml. I 
have no idea why I thought this would work. Probably because I only 
thought this from the documentation POV.

So, as far as I understand, the only viable options are expanding the 
existing battery.yaml with these properties (which I hoped to avoid, see 
below)

 >> The right place for them is the battery node, which is described by the
 >> generic "battery.yaml". I was not comfortable with adding these
 >> properties to the generic battery.yaml because they are:
 >>    - Meaningful only for those charger drivers which have the VDR
 >>      algorithm implemented. (And even though the algorithm is not 
charger
 >>      specific, AFAICS, it is currently only used by some ROHM PMIC
 >>      drivers).
 >>    - Technique of measuring the VDR tables for a battery is not widely
 >>      known. AFAICS, only folks at ROHM are measuring those for some
 >>      customer products. We do have those tables available for some 
of the
 >>      products though (Kobo?).

or, to add new compatible for the "vdr-battery".
AFAICS, adding new compatible would require us to wither duplicate the 
used properties from battery.yaml here (as battery.yaml mandates the 
"simple-battery" - compatible) - or to split the battery.yaml in two 
files, one containing the generic properties, other containing the 
"simple-battery" -compatible and referencing the generic one. Then the 
"vdr-battery" could also reference the generic one.

Any suggestions for the next path to follow?

Oh, and sorry for asking to review something which is obviously not 
working approach. I should've understood this from the beginning.

Yours,
	-- Matti

---
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ