Re: [PATCH 1/2] dt-bindings: iio: imu: mpu6050: Document invensense,icm20608d

[Krzysztof Kozlowski <krzk@kernel.org>]

On 21/03/2022 16:04, Jonathan Cameron wrote:
> On Mon, 21 Mar 2022 09:04:11 +0100
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
>> On 20/03/2022 16:12, Jonathan Cameron wrote:
>>> On Thu, 10 Mar 2022 22:24:03 +0100
>>> Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> 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