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]
Message-ID: <CAOMqctSuP6E55mJ7QrqASRQUpxSy=ZR-b7VPF=0vcw45B6S+Yg@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