On Mon, 19 Feb 2018 16:25:10 +0000 Mark Brown <broonie@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html