When SND_SOC_AMD_YC_MACH is selected,
and GPIOLIB is not selected,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for SND_SOC_DMIC
Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n]
Selected by [y]:
- SND_SOC_AMD_YC_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AMD_ACP6x [=y]
This is because SND_SOC_AMD_YC_MACH selects SND_SOC_DMIC,
without selecting or depending on GPIOLIB, despite
SND_SOC_DMIC depending on GPIOLIB.
This unmet dependency bug was detected by Kismet,
a static analysis tool for Kconfig. Please advise
if this is not the appropriate solution.
Signed-off-by: Julian Braha <[email protected]>
---
sound/soc/amd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
index 7a9e45094f37..4aa067c5f054 100644
--- a/sound/soc/amd/Kconfig
+++ b/sound/soc/amd/Kconfig
@@ -88,7 +88,7 @@ config SND_SOC_AMD_ACP6x
config SND_SOC_AMD_YC_MACH
tristate "AMD YC support for DMIC"
select SND_SOC_DMIC
- depends on SND_SOC_AMD_ACP6x
+ depends on SND_SOC_AMD_ACP6x && GPIOLIB
help
This option enables machine driver for Yellow Carp platform
using dmic. ACP IP has PDM Decoder block with DMA controller.
--
2.32.0
On Sun, Jan 16, 2022 at 11:15:28PM -0500, Julian Braha wrote:
> When SND_SOC_AMD_YC_MACH is selected,
> and GPIOLIB is not selected,
> Kbuild gives the following warning:
>
> WARNING: unmet direct dependencies detected for SND_SOC_DMIC
> Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n]
> Selected by [y]:
> - SND_SOC_AMD_YC_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AMD_ACP6x [=y]
Why is this a good fix and not removing the dependency on gpiolib from
DMIC? While a DMIC *can* use a GPIO it's not something that's an
intrinsic requirement and it's entirely optional in the code.
On 1/18/22 11:10 AM, Mark Brown wrote:
> On Sun, Jan 16, 2022 at 11:15:28PM -0500, Julian Braha wrote:
>> When SND_SOC_AMD_YC_MACH is selected,
>> and GPIOLIB is not selected,
>> Kbuild gives the following warning:
>>
>> WARNING: unmet direct dependencies detected for SND_SOC_DMIC
>> Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n]
>> Selected by [y]:
>> - SND_SOC_AMD_YC_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AMD_ACP6x [=y]
>
> Why is this a good fix and not removing the dependency on gpiolib from
> DMIC? While a DMIC *can* use a GPIO it's not something that's an
> intrinsic requirement and it's entirely optional in the code.
We also have similar 'depends on GPIOLIB' for Intel boards that are not
really useful. see e.g. 4262ddc2ad63 ('ASoC: Intel: boards: add explicit
dependency on GPIOLIB when DMIC is used'). IIRC we had this discussion
before about doing a larger cleanup.
On Tue, Jan 18, 2022 at 11:21:50AM -0600, Pierre-Louis Bossart wrote:
> On 1/18/22 11:10 AM, Mark Brown wrote:
> > Why is this a good fix and not removing the dependency on gpiolib from
> > DMIC? While a DMIC *can* use a GPIO it's not something that's an
> > intrinsic requirement and it's entirely optional in the code.
> We also have similar 'depends on GPIOLIB' for Intel boards that are not
> really useful. see e.g. 4262ddc2ad63 ('ASoC: Intel: boards: add explicit
> dependency on GPIOLIB when DMIC is used'). IIRC we had this discussion
> before about doing a larger cleanup.
At first glance it's just that the gpiolib dependency on the DMIC driver
is spurious and should be deleted, the code looks fine and I'd not
expect any need for an actual dependency (but I'm out of office this
week so probably not going to actually poke at things properly right
now).