Aspeed SPI driver upstreaming

[Cédric Le Goater]

Hello,

On 1/7/20 12:27 AM, Patrick Williams wrote:
> Cedric, Joel,
> 
> There is currently the aspeed-smc driver[1], which is upstreamed, but only
> supports spi-nor devices.  

Upstream lacks read training.

> There also a more generic spi-aspeed
> driver[2], which might only exist in Facebook kernel trees, that
> supports all spi devices but it doesn't do the calibration work.
> 
> I made some changes to the spi-aspeed driver recently in order to get it
> to somewhat support TPM 2.0 devices (*).  The spi-aspeed driver also
> already supported generic spi-nor MTD devices, but just at a slower
> speed than aspeed-smc due to missing the calibration routines.

Yes. That is the problem.

> Tao mentioned to me that there was a discussion at one of the F2F events
> in 2019 about combining those two drivers and getting them upstreamed,
> but that the hang-up was getting upstream mtd and spi subsystems to
> agree on how to handle calibration routines in the spi subsystem?  I
> can't seem to find anything about this on the LKML.  Do either of you
> know where that discussion went and what the current state / plans of
> upstreamming a generic Aspeed SPI driver are?

Regarding the SMC driver, the maintainers are requesting a rewrite 
of the driver using the spimem layer, but we lack handlers to do 
the read training and compute the timing register value.

This is the first thing to address on the todo list. When available,
it shouldn't take too long to upstream the driver. Some more info 
here :

   https://www.spinics.net/lists/linux-mtd/msg09417.html

Cheers,

C.

> 
> [1] https://github.com/openbmc/linux/blob/dev-5.3/drivers/mtd/spi-nor/aspeed-smc.c
> [2] https://github.com/facebook/openbmc-linux/blob/dev-5.0/drivers/spi/spi-aspeed.c
> 
> (*) The Aspeed SPI master is half-duplex and the TPM SPI spec effectively
>     requires full duplex hardware.  I did some workarounds to get it to work
>     with one particular part and need to work with the vendor and upstream
>     to figure out the best way to reliably handle half-duplex SPI masters.
>