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]
Message-ID:
 <DU2PR04MB8567950B89B1F4F1F97FCD43ED41A@DU2PR04MB8567.eurprd04.prod.outlook.com>
Date: Tue, 1 Jul 2025 07:47:27 +0000
From: Luke Wang <ziniu.wang_1@....com>
To: Bough Chen <haibo.chen@....com>, Pratyush Yadav <pratyush@...nel.org>,
	Miquel Raynal <miquel.raynal@...tlin.com>
CC: Tudor Ambarus <tudor.ambarus@...aro.org>, "broonie@...nel.org"
	<broonie@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mtd@...ts.infradead.org"
	<linux-mtd@...ts.infradead.org>, "linux-spi@...r.kernel.org"
	<linux-spi@...r.kernel.org>, "michael@...le.cc" <michael@...le.cc>,
	"p.yadav@...com" <p.yadav@...com>, "richard@....at" <richard@....at>,
	"vigneshr@...com" <vigneshr@...com>, Han Xu <han.xu@....com>
Subject: RE: [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address
 writes in 8D-8D-8D mode



> -----Original Message-----
> From: Bough Chen <haibo.chen@....com>
> Sent: Monday, May 12, 2025 7:10 PM
> To: Pratyush Yadav <pratyush@...nel.org>; Miquel Raynal
> <miquel.raynal@...tlin.com>
> Cc: Tudor Ambarus <tudor.ambarus@...aro.org>; Luke Wang
> <ziniu.wang_1@....com>; broonie@...nel.org; linux-
> kernel@...r.kernel.org; linux-mtd@...ts.infradead.org; linux-
> spi@...r.kernel.org; michael@...le.cc; p.yadav@...com; richard@....at;
> vigneshr@...com; Han Xu <han.xu@....com>
> Subject: RE: [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address
> writes in 8D-8D-8D mode
> 
> > -----Original Message-----
> > From: Pratyush Yadav <pratyush@...nel.org>
> > Sent: 2025年5月12日 17:35
> > To: Miquel Raynal <miquel.raynal@...tlin.com>
> > Cc: Pratyush Yadav <pratyush@...nel.org>; Tudor Ambarus
> > <tudor.ambarus@...aro.org>; Luke Wang <ziniu.wang_1@....com>;
> > broonie@...nel.org; linux-kernel@...r.kernel.org;
> > linux-mtd@...ts.infradead.org; linux-spi@...r.kernel.org; michael@...le.cc;
> > p.yadav@...com; richard@....at; vigneshr@...com; Bough Chen
> > <haibo.chen@....com>; Han Xu <han.xu@....com>
> > Subject: Re: [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address
> writes
> > in 8D-8D-8D mode
> >
> > [Some people who received this message don't often get email from
> > pratyush@...nel.org. Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Mon, May 12 2025, Miquel Raynal wrote:
> >
> > > Hello,
> > >
> > > On 07/05/2025 at 09:43:25 GMT, Pratyush Yadav <pratyush@...nel.org>
> > wrote:
> > >
> > >> Hi Luke,
> > >>
> > >> On Tue, Apr 29 2025, Tudor Ambarus wrote:
> > >>
> > >>> On 4/29/25 10:03 AM, Luke Wang wrote:
> > >>>> Hi Pratyush,
> > >>>>
> > >>>> I'm following up on this patch series [1] Avoid odd length/address
> > >>>> read/ writes in 8D-8D-8D mode. While some of the series has been
> > >>>> merged, the patch 4-6 remains unmerged.
> > >>>>
> > >>>> In fact, we also encountered similar read/write issue of odd
> > >>>> address/ length with NXP FSPI controller (spi-nxp-fspi.c).
> > >>>> Currently, we handled the odd address/length in the controller
> > >>>> driver, but I think this should be a common issue in the octal dtr
> > >>>> mode. Was there a technical reason for not merging the core layer
> > solution?
> > >>>
> > >>> I guess I stumbled on those small comments and did not consider the
> > >>> greater benefit of taking the patches. No one cared and we forgot
> > >>> about it. Please address the comments and resubmit.
> > >>
> > >> Yes, it should have been a simple next revision from me but
> > >> apparently it fell through the cracks. I do strongly agree that this
> > >> should be done in SPI NOR, and not in controller drivers. So it would
> > >> be great if you can respin the remaining patches of the series.
> > >
> > > The fact is that we will have octal DTR support in SPI NAND as well at
> > > some point, hence a common solution would be welcome as we will likely
> > > face similar problems when performing these unaligned accesses. I
> > > don't know how feasible it is yet, but if we have a fix for SPI NOR,
> > > we will need something similar for SPI NAND.
> >
> > The common solution would then probably be in SPI MEM? Since you need
> to
> > make sure you don't do an out of bounds read, you need to know the size
> of the
> > flash at least. That is recorded in the dirmap operations, so perhaps we can
> have
> > this logic in spi_mem_dirmap_{read,write}()? Haven't thought too deeply so
> not
> > sure if it would end up being a good idea.
> 
> Seems reasonable, I will have a try.
> 

Sorry for delayed response.

After reviewing the SPI NAND driver, I noticed that the addr and len alignment has already been implemented in spinand_read_from_cache_op() and spinand_write_to_cache_op() functions.

Additionally, using 0xff padding in spi_mem_dirmap_write() might not be suitable for non-flash memory devices.

I can respin the remaining patches of the series if you agree.

Regards,
Luke Wang

> Regards
> Haibo Chen
> >
> > --
> > Regards,
> > Pratyush Yadav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