diff mbox

[v9,17/19] drm/virtio: kconfig: Fix recursive dependency issue.

Message ID 1473081421-16555-18-git-send-email-peter.griffin@linaro.org
State Superseded
Headers show

Commit Message

Peter Griffin Sept. 5, 2016, 1:16 p.m. UTC
ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
recursive dependency.

[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42:	symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36:	symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1:	symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1:	symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4:	symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103:	symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440:	symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5:	symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29:	symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64:	symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7:	symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63:	symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378:	symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366:	symbol FB_CYBER2000 depends on FB

which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO.

Fix by dropping depend and switching to select VIRTIO.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>

---
 drivers/gpu/drm/virtio/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
1.9.1

Comments

Peter Griffin Sept. 20, 2016, 8:32 a.m. UTC | #1
Hi Emil,

On Tue, 20 Sep 2016, Emil Velikov wrote:

> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:

> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following

> > recursive dependency.



> >

> From a humble skim through remoteproc, drm and a few other subsystems

> I think the above is wrong. All the drivers (outside of remoteproc),

> that I've seen, depend on the core component, they don't select it.


I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.

For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.

For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'

git grep "select VIRTIO" | wc -l
14

git grep "depends on VIRTIO" | wc -l
10


> Furthermore most places explicitly hide the drivers from the menu if

> the core component isn't enabled.


Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).

It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.

> 

> Is there something that requires such a different/unusual behaviour in

> remoteproc ?

> 


I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
mfd subsystem, client drivers select MFD_CORE.

I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?

regards,

Peter.
Bjorn Andersson Sept. 27, 2016, 5:01 p.m. UTC | #2
On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:

> > Hi Emil,

> >

> > On Tue, 20 Sep 2016, Emil Velikov wrote:

> >

> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:

> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following

> >> > recursive dependency.

> >

> >

> >> >

> >> From a humble skim through remoteproc, drm and a few other subsystems

> >> I think the above is wrong. All the drivers (outside of remoteproc),

> >> that I've seen, depend on the core component, they don't select it.

> >

> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and

> > why it is like it is.

> >

> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all

> > the other drivers in the remoteproc subsystem which has exposed this recursive

> > dependency issue.

> >

> > For this particular kconfig symbol a quick grep reveals more drivers in

> > the kernel using 'select', than 'depend on'

> >

> > git grep "select VIRTIO" | wc -l

> > 14

> >

> > git grep "depends on VIRTIO" | wc -l

> > 10

> >

> Might be worth taking a closer look into these at some point.

> 


The general idea here is that VIRTIO provides the "framework" and as
such drivers implementing VIRTIO do select and drivers using virtio use
depends.

This is found in several places around the kernel.

> >

> >> Furthermore most places explicitly hide the drivers from the menu if

> >> the core component isn't enabled.

> >

> > Remoteproc subsystem takes a different approach, the core code is only enabled

> > if a driver which relies on it is enabled. This IMHO makes sense, as

> > remoteproc is not widely used (only a few particular ARM SoC's).

> >

> > It is true that for subsystems which rely on the core component being

> > explicitly enabled, they often tend to hide drivers which depend on it

> > from the menu unless it is. This also makes sense.

> >

> >>

> >> Is there something that requires such a different/unusual behaviour in

> >> remoteproc ?

> >>


There's nothing unusual in remoteproc that forces us to stay with this
model; however the parts related to the REMOTEPROC config is useless by
themselves.

Regards,
Bjorn
Peter Griffin Oct. 6, 2016, 9:37 a.m. UTC | #3
Hi Jani,

Sorry for the delay, I've been travelling last week.

On Tue, 20 Sep 2016, Jani Nikula wrote:

> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:

> > Hi Emil,

> >

> > On Tue, 20 Sep 2016, Emil Velikov wrote:

> >

> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:

> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following

> >> > recursive dependency.

> >

> >

> >> >

> >> From a humble skim through remoteproc, drm and a few other subsystems

> >> I think the above is wrong. All the drivers (outside of remoteproc),

> >> that I've seen, depend on the core component, they don't select it.

> >

> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and

> > why it is like it is.

> >

> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all

> > the other drivers in the remoteproc subsystem which has exposed this recursive

> > dependency issue.

> >

> > For this particular kconfig symbol a quick grep reveals more drivers in

> > the kernel using 'select', than 'depend on'

> >

> > git grep "select VIRTIO" | wc -l

> > 14

> >

> > git grep "depends on VIRTIO" | wc -l

> > 10

> >

> >

> >> Furthermore most places explicitly hide the drivers from the menu if

> >> the core component isn't enabled.

> >

> > Remoteproc subsystem takes a different approach, the core code is only enabled

> > if a driver which relies on it is enabled. This IMHO makes sense, as

> > remoteproc is not widely used (only a few particular ARM SoC's).

> >

> > It is true that for subsystems which rely on the core component being

> > explicitly enabled, they often tend to hide drivers which depend on it

> > from the menu unless it is. This also makes sense.

> >

> >> 

> >> Is there something that requires such a different/unusual behaviour in

> >> remoteproc ?

> >> 

> >

> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in

> > mfd subsystem, client drivers select MFD_CORE.

> >

> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him

> > recently, maybe he has some thoughts on whether this is the correct fix or not?

> 

> 

> Documentation/kbuild/kconfig-language.txt:

> 

>   Note:

> 	select should be used with care. select will force

> 	a symbol to a value without visiting the dependencies.

> 	By abusing select you are able to select a symbol FOO even

> 	if FOO depends on BAR that is not set.

> 	In general use select only for non-visible symbols

> 	(no prompts anywhere) and for symbols with no dependencies.

> 	That will limit the usefulness but on the other hand avoid

> 	the illegal configurations all over.


Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.

In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.

> 

> People tend to abuse select because it's "convenient". If you depend,

> but some of your dependencies aren't met, you're in for some digging

> through Kconfig to find the missing deps. Just to make the option you

> want visible in menuconfig. If you instead select something with

> dependencies, it'll be right most of the time, and it's "convenient",

> until it breaks. (And hey, it usually breaks for someone else with some

> other config, so it's still convenient for you.)


I'm sure they do but in this case it is actually the use of 'depends on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.

> 

> Perhaps kconfig should complain about selecting visible symbols and

> symbols with dependencies.


That sounds like it would be a useful addition.

Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?

regards,

Peter.
diff mbox

Patch

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@ 
 config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
-	depends on DRM && VIRTIO
+	depends on DRM
+	select VIRTIO
         select DRM_KMS_HELPER
         select DRM_TTM
 	help