linux-kernel - Re: [PATCH 1/6] dt-bindings: power: supply: Add Maxim MAX77759 charger

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] [day] [month] [year] [list]

Message-ID: <20251125-amorphous-bobcat-of-whirlwind-afdab1@kuoka>
Date: Tue, 25 Nov 2025 10:56:51 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Amit Sunil Dhamne <amitsd@...gle.com>
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 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.

> 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.

Best regards,
Krzysztof