Re: [PATCH 1/2 v2] spi: add SPI_MOSI_IDLE_LOW support from device tree

[Marcelo Schmitt]

On 03/29, Couret Charles-Antoine wrote:
> Le 29/03/26 à 16:25, Marcelo Schmitt a écrit :
> > Hello Charles-Antoine,
> > 
> > On 03/29, charles-antoine.couret@xxxxxxx wrote:
> > > From: Charles-Antoine Couret <charles-antoine.couret@xxxxxxx>
> > > 
> > > This flag was introduced but was not added as device tree property which is
> > > limiting the possibility to use this flag on real devices.
> > I'm not seeing why a device tree property is needed for SPI idle modes. For
> > idling high, the configuration is requested through spi_setup(). It should
> > work in similar way for idling low. See spi-summary.rst. If believe a dt
> > property is needed despite the spi_setup() interface, can you elaborate on why?
> 
> Hi Marcelo,
> 
> You're right that for a compliant SPI device, this devicetree option is not
> really relevant and this must be in the driver itself. However, I think the
> purpose of this mode is itself not designed for compliant SPI devices.
> 
> It's not unusual to use Linux SPI subsystem for devices which are not fully
> compliant with SPI in embedded context and where both options (idle low or
> idle high) can make sense based on hardware design around the device or the
> feature that you want. So having this property in device tree is documenting
> the hardware then giving more flexibility.

I agree that having an spi-mosi-idle property in dt can make the hw description
more complete. I'm not seeing how that would provide more flexibility to device
configuration. Do the controller or anything else needs to check whether a
peripheral needs a particular MOSI idle mode before the peripheral driver probes
the device itself?

> For example we used that to communicate with TI DAC161P997 device, where
> "IDLE low" setting can be used to detect when the device is really powered
> or not. But this is an optional setting, this option does not affect the
> rest of the driver.

Can't that be done with the existing support for idle modes? E.g.
		spi->mode |= SPI_MOSI_IDLE_LOW;
		ret = spi_setup(spi);
		if (ret < 0) {
			/* No controller MOSI idle low support. */
			/* Can't verify device is powered on. Return or do something else. */
		}
		/* MOSI idle low support. Verify the device is powered on. */

> I can understand this is a corner case and you don't want to support it at
> all, I thought this can be interesting to provide it anyway. If you want to
> reject it, I understand.
> 
Not rejecting neither accepting. I just don't see benefit of having an
spi-idle-mode prop from the mentioned use case.