From: Sam Ravnborg <sam@ravnborg.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: marex@denx.de, linux-renesas-soc@vger.kernel.org,
linux-fbdev@vger.kernel.org, dsd@laptop.org,
Nicolas Pitre <nico@fluxnic.net>,
airlied@linux.ie, masahiroy@kernel.org, jfrederich@gmail.com,
Saeed Mahameed <saeedm@mellanox.com>,
thellstrom@vmware.com, haojian.zhuang@gmail.com,
Andrzej Hajda <a.hajda@samsung.com>,
kieran.bingham+renesas@ideasonboard.com, geert@linux-m68k.org,
dri-devel@lists.freedesktop.org,
linux-graphics-maintainer@vmware.com, robert.jarzmik@free.fr,
Jason Gunthorpe <jgg@ziepe.ca>,
daniel@zonque.org, Laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH 6/8] drm: decouple from CONFIG_FB
Date: Fri, 17 Apr 2020 16:50:41 +0000 [thread overview]
Message-ID: <20200417165041.GA30483@ravnborg.org> (raw)
In-Reply-To: <20200417155553.675905-7-arnd@arndb.de>
Hi Arnd.
On Fri, Apr 17, 2020 at 05:55:51PM +0200, Arnd Bergmann wrote:
> CONFIG_DRM_KMS_FB_HELPER selects CONFIG_FB, which is something it
> really should not, to avoid circular dependencies and accidentally
> including potentially dangerous user interfaces in the kernel,
> so change this into a 'depends on' check.
>
> Two device drivers currently select CONFIG_DRM_KMS_FB_HELPER, but
> as far as I can tell, they do not really need to any more, so those
> selects can be removed.
>
> This leaves DRM_FBDEV_EMULATION as the only thing that rightfully
> selects CONFIG_DRM_KMS_FB_HELPER, and this now has to depend on
> CONFIG_FB and its dependencies.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/gpu/drm/Kconfig | 5 +++--
> drivers/gpu/drm/mxsfb/Kconfig | 1 -
> drivers/gpu/drm/zte/Kconfig | 1 -
> 3 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 43594978958e..7c3109133685 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -80,7 +80,7 @@ config DRM_KMS_HELPER
> config DRM_KMS_FB_HELPER
> bool
> depends on DRM_KMS_HELPER
> - select FB
> + depends on FB
> select FRAMEBUFFER_CONSOLE if !EXPERT
> select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
> select FB_SYS_FOPS
> @@ -111,7 +111,8 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
>
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modesetting driver"
> - depends on DRM
> + depends on DRM && FB
> + depends on FB=y || DRM=m
> select DRM_KMS_HELPER
> select DRM_KMS_FB_HELPER
> default y
This statement:
depends on DRM && FB
tell us that both symbols must be either y or m. Any combination of y
and m will do the trick
Then we have this statement:
depends on FB=y || DRM=m
It tells us that either FB equals y or DRM equals m.
So we have following table
FB DRM Result
n n n
n y n
n m n
y n n
y y y
y m y
m n n
m y N
m m y
So what this try to say is that we cannot have FB a module while DRM is
built-in (marked N in the above).
Could you explain in the changelog why this combination is not good.
(Or tell me if my analysis was flawed).
With this fixed (assuming I am right):
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 0dca8f27169e..33916b7b2c50 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -10,7 +10,6 @@ config DRM_MXSFB
> depends on COMMON_CLK
> select DRM_MXS
> select DRM_KMS_HELPER
> - select DRM_KMS_FB_HELPER
> select DRM_KMS_CMA_HELPER
> select DRM_PANEL
> help
> diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
> index 90ebaedc11fd..aa8594190b50 100644
> --- a/drivers/gpu/drm/zte/Kconfig
> +++ b/drivers/gpu/drm/zte/Kconfig
> @@ -3,7 +3,6 @@ config DRM_ZTE
> tristate "DRM Support for ZTE SoCs"
> depends on DRM && ARCH_ZX
> select DRM_KMS_CMA_HELPER
> - select DRM_KMS_FB_HELPER
> select DRM_KMS_HELPER
> select SND_SOC_HDMI_CODEC if SND_SOC
> select VIDEOMODE_HELPERS
> --
> 2.26.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-17 16:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 15:55 [PATCH 0/8] drm, fbdev: rework dependencies Arnd Bergmann
2020-04-17 15:55 ` [PATCH 1/8] fbdev: w100fb: clean up mach-pxa compile-time dependency Arnd Bergmann
2020-04-18 10:10 ` Robert Jarzmik
2020-04-18 10:14 ` Arnd Bergmann
2020-04-17 15:55 ` [PATCH 2/8] fbdev/ARM: pxa: avoid selecting CONFIG_FB Arnd Bergmann
2020-04-18 10:18 ` Robert Jarzmik
2020-04-17 15:55 ` [PATCH 3/8] fbdev: rework FB_DDC dependencies Arnd Bergmann
2020-04-17 15:55 ` [PATCH 4/8] drm/rcar: stop using 'imply' for dependencies Arnd Bergmann
2020-04-17 15:55 ` [PATCH 5/8] drm/vmwgfx: make framebuffer support optional Arnd Bergmann
2020-04-20 12:07 ` Thomas Zimmermann
2020-04-17 15:55 ` [PATCH 6/8] drm: decouple from CONFIG_FB Arnd Bergmann
2020-04-17 16:50 ` Sam Ravnborg [this message]
2020-04-17 20:03 ` Arnd Bergmann
2020-04-17 20:29 ` Sam Ravnborg
2020-04-17 15:55 ` [PATCH 7/8] fbdev: rework backlight dependencies Arnd Bergmann
2020-04-17 17:04 ` Sam Ravnborg
2020-04-17 19:55 ` Arnd Bergmann
2020-04-20 8:02 ` Jani Nikula
2020-04-17 15:55 ` [PATCH 8/8] drm/bridge/sii8620: fix extcon dependency Arnd Bergmann
2020-04-17 16:52 ` Andrzej Hajda
2020-04-17 17:14 ` [PATCH 0/8] drm, fbdev: rework dependencies Daniel Vetter
2020-04-17 19:08 ` Jason Gunthorpe
2020-04-20 8:14 ` Jani Nikula
2020-04-20 14:03 ` Arnd Bergmann
2020-04-21 12:27 ` Daniel Vetter
2020-04-21 12:58 ` Jani Nikula
2020-04-21 13:05 ` Geert Uytterhoeven
2020-04-21 13:10 ` Daniel Vetter
2020-04-21 13:25 ` Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200417165041.GA30483@ravnborg.org \
--to=sam@ravnborg.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=arnd@arndb.de \
--cc=daniel@zonque.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsd@laptop.org \
--cc=geert@linux-m68k.org \
--cc=haojian.zhuang@gmail.com \
--cc=jfrederich@gmail.com \
--cc=jgg@ziepe.ca \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-graphics-maintainer@vmware.com \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=marex@denx.de \
--cc=masahiroy@kernel.org \
--cc=nico@fluxnic.net \
--cc=robert.jarzmik@free.fr \
--cc=saeedm@mellanox.com \
--cc=thellstrom@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).