The current spi-imx driver completely fails when used with more than four (gpio) chip-selects, since the chip select number is used unconditionally as shift amount when updating the control and configuration registers, so the code ends up modifying random bits outside the intended fields. This fixes it by making use of the unused_native_cs variable filled in by the spi core, and use that as the "channel number" for all gpiod chip selects. In the presumably common case where all chip selects are gpios, this means we end up using channel 0 exclusively, so the optimization where the config register is left alone if it is unchanged (see 184434fcd617) might become less effective, if the workload consists of different slaves with differing spi modes being accessed one after the other. It would be nice if one could make use of the unused native chip selects in a round-robin manner, but for that the core would have to tell us not just unused_native_cs, but the whole ~native_cs_mask from spi_get_gpio_descs(). Maybe a simpler fix, if there is anything to fix, is to make the new mx51_ecspi_channel() do if (!spi->cs_gpiod || spi->controller->num_chipselect <= 4) Rasmus Villemoes (3): spi: spi-imx: use "controller" variable consistently in spi_imx_probe() spi: spi-imx: set max_native_cs for imx51/imx53/imx6 variants spi: spi-imx: fix use of more than four chipselects drivers/spi/spi-imx.c | 56 +++++++++++++++++++++++++++---------------- 1 file changed, 35 insertions(+), 21 deletions(-) -- 2.37.2