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@xxxxxxxxxxxxxx> wrote: >> >>> On 22-12-23, Jonathan Cameron wrote: >>>> On Fri, 23 Dec 2022 16:03:38 +0100 >>>> Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote: >>>> >>>>> On 22-12-23, Jonathan Cameron wrote: >>>>>> On Wed, 21 Dec 2022 10:27:59 +0100 >>>>>> Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote: >>>>>> >>>>>>> The TMP116 is the predecessor of the TMP117. >>>>>>> >>>>>>> Signed-off-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx> >>>>>> 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
