spi: imx: Fix failure path leak on GPIO request error
If the code that requests any chip select GPIOs fails, the cleanup of spi_bitbang_start() by calling spi_bitbang_stop() is not done.
Fix this by moving spi_bitbang_start() to after the code that requets GPIOs. The GPIOs are dev managed and don't need explicit cleanup. Since spi_bitbang_start() is now the last operation, it doesn't need to be cleaned up in the failure path.
CC: Shawn Guo <shawnguo@...> CC: Sascha Hauer <kernel@...> CC: Fabio Estevam <fabio.estevam@...> CC: Mark Brown <broonie@...> Reviewed-by: Oleksij Rempel <o.rempel@...> Signed-off-by: Trent Piepho <tpiepho@...> Signed-off-by: Mark Brown <broonie@...>
Seems to be the culprit; I think you might be missing the chip-select pin, no?
That one looked innocent to me, but it is indeed the only change in spi-imx.c between the two commits I mentioned. It feels quite odd that no one would have noticed the regression in a month time. Just to be sure, the relevant snippet from the device tree file:
/* Test device */ spidev1_0: spi@0 { compatible = "spidev", "rohm,dh2228fv"; /* spidev driver needs this entry to avoid runtime warning */ reg = <0>; spi-max-frequency = <5000000>; #ifndef SPIDEV_SPI1_ENABLE status = "disabled"; #else status = "okay"; #endif }; };
SPIDEV_SPI1_ENABLE is not defined; it is a terrible kludge to produce a separate device tree file where we can have direct SPI access to the microchip radio during test. If someone has a better idea, please let me know. Creating a DT overlay came to mind, but I haven't got around it yet.
