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

[Amit Sunil Dhamne]

On 12/2/25 5:00 AM, Krzysztof Kozlowski wrote:
> On 26/11/2025 00:48, Amit Sunil Dhamne wrote:
> > 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@xxxxxxxxxx>
> > > > > >
> > > > > > Add bindings for Maxim max77759 charger device.
> > > > > >
> > > > > > Signed-off-by: Amit Sunil Dhamne <amitsd@xxxxxxxxxx>
> > > > > > ---
> > > > > >    .../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@xxxxxxxxxx>
> > > > > > +
> > > > > > +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
> You do not need children for that at all.

Actually what you said makes sense. I will fold the charger's schema 
into mfd/maxim,max77759's schema.


Thanks,

Amit

> > 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.
> Sorry but argument that you need a child device to be able to construct
> a phandle is just wrong. You can create phandles on every other way as well.
>
>
> Best regards,
> Krzysztof