[PATCH] drm/tiny: pixpaper: Prevent inlining of send helpers to reduce stack usage

[PATCH] drm/tiny: pixpaper: Prevent inlining of send helpers to reduce stack usage

[LiangCheng Wang]

Clang reports that pixpaper_panel_hw_init() exceeds the 8 KB stack
frame limit:

    drivers/gpu/drm/tiny/pixpaper.c:579:12: warning:
      stack frame size (20024) exceeds limit (8192)
      in 'pixpaper_panel_hw_init'

This warning occurs because the compiler aggressively inlines
pixpaper_send_cmd() and pixpaper_send_data() into
pixpaper_panel_hw_init(), which inflates the estimated stack usage.

Mark these two helper functions as 'noinline' to prevent inlining.
This significantly reduces the reported stack usage without changing
runtime behavior.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510270858.1GzE6iQg-lkp@intel.com/
Fixes: c9e70639f591 ("drm: tiny: Add support for Mayqueen Pixpaper e-ink panel")
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
---
When building with Clang and frame size warnings enabled
(-Wframe-larger-than=8192), the compiler reports that
pixpaper_panel_hw_init() consumes over 20 KB of stack space:

    drivers/gpu/drm/tiny/pixpaper.c:579:12: warning:
      stack frame size (20024) exceeds limit (8192)
      in 'pixpaper_panel_hw_init'

This happens because Clang aggressively inlines
pixpaper_send_cmd() and pixpaper_send_data() into
pixpaper_panel_hw_init(), causing the calculated stack usage
to balloon far beyond the warning threshold.

The fix is straightforward: mark these two helper functions as
'noinline' to prevent inlining. This reduces the reported stack
usage to within normal limits without changing runtime behavior.
---
 drivers/gpu/drm/tiny/pixpaper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tiny/pixpaper.c b/drivers/gpu/drm/tiny/pixpaper.c
index 32598fb2fee7fcdea3ea0696c2bf54404fcffa2e..70e3239adfd0f86f92551991872486380489fb9b 100644
--- a/drivers/gpu/drm/tiny/pixpaper.c
+++ b/drivers/gpu/drm/tiny/pixpaper.c
@@ -536,7 +536,7 @@ static void pixpaper_spi_sync(struct spi_device *spi, struct spi_message *msg,
 		err->errno_code = ret;
 }
 
-static void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
+static noinline void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
 			      struct pixpaper_error_ctx *err)
 {
 	if (err->errno_code)
@@ -556,7 +556,7 @@ static void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
 	pixpaper_spi_sync(panel->spi, &msg, err);
 }
 
