linux-kernel - Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Jun 2016 22:35:45 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Cyrille Pitchen <cyrille.pitchen@...el.com>
Cc:	Brian Norris <computersforpeace@...il.com>,
	MTD Maling List <linux-mtd@...ts.infradead.org>,
	Marek Vašut <marex@...x.de>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	nicolas.ferre@...el.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi
 protocols to all commands

Hello,

this patch is kind of awesome.

I have a few practical concerns however.

On 20 June 2016 at 18:50, Cyrille Pitchen <cyrille.pitchen@...el.com> wrote:
> Before this patch, m25p80_read() supported few SPI protocols:
> - regular SPI 1-1-1
> - SPI Dual Output 1-1-2
> - SPI Quad Output 1-1-4
> On the other hand, all other m25p80_*() hooks only supported SPI 1-1-1.

Under typical use my estimate is that huge majority of data is
transferred in _read() seconded by _write().

As I understand it the n-n-n means how many bits you transfer in
parallel when sending command-address-data.

In _read() the command and data overhead is negligible when you can
read kilobytes at once. So difference between 1-1-4 and 4-4-4 is not
meaningful performance-wise. Are there flash chips that support one
but not the other?

For _write() the benefits are even harder to assess. You can
presumably write at n-n-4 or n-n-2 if your controller and flash
supports it transferring the page faster. And then spend possibly
large amount of time waiting for the flash to get ready again. If the
programming time is fixed transferring the page faster may or may not
have benefits. It may at least free the bus for other devices to use.

The _reg_ stuff is probably negligible altogether,

Lastly the faster transfers of address bytes seem to be achieved with
increasingly longer command codes given how much the maximum command
length increased. So even in a page write where the address is a few %
of the transfer the benefit of these extra modes is dubious.

Overall I wonder how much it is worthwhile to complicate the code to
get all these modes in every single function.

Thanks

Michal