From: Sun Jian <sun.jian.kdev@gmail.com>
To: Andy Shevchenko <andy@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Sun Jian <sun.jian.kdev@gmail.com>
Subject: [PATCH v1 1/4] staging: fbtft: core: avoid large stack usage in DT init parsing
Date: Sun, 4 Jan 2026 19:06:35 +0800 [thread overview]
Message-ID: <20260104110638.532615-2-sun.jian.kdev@gmail.com> (raw)
In-Reply-To: <20260104110638.532615-1-sun.jian.kdev@gmail.com>
Clang reports a large stack frame for fbtft_init_display_from_property()
(-Wframe-larger-than=1024) when the init sequence is emitted through a
fixed 64-argument write_register() call.
write_reg()/write_register() relies on NUMARGS((int[]){...}) and large
varargs which inflates stack usage. Switch the DT "init" path to send the
command byte and the payload via fbtft_write_buf_dc() instead.
No functional change intended: the same register values are sent in the
same order, only the transport is changed.
Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
---
drivers/staging/fbtft/fbtft-core.c | 32 ++++++++++++------------------
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index 8a5ccc8ae0a1..127d0de87e03 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -846,7 +846,8 @@ EXPORT_SYMBOL(fbtft_unregister_framebuffer);
static int fbtft_init_display_from_property(struct fbtft_par *par)
{
struct device *dev = par->info->device;
- int buf[64], count, index, i, j, ret;
+ u8 buf[64];
+ int count, index, i, j, ret;
u32 *values;
u32 val;
@@ -881,7 +882,7 @@ static int fbtft_init_display_from_property(struct fbtft_par *par)
ret = -EINVAL;
goto out_free;
}
- buf[i++] = val;
+ buf[i++] = val & 0xFF;
val = values[++index];
}
/* make debug message */
@@ -891,23 +892,16 @@ static int fbtft_init_display_from_property(struct fbtft_par *par)
fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
"buf[%d] = %02X\n", j, buf[j]);
- 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]);
+ /* buf[0] is command, buf[1..i-1] is data */
+ ret = fbtft_write_buf_dc(par, &buf[0], 1, 0);
+ if (ret < 0)
+ goto out_free;
+
+ if (i > 1) {
+ ret = fbtft_write_buf_dc(par, &buf[1], i - 1, 1);
+ if (ret < 0)
+ goto out_free;
+ }
} else if (val & FBTFT_OF_INIT_DELAY) {
fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
"init: msleep(%u)\n", val & 0xFFFF);
--
2.43.0
next prev parent reply other threads:[~2026-01-04 11:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-04 11:06 [PATCH v1 0/4] staging: fbtft: reduce stack usage by avoiding large write_reg() varargs Sun Jian
2026-01-04 11:06 ` Sun Jian [this message]
2026-01-05 16:28 ` [PATCH v1 1/4] staging: fbtft: core: avoid large stack usage in DT init parsing Andy Shevchenko
2026-01-05 17:00 ` sun jian
2026-01-05 18:15 ` Andy Shevchenko
2026-01-06 0:42 ` sun jian
2026-01-04 11:06 ` [PATCH v1 2/4] staging: fbtft: ssd1351: send gamma table via fbtft_write_buf_dc() Sun Jian
2026-01-05 14:39 ` Dan Carpenter
2026-01-05 15:09 ` sun jian
2026-01-04 11:06 ` [PATCH v1 3/4] staging: fbtft: ssd1331: " Sun Jian
2026-01-04 11:06 ` [PATCH v1 4/4] staging: fbtft: hx8353d: send LUT via buffer to reduce stack usage Sun Jian
2026-01-05 16:36 ` Andy Shevchenko
2026-01-05 16:32 ` [PATCH v1 0/4] staging: fbtft: reduce stack usage by avoiding large write_reg() varargs Andy Shevchenko
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=20260104110638.532615-2-sun.jian.kdev@gmail.com \
--to=sun.jian.kdev@gmail.com \
--cc=andy@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/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