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

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Sun, 20 Mar 2022 13:56:18 -0400
Rob Herring <robh@kernel.org> wrote:

> On Sun, Mar 20, 2022 at 03:15:25PM +0000, Jonathan Cameron wrote:
> > On Fri, 11 Mar 2022 17:15:59 +0100
> > michael.srba@seznam.cz wrote:
> >   
> > > From: Michael Srba <Michael.Srba@seznam.cz>
> > > 
> > > ICM-20608-D differs from the other ICM-20608 variants by having
> > > a DMP (Digital Motion Processor) core tacked on.
> > > Despite having a different WHOAMI register, this variant is
> > > completely interchangeable with the other ICM-20608 variants
> > > by simply pretending the DMP core doesn't exist.
> > > 
> > > Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
> > > ---
> > > changelog:
> > >  - v2: require specifying "invensense,icm20608" as a fallback compatible  
> > 
> > Apologies that I joined the thread for v1 late, but no. That doesn't work.
> > If the older driver before the new ID is present with this binding
> > it won't probe because of the WHOAMI value difference so it's not
> > compatible.
> > 
> > I'm fine with the v1 version.  
> 
> If the driver didn't check WHOAMI then it would be compatible. So does 
> driver implementation determine what's compatible or not? It shouldn't 
> as those are supposed to be decoupled.

OK. That decoupling needs perhaps to be more clearly stated as it wasn't
something I was keeping an eye open for in drivers.

It does check them and warns if there isn't a match. This is partly historical
because we had board implementers switch to an 'mostly' compatible part
that was fine with their software stack but not with the Linux drivers and
those bugs were hard to diagnose. We didn't support he particular WHOAMI
at the time so the check was dded.

The code could be improved as it carries on using the chip
specified when it should perhaps use the one matched on WHOAMI.  
The discussion of the original patch that added the check
"iio: inv_mpu6050: Check WHO_AM_I register on probe"
included a request for such a change as a follow up patch.
I guess that never showed up.

The driver supports a bunch of parts that aren't completely compatible
from a register interface point of view + we have other drivers supporting
additional parts. The particular question of which part is supported
by what driver is a choice that other software stacks may have made
differently. So we can't have a general compatible covering everything
supported by the driver.

Having said that we could do subsets where a particular compatible
maps to some of the supported parts where the compatibility is such that
it is unlikely another OS would chose to support them with different
drivers.

> 
> Generally, if there are h/w id registers, then we'll rely on them and 
> don't need a compatible for every variant.

I don't mind the driver moving to that model, but it's not true today
and we'd still have to be careful with what we describe with each
compatible.

Jonathan
> 
> Rob