Re: [PATCH v2 2/4] dt-bindings: iio: ti,tmp117: add binding for the TMP116

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 27 Dec 2022 09:40:13 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 23/12/2022 18:13, Marco Felsch wrote:
> > Hi Jonathan,
> > 
> > On 22-12-23, Jonathan Cameron wrote:  
> >> On Fri, 23 Dec 2022 17:10:51 +0100
> >> Marco Felsch <m.felsch@pengutronix.de> wrote:
> >>  
> >>> On 22-12-23, Jonathan Cameron wrote:  
> >>>> On Fri, 23 Dec 2022 16:03:38 +0100
> >>>> Marco Felsch <m.felsch@pengutronix.de> wrote:
> >>>>     
> >>>>> On 22-12-23, Jonathan Cameron wrote:    
> >>>>>> On Wed, 21 Dec 2022 10:27:59 +0100
> >>>>>> Marco Felsch <m.felsch@pengutronix.de> wrote:
> >>>>>>       
> >>>>>>> The TMP116 is the predecessor of the TMP117.
> >>>>>>>
> >>>>>>> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>      
> >>>>>> I'm not sure this is introducing a valid fallback. The driver changes
> >>>>>> imply some things the tmp117 driver supports, that this device
> >>>>>> does not. A fallback compatible would mean that a new DT
> >>>>>> with an old kernel would load the tmp117 against a tmp116 and
> >>>>>> expect it to fully work.      
> >>>>>
> >>>>> Since driver does all the detection an update of the bindings isn't
> >>>>> really necessary. It is just to have a compatible already in place in
> >>>>> case there a things we can't detected during runtime. This flow is
> >>>>> common for a lot of SoC drivers. The fallback will be used as long as
> >>>>> possible and once a specific feature can't be detected only via the
> >>>>> binding, the driver adds the new binding to it of_compatible.    
> >>>>
> >>>> That's true going forwards and for drivers that introduce a shared
> >>>> generic compatible alongside the initial binding. It can't be easily
> >>>> retrofit.
> >>>>
> >>>> Fallback compatible is also to allow this to work with old kernels    
> 
> Yes, if the devices are compatible, e.g. there is no need to change in
> the driver to support new device.
> 
> If the devices need auto-detection and are compatible in an auto-detect
> way, then I don't think we have such goal.
> 
> >>>
> >>> What this small series does is adding the support for the chip. So the
> >>> support starts with the kernel version which includes these patches. Why
> >>> do you assume that one expect to have a proper support with an older
> >>> kernel? I fully get the point that driver needs to deal with older
> >>> device-tree's but having using a newer device-tree's (fw) on older
> >>> kernels and expecting that older kernels does support the chip is a bit
> >>> odd to me.  
> >>
> >> Probably need the DT maintainers to offer the opinion on this as we
> >> disagree on how fallback compatibles are supposed to work.
> >> I'll accept whatever they say on this point (I've been persuaded
> >> into a more relaxed stance in the past on this).  
> 
> DTS can be used outside of kernel - other projects or new DTS with old
> kernel - and the way of working is bound by bindings. Therefore it is
> really good if you use new DTS with older kernel and it works.
> 
> As I said above, for devices that are fully compatible, this should be
> the goal. Many SoC components are like this and we describe them that
> way. However they do not have mostly auto-detection.
> 
> Now for devices which are both:
>  - compatible according to the binding (so the interface is the same,
> stable and handled by Linux),
>  - AND actually significantly different, where the difference is
> recognized by auto-detection,
> the Linux should be reasonable and it might freely choose not to support
> unknown devices.

Ok. In this case my gut feeling would be that a new ID and no fallback
is the best balance.  Ironically if we'd had a binding for the tmp116 first
and fell back to that from the tmp117 we'd probably be fine (just
have fewer features).  I guess nothing stops us documenting that binding
even though the tmp117 is already used to match in Linux.

> 
> You can compare it to the world without DT where everything is
> auto-detectable. The Linux kernel performs auto-detection and based on
> this either works or does not work with the device. But the kernel has
> full discretion to decide about it.
> 
> Users would be happy if kernel would work with unknown, new devices. But
> also users would be unhappy if this damages their system because of e.g.
> wrong voltage.

Agreed - using old code is a nice to have, but not always the best choice.

Jonathan

> 
> Best regards,
> Krzysztof
>