Re: SPI driver probe problem during boot

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Tue, May 5, 2020 at 11:04 AM Martin Townsend <mtownsend1973@xxxxxxxxx> wrote:

> I've just finished debugging a SPI comms problem for a TPM device on a
> TI Sitara AM4372 SoC.  The SPI bus has 3 devices
>
> 1) CAN FD Controller 0 (Using native CS)
> 2) CAN FD Controller 1 (Using GPIO for CS)
> 3) TPM Device (Using GPIO for CS)
>
> All CS are active low.
>
> During boot the TPM would fail it's probe but if I unbind and then
> rebind the driver after boot the TPM would work fine so I got the
> logic analyser out to probe the SPI bus and could see that the voltage
> on the MISO line was half the expected voltage whilst the TPM was
> being probed and this was due to CS0 being driven low for this period
> of time.  After the TPM was probed the CS0 went high.  After debugging
> this I found that the OMAP SPI controller defaults internal CS lines
> to active high so when the SPI master controller is initialised this
> is the state of CS0 so it's driven low for inactive.  During the probe
> of the SPI master controller it calls devm_spi_register_master ->
> spi_register_master which calls of_register_spi_devices which will add
> the devices to the SPI master controller via spi_add_device.  This
> function would call device_add. Due to the way the device tree is
> parsed the SPI devices above are enumerated from the highest CS to the
> lowest so the TPM device is setup first.  When device_add is called it
> triggers it's probe function but the SPI bus hasn't been setup yet and
> hence the TPM driver tries to communicate with the TPM device whilst
> CS0 is being driven low causing the CAN FD controller to also respond
> reducing the voltage on the MISO line.  In spi_device_add it calls
>
> status = spi_setup(spi);
>
> which would setup the CS lines so I modified the
> of_register_spi_devices function to make it a 2 phase operation so the
> CS lines are all setup and then it iterates of the SPI devices a
> second time to add them to the driver model via device_add and the TPM
> now probes fine.

...

> Now this is on a oldish kernel (4.12) and moving the kernel forward
> isn't trivial.  I was just wondering if this has been fixed already so
> I could backport it, I couldn't see anything in the latest kernel but
> maybe it has been solved a different way.  If not is there a better
> way of fixing this? Or is the OMAP SPI controller driver the problem,
> should it parse the child nodes first and set itself up accordingly?

Can you confirm the issue on v5.7-rc4?

-- 
With Best Regards,
Andy Shevchenko