spi: orion: fix CS GPIO handling again
authorJan Kundrát <jan.kundrat@cesnet.cz>
Mon, 4 Jun 2018 14:34:25 +0000 (16:34 +0200)
committerMark Brown <broonie@kernel.org>
Tue, 19 Jun 2018 12:06:51 +0000 (13:06 +0100)
commitfb9acf5f1f21f1de193523ff780bda375b4c2e21
treed9c5048e5ff1a6014cbd4e198f93158890e7a715
parent931c4e9a72ae91d59c5332ffb6812911a749da8e
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>
drivers/spi/spi-orion.c