[RFC PATCH 0/6] spi: Extend the framework to generically support memory devices

[Mark Brown]

On Tue, Feb 06, 2018 at 12:21:14AM +0100, Boris Brezillon wrote:

> SPI NAND layer): you can register a SPI NOR device directly from the
> dedicated SPI memory controller, or it can be registered through the
> SPI layer if the SPI controller is a generic SPI controller. While
> the generic SPI controller path works fine, the dedicated SPI NOR
> controller path brings its own set of issues:

> * the SPI bus is not represented in sysfs

I'm not sure if this is a big deal or not - at some point it's just an
implementation detail of the hardware rather than something we're aware
of or interested in.

> * because there's no bus, there's no uevent, which means you'll have to
>   select both the SPI NAND and SPI NOR logic as soon as one driver
>   supports both interfaces if you don't want to run into loading
>   dependency issues

This is sounding like we want a class (well, virtual bus in the new
world) for these devices with a SPI based driver sitting on top of that
for use with genuine SPI controllers.  If the intention is as the
comments in the code suggested that controllers implementing the memory
mapping stuff don't use SPI at all then we could have the legacy SPI bus
support be just another driver for this class.  However when I look at
what the drivers are actually doing it seems like that's not the case
and the new API is intended to sit alongside normal SPI support, perhaps
only implementing certain operations and using regular SPI for others.
In that case it makes a lot more sense to have this be bolted on the
side of SPI.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20180219/7d8788b4/attachment-0001.sig>