Re: [PATCH] spi: tegra114: initialize native chip selects inactive

[Abraham Zukor <abe@maticrobots.com>]

On 28/07/2026 22:09, Jon Hunter wrote:
> I am a bit reluctant to make this change after 10+ years of this driver
> being around.

That is fair, and v1 deserved it. I have sent a v2 that only touches
chip selects the device tree describes:

  https://lore.kernel.org/r/20260731030134.4182688-1-abe@maticrobots.com/

The steady state is unchanged - tegra_spi_setup() already programs these
bits for each device, so only the window before that runs changes, and
only for active-low devices. Nothing the device tree does not describe is
touched at all.

> Right. Although this patch is specific to Tegra, I am guessing that
> other devices could also face similar issues and therefore, it would
> seem that having a generic facility to scan the devices would be ideal.

The window exists because __spi_add_device() calls __spi_setup() and then
device_add() per child, so of_register_spi_devices() runs setup(0),
add(0), setup(1), add(1) - device 0's driver can transfer before device
1's chip select has been configured. The comment above that __spi_setup()
call already notes that devices using SPI_CS_HIGH "can't coexist well
otherwise".

Splitting __spi_add_device() into a prepare half and a publish half, and
having of_register_spi_devices() prepare every child before publishing
any, would close it for every controller with a programmable chip select
idle level. The awkward part is that the duplicate chip select check
uses bus_for_each_dev(), so it only sees published devices and would
need to consider the pending ones too.

That is a larger change than I want to put in front of a fix, and it
would not help a chip select that never gets an spi_device at all, such
as a disabled node. So I do not think the two are alternatives - the core
change would subsume the declared sibling half of this patch and leave
the rest.

Thanks,
Abe