On Tue, 27 Dec 2022 09:40:13 +0100 Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> 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@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. 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 >
