[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <088dc0a1-fc54-478c-b253-4ed5dd6d6bae@app.fastmail.com>
Date: Tue, 10 Jun 2025 12:35:14 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>,
"Arnd Bergmann" <arnd@...nel.org>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Riyan Dhiman" <riyandhiman14@...il.com>,
"Thomas Zimmermann" <tzimmermann@...e.de>, "Paolo Perego" <pperego@...e.de>,
"Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
"Matthew Wilcox" <willy@...radead.org>,
"Jeff Johnson" <jeff.johnson@....qualcomm.com>,
dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fbtft: reduce stack usage
On Tue, Jun 10, 2025, at 12:26, Andy Shevchenko wrote:
> On Tue, Jun 10, 2025 at 11:24:38AM +0200, Arnd Bergmann wrote:
>> Move the varargs handling into a separate noinline function so each
>> individual function stays below the limit. A better approach might be to
>> replace the varargs function with one that takes an array of arguments,
>> but that would be a much larger rework of the other callers.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
>
> ...
Thanks
>> +static noinline_for_stack void fbtft_write_register_64(struct fbtft_par *par,
>> + int i, int buf[64])
>
> Perhaps int i, int buf[64] should be u32?
Right, I can send an updated patch, or this could be fixed up when applying
the patch
>> +{
>> + par->fbtftops.write_register(par, i,
>> + buf[0], buf[1], buf[2], buf[3],
>> + buf[4], buf[5], buf[6], buf[7],
>> + buf[8], buf[9], buf[10], buf[11],
>> + buf[12], buf[13], buf[14], buf[15],
>> + buf[16], buf[17], buf[18], buf[19],
>> + buf[20], buf[21], buf[22], buf[23],
>> + buf[24], buf[25], buf[26], buf[27],
>> + buf[28], buf[29], buf[30], buf[31],
>> + buf[32], buf[33], buf[34], buf[35],
>> + buf[36], buf[37], buf[38], buf[39],
>> + buf[40], buf[41], buf[42], buf[43],
>> + buf[44], buf[45], buf[46], buf[47],
>> + buf[48], buf[49], buf[50], buf[51],
>> + buf[52], buf[53], buf[54], buf[55],
>> + buf[56], buf[57], buf[58], buf[59],
>> + buf[60], buf[61], buf[62], buf[63]);
>> +}
>
> Wondering if we may reuse this in other cases (by providing the additional
> length parameter). But it may be done later on.
I tried this and that quickly became a mess. It is probably a good
idea to rework the code to completely avoid the varargs function
pointer and instead take an array here, but this is not something
I could easily do myself as that takes more time and needs better
testing.
Arnd
Powered by blists - more mailing lists