[RFC 5/6] drm/rcar-du: fix selection of CMM driver

Arnd Bergmann arnd at arndb.de
Wed Apr 15 21:22:08 UTC 2020


On Wed, Apr 15, 2020 at 11:12 PM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Wed, Apr 15, 2020 at 09:07:14PM +0200, Arnd Bergmann wrote:
> > On Wed, Apr 15, 2020 at 5:18 PM Arnd Bergmann <arnd at arndb.de> wrote:
> > > On Wed, Apr 15, 2020 at 4:13 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > On Wed, Apr 15, 2020 at 3:47 PM Arnd Bergmann <arnd at arndb.de> wrote:
> > > > > On Tue, Apr 14, 2020 at 10:52 PM Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote:
> > > > > > Doesn't "imply" mean it gets selected by default but can be manually
> > > > > > disabled ?
> > > > >
> > > > > That may be what it means now (I still don't understand how it's defined
> > > > > as of v5.7-rc1), but traditionally it was more like a 'select if all
> > > > > dependencies are met'.
> > > >
> > > > That's still what it is supposed to mean right now ;-)
> > > > Except that now it should correctly handle the modular case, too.
> > >
> > > Then there is a bug. If I run 'make menuconfig' now on a mainline kernel
> > > and enable CONFIG_DRM_RCAR_DU, I can set
> > > DRM_RCAR_CMM and DRM_RCAR_LVDS to 'y', 'n' or 'm' regardless
> > > of whether CONFIG_DRM_RCAR_DU is 'm' or 'y'. The 'implies'
> > > statement seems to be ignored entirely, except as reverse 'default'
> > > setting.
> >
> > Here is another version that should do what we want and is only
> > half-ugly. I can send that as a proper patch if it passes my testing
> > and nobody hates it too much.
>
> This may be a stupid question, but doesn't this really call for fixing
> Kconfig ? This seems to be such a common pattern that requiring
> constructs similar to the ones below will be a never-ending chase of
> offenders.

Maybe, I suppose the hardest part here would be to come up with
an appropriate name for the keyword ;-)

Any suggestions?

This specific issue is fairly rare though, in most cases the dependencies
are in the right order so a Kconfig symbol 'depends on' a second one
when the corresponding loadable module uses symbols from that second
module. The problem here is that the two are mixed up.

The much more common problem is the one where one needs to
wrong

config FOO
       depends on BAR || !BAR

To ensure the dependency is either met or BAR is disabled, but
not FOO=y with BAR=m. If you have any suggestions for a keyword
for that thing, we can clean up hundreds of such instances.

        Arnd


More information about the dri-devel mailing list