[PATCH v3 0/9] spi: Extend the framework to generically support memory devices
Boris Brezillon
boris.brezillon at bootlin.com
Thu Apr 26 02:27:11 PDT 2018
On Thu, 26 Apr 2018 14:37:10 +0530
Vignesh R <vigneshr at ti.com> wrote:
> On Monday 23 April 2018 12:05 AM, Boris Brezillon wrote:
> > Hello,
> >
> > Shrinking a bit the explanation on why the spi-mem abstraction is
> > needed (a detailed explanation is available here [2]). In addition to
> > what as been said in my initial explanation I'll add that making it part
> > of the SPI framework instead of as an extra independent layer is
> > justified by the fact that some controllers support both SPI memory
> > operations and regular SPI transfers, and it's cleaner to have both
> > features exposed through a single driver.
> >
> > For those who want to have the full picture, here is a branch [1]
> > containing the SPI NAND framework based on top of this spi-mem layer.
> >
> > Thanks,
> >
> > Boris
> >
> > [1]https://github.com/bbrezillon/linux/tree/spi-mem
> > [2]https://www.spinics.net/lists/linux-spi/msg12058.html
> >
> >
>
> I am trying to apply this on top of linux-next, but
> [PATCH v2 01/10] spi: Check presence the of ->transfer[_xxx]() before
> registering a controller
> from v2 is missing in this series and it does not seem to be in spi.git
> as well?
Hm, that's weird. I'm almost sure I received a notification saying it
had been applied. I'll double check.
More information about the linux-mtd
mailing list