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 Boris Brezillon (9): spi: Expose spi_{map,unmap}_buf() for internal use spi: Add an helper to flush the message queue spi: Extend the core to ease integration of SPI memory controllers spi: Make support for regular transfers optional when ->mem_ops != NULL spi: bcm-qspi: Implement the spi_mem interface spi: bcm53xx: Implement the spi_mem interface spi: ti-qspi: Implement the spi_mem interface mtd: spi-nor: Use the spi_mem_xx() API spi: Get rid of the spi_flash_read() API drivers/mtd/devices/Kconfig | 1 + drivers/mtd/devices/m25p80.c | 236 +++++++++---------------- drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/internals.h | 43 +++++ drivers/spi/spi-bcm-qspi.c | 162 ++++++++--------- drivers/spi/spi-bcm53xx.c | 37 ++-- drivers/spi/spi-mem.c | 410 +++++++++++++++++++++++++++++++++++++++++++ drivers/spi/spi-ti-qspi.c | 85 +++++---- drivers/spi/spi.c | 131 ++++++-------- include/linux/spi/spi-mem.h | 249 ++++++++++++++++++++++++++ include/linux/spi/spi.h | 60 +------ 12 files changed, 1007 insertions(+), 415 deletions(-) create mode 100644 drivers/spi/internals.h create mode 100644 drivers/spi/spi-mem.c create mode 100644 include/linux/spi/spi-mem.h -- 2.14.1 -- 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