On Thu, Feb 27, 2025 at 7:14 AM André Draszik <andre.draszik@xxxxxxxxxx> wrote: > > On Thu, 2025-02-27 at 07:04 -0600, Rob Herring wrote: > > On Wed, Feb 26, 2025 at 05:51:22PM +0000, André Draszik wrote: > > > The Maxim MAX77759 is a companion PMIC for USB Type-C applications and > > > includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C > > > Port Controller (TCPC), NVMEM, and a GPIO expander. > > > > > > This describes the top-level device. > > > > > > Signed-off-by: André Draszik <andre.draszik@xxxxxxxxxx> > > > > > > --- > > > v2: > > > * rename expected nvmem subdev nodename to 'nvmem-0' > > > I'd have preferred just 'nvmem', but that matches nvmem-consumer.yaml > > > and fails validation. > > > > > > Note: MAINTAINERS doesn't need updating, the binding update for the > > > first leaf device (gpio) adds a wildcard matching all max77759 bindings > > > --- > > > .../devicetree/bindings/mfd/maxim,max77759.yaml | 104 +++++++++++++++++++++ > > > 1 file changed, 104 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml > > > new file mode 100644 > > > index 0000000000000000000000000000000000000000..87e3737896a289998a18b67932dbccacfb8e3150 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml > > > @@ -0,0 +1,104 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mfd/maxim,max77759.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Maxim Integrated MAX77759 PMIC for USB Type-C applications > > > + > > > +maintainers: > > > + - André Draszik <andre.draszik@xxxxxxxxxx> > > > + > > > +description: | > > > + This is a part of device tree bindings for the MAX77759 companion Power > > > + Management IC for USB Type-C applications. > > > + > > > + The MAX77759 includes Battery Charger, Fuel Gauge, temperature sensors, USB > > > + Type-C Port Controller (TCPC), NVMEM, and a GPIO expander. > > > + > > > +properties: > > > + compatible: > > > + const: maxim,max77759 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + interrupt-controller: true > > > + > > > + "#interrupt-cells": > > > + const: 2 > > > + > > > + gpio-controller: true > > > + > > > + "#gpio-cells": > > > + const: 2 > > > > Why do you have GPIO properties here and in the child node? Either would > > be valid, but both probably not. Putting them here is actually > > preferred. > > That's an oversight, I meant to put them into the child only, not here, > since the child is the one providing the gpio functionality. > > What's the reason to have it preferred inside this parent node? It really depends whether the GPIO block is a separate sub-block which is going to get reused or has its own resources or not. It's the same thing in system controllers which are often just a collection of leftover control bits. We just don't want child nodes created just for the ease of instantiating drivers in Linux. While it's nice if drivers and nodes are 1 to 1, but that's specific to an OS. You already need other child nodes here, so I don't care too much in this case. Rob
