mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Lukas Wunner <lukas@wunner.de>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: cfi_cmdset_0001: shrink do_write_buffer() stack frame
Date: Mon, 24 Aug 2026 08:56:32 +0100	[thread overview]
Message-ID: <20260824085632.2dd08ba9@pumpkin> (raw)
In-Reply-To: <20260824014703.56502-1-kmehltretter@gmail.com>

On Mon, 24 Aug 2026 03:47:03 +0200
Karl Mehltretter <kmehltretter@gmail.com> wrote:

> arm32 allmodconfig fails to build with gcc:
> 
>   drivers/mtd/chips/cfi_cmdset_0001.c:1883:1: error: the frame size of 1296
>   bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
> 
> With MTD_MAP_BANK_WIDTH_32 a map_word is 32 bytes, and with KASAN_STACK
> every temporary gets its own redzoned slot.  do_write_buffer() builds a
> map_word for each of the twelve commands it issues, and those temporaries
> dominate its frame.

Looks to me like pretty much all of mtd/map.h should be real functions
and not #defines or inlines.

The bloat from all those expansions is going to be significant.
They only time they get optimised to anything small is when only
CONFIG_MTD_MAP_BANK_WIDTH_1 is set.

The execution time of all those that do real io (especially reads)
will be dominated by the io access itself.

David

