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

Boris Brezillon boris.brezillon at bootlin.com
Mon Feb 19 08:51:40 PST 2018


On Mon, 19 Feb 2018 16:25:10 +0000
Mark Brown <broonie at 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
http://bootlin.com



More information about the linux-mtd mailing list