[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200218100959.GD108283@ediswmail.ad.cirrus.com>
Date: Tue, 18 Feb 2020 10:09:59 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Randy Dunlap <rdunlap@...radead.org>
CC: Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
moderated for non-subscribers <alsa-devel@...a-project.org>,
Mark Brown <broonie@...nel.org>,
<patches@...nsource.cirrus.com>, <geert@...ux-m68k.org>
Subject: Re: linux-next: Tree for Feb 18 (sound/soc/codecs/wm5110.c)
On Mon, Feb 17, 2020 at 11:05:49PM -0800, Randy Dunlap wrote:
> [resending to broonie@...nel.org; other email address got message too big for mailbox]
>
Will have a word with our IT guys, Mark's
opensource.wolfsonmicro.com account certainly shouldn't still be
accepting email.
>
> On 2/17/20 11:04 PM, Randy Dunlap wrote:
> > On 2/17/20 8:28 PM, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Changes since 20200217:
> >>
> >
> > on x86_64:
> >
> > WARNING: unmet direct dependencies detected for SND_SOC_WM5110
> > Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && MFD_WM5110 [=n]
> > Selected by [y]:
> > - SND_SOC_BELLS [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_SAMSUNG [=y] && MFD_ARIZONA [=y] && I2C [=y] && SPI_MASTER [=y] && (MACH_WLF_CRAGG_6410 || COMPILE_TEST [=y])
> > - SND_SOC_SAMSUNG_TM2_WM5110 [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_SAMSUNG [=y] && MFD_ARIZONA [=y] && I2C [=y] && SPI_MASTER [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> >
> >
> > Full randconfig file is attached.
> >
>
This looks like it comes from these two patches:
ea00d95200d0 ("ASoC: Use imply for SND_SOC_ALL_CODECS")
d8dd3f92a6ba ("ASoC: Fix SND_SOC_ALL_CODECS imply misc fallout")
What is happening is the machine drivers still select these
symbols but this doesn't take account of the dependencies, which
are now added by the second of those patches.
I guess there are a couple of options:
1) We could update the machine drivers to do an imply as well,
like the changes to SND_SOC_ALL_CODECS. I think this will
generally work but doesn't really feel right as you can end up with
the machine driver built without the CODEC.
2) We could update the machine drivers to a depends on and make
the CODEC symbols manually selectable. I guess this also has the
advantages that it would be necessary for the simple card stuff
that seems to be everyones first choice for machine drivers these
days.
Mark do you have any strong feelings on this I am leaning towards
2?
Thanks,
Charles
Powered by blists - more mailing lists