All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Luke Wang <ziniu.wang_1@nxp.com>
Cc: Bough Chen <haibo.chen@nxp.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	 Tudor Ambarus <tudor.ambarus@linaro.org>,
	 "broonie@kernel.org" <broonie@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"michael@walle.cc" <michael@walle.cc>,
	 "p.yadav@ti.com" <p.yadav@ti.com>,
	 "richard@nod.at" <richard@nod.at>,
	 "vigneshr@ti.com" <vigneshr@ti.com>,  Han Xu <han.xu@nxp.com>
Subject: Re: [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address writes in 8D-8D-8D mode
Date: Thu, 24 Jul 2025 16:14:51 +0200	[thread overview]
Message-ID: <mafs0a54tsmjo.fsf@kernel.org> (raw)
In-Reply-To: <DU2PR04MB8567950B89B1F4F1F97FCD43ED41A@DU2PR04MB8567.eurprd04.prod.outlook.com>

On Tue, Jul 01 2025, Luke Wang wrote:

>> > On Mon, May 12 2025, Miquel Raynal wrote:
>> >
>> > > Hello,
>> > >
>> > > On 07/05/2025 at 09:43:25 GMT, Pratyush Yadav <pratyush@kernel.org>
[...]
>> > >
>> > > 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.
[...]
>
> 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.

Right. I took a very quick look as well and it seems that SPI NAND only
does page sized reads and writes in spinand_write_to_cache_op() and
spinand_read_from_cache_op(). So it should not be a problem.

Miquel, Luke sent a respin [0] for fixing this in SPI NOR and I need to
decide if I should take them or push for a more generic fix. Did I miss
some place where SPI NAND can do odd-length reads or writes? If not, I'd
rather just take the respinned patches.

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

NAND also seems to be using 0xff though. From spinand_write_to_cache_op():

	nbytes = nanddev_page_size(nand) + nanddev_per_page_oobsize(nand);
	memset(spinand->databuf, 0xff, nanddev_page_size(nand));

Anyway, if needed we can solve that with a field in struct
spi_mem_dirmap_info I guess.

[0] https://lore.kernel.org/linux-mtd/20250708091646.292-1-ziniu.wang_1@nxp.com/T/#u

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Pratyush Yadav <pratyush@kernel.org>
To: Luke Wang <ziniu.wang_1@nxp.com>
Cc: Bough Chen <haibo.chen@nxp.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	 Tudor Ambarus <tudor.ambarus@linaro.org>,
	 "broonie@kernel.org" <broonie@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"michael@walle.cc" <michael@walle.cc>,
	 "p.yadav@ti.com" <p.yadav@ti.com>,
	 "richard@nod.at" <richard@nod.at>,
	 "vigneshr@ti.com" <vigneshr@ti.com>,  Han Xu <han.xu@nxp.com>
Subject: Re: [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address writes in 8D-8D-8D mode
Date: Thu, 24 Jul 2025 16:14:51 +0200	[thread overview]
Message-ID: <mafs0a54tsmjo.fsf@kernel.org> (raw)
In-Reply-To: <DU2PR04MB8567950B89B1F4F1F97FCD43ED41A@DU2PR04MB8567.eurprd04.prod.outlook.com>

On Tue, Jul 01 2025, Luke Wang wrote:

>> > On Mon, May 12 2025, Miquel Raynal wrote:
>> >
>> > > Hello,
>> > >
>> > > On 07/05/2025 at 09:43:25 GMT, Pratyush Yadav <pratyush@kernel.org>
[...]
>> > >
>> > > 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.
[...]
>
> 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.

Right. I took a very quick look as well and it seems that SPI NAND only
does page sized reads and writes in spinand_write_to_cache_op() and
spinand_read_from_cache_op(). So it should not be a problem.

Miquel, Luke sent a respin [0] for fixing this in SPI NOR and I need to
decide if I should take them or push for a more generic fix. Did I miss
some place where SPI NAND can do odd-length reads or writes? If not, I'd
rather just take the respinned patches.

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

NAND also seems to be using 0xff though. From spinand_write_to_cache_op():

	nbytes = nanddev_page_size(nand) + nanddev_per_page_oobsize(nand);
	memset(spinand->databuf, 0xff, nanddev_page_size(nand));

Anyway, if needed we can solve that with a field in struct
spi_mem_dirmap_info I guess.

[0] https://lore.kernel.org/linux-mtd/20250708091646.292-1-ziniu.wang_1@nxp.com/T/#u

-- 
Regards,
Pratyush Yadav

  reply	other threads:[~2025-07-24 17:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DU2PR04MB85678048FE8B475B1E323E0AED802@DU2PR04MB8567.eurprd04.prod.outlook.com>
2025-04-29  9:22 ` [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address writes in 8D-8D-8D mode Tudor Ambarus
2025-04-29  9:22   ` Tudor Ambarus
2025-05-07  9:43   ` Pratyush Yadav
2025-05-07  9:43     ` Pratyush Yadav
2025-05-12  7:57     ` Miquel Raynal
2025-05-12  7:57       ` Miquel Raynal
2025-05-12  8:33       ` Bough Chen
2025-05-12  8:33         ` Bough Chen
2025-05-12  9:34       ` Pratyush Yadav
2025-05-12  9:34         ` Pratyush Yadav
2025-05-12 11:09         ` Bough Chen
2025-05-12 11:09           ` Bough Chen
2025-07-01  7:47           ` Luke Wang
2025-07-01  7:47             ` Luke Wang
2025-07-24 14:14             ` Pratyush Yadav [this message]
2025-07-24 14:14               ` Pratyush Yadav
2021-05-31 18:17 [PATCH v2 0/6] Avoid odd length/address read/writes " Pratyush Yadav
2021-05-31 18:17 ` [PATCH v2 6/6] mtd: spi-nor: core: avoid odd length/address writes " Pratyush Yadav
2021-05-31 18:17   ` Pratyush Yadav
2021-06-01 12:44   ` Michael Walle
2021-06-01 12:44     ` Michael Walle
2021-12-23 12:59   ` Tudor.Ambarus
2021-12-23 12:59     ` Tudor.Ambarus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mafs0a54tsmjo.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=broonie@kernel.org \
    --cc=haibo.chen@nxp.com \
    --cc=han.xu@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.com \
    --cc=ziniu.wang_1@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.