Re: mtd: mchp23k256: How to follow a more generic approach?

[Boris Brezillon <boris.brezillon@collabora.com>]

On Tue, 19 Feb 2019 14:47:08 +0000
Schrempf Frieder <frieder.schrempf@kontron.de> wrote:

> >   
> >> The instructions seem to be very similar to EEPROM and SPI NOR devices.
> >> So I'm curious about what others propose how to support these devices.  
> > 
> > I'm planning to write the driver for the ANV32AA1W during the next weeks
> > and it would be really great to have some feedback on the approach here.  
> 
> Maybe you can create a new generic SPI RAM driver (I don't think 
> something like this exists yet), that can be used with things like SRAM, 
> nvSRAM, FRAM, etc.?

Creating a new framework makes sense if you have enough to share
between all those drivers. I might be wrong (didn't look at the code)
but I think SRAM devices are simple enough to not require a new
mid-layer (especially if they use a different cmdset). What we could do
though is group them in drivers/mtd/sram/.

> 
> At the time when a generic driver exists, we could use it to replace the 
> mchp23k256 driver.
> 
> If you write a new driver or convert an existing one to support the 
> nvSRAM chips, please use the SPI MEM interface (drivers/spi/spi-mem.c). 
> This would enable us to share some code and connect those chips to all 
> kinds of controllers that support this interface (which are not only 
> generic SPI controllers, but also some QSPI controllers, that don't 
> support generic SPI transfers).

Yes, please use the spi-mem layer (note that I already started the
conversion of at25 here [1]).

[1]https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1904223.html

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/