linux-kernel - Re: linux-next: build warning after merge of the sound-asoc tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CC98F1397C1BC467+aP7bb005VjZNJmS3@kernel.org>
Date: Mon, 27 Oct 2025 10:39:43 +0800
From: Troy Mitchell <troy.mitchell@...ux.spacemit.com>
To: Randy Dunlap <rdunlap@...radead.org>,
	Troy Mitchell <troy.mitchell@...ux.spacemit.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Mark Brown <broonie@...nel.org>,
	Liam Girdwood <lgirdwood@...il.com>
Cc: Jinmei Wei <weijinmei@...ux.spacemit.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build warning after merge of the sound-asoc tree

On Fri, Oct 24, 2025 at 12:40:07PM -0700, Randy Dunlap wrote:
> 
> 
> On 10/24/25 6:27 AM, Troy Mitchell wrote:
> > On Wed, Oct 22, 2025 at 02:17:05PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the sound-asoc tree, today's linux-next build (powercp
> >> allyesconfig) produced this warning:
> >>
> >> WARNING: unmet direct dependencies detected for DMA_CMA
> >>   Depends on [n]: HAVE_DMA_CONTIGUOUS [=n] && CMA [=y]
> >>   Selected by [y]:
> >>   - SND_SOC_K1_I2S [=y] && SOUND [=y] && SND [=y] && SND_SOC [=y] && (COMPILE_TEST [=y] || ARCH_SPACEMIT) && HAVE_CLK [=y]
> >>
> >> Probably introduced by commit
> >>
> >>   fce217449075 ("ASoC: spacemit: add i2s support for K1 SoC")
> > Sorry, I didn't realize that this email ended up in my spam folder,
> > and I just saw it today.
> > 
> > I am considering directly selecting `HAVE_DMA_CONTIGUOUS`,
> > but another possibility is to make it depend on `DMA_CMA`.
> > Can anyone advise which approach would be better?
> > If there are no objections, I plan to send a patch on Monday:
> > select `HAVE_DMA_CONTIGUOUS`
> 
> Hi,
> 
> My read of how HAVE_DMA_CONTIGUOUS is used is that an arch or
> platform selects it to show that it has this capability.
> Drivers don't do that.
Oh yes, that's true.
> 
> Possibly ARCH_SPACEMIT should select HAVE_CONTIGUOUS_DMA but that
> wouldn't help here since this is COMPILE_TEST=y, which did
> its job here.
> 
> I think this driver should
> 	depend on DMA_CMA
> That will take care of being dependent on both CMA and
> HAVE_CONTIGUOUS_DMA.
> 
> Or IF the driver can operate without DMA_CMA being enabled,
> the driver Kconfig could do
> 	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
> and then have alternate code paths for whatever is
> enabled.
> 
> This driver could
> 	select CMA if MMU
> 
> or it could do
> 	depends on MMU
> 	depends on HAVE_CONTIGUOUS_DMA
> 	select CMA
> 
> but
> 	depends on DMA_CMA
> wraps all of driver dependencies into one statement.
> But no, not
> 	select HAVE_CONTIGUOUS_DMA
Yes, thank you for the clarification.
I will go with using depends on.

I also think I no longer need to select HAVE_DMA_CONTIGUOUS
in ARCH_SPACEMIT, as it is handled here:
arch/riscv/Kconfig +154

                          - Troy
> 
> -- 
> ~Randy
> 
>