linux-kernel - Re: [PATCH 1/2] drm/vesadrm: Match framebuffer device by id instead of driver name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d74f16f0-9615-4816-a49c-efa35b9ab344@suse.de>
Date: Mon, 18 Aug 2025 09:17:42 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Yao Zi <ziyao@...root.org>, Javier Martinez Canillas
 <javierm@...hat.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] drm/vesadrm: Match framebuffer device by id instead
 of driver name

Hi

Am 16.08.25 um 17:34 schrieb Yao Zi:
> Currently the driver matches the platform framebuffer device registered
> by sysfb through driver name, "vesa-framebuffer", this is a little
> confusing since this driver registers a DRM device, instead of a
> framebuffer.
>
> Moreover, we have a driver with the same name, enabled by
> CONFIG_FB_VESA, that acts as a consumer of vesa-framebuffer as well.
> They cannot be both loaded into the kernel.

That is intentional and desired. Please pick one of the drivers and use 
that. Vesafb is obsolete, but it's slightly smaller footprint might make 
s difference on ancient systems. For anything new, vesadrm is a better 
choice.

>
> Making these two drivers coexist is sometimes useful, e.g., a
> distribution may want to build fbcon into the kernel image for debugging
> purpose, but keep the whole DRM subsystem enabled as module. In such
> case vesadrm could serve as a solution for running DRM-specific
> userspace programs on platforms with only VESA VBIOS available.

You can do debugging with vesadrm as well. We also have DRM-based panic 
output if you just want the stack trace. If that's not enough, please 
build better debugging infrastructure for DRM.

>
> Let's rename the driver as "vesa-display" to avoid possible confusion.
> A platform_device_id table is introduced to match "vesa-framebuffer"
> devices.

NAK.

Best regards
Thomas

>
> Signed-off-by: Yao Zi <ziyao@...root.org>
> ---
>   drivers/gpu/drm/sysfb/vesadrm.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sysfb/vesadrm.c b/drivers/gpu/drm/sysfb/vesadrm.c
> index 90615e9ac86b..16635dc3d5cc 100644
> --- a/drivers/gpu/drm/sysfb/vesadrm.c
> +++ b/drivers/gpu/drm/sysfb/vesadrm.c
> @@ -3,6 +3,7 @@
>   #include <linux/aperture.h>
>   #include <linux/ioport.h>
>   #include <linux/limits.h>
> +#include <linux/mod_devicetable.h>
>   #include <linux/platform_device.h>
>   #include <linux/screen_info.h>
>   
> @@ -517,10 +518,17 @@ static void vesadrm_remove(struct platform_device *pdev)
>   	drm_dev_unplug(dev);
>   }
>   
> +static const struct platform_device_id vesadrm_platform_id[] = {
> +	{ "vesa-framebuffer" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(platform, vesadrm_platform_id);
> +
>   static struct platform_driver vesadrm_platform_driver = {
>   	.driver = {
> -		.name = "vesa-framebuffer",
> +		.name = "vesa-display",
>   	},
> +	.id_table = vesadrm_platform_id,
>   	.probe = vesadrm_probe,
>   	.remove = vesadrm_remove,
>   };

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)