All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Sun Jian <sun.jian.kdev@gmail.com>
Cc: Andy Shevchenko <andy@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-staging@lists.linux.dev, linux-fbdev@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1 0/4] staging: fbtft: reduce stack usage by avoiding large write_reg() varargs
Date: Mon, 5 Jan 2026 18:32:10 +0200	[thread overview]
Message-ID: <aVvniqcE_PBkKCnn@smile.fi.intel.com> (raw)
In-Reply-To: <20260104110638.532615-1-sun.jian.kdev@gmail.com>

On Sun, Jan 04, 2026 at 07:06:34PM +0800, Sun Jian wrote:

> This series fixes clang `-Wframe-larger-than=1024` warnings in the fbtft
> staging drivers.
> 
> The warnings are triggered by very large `write_reg()`/`write_register()`
> varargs calls, which result in excessive stack usage.
> 
> Switch the affected paths to send a u8 command byte followed by the u8
> payload using `fbtft_write_buf_dc()`. The register values and ordering are
> kept unchanged; only the transfer method is updated.

Looking at the patches I think this is wrong. W.o. detailed test pattern
provided and the list of the devices, NAK.

If you want to address a warning without HW being accessible, perhaps you just
need a simple bump in the Makefile as an exception, however it's also doubtful
as it will hide a potential issue with the stack in the future.

-- 
With Best Regards,
Andy Shevchenko



      parent reply	other threads:[~2026-01-05 16:32 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 ` [PATCH v1 1/4] staging: fbtft: core: avoid large stack usage in DT init parsing Sun Jian
2026-01-05 16:28   ` 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 ` Andy Shevchenko [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=aVvniqcE_PBkKCnn@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.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 \
    --cc=sun.jian.kdev@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.