| Message ID | 20220117041528.59958-1-julianbraha@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | ASoC: amd: fix unmet dependency on GPIOLIB for SND_SOC_DMIC | expand |
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).
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.
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 <julianbraha@gmail.com> --- sound/soc/amd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)