> 
> Issue the commands through a small noinline helper that takes the
> command as a plain value and builds the map_word in its own frame.  The
> sequence of reads and writes to the chip is unchanged.
> 
> The helper must not be inlined, and reusing one map_word local is not
> enough: clang cannot assume the callee does not observe the local, so it
> still returns each CMD() into a per-call-site temporary, and the frame
> grows (1760 -> 1824 bytes in cfi_intelext_writev(), into which clang
> inlines do_write_buffer()).
> 
> Frame sizes with MTD_MAP_BANK_WIDTH_32 and KASAN_STACK:
> 
>   gcc 15.2   do_write_buffer()      1296 -> 520
>   clang 21   cfi_intelext_writev()  1760 -> 896
> 
> The helper itself takes 168 (gcc) / 160 (clang) bytes.
> 
> Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Closes: https://lore.kernel.org/all/20260408211407.2295175-1-andriy.shevchenko@linux.intel.com/
> Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Link: https://lore.kernel.org/all/87ik9cfm6g.fsf@bootlin.com/
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
>  drivers/mtd/chips/cfi_cmdset_0001.c | 42 ++++++++++++++++++-----------
>  1 file changed, 26 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
> index b73596a8e021..a7c77c4e76ae 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> @@ -1716,12 +1716,24 @@ static int cfi_intelext_write_words (struct mtd_info *mtd, loff_t to , size_t le
>  }
>  
>  
> +/*
> + * Keep noinline: inlined, the map_word temporaries put do_write_buffer() over
> + * the frame-size limit with MTD_MAP_BANK_WIDTH_32 and KASAN_STACK.
> + */
> +static noinline void __xipram cfi_write_cmd(struct map_info *map,
> +					    unsigned long cmd, unsigned long adr)
> +{
> +	struct cfi_private *cfi = map->fldrv_priv;
> +
> +	map_write(map, CMD(cmd), adr);
> +}
> +
>  static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  				    unsigned long adr, const struct kvec **pvec,
>  				    unsigned long *pvec_seek, int len)
>  {
>  	struct cfi_private *cfi = map->fldrv_priv;
> -	map_word status, write_cmd, datum;
> +	map_word status, datum;
>  	unsigned long cmd_adr;
>  	int ret, wbufsize, word_gap, words;
>  	const struct kvec *vec;
> @@ -1740,9 +1752,6 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  	if (is_LH28F640BF(cfi))
>  		cmd_adr = adr;
>  
> -	/* Let's determine this according to the interleave only once */
> -	write_cmd = (cfi->cfiq->P_ID != P_ID_INTEL_PERFORMANCE) ? CMD(0xe8) : CMD(0xe9);
> -
>  	mutex_lock(&chip->mutex);
>  	ret = get_chip(map, chip, cmd_adr, FL_WRITING);
>  	if (ret) {
> @@ -1759,7 +1768,7 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  	   So we must check here and reset those bits if they're set. Otherwise
>  	   we're just pissing in the wind */
>  	if (chip->state != FL_STATUS) {
> -		map_write(map, CMD(0x70), cmd_adr);
> +		cfi_write_cmd(map, 0x70, cmd_adr);
>  		chip->state = FL_STATUS;
>  	}
>  	status = map_read(map, cmd_adr);
> @@ -1767,21 +1776,22 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  		xip_enable(map, chip, cmd_adr);
>  		printk(KERN_WARNING "SR.4 or SR.5 bits set in buffer write (status %lx). Clearing.\n", status.x[0]);
>  		xip_disable(map, chip, cmd_adr);
> -		map_write(map, CMD(0x50), cmd_adr);
> -		map_write(map, CMD(0x70), cmd_adr);
> +		cfi_write_cmd(map, 0x50, cmd_adr);
> +		cfi_write_cmd(map, 0x70, cmd_adr);
>  	}
>  
>  	chip->state = FL_WRITING_TO_BUFFER;
> -	map_write(map, write_cmd, cmd_adr);
> +	cfi_write_cmd(map, (cfi->cfiq->P_ID != P_ID_INTEL_PERFORMANCE) ? 0xe8 : 0xe9,
> +		      cmd_adr);
>  	ret = WAIT_TIMEOUT(map, chip, cmd_adr, 0, 0);
>  	if (ret) {
>  		/* Argh. Not ready for write to buffer */
>  		map_word Xstatus = map_read(map, cmd_adr);
> -		map_write(map, CMD(0x70), cmd_adr);
> +		cfi_write_cmd(map, 0x70, cmd_adr);
>  		chip->state = FL_STATUS;
>  		status = map_read(map, cmd_adr);
> -		map_write(map, CMD(0x50), cmd_adr);
> -		map_write(map, CMD(0x70), cmd_adr);
> +		cfi_write_cmd(map, 0x50, cmd_adr);
> +		cfi_write_cmd(map, 0x70, cmd_adr);
>  		xip_enable(map, chip, cmd_adr);
>  		printk(KERN_ERR "%s: Chip not ready for buffer write. Xstatus = %lx, status = %lx\n",
>  				map->name, Xstatus.x[0], status.x[0]);
> @@ -1800,7 +1810,7 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  	}
>  
>  	/* Write length of data to come */
> -	map_write(map, CMD(words), cmd_adr );
> +	cfi_write_cmd(map, words, cmd_adr);
>  
>  	/* Write data */
>  	vec = *pvec;
> @@ -1837,7 +1847,7 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  	*pvec_seek = vec_seek;
>  
>  	/* GO GO GO */
> -	map_write(map, CMD(0xd0), cmd_adr);
> +	cfi_write_cmd(map, 0xd0, cmd_adr);
>  	chip->state = FL_WRITING;
>  
>  	ret = INVAL_CACHE_AND_WAIT(map, chip, cmd_adr,
> @@ -1845,7 +1855,7 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  				   chip->buffer_write_time,
>  				   chip->buffer_write_time_max);
>  	if (ret) {
> -		map_write(map, CMD(0x70), cmd_adr);
> +		cfi_write_cmd(map, 0x70, cmd_adr);
>  		chip->state = FL_STATUS;
>  		xip_enable(map, chip, cmd_adr);
>  		printk(KERN_ERR "%s: buffer write error (status timeout)\n", map->name);
> @@ -1858,8 +1868,8 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
>  		unsigned long chipstatus = MERGESTATUS(status);
>  
>  		/* reset status */
> -		map_write(map, CMD(0x50), cmd_adr);
> -		map_write(map, CMD(0x70), cmd_adr);
> +		cfi_write_cmd(map, 0x50, cmd_adr);
> +		cfi_write_cmd(map, 0x70, cmd_adr);
>  		xip_enable(map, chip, cmd_adr);
>  
>  		if (chipstatus & 0x02) {


      reply	other threads:[~2026-08-24  7:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24  1:47 Karl Mehltretter
2026-08-24  7:56 ` David Laight [this message]

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=20260824085632.2dd08ba9@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=kmehltretter@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=lukas@wunner.de \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®