Re: [PATCH v2 1/5] dt-bindings: hwmon: (pmbus/max20830): add enable-gpios property and complete examples

[Guenter Roeck]

On 7/10/26 03:13, Krzysztof Kozlowski wrote:
> On Mon, Jul 06, 2026 at 09:33:32AM -0700, Guenter Roeck wrote:
> > On 7/6/26 00:13, Torreno, Alexis Czezar wrote:
> > > > On Mon, Jul 06, 2026 at 10:08:41AM +0800, Alexis Czezar Torreno wrote:
> > > > > Adding an entry for the MAX20830 EN (enable) pin. This pin exist but
> > > > > was not included before. Also edited examples entry to be more complete.
> > > > >
> > > > > Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@xxxxxxxxxx>
> > > > > ---
> > > > >    .../devicetree/bindings/hwmon/pmbus/adi,max20830.yaml         | 11
> > > > +++++++++++
> > > > >    1 file changed, 11 insertions(+)
> > > >
> > > > How did you address previous feedback?
> > >
> > > Regarding the enable pin, I added this since I know bindings like being complete
> > > and saw that I didn't add it the first time I submitted max20830.
> > > I added driver code for the gpio but learned that it wasn't really a use case so
> > > I simply dropped the patch for it.
> >
> > I guess I am completely missing the point here. I can not imagine a situation
> > where one would want to connect the enable pin to a driver-controlled GPIO pin,
> > or why would one connect the chip's PGOOD output pin to a GPIO input pin
> > and connect that back to the driver.
> >
> > I think we will need guidance from devicetree maintainers explaining what
> > "complete" means in such a context to avoid having to repeat this discussion
> > for every driver going forward.
>
> I think complete means all reasonable hardware resources/properties,
> regardless whether current OS implementation uses them or not. That's
> why if there is enable-gpios which is not used by Linux but could be in
> the future, then it should be documented.
>
> However if you claim that enable-gpios will absolutely NEVER be used by
> Linux or bootloader or any other DT bindings user (*BSD, Barebox, U-boot
> etc), then I would skip it, just like we do not describe many other
> parts which simply have no use for the software.
>
> IOW, DTS is description of non-discoverable hardware for the software.
> We do not describe hardware for the sake of description, to mirror
> schematics. That's not the goal. The goal is to make some software
> happy, even if this is a future software implementation.
>
> What is the case here - I rely on your guidance whether enable-gpios can
> EVER be used by software. If there is a chance, then IMO property could
> stay.

Unfortunately, as it turns out, some of the chips handled by this driver
do _not_ implement software-override for the enable pin (or at least so I
am told; the chip datasheets are not public). Given that, we will have
to support the enable pin property.

Sorry, I was not aware of this detail.

Guenter