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

[Torreno, Alexis Czezar]

> >>>> 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.
> 

Just to straighten possible mix up of parts/submissions (sad they all start with 'max20')

The parts that have no software override for the enable pin are MAX20912, MAX20916
and other chips that we would be submitting with it (as the original submitter
deferred to us to submit our series instead + the datasheet)

This series deal with MAX20830, and MAX20830C/MAX20840C.
In relation to the discussion above about the enable-gpio and "completeness", the parts
here don't have anything special to their enables.
With the clarification that the DTS goal isn't just to describe for the sake of
mirroring schematics, then this patch I believe can be dropped as well.

Can drop in v3 after the other patches gets reviewed.

Thanks again for the clarification!,
Alexis