[PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out do_write_buffer_locked() to reduce stack frame

[Andy Shevchenko]

On Tue, Apr 28, 2026 at 10:20:16AM +0200, Miquel Raynal wrote:

I had some text here already written in response, but...

...

> >> >> > Stack usage is high here because of the three "map_word" types,
> >> >> > which can each be up to 256 unsigned longs (32 * 8), see the
> >> >> > definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in
> >> >> > include/linux/mtd/map.h.
> >> >> 
> >> >> Ugg - that code is horrid.
> >> >> Returning structures by value isn't really a good idea.
> >> 
> >> Looks like the primary reason for the stack over usage, no? Isn't
> >> playing with inline and refactoring just a tiny fix that prevents
> >> problem by just a couple of bytes?
> >> 
> >> I haven't looked too carefully, but could we (Andy?) have a fix that
> >> reduces the number of map_word (as suggested, IIUC) and/or avoid passing
> >> them by value?
> >
> > I am not an expert for this particular change, I am afraid.
> 
> Surprising flannel from someone sorely insisting to force contributors
> into doing zillions more changes than they initially wanted, easily
> triggering iniquitously NACKs otherwise.

...after meeting you during Linux Plumbers and actually having a couple of
ideas how to solve that, I promised to answer to that thread sharing new
information.

> > Consider my patch
> > as a bug report that needs to be addressed, Currently it might break some
> > builds when `make W=1` is passed.
> 
> Hopefully you will remember that you have your own limits too. Maybe
> that will allow others to breeze next time there will be something that
> matters so much to you that you prefer to fully block their work.

As for the changes that reside in the lib/, which is tree wide and
has zillions of different users with different requirements, finding
a common ground is really hard.

> >> I can also take this cleanup if enclosed in a bigger
> >> series, I don't mind because it may make the code easier to read as
> >> well, but I feel like this is not a proper fix. If it is, please explain
> >> to me again :-)

-- 
With Best Regards,
Andy Shevchenko