Fix condition for deactivating chipselect after processing of spi_message - if cs_change==0, chipselect should not be touched and left active for next spi_message to follow. Signed-off-by: Jan Nikitenko --- I am not sure about the meaning of spi message transfer cs_change attribute. I assume that non-zero cs_change indicate that chipselect should be toggled between spi_transfers. What about cs_change in last spi_transfer of spi_message? Should zero cs_change provide hinting that chipselect should be left active, because spi_message to follow will be for the same spi device? If that is so, the handling in spi_bitbang.c would be incorrect, because chipselect would be deactivated when cs_change==0. Or is the meaning of cs_change in the last spi_transfer of spi_message different than in previous spi_transfers in single spi_message? Like cs_change==0 in last spi_transfer would indicate to deactivate chipselect and cs_change!=0 in last spi_transfer would provide hinting that next spi_message will be for the same spi device and chipselect should be left active? If that is so, it's quite confusing (and not documented), as the meaning of cs_change in the last spi_transfer would be opposite than in other spi_transfers in single spi_message. The patch here fixes the condition for the case that cs_change meaning is the first variant described. spi_bitbang.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)