spi: orion: fix CS GPIO handling again

The code did not de-assert any CS GPIOs before probing slaves. This
means that several CS signals could be active at once, garbling the
communication. Whether this was actually a problem depended on the type
of the SPI device attached (so my "spidev" for userspace access worked
correctly because its probe was effectively a no-op), and on the state
of the GPIO pins at SoC's boot.

The code was already iterating through all DT children of the SPI
controller, so this change re-uses that loop for CS GPIO setup as well.
This means that this might change the number of the HW CS signal which
is picked for all GPIO CS devices. Previously, the lowest one was used,
but we now use the first one from the DT.

With this move of the code, we can also finally initialize each GPIO CS
lane before registering the SPI controller (which in turn probes for
slaves).

I tried to fix this in 544248623b95 already, but that only did it half
way by registering the GPIOs properly. That patch failed to set their
logic signals early enough, though.

Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Mark Brown <broonie@kernel.org>

0 files changed, 0 insertions, 0 deletions