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

[Krzysztof Kozlowski <krzk@kernel.org>]

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@analog.com>
> > > > ---
> > > >   .../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.

Also, no harm will be done if we skip this property and we add it later
in the future when actual use appears. Maybe no need to spend time on
discussing such triviality and instead just skip it.

Best regards,
Krzysztof