linux-kernel - RE: [PATCH v3 2/2] 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:
 <PAXPR04MB85749F748DD87CE41452AEBBED2AA@PAXPR04MB8574.eurprd04.prod.outlook.com>
Date: Wed, 13 Aug 2025 02:49:58 +0000
From: Luke Wang <ziniu.wang_1@....com>
To: "pratyush@...nel.org" <pratyush@...nel.org>, "tudor.ambarus@...aro.org"
	<tudor.ambarus@...aro.org>, "mwalle@...nel.org" <mwalle@...nel.org>,
	"miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>, "richard@....at"
	<richard@....at>, "vigneshr@...com" <vigneshr@...com>
CC: "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Bough Chen
	<haibo.chen@....com>, Han Xu <han.xu@....com>
Subject: RE: [PATCH v3 2/2] mtd: spi-nor: core: avoid odd length/address
 writes in 8D-8D-8D mode

Gentle ping on this, are there any comments or issues?

Thanks,
Luke

> -----Original Message-----
> From: Luke Wang
> Sent: Tuesday, July 8, 2025 5:18 PM
> To: pratyush@...nel.org; tudor.ambarus@...aro.org; mwalle@...nel.org;
> miquel.raynal@...tlin.com; richard@....at; vigneshr@...com
> Cc: linux-mtd@...ts.infradead.org; linux-kernel@...r.kernel.org; Bough Chen
> <haibo.chen@....com>; Han Xu <han.xu@....com>
> Subject: [PATCH v3 2/2] mtd: spi-nor: core: avoid odd length/address writes in
> 8D-8D-8D mode
> 
> From: Pratyush Yadav <p.yadav@...com>
> 
> On Octal DTR capable flashes like Micron Xcella the writes cannot start
> or end at an odd address in Octal DTR mode. Extra 0xff bytes need to be
> appended or prepended to make sure the start address and end address are
> even. 0xff is used because on NOR flashes a program operation can only
> flip bits from 1 to 0, not the other way round. 0 to 1 flip needs to
> happen via erases.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@...com>
> Reviewed-by: Michael Walle <michael@...le.cc>
> Signed-off-by: Luke Wang <ziniu.wang_1@....com>
> ---
> Changes in v3:
> - remove last if (ret < 0) check, as ret always >= 0
> - remove Micron manufacturers info in comments
> - change nor->page_size to nor->params->page_size for latest kernel
> ---
>  drivers/mtd/spi-nor/core.c | 69
> +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 68 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 1b594f720b6c..20ea80450f22 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2128,6 +2128,68 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
> from, size_t len,
>  	return ret;
>  }
> 
> +/*
> + * On Octal DTR capable flashes, writes cannot start or end at an odd address
> + * in Octal DTR mode. Extra 0xff bytes need to be appended or prepended to
> + * make sure the start address and end address are even. 0xff is used because
> + * on NOR flashes a program operation can only flip bits from 1 to 0, not the
> + * other way round. 0 to 1 flip needs to happen via erases.
> + */
> +static int spi_nor_octal_dtr_write(struct spi_nor *nor, loff_t to, size_t len,
> +				   const u8 *buf)
> +{
> +	u8 *tmp_buf;
> +	size_t bytes_written;
> +	loff_t start, end;
> +	int ret;
> +
> +	if (IS_ALIGNED(to, 2) && IS_ALIGNED(len, 2))
> +		return spi_nor_write_data(nor, to, len, buf);
> +
> +	tmp_buf = kmalloc(nor->params->page_size, GFP_KERNEL);
> +	if (!tmp_buf)
> +		return -ENOMEM;
> +
> +	memset(tmp_buf, 0xff, nor->params->page_size);
> +
> +	start = round_down(to, 2);
> +	end = round_up(to + len, 2);
> +
> +	memcpy(tmp_buf + (to - start), buf, len);
> +
> +	ret = spi_nor_write_data(nor, start, end - start, tmp_buf);
> +	if (ret == 0) {
> +		ret = -EIO;
> +		goto out;
> +	}
> +	if (ret < 0)
> +		goto out;
> +
> +	/*
> +	 * More bytes are written than actually requested, but that number
> can't
> +	 * be reported to the calling function or it will confuse its
> +	 * calculations. Calculate how many of the _requested_ bytes were
> +	 * written.
> +	 */
> +	bytes_written = ret;
> +
> +	if (to != start)
> +		ret -= to - start;
> +
> +	/*
> +	 * Only account for extra bytes at the end if they were actually
> +	 * written. For example, if for some reason the controller could only
> +	 * complete a partial write then the adjustment for the extra bytes at
> +	 * the end is not needed.
> +	 */
> +	if (start + bytes_written == end)
> +		ret -= end - (to + len);
> +
> +out:
> +	kfree(tmp_buf);
> +	return ret;
> +}
> +
>  /*
>   * Write an address range to the nor chip.  Data must be written in
>   * FLASH_PAGESIZE chunks.  The address range may be any size provided
> @@ -2164,7 +2226,12 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t
> to, size_t len,
>  			goto write_err;
>  		}
> 
> -		ret = spi_nor_write_data(nor, addr, page_remain, buf + i);
> +		if (nor->write_proto == SNOR_PROTO_8_8_8_DTR)
> +			ret = spi_nor_octal_dtr_write(nor, addr, page_remain,
> +						      buf + i);
> +		else
> +			ret = spi_nor_write_data(nor, addr, page_remain,
> +						 buf + i);
>  		spi_nor_unlock_device(nor);
>  		if (ret < 0)
>  			goto write_err;
> --
> 2.34.1