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

Boris Brezillon
2018-02-19T16:52:05Z

On Mon, 19 Feb 2018 16:25:10 +0000
Mark Brown <broonie@kernel.org> wrote:

> 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.

This is a case: most controllers support both regular SPI transfers and
memory-like operations (with some optimizations for memory oriented
operations).

--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering