| 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
| ||
|
Message-ID: <7ad91325-e881-461d-b39e-6ff15d98b3c5@google.com>
Date: Tue, 25 Nov 2025 15:48:32 -0800
From: Amit Sunil Dhamne <amitsd@...gle.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Sebastian Reichel <sre@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, André Draszik
<andre.draszik@...aro.org>, Lee Jones <lee@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Badhri Jagan Sridharan <badhri@...gle.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Peter Griffin <peter.griffin@...aro.org>,
Tudor Ambarus <tudor.ambarus@...aro.org>,
Alim Akhtar <alim.akhtar@...sung.com>, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
linux-usb@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org, RD Babiera <rdbabiera@...gle.com>,
Kyle Tso <kyletso@...gle.com>
Subject: Re: [PATCH 1/6] dt-bindings: power: supply: Add Maxim MAX77759
charger
On 11/25/25 1:56 AM, Krzysztof Kozlowski wrote:
> On Sun, Nov 23, 2025 at 06:34:05PM -0800, Amit Sunil Dhamne wrote:
>> Hi Krzysztof,
>>
>> On 11/23/25 1:28 AM, Krzysztof Kozlowski wrote:
>>> On 23/11/2025 09:35, Amit Sunil Dhamne via B4 Relay wrote:
>>>> From: Amit Sunil Dhamne <amitsd@...gle.com>
>>>>
>>>> Add bindings for Maxim max77759 charger device.
>>>>
>>>> Signed-off-by: Amit Sunil Dhamne <amitsd@...gle.com>
>>>> ---
>>>> .../power/supply/maxim,max77759-charger.yaml | 36 ++++++++++++++++++++++
>>>> 1 file changed, 36 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max77759-charger.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max77759-charger.yaml
>>>> new file mode 100644
>>>> index 000000000000..71f866419774
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/power/supply/maxim,max77759-charger.yaml
>>>> @@ -0,0 +1,36 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/power/supply/maxim,max77759-charger.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Maxim Integrated MAX77759 Battery charger
>>>> +
>>>> +maintainers:
>>>> + - Amit Sunil Dhamne <amitsd@...gle.com>
>>>> +
>>>> +description: |
>>>> + This module is part of the MAX77759 PMIC. For additional information, see
>>>> + Documentation/devicetree/bindings/mfd/maxim,max77759.yaml.
>>>> +
>>>> + The Maxim MAX77759 is a dual input switch mode battery charger for portable
>>>> + applications. It supports wired and wireless charging and can operate in buck
>>>> + and boost mode.
>>>> +
>>>> +allOf:
>>>> + - $ref: power-supply.yaml#
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: maxim,max77759-charger
>>>> +
>>> This should be just folded into parent node, no need for separate
>>> charger device or is just incomplete.
>> Thanks for the review! You are right, the binding is incomplete. This
>> charger block actually listens on its own I2C address, distinct from the
>> main PMIC.
>>
>> I will update v2 to include the reg property. I will also add the
> AFAIK, the main (parent) device schema does not reference children via
> any sort of addressing, so reg here would not be suitable.
I agree that currently nvmem and gpio devices (which are children of
PMIC device) are not referenced using any address. But I was guessing
that's because they share the i2c client id with the PMIC and sharing
its address space (implied).
The charger device while being part of the MAX77759 PMIC package has
it's own i2c client id and address space that's why I proposed "reg".
The underlying assumption I made was separate client id implies that a
"reg" property required. But maybe that's incorrect.
I can understand the argument against having a "reg" property. As the
i2c client id will remain same for a max77759 charger device (as it's a
chip property and not a board property) it will always remain a
constant. I will drop the "reg" proposal.
>
>> standard properties `constant-charge-current-max-microamp` and
>> `constant-charge-voltage-max-microvolt` to configure the hardware
>> limits, as this charger device does not manage the battery profile
>> directly (that is handled by a separate fuel gauge).
> Well, still, what's the benefit for the bindings to have it as a
> separate child? Kind of depends on your example, which is quite small -
> one regulator and supply. Grow the example with battery and other
> independent resources (if they are) to justify it. Or show arguments why
> this is re-usable.
The primary reasons for keeping the charger as a distinct child node are
to model the hardware topology for the power supply subsystem and to
house the OTG regulator provided by the charger block.
The charger needs to be referenced by the Fuel Gauge (which handles the
battery profile) via power-supplies. Additionally, the charger block
provides a regulator for USB OTG VBUS, which is cleaner to represent as
a child node of the charger rather than mixing it into the top-level
PMIC node.
The final goal is to correctly represent the hardware connections so
that I can use it for [2]. The dts would ideally look like this:
```
maxtcpc: usb-typec@25 {
compatible = "maxim,max77759-tcpci";
...
otg-vbus-supply = <&otg_vbus_reg>;
};
pmic@66 {
compatible = "maxim,max77759";
....
chg: charger {
compatible = "maxim,max77759-charger";
power-supplies = <&maxtcpc>;
otg_vbus_reg: usb-otg-vbus-regulator {
regulator-name = "usb-otg-vbus"
};
};
};
battery: battery {
compatible = "simple-battery";
....
};
fuel-guage@36 {
compatible = "maxim,max77759-fg";
....
power-supplies = <&chg>;
monitored-battery = <&battery>;
};
```
[1]
https://lore.kernel.org/all/20250915-b4-gs101_max77759_fg-v6-0-31d08581500f@uclouvain.be/
[2]
https://lore.kernel.org/all/20250507-batt_ops-v2-0-8d06130bffe6@google.com/
BR,
Amit
>
> Best regards,
> Krzysztof
>
Powered by blists - more mailing lists