mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-10-16 22:39:48 +00:00
spi: rspi: Fix register initialization while runtime-suspended
commit42bdaaece1upstream. The Renesas RSPI/QSPI driver performs SPI controller register initialization in its spi_operations.setup() callback, without calling pm_runtime_get_sync() first, which may cause spurious failures. So far this went unnoticed, as this SPI controller is typically used with a single SPI NOR FLASH containing the boot loader: 1. If the device's module clock is still enabled (left enabled by the bootloader, and not yet disabled by the clk_disable_unused() late initcall), register initialization succeeds, 2. If the device's module clock is disabled, register writes don't seem to cause lock-ups or crashes. Data received in the first SPI message may be corrupted, though. Subsequent SPI messages seem to be OK. E.g. on r8a7791/koelsch, one bit is lost while receiving the 6th byte of the JEDEC ID for the s25fl512s FLASH, corrupting that byte and all later bytes. But until commita2126b0a01("mtd: spi-nor: refine Spansion S25FL512S ID"), the 6th byte was not considered for FLASH identification. Fix this by moving all initialization from the .setup() to the .prepare_message() callback. The latter is always called after the device has been runtime-resumed by the SPI core. This also makes the driver follow the rule that .setup() must not change global driver state or register values, as that might break a transfer in progress. Fixes:490c97747d("spi: rspi: Add runtime PM support, using spi core auto_runtime_pm") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org> [bwh: Backported to 3.16: s/(controller|ctlr)/master/g] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This commit is contained in:
parent
a3d313e330
commit
2987155e8f
1 changed files with 16 additions and 23 deletions
Loading…
Add table
Add a link
Reference in a new issue