Re: [linux-next:master 8699/10823] sound/soc/sdca/sdca_interrupts.c:220:1: warning: the frame size of 1264 bytes is larger than 1024 bytes

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Fri, Jul 18, 2025 at 05:50:23PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 18, 2025, at 16:43, kernel test robot wrote:
> > First bad commit (maybe != root cause):
> > 
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   024e09e444bd2b06aee9d1f3fe7b313c7a2df1bb
> > commit: 6894e49b7b62cdb0edbcaaa23ea0218edb3b02dd [8699/10823] ASoC: SDCA: Kconfig Makefile fixups
> 
> The actual root cause was commit b9ab3b618241 ("ASoC: SDCA: Add some
> initial IRQ handlers"), which introduced the new interrupt handler.
> 
> > If you fix the issue in a separate patch/commit (i.e. not just a new 
> > version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: 
> > https://lore.kernel.org/oe-kbuild-all/202507182222.OLgOy9fX-lkp@intel.com/
> >
> > All warnings (new ones prefixed by >>):
> >
> >    sound/soc/sdca/sdca_interrupts.c: In function 'detected_mode_handler':
> >>> sound/soc/sdca/sdca_interrupts.c:220:1: warning: the frame size of 1264 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> >      220 | }
> >          | ^
> 
> I have not seen this one in my testing, but I have looked at
> a lot of similar issues recently.
> 
> 
> The first thing I see is the "struct snd_ctl_elem_value" structure
> on the stack, which is about 700 bytes long. This is probably
> too big for the stack, but doesn't explain the warning by itself.
> 
> Seeing that only a single integer (ucontrol.value.enumerated.item[0])
> is actually initialized in the structure that gets passed down,
> I wonder if it could just call a different interface instead that
> takes a u32 argument instead of the full ucontrol.
> 
> Alternatively, the ucontrol could be preallocated, e.g. in
> struct sdca_interrupt, as there should be no concurrent callers
> of detect_mode_handler for a single sdca_interrupt.

I have a patch I will send out shortly, although I have just gone
for the lazy allocate it locally approach. The jack detect is
hardly a critical path since it only runs when someone plugs
in/out a jack, so keeping it simple seemed best.

Thanks,
Charles