linux-kernel - RE: [PATCH v4 7/7] mtd: spi-nor: add read loop

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:	Tue, 12 Jan 2016 06:35:21 +0000
From:	Zhiqiang Hou <zhiqiang.hou@....com>
To:	Michal Suchanek <hramrach@...il.com>
CC:	Andrew Murray <amurray@...edded-bits.co.uk>,
	Huang Shijie <shijie.huang@...el.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Han Xu <han.xu@...escale.com>,
	Rafa? Mi?ecki <zajec5@...il.com>,
	Huang Shijie <b32955@...escale.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Marek Vasut <marex@...x.de>, Gabor Juhos <juhosg@...nwrt.org>,
	Bean Huo 霍斌斌, <beanhuo@...ron.com>,
	MTD Maling List <linux-mtd@...ts.infradead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 7/7] mtd: spi-nor: add read loop

Hi Michal,

Thanks for your info, and I see you have updated the patchset on Dec.02. Is it the conclusion, right?

> -----Original Message-----
> From: Michal Suchanek [mailto:hramrach@...il.com]
> Sent: 2015年11月21日 3:19
> To: Hou Zhiqiang-B48286
> Cc: Andrew Murray; Huang Shijie; David Woodhouse; Brian Norris; Xu Han-
> B45815; Rafa? Mi?ecki; Huang Shijie; Ben Hutchings; Marek Vasut; Gabor
> Juhos; Bean Huo 霍斌斌,; MTD Maling List; LKML
> Subject: Re: [PATCH v4 7/7] mtd: spi-nor: add read loop
> 
> Hello,
> 
> On 5 November 2015 at 04:39, Hou Zhiqiang <B48286@...escale.com> wrote:
> > Hi Michal,
> >
> > Does this have any updates?
> 
> I will try to update this patchset when it's agreed how the limit on
> transfer size is handled. Writing less data than was requested is
> acceptable for spi-nor but might disrupt other drivers so perhaps some
> preemptive mechanism with the SPI master saying how much data it can
> transfer and the drivers looking at that value would be preferred.
> 

Thanks,
Zhiqiang