Message-ID: <076777c3-b238-4d1d-a11b-602027348ee4@kernel.org>
Date: Tue, 2 Dec 2025 14:00:39 +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 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@...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 

You do not need children for that at all.

> 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

Powered by blists - more mailing lists