On 21/03/2022 16:04, Jonathan Cameron wrote: > On Mon, 21 Mar 2022 09:04:11 +0100 > Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > >> On 20/03/2022 16:12, Jonathan Cameron wrote: >>> On Thu, 10 Mar 2022 22:24:03 +0100 >>> Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote: >>> >>>> On 10/03/2022 19:56, Michael Srba wrote: >>>>> Hi, >>>>> the thing is, the only reason the different compatible is needed at all >>>>> is that the chip presents a different WHOAMI, and the invensense,icm20608 >>>>> compatible seems to imply the non-D WHOAMI value. >>>> >>>> But this is a driver implementation issue, not related to bindings. >>>> Bindings describe the hardware. >>> >>> Indeed, but the key thing here is the WHOAMI register is hardware. >>> >>>> >>>>> I'm not sure how the driver would react to both compatibles being present, >>>>> and looking at the driver code, it seems that icm20608d is not the only >>>>> fully icm20608-compatible (to the extent of features supported by >>>>> the driver, and excluding the WHOAMI value) invensense IC, yet none >>>>> of these other ICs add the invensense,icm20608 compatible, so I guess I >>>>> don't see a good reason to do something different. >>>> >>>> Probably my question should be asked earlier, when these other >>>> compatibles were added in such way. >>>> >>>> Skipping the DMP core, the new device is fully backwards compatible with >>>> icm20608. >>> >>> No. It is 'nearly' compatible... The different WHOAMI value (used >>> to check the chip is the one we expect) makes it incompatible. Now we >>> could change the driver to allow for that bit of incompatibility and >>> some other drivers do (often warning when the whoami is wrong but continuing >>> anyway). >> >> Different value of HW register within the same programming model does >> not make him incompatible. Quite contrary - it is compatible and to >> differentiate variants you do not need specific compatibles. > > Whilst I don't personally agree with the definition of "compatible" > and think you are making false distinctions between hardware and software... > > I'll accept Rob's statement of best practice. However we can't just > add a compatible that won't work if someone uses it on a new board > that happens to run an old kernel. > The please explain me how this patch (the compatible set I proposed) fails to work in such case? How a new board with icm20608 (not icm20608d!) fails to work? To remind, the compatible has a format of: comaptible = "new", "old" e.g.: "invensense,icm20608d", "invensense,icm20608" Best regards, Krzysztof
