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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <mafs0wmam6ukq.fsf@kernel.org>
Date: Mon, 12 May 2025 09:34:45 +0000
From: Pratyush Yadav <pratyush@...nel.org>
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" <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>,  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

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.

-- 
Regards,
Pratyush Yadav