Aspeed SPI driver upstreaming

[Patrick Williams]

Thanks for the reply Cédric.

On Tue, Jan 07, 2020 at 09:34:03AM +0100, Cédric Le Goater wrote:
> 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
> 

It looks like this patch set is still the MTD-only implementation, which
is useful for SPI-NOR chips but not useful for non-flash devices such as
TPMs.  Is there any work or thought into how we could do a generic SPI
controller and then layer the MTD above it?

We have some system designs where we have both a NOR device and a TPM on
the same SPI bus.  What we're currently doing is using the
(non-upstream) aspeed-spi driver which lets us use both the TPM and
MTD/SPI-NOR driver, but since it doesn't have the calibration routines
the SPI-NOR runs at a slower speed than optimal.

I'd really like to get a generic SPI controller driver upstreamed, even if it
doesn't have the calibration (the SPI-NOR device in this case is not as
performance critical as the BMC's own NOR devices).  Is there any path
to combining the features of the aspeed-smc and aspeed-spi into a single
driver, or do you think we should start with them as separate and get
aspeed-spi upstreamed as an alternative to aspeed-smc?

Also, do you have any soft timeline on the follow-ups to this patch set?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200109/0059bff5/attachment.sig>