linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).