On Sat, Aug 01, 2026 at 03:23:10AM +0100, Jonathan Cameron wrote: > On Tue, 28 Jul 2026 20:43:50 +0200 > Jorijn van der Graaf wrote: > > > A WHOAMI value differing from the one the compatible implies aborts > > probe with -ENODEV, preventing a register-compatible part described > > with a fallback compatible from probing at all. > > > > The devicetree compatible is authoritative for which part is fitted: > > drop the check, and with it the now-unused whoami definitions. No > > warning replaces it, since probing via a fallback compatible is > > legitimate use, not a condition to report. This changes the probe > > outcome on mismatch for all parts the driver supports. > > > > Tested via a backport to a Fairphone 6 running a 7.1-based kernel: its > > ICM-42630 (WHOAMI 0x0C), described with an icm42631 fallback compatible > > and matched as icm42631, probes silently, and accelerometer, gyroscope > > and temperature reads work. > > > > Suggested-by: Conor Dooley > > Link: https://lore.kernel.org/all/20260722-creature-volley-0f083b904c1d@spud/ > > Link: https://lore.kernel.org/all/20260728-extradite-yanking-42d918637f61@spud/ > > Assisted-by: Claude:claude-fable-5 > > Signed-off-by: Jorijn van der Graaf > > Hi Jorijn, > > I'm open to other opinions, particularly from those who are using > this driver but I think dropping any form of hint that the device isn't > the one we expect is too far when previous we just failed to probe. FWIW, what I don't want is warning or error level printouts, so something informational is tolerable to me. > > We have a lot of drivers that issue such a print and my understanding > is that has been useful. If we want to make it non threatening we could > phrase it as something like "Device ID XX is not the YY associate with the > FW specified device, probably using a valid fallback compatible". That > would still provide the breadcrumb for anyone seeing an unexpected > part change on their device vs the DT. >