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

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

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.

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.

Best regards,
Krzysztof