RE: [PATCH v3 2/6] dt-bindings: iio: imu: Add bindings for ADI ADIS16607

[Sabau, Radu bogdan]

> -----Original Message-----
> From: Jonathan Cameron <jic23@xxxxxxxxxx>
> Sent: Saturday, October 17, 2026 4:12 AM

...

> >
> > Add device tree bindings for the Analog Devices ADIS16607 Precision
> > MEMS Inertial Measurement Unit. The ADIS16607 integrates a triaxial
> > gyroscope, triaxial accelerometer, and temperature sensor, and
> > communicates over SPI Half-Duplex.
> >
> > Two variants are supported: adis16607-2 and adis16607-3.
> 
> Say briefly how they are different and hence require their
> own compatibles.

Hi Jonathan, thank you for looking at this, as well.

The only difference between them is the gyroscope's fixed full-scale
range: ±450°/s for adis16607-2, ±2000°/s for adis16607-3. Everything
else (accelerometer range, decimation, internal clock, sync modes) is
identical, and both report the same device ID over SPI, so the driver
has no way to tell which gyro range is populated at runtime - the
compatible string is the only source of that information. I'll make
the commit message say this explicitly.

> 
> The hardware rest being a configurable pin is an unusual
> bit of hardware design given how do we reset the reset pin
> to issue a reset if the device is hung?
> 

I agree the hardware reset being configurable is unusual. GPIO0 is configured
as reset by default at power-up, so the driver probing at power-up is ok.
However, to answer your question if the USER_GPIO_CFG register is altered
by debugfs read or a bug or something else and the device is hung, the true
answer is you can't use hardware reset anymore and the only way out of this
would be a power-cycle.

Perhaps a force write of the RESET_GPIO_MASK before the initial_startup
would help in case the SPI communication would still be alive, and I guess
if the SPI communication is broken we would then get an errno code anyway,
right? I am not sure this is the best solution so I would like to know your 
thoughts on this.

> >
> > The binding exposes optional properties for:
> >   - An external clock for sync mode (falling back to the internal 8 kHz
> >     clock when absent)
> >   - A hardware reset GPIO (active low)
> >

...

> > +  reset-gpios:
> > +    description:
> > +      Optional GPIO for hardware reset. The line is active low.
> > +    maxItems: 1
> 
> The datasheet I looked at has 4 gpio pins. You are calling out one
> as reset.  What happens if we don't have controllable supplies
> and someone else (firmware for instance) configured GPIO0 to not
> be reset?
> 
> Anyhow, feels like this isn't a full description.
> 

Indeed, this is not a full description. There are a total of 5 gpio pins to
this device and each one has a fixed function, the USER_GPIO_CFG is
more like an enable/disable register I would say. So RESET is either
GPIO0 or idle to say so.

Would you say that a description like this would be more suitable? :

reset-gpios:
    description:
      Optional GPIO for hardware reset, active low. Of the device's
      five GPIO pins, this one is dedicated to the reset function,
      which can be independently enabled or idled via an on-chip
      register.
    maxItems: 1