Using a Kconfig 'select' statement for a user-visible symbol that other
drivers depend on often causes circular dependencies. A new one showed
up when I wanted to add an NVMEM dependency to the DRM_MSM driver:
drivers/i2c/Kconfig:7:error: recursive dependency detected!
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
drivers/video/fbdev/Kconfig:390: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000 depends on FB
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:71: symbol DRM_KMS_HELPER is selected by DRM_MSM
drivers/gpu/drm/msm/Kconfig:2: symbol DRM_MSM depends on NVMEM
drivers/nvmem/Kconfig:1: symbol NVMEM is selected by EEPROM_AT24
drivers/misc/eeprom/Kconfig:3: symbol EEPROM_AT24 depends on I2C
Here, the problem is that many fbdev drivers have an i2c based interface
and just 'select i2c' for that, while we also select the framebuffer
subsystem indirectly from a DRM driver that now depends on i2c.
This does away with the 'select' statement and instead uses 'depends on',
like almost all I2C users.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/video/fbdev/Kconfig | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
When NVMEM is configured as a loadable module, and adreno
is built-in, we get a link failure:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_init':
a5xx_gpu.c:(.text+0x15cc): undefined reference to `nvmem_cell_get'
a5xx_gpu.c:(.text+0x15da): undefined reference to `nvmem_cell_read'
a5xx_gpu.c:(.text+0x15e4): undefined reference to `nvmem_cell_put'
This adds a Kconfig dependency to enforce valid configurations,
when NVMEM is a loadable module, adreno now has to also be one.
The code seems to deal fine with nvmem being completely disabled,
it will just not set the right speed bin then, so we don't need
a hard dependency.
Fixes: f56d9df656c4 ("drm/msm/adreno: Read the speed bins for a5xx targets")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/gpu/drm/msm/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: Jordan Crouse <hidden> Date: 2018-01-17 21:21:12
On Mon, Jan 15, 2018 at 05:14:05PM +0100, Arnd Bergmann wrote:
When NVMEM is configured as a loadable module, and adreno
is built-in, we get a link failure:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_init':
a5xx_gpu.c:(.text+0x15cc): undefined reference to `nvmem_cell_get'
a5xx_gpu.c:(.text+0x15da): undefined reference to `nvmem_cell_read'
a5xx_gpu.c:(.text+0x15e4): undefined reference to `nvmem_cell_put'
This adds a Kconfig dependency to enforce valid configurations,
when NVMEM is a loadable module, adreno now has to also be one.
The code seems to deal fine with nvmem being completely disabled,
it will just not set the right speed bin then, so we don't need
a hard dependency.
Fixes: f56d9df656c4 ("drm/msm/adreno: Read the speed bins for a5xx targets")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From: Rob Clark <hidden> Date: 2018-01-17 21:52:49
On Mon, Jan 15, 2018 at 11:14 AM, Arnd Bergmann [off-list ref] wrote:
When NVMEM is configured as a loadable module, and adreno
is built-in, we get a link failure:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_init':
a5xx_gpu.c:(.text+0x15cc): undefined reference to `nvmem_cell_get'
a5xx_gpu.c:(.text+0x15da): undefined reference to `nvmem_cell_read'
a5xx_gpu.c:(.text+0x15e4): undefined reference to `nvmem_cell_put'
This adds a Kconfig dependency to enforce valid configurations,
when NVMEM is a loadable module, adreno now has to also be one.
The code seems to deal fine with nvmem being completely disabled,
it will just not set the right speed bin then, so we don't need
a hard dependency.
Fixes: f56d9df656c4 ("drm/msm/adreno: Read the speed bins for a5xx targets")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Arnd, beyond randconfig, I guess there are probably two real-world
scenarios, both =m (distro) and both =y (android/oe/etc)..
Is there a kconfig way to say if nvmem=m then drm_msm must be =n or =m?
BR,
-R
From: Lucas Stach <l.stach@pengutronix.de> Date: 2018-01-18 10:15:36
Am Mittwoch, den 17.01.2018, 16:52 -0500 schrieb Rob Clark:
On Mon, Jan 15, 2018 at 11:14 AM, Arnd Bergmann [off-list ref]
wrote:
quoted
When NVMEM is configured as a loadable module, and adreno
is built-in, we get a link failure:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_init':
a5xx_gpu.c:(.text+0x15cc): undefined reference to `nvmem_cell_get'
a5xx_gpu.c:(.text+0x15da): undefined reference to `nvmem_cell_read'
a5xx_gpu.c:(.text+0x15e4): undefined reference to `nvmem_cell_put'
This adds a Kconfig dependency to enforce valid configurations,
when NVMEM is a loadable module, adreno now has to also be one.
The code seems to deal fine with nvmem being completely disabled,
it will just not set the right speed bin then, so we don't need
a hard dependency.
Fixes: f56d9df656c4 ("drm/msm/adreno: Read the speed bins for a5xx
targets")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Arnd, beyond randconfig, I guess there are probably two real-world
scenarios, both =m (distro) and both =y (android/oe/etc)..
Is there a kconfig way to say if nvmem=m then drm_msm must be =n or
=m?
That's exactly what the below patch does.
Regards,
Lucas
depends on DRM
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
depends on OF && COMMON_CLK
+ depends on NVMEM || !NVMEM
depends on MMU
select QCOM_MDT_LOADER if ARCH_QCOM
select REGULATOR
--
2.9.0
On Monday, January 15, 2018 05:14:04 PM Arnd Bergmann wrote:
Using a Kconfig 'select' statement for a user-visible symbol that other
drivers depend on often causes circular dependencies. A new one showed
up when I wanted to add an NVMEM dependency to the DRM_MSM driver:
drivers/i2c/Kconfig:7:error: recursive dependency detected!
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
drivers/video/fbdev/Kconfig:390: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000 depends on FB
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:71: symbol DRM_KMS_HELPER is selected by DRM_MSM
drivers/gpu/drm/msm/Kconfig:2: symbol DRM_MSM depends on NVMEM
drivers/nvmem/Kconfig:1: symbol NVMEM is selected by EEPROM_AT24
drivers/misc/eeprom/Kconfig:3: symbol EEPROM_AT24 depends on I2C
Here, the problem is that many fbdev drivers have an i2c based interface
and just 'select i2c' for that, while we also select the framebuffer
subsystem indirectly from a DRM driver that now depends on i2c.
This does away with the 'select' statement and instead uses 'depends on',
like almost all I2C users.
I worry that this change may cause various driver options to no longer
be visible to people configuring their kernels and not having I2C already
selected.
DRM somehow manages to select I2C and I would prefer to be it the same
way for fbdev (also looking at the current next tree there are still
some drivers that 'select I2C')..
From: Randy Dunlap <hidden> Date: 2018-02-02 00:21:27
On 02/01/2018 08:14 AM, Bartlomiej Zolnierkiewicz wrote:
On Monday, January 15, 2018 05:14:04 PM Arnd Bergmann wrote:
quoted
Using a Kconfig 'select' statement for a user-visible symbol that other
drivers depend on often causes circular dependencies. A new one showed
up when I wanted to add an NVMEM dependency to the DRM_MSM driver:
drivers/i2c/Kconfig:7:error: recursive dependency detected!
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
drivers/video/fbdev/Kconfig:390: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000 depends on FB
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:71: symbol DRM_KMS_HELPER is selected by DRM_MSM
drivers/gpu/drm/msm/Kconfig:2: symbol DRM_MSM depends on NVMEM
drivers/nvmem/Kconfig:1: symbol NVMEM is selected by EEPROM_AT24
drivers/misc/eeprom/Kconfig:3: symbol EEPROM_AT24 depends on I2C
Here, the problem is that many fbdev drivers have an i2c based interface
and just 'select i2c' for that, while we also select the framebuffer
subsystem indirectly from a DRM driver that now depends on i2c.
This does away with the 'select' statement and instead uses 'depends on',
like almost all I2C users.
I worry that this change may cause various driver options to no longer
be visible to people configuring their kernels and not having I2C already
selected.
DRM somehow manages to select I2C and I would prefer to be it the same
way for fbdev (also looking at the current next tree there are still
some drivers that 'select I2C')..
a. Linus has stated that a driver should not enable an entire subsystem,
so depends on would be better than select.
If I had the email/patch, I would be glad to Ack it.
b. DRM configuration is a mess. You shouldn't want to follow their model. :)
c. If I2C is not enabled in the FB menu, someone could just add something like this:
comment "Enable I2C to see more driver choices"
depends on !I2C
On Fri, Feb 2, 2018 at 1:21 AM, Randy Dunlap [off-list ref] wrote:
On 02/01/2018 08:14 AM, Bartlomiej Zolnierkiewicz wrote:
quoted
On Monday, January 15, 2018 05:14:04 PM Arnd Bergmann wrote:
quoted
Using a Kconfig 'select' statement for a user-visible symbol that other
drivers depend on often causes circular dependencies. A new one showed
up when I wanted to add an NVMEM dependency to the DRM_MSM driver:
drivers/i2c/Kconfig:7:error: recursive dependency detected!
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
drivers/video/fbdev/Kconfig:390: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000 depends on FB
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:71: symbol DRM_KMS_HELPER is selected by DRM_MSM
drivers/gpu/drm/msm/Kconfig:2: symbol DRM_MSM depends on NVMEM
drivers/nvmem/Kconfig:1: symbol NVMEM is selected by EEPROM_AT24
drivers/misc/eeprom/Kconfig:3: symbol EEPROM_AT24 depends on I2C
Here, the problem is that many fbdev drivers have an i2c based interface
and just 'select i2c' for that, while we also select the framebuffer
subsystem indirectly from a DRM driver that now depends on i2c.
This does away with the 'select' statement and instead uses 'depends on',
like almost all I2C users.
I worry that this change may cause various driver options to no longer
be visible to people configuring their kernels and not having I2C already
selected.
DRM somehow manages to select I2C and I would prefer to be it the same
way for fbdev (also looking at the current next tree there are still
some drivers that 'select I2C')..
a. Linus has stated that a driver should not enable an entire subsystem,
so depends on would be better than select.
If I had the email/patch, I would be glad to Ack it.
b. DRM configuration is a mess. You shouldn't want to follow their model. :)
Right, that should also be fixed, so DRM no longer includes I2C ;-)
At the moment, DRM is the most common cause for circular dependencies
because it has a number of 'select' statements for symbols that otherwise
are used with 'depends on'. We should probably address the 'select I2C'
portion in there, but also some of the others like:
drivers/gpu/drm/Kconfig: select POWER_SUPPLY
drivers/gpu/drm/Kconfig: select HWMON
drivers/gpu/drm/Kconfig: select FB
drivers/gpu/drm/udl/Kconfig: select USB
drivers/gpu/drm/sti/Kconfig: select OF
drivers/gpu/drm/sti/Kconfig: select RESET_CONTROLLER
drivers/gpu/drm/etnaviv/Kconfig: select CMA if HAVE_DMA_CONTIGUOUS
drivers/gpu/drm/etnaviv/Kconfig: select TMPFS
drivers/gpu/drm/i915/Kconfig.debug: select DEBUG_FS
drivers/gpu/drm/i915/Kconfig.debug: select PREEMPT_COUNT
drivers/gpu/drm/i915/Kconfig.debug: select TRACING
drivers/gpu/drm/i915/Kconfig.debug: select FAULT_INJECTION
drivers/gpu/drm/mediatek/Kconfig: select MEMORY
drivers/gpu/drm/mediatek/Kconfig: select GENERIC_PHY
drivers/gpu/drm/msm/Kconfig: select REGULATOR
c. If I2C is not enabled in the FB menu, someone could just add something like this:
comment "Enable I2C to see more driver choices"
depends on !I2C
I don't think that would address the issue of 'defconfig' builds losing
I2C support when it's no longer automatically selection. On x86, this
is not an issue, as X86 always enables I2C. For the rest, we could
do a hack like this:
On Fri, Feb 2, 2018 at 12:59 PM, Arnd Bergmann [off-list ref] wrote:
On Fri, Feb 2, 2018 at 1:21 AM, Randy Dunlap [off-list ref] wrote:
quoted
b. DRM configuration is a mess. You shouldn't want to follow their model. :)
Right, that should also be fixed, so DRM no longer includes I2C ;-)
At the moment, DRM is the most common cause for circular dependencies
because it has a number of 'select' statements for symbols that otherwise
are used with 'depends on'. We should probably address the 'select I2C'
portion in there, but also some of the others like:
drivers/gpu/drm/Kconfig: select POWER_SUPPLY
drivers/gpu/drm/Kconfig: select HWMON
drivers/gpu/drm/Kconfig: select FB
drivers/gpu/drm/udl/Kconfig: select USB
c. If I2C is not enabled in the FB menu, someone could just add something like this:
comment "Enable I2C to see more driver choices"
depends on !I2C
I don't think that would address the issue of 'defconfig' builds losing
I2C support when it's no longer automatically selection. On x86, this
is not an issue, as X86 always enables I2C. For the rest, we could
do a hack like this:
which would let all 'defconfig' versions keep working. It's a bit ugly, but
at least wouldn't cause other circular dependencies.
And then we'll have to refresh all defconfigs for machines with FB and
without I2C?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds