linux-kernel - Re: [PATCH v5 0/3] Merge m25p80 into spi-nor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 12 Aug 2019 10:33:23 +0000
From:   <Tudor.Ambarus@...rochip.com>
To:     <vigneshr@...com>, <miquel.raynal@...tlin.com>, <richard@....at>
CC:     <marek.vasut@...il.com>, <bbrezillon@...nel.org>,
        <linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
        <tmaimon77@...il.com>
Subject: Re: [PATCH v5 0/3] Merge m25p80 into spi-nor



On 08/06/2019 08:10 AM, Vignesh Raghavendra wrote:
> External E-Mail
> 
> 
> This is repost of patch 6 and 7 split from from Boris Brezillon's X-X-X
> mode support series[1]
> 
> Background from cover letter for RFC[1]:
> m25p80 is just a simple SPI NOR controller driver (a wrapper around the
> SPI mem API). Not only it shouldn't be named after a specific SPI NOR
> chip, but it also doesn't deserve a specific driver IMO, especially if
> the end goal is to get rid of SPI NOR controller drivers found in
> drivers/mtd/spi-nor/ and replace them by SPI mem drivers (which would
> be placed in drivers/spi/). With this solution, we declare the SPI NOR
> driver as a spi_mem_driver, just like the SPI NAND layer is declared as
> a spi_mem driver (patch 1/2).
> This solution also allows us to check at a fined-grain level (thanks to
> the spi_mem_supports_op() function) which operations are supported and
> which ones are not, while the original m25p80 logic was basing this
> decision on the SPI_{RX,TX}_{DUAL,QUAD,OCTO} flags only (patch 2/2).
> 
> [1] https://patchwork.ozlabs.org/cover/982926/
> 
> Tested on TI' DRA7xx EVM with TI QSPI controller (a spi-mem driver) with
> DMA (s25fl256 and mx66l51235l) flash. I don't see any performance
> regression due to bounce buffer copy introduced by this series
> Also tested with cadence-quadspi (a spi-nor driver) driver
> 
> Boris Brezillon (2):
>   mtd: spi-nor: Move m25p80 code in spi-nor.c
>   mtd: spi-nor: Rework hwcaps selection for the spi-mem case
> 
> Vignesh Raghavendra (1):
>   mtd: spi-nor: always use bounce buffer for register read/writes
> 
>  drivers/mtd/devices/Kconfig   |  18 -
>  drivers/mtd/devices/Makefile  |   1 -
>  drivers/mtd/devices/m25p80.c  | 347 ---------------
>  drivers/mtd/spi-nor/Kconfig   |   2 +
>  drivers/mtd/spi-nor/spi-nor.c | 814 +++++++++++++++++++++++++++++++---
>  include/linux/mtd/spi-nor.h   |  24 +-
>  6 files changed, 777 insertions(+), 429 deletions(-)
>  delete mode 100644 drivers/mtd/devices/m25p80.c
> 

I did an erase-write-read-check and a mtd_speedtest on mx25l25635e and
sst26vf064b flashes using atmel-quadspi driver, everything was ok.

I updated patch 3/3 as I said in its thread.

All applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git,
spi-nor/next branch.

Thanks,
ta