-static void pixpaper_send_data(struct pixpaper_panel *panel, u8 data,
+static noinline void pixpaper_send_data(struct pixpaper_panel *panel, u8 data,
 			       struct pixpaper_error_ctx *err)
 {
 	if (err->errno_code)

---
base-commit: d127176862a93c4b3216bda533d2bee170af5e71
change-id: 20251031-fix_202510270858-2e4643b00545

Best regards,
-- 
LiangCheng Wang <zaq14760@gmail.com>

Re: [PATCH] drm/tiny: pixpaper: Prevent inlining of send helpers to reduce stack usage

[Jani Nikula]

On Fri, 31 Oct 2025, LiangCheng Wang <zaq14760@gmail.com> wrote:
> Clang reports that pixpaper_panel_hw_init() exceeds the 8 KB stack
> frame limit:
>
>     drivers/gpu/drm/tiny/pixpaper.c:579:12: warning:
>       stack frame size (20024) exceeds limit (8192)
>       in 'pixpaper_panel_hw_init'
>
> This warning occurs because the compiler aggressively inlines
> pixpaper_send_cmd() and pixpaper_send_data() into
> pixpaper_panel_hw_init(), which inflates the estimated stack usage.
>
> Mark these two helper functions as 'noinline' to prevent inlining.
> This significantly reduces the reported stack usage without changing
> runtime behavior.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202510270858.1GzE6iQg-lkp@intel.com/
> Fixes: c9e70639f591 ("drm: tiny: Add support for Mayqueen Pixpaper e-ink panel")
> Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
> ---
> When building with Clang and frame size warnings enabled
> (-Wframe-larger-than=8192), the compiler reports that
> pixpaper_panel_hw_init() consumes over 20 KB of stack space:
>
>     drivers/gpu/drm/tiny/pixpaper.c:579:12: warning:
>       stack frame size (20024) exceeds limit (8192)
>       in 'pixpaper_panel_hw_init'
>
> This happens because Clang aggressively inlines
> pixpaper_send_cmd() and pixpaper_send_data() into
> pixpaper_panel_hw_init(), causing the calculated stack usage
> to balloon far beyond the warning threshold.
>
> The fix is straightforward: mark these two helper functions as
> 'noinline' to prevent inlining. This reduces the reported stack
> usage to within normal limits without changing runtime behavior.

I really *really* wish we wouldn't have to go this route at all.

But if we have to, I think noinline_for_stack is the keyword to use.


BR,
Jani.

> ---
>  drivers/gpu/drm/tiny/pixpaper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/pixpaper.c b/drivers/gpu/drm/tiny/pixpaper.c
> index 32598fb2fee7fcdea3ea0696c2bf54404fcffa2e..70e3239adfd0f86f92551991872486380489fb9b 100644
> --- a/drivers/gpu/drm/tiny/pixpaper.c
> +++ b/drivers/gpu/drm/tiny/pixpaper.c
> @@ -536,7 +536,7 @@ static void pixpaper_spi_sync(struct spi_device *spi, struct spi_message *msg,
>  		err->errno_code = ret;
>  }
>  
> -static void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
> +static noinline void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
>  			      struct pixpaper_error_ctx *err)
>  {
>  	if (err->errno_code)
> @@ -556,7 +556,7 @@ static void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
>  	pixpaper_spi_sync(panel->spi, &msg, err);
>  }
>  
> -static void pixpaper_send_data(struct pixpaper_panel *panel, u8 data,
> +static noinline void pixpaper_send_data(struct pixpaper_panel *panel, u8 data,
>  			       struct pixpaper_error_ctx *err)
>  {
>  	if (err->errno_code)
>
> ---
> base-commit: d127176862a93c4b3216bda533d2bee170af5e71
> change-id: 20251031-fix_202510270858-2e4643b00545
>
> Best regards,

-- 
Jani Nikula, Intel

Re: [PATCH] drm/tiny: pixpaper: Prevent inlining of send helpers to reduce stack usage

[Nathan Chancellor]

On Fri, Oct 31, 2025 at 10:40:13AM +0200, Jani Nikula wrote:
> On Fri, 31 Oct 2025, LiangCheng Wang <zaq14760@gmail.com> wrote:
> > Clang reports that pixpaper_panel_hw_init() exceeds the 8 KB stack
> > frame limit:
> >
> >     drivers/gpu/drm/tiny/pixpaper.c:579:12: warning:
> >       stack frame size (20024) exceeds limit (8192)
> >       in 'pixpaper_panel_hw_init'
> >
> > This warning occurs because the compiler aggressively inlines
> > pixpaper_send_cmd() and pixpaper_send_data() into
> > pixpaper_panel_hw_init(), which inflates the estimated stack usage.
> >
> > Mark these two helper functions as 'noinline' to prevent inlining.
> > This significantly reduces the reported stack usage without changing
> > runtime behavior.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202510270858.1GzE6iQg-lkp@intel.com/
> > Fixes: c9e70639f591 ("drm: tiny: Add support for Mayqueen Pixpaper e-ink panel")
> > Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
> > ---
> > When building with Clang and frame size warnings enabled
> > (-Wframe-larger-than=8192), the compiler reports that
> > pixpaper_panel_hw_init() consumes over 20 KB of stack space:
> >
> >     drivers/gpu/drm/tiny/pixpaper.c:579:12: warning:
> >       stack frame size (20024) exceeds limit (8192)
> >       in 'pixpaper_panel_hw_init'
> >
> > This happens because Clang aggressively inlines
> > pixpaper_send_cmd() and pixpaper_send_data() into
> > pixpaper_panel_hw_init(), causing the calculated stack usage
> > to balloon far beyond the warning threshold.
> >
> > The fix is straightforward: mark these two helper functions as
> > 'noinline' to prevent inlining. This reduces the reported stack
> > usage to within normal limits without changing runtime behavior.
> 
> I really *really* wish we wouldn't have to go this route at all.
> 
> But if we have to, I think noinline_for_stack is the keyword to use.

For what it's worth, the configuration in the report linked above has
CONFIG_KASAN_STACK=y, which is known to be broken with clang and
requires !COMPILE_TEST to even select it (which the robot should be
using to avoid pathological cases such as this). If I disable
CONFIG_KASAN_STACK, there is no warning even with a 1024 byte limit, so
realistically, I think we can just leave this be.

Cheers,
Nathan

> > ---
> >  drivers/gpu/drm/tiny/pixpaper.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tiny/pixpaper.c b/drivers/gpu/drm/tiny/pixpaper.c
> > index 32598fb2fee7fcdea3ea0696c2bf54404fcffa2e..70e3239adfd0f86f92551991872486380489fb9b 100644
> > --- a/drivers/gpu/drm/tiny/pixpaper.c
> > +++ b/drivers/gpu/drm/tiny/pixpaper.c
> > @@ -536,7 +536,7 @@ static void pixpaper_spi_sync(struct spi_device *spi, struct spi_message *msg,
> >  		err->errno_code = ret;
> >  }
> >  
> > -static void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
> > +static noinline void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
> >  			      struct pixpaper_error_ctx *err)
> >  {
> >  	if (err->errno_code)
> > @@ -556,7 +556,7 @@ static void pixpaper_send_cmd(struct pixpaper_panel *panel, u8 cmd,
> >  	pixpaper_spi_sync(panel->spi, &msg, err);
> >  }
> >  
> > -static void pixpaper_send_data(struct pixpaper_panel *panel, u8 data,
> > +static noinline void pixpaper_send_data(struct pixpaper_panel *panel, u8 data,
> >  			       struct pixpaper_error_ctx *err)
> >  {
> >  	if (err->errno_code)
> >
> > ---
> > base-commit: d127176862a93c4b3216bda533d2bee170af5e71
> > change-id: 20251031-fix_202510270858-2e4643b00545
> >
> > Best regards,
> 
> -- 
> Jani Nikula, Intel

Re: [PATCH] drm/tiny: pixpaper: Prevent inlining of send helpers to reduce stack usage

[LiangCheng Wang]

Hi Nathan, Jani,

Thanks for the detailed explanation.

Understood — if this only happens when CONFIG_KASAN_STACK is enabled
with clang, it doesn’t look like something that needs to be addressed in
the driver itself.

Thanks everyone for helping clarify this!

Best regards,
LiangCheng