linux-kernel - RE: [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address writes in 8D-8D-8D mode

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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <DU0PR04MB9496B734F6BA84ABAE051D439097A@DU0PR04MB9496.eurprd04.prod.outlook.com>
Date: Mon, 12 May 2025 11:09:56 +0000
From: Bough Chen <haibo.chen@....com>
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" <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: 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.

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