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

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 19 Oct 2026 08:15:41 +0000
"Sabau, Radu bogdan" <radu.sabau@analog.com> wrote:

> > -----Original Message-----
> > From: Jonathan Cameron <jic23@kernel.org>
> > 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.

Good. A one liner to say scales differ in the commit message will do nicely.

> 
> > 
> > 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.

Yeah. I think try to write it - but only warn if write fails rather
than error out.  Gives us the best chance of recovering from any
problems.

> 
> > >
> > > 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.
Only talk about this one in this description.
But add the pins with appropriate names for the functions the others
support.  The GPIOX naming is silly given they are only good for
one thing each.  Just make sure to add something in the comment
to refer to what they are called on the datasheet.

Jonathan


>     maxItems: 1
>