[RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Javier Martinez Canillas]

This patch series splits the fbdev core support in two different Kconfig
symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
be disabled, while still using fbcon with the DRM fbdev emulation layer.

The reason for doing this is that now with simpledrm we could just boot
with simpledrm -> real DRM driver, without needing any legacy fbdev driver
(e.g: efifb or simplefb) even for the early console.

We want to do that in the Fedora kernel, but currently need to keep option
CONFIG_FB enabled and all fbdev drivers explicitly disabled, which makes
the configuration harder to maintain.

It is a RFC because I'm not that familiar with the fbdev core, but I have
tested and works with CONFIG_DRM_FBDEV_EMULATION=y and CONFIG_FB disabled.
This config automatically disables all the fbdev drivers that is our goal.

Patch 1/4 is just a clean up, patch 2/4 moves a couple of functions out of
fbsysfs.o, that are not related to sysfs attributes creation and finally
patch 3/4 makes the fbdev split that is mentioned above.

Patch 4/4 makes the DRM fbdev emulation depend on the new FB_CORE symbol
instead of FB. This could be done as a follow-up but for completeness is
also included in this series.

Best regards,
Javier


Javier Martinez Canillas (4):
  fbdev: Rename fb_*_device() functions names to match what they do
  fbdev: Move framebuffer_{alloc,release}() functions to fbmem.c
  fbdev: Split frame buffer support in FB and FB_CORE symbols
  drm: Make fbdev emulation depend on FB_CORE instead of FB

 arch/x86/Makefile                  |  2 +-
 arch/x86/video/Makefile            |  2 +-
 drivers/gpu/drm/Kconfig            |  2 +-
 drivers/video/console/Kconfig      |  2 +-
 drivers/video/fbdev/Kconfig        | 57 +++++++++++++---------
 drivers/video/fbdev/core/Makefile  | 13 +++--
 drivers/video/fbdev/core/fbmem.c   | 73 ++++++++++++++++++++++++++--
 drivers/video/fbdev/core/fbsysfs.c | 77 +-----------------------------
 include/linux/fb.h                 | 18 ++++++-
 9 files changed, 134 insertions(+), 112 deletions(-)

-- 
2.31.1

[RFC PATCH 1/4] fbdev: Rename fb_*_device() functions names to match what they do

[Javier Martinez Canillas]

The fb_init_device() and fb_cleanup_device() functions only register and
unregister sysfs attributes as their initialization and cleanup logic.
Let's rename these functions to better match what they actually do.

There's only a call to dev_set_drvdata() that's not related to the sysfs
registration, so move it to the do_register_framebuffer() function which
is where the device is created.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---

 drivers/video/fbdev/core/fbmem.c   | 8 +++++---
 drivers/video/fbdev/core/fbsysfs.c | 6 ++----
 include/linux/fb.h                 | 4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 71fb710f1ce..d886582c0a4 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1602,8 +1602,10 @@ static int do_register_framebuffer(struct fb_info *fb_info)
 		/* Not fatal */
 		printk(KERN_WARNING "Unable to create device for framebuffer %d; errno = %ld\n", i, PTR_ERR(fb_info->dev));
 		fb_info->dev = NULL;
-	} else
-		fb_init_device(fb_info);
+	} else {
+		dev_set_drvdata(fb_info->dev, fb_info);
+		fb_register_sysfs(fb_info);
+	}
 
 	if (fb_info->pixmap.addr == NULL) {
 		fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
@@ -1701,7 +1703,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
 	fb_destroy_modelist(&fb_info->modelist);
 	registered_fb[fb_info->node] = NULL;
 	num_registered_fb--;
-	fb_cleanup_device(fb_info);
+	fb_unregister_sysfs(fb_info);
 #ifdef CONFIG_GUMSTIX_AM200EPD
 	{
 		struct fb_event event;
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 65dae05fff8..a040d6bd6c3 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -507,12 +507,10 @@ static struct device_attribute device_attrs[] = {
 #endif
 };
 
-int fb_init_device(struct fb_info *fb_info)
+int fb_register_sysfs(struct fb_info *fb_info)
 {
 	int i, error = 0;
 
-	dev_set_drvdata(fb_info->dev, fb_info);
-
 	fb_info->class_flag |= FB_SYSFS_FLAG_ATTR;
 
 	for (i = 0; i < ARRAY_SIZE(device_attrs); i++) {
@@ -531,7 +529,7 @@ int fb_init_device(struct fb_info *fb_info)
 	return 0;
 }
 
-void fb_cleanup_device(struct fb_info *fb_info)
+void fb_unregister_sysfs(struct fb_info *fb_info)
 {
 	unsigned int i;
 
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5950f8f5dc7..96111248a25 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -689,8 +689,8 @@ static inline bool fb_be_math(struct fb_info *info)
 /* drivers/video/fbsysfs.c */
 extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
 extern void framebuffer_release(struct fb_info *info);
-extern int fb_init_device(struct fb_info *fb_info);
-extern void fb_cleanup_device(struct fb_info *head);
+extern int fb_register_sysfs(struct fb_info *fb_info);
+extern void fb_unregister_sysfs(struct fb_info *head);
 extern void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max);
 
 /* drivers/video/fbmon.c */
-- 
2.31.1

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 3383 bytes --]

Hi

Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:
> This patch series splits the fbdev core support in two different Kconfig
> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> be disabled, while still using fbcon with the DRM fbdev emulation layer.

I'm skeptical. DRM's fbdev emulation is not just the console emulation, 
it's a full fbdev device. You can see the related device file as 
/dev/fb*. Providing the file while having CONFIG_FB disabled doesn't 
make much sense to me. I know it's not pretty, but it's consistent at least.

If you want to remove fbdev, you could try to untangle fbdev and the 
console emulation such that DRM can set up a console by itself. Old 
fbdev drives would also set up the console individually.

Another low-hangling fruit is a config option to enable/disable the 
fbdev userspace interface (i.e., dev/fb*). Disabling the interface would 
remove the rsp mmap of the fbdev graphics buffer. We sometimes have to 
use an extra shadow buffer because mmap requires non-moving buffers. 
Without mmap we might be able to avoid some of the costly internal 
memcpys for some of our drivers.

Best regards
Thomas

> 
> The reason for doing this is that now with simpledrm we could just boot
> with simpledrm -> real DRM driver, without needing any legacy fbdev driver
> (e.g: efifb or simplefb) even for the early console.
> 
> We want to do that in the Fedora kernel, but currently need to keep option
> CONFIG_FB enabled and all fbdev drivers explicitly disabled, which makes
> the configuration harder to maintain.
> 
> It is a RFC because I'm not that familiar with the fbdev core, but I have
> tested and works with CONFIG_DRM_FBDEV_EMULATION=y and CONFIG_FB disabled.
> This config automatically disables all the fbdev drivers that is our goal.
> 
> Patch 1/4 is just a clean up, patch 2/4 moves a couple of functions out of
> fbsysfs.o, that are not related to sysfs attributes creation and finally
> patch 3/4 makes the fbdev split that is mentioned above.
> 
> Patch 4/4 makes the DRM fbdev emulation depend on the new FB_CORE symbol
> instead of FB. This could be done as a follow-up but for completeness is
> also included in this series.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (4):
>    fbdev: Rename fb_*_device() functions names to match what they do
>    fbdev: Move framebuffer_{alloc,release}() functions to fbmem.c
>    fbdev: Split frame buffer support in FB and FB_CORE symbols
>    drm: Make fbdev emulation depend on FB_CORE instead of FB
> 
>   arch/x86/Makefile                  |  2 +-
>   arch/x86/video/Makefile            |  2 +-
>   drivers/gpu/drm/Kconfig            |  2 +-
>   drivers/video/console/Kconfig      |  2 +-
>   drivers/video/fbdev/Kconfig        | 57 +++++++++++++---------
>   drivers/video/fbdev/core/Makefile  | 13 +++--
>   drivers/video/fbdev/core/fbmem.c   | 73 ++++++++++++++++++++++++++--
>   drivers/video/fbdev/core/fbsysfs.c | 77 +-----------------------------
>   include/linux/fb.h                 | 18 ++++++-
>   9 files changed, 134 insertions(+), 112 deletions(-)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Daniel Vetter]

On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:
> > This patch series splits the fbdev core support in two different Kconfig
> > symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> > be disabled, while still using fbcon with the DRM fbdev emulation layer.
> 
> I'm skeptical. DRM's fbdev emulation is not just the console emulation, it's
> a full fbdev device. You can see the related device file as /dev/fb*.
> Providing the file while having CONFIG_FB disabled doesn't make much sense
> to me. I know it's not pretty, but it's consistent at least.
> 
> If you want to remove fbdev, you could try to untangle fbdev and the console
> emulation such that DRM can set up a console by itself. Old fbdev drives
> would also set up the console individually.

Yeah given the horrendous security track record of all that code, and the
maze of handover we have (stuff like flicker free boot and all that) I'm
wondering whether typing a new drmcon wouldn't be faster and a lot more
maintainable.

With drm_client this shouldn't be too much work at least for the drm code.

> Another low-hangling fruit is a config option to enable/disable the fbdev
> userspace interface (i.e., dev/fb*). Disabling the interface would remove
> the rsp mmap of the fbdev graphics buffer. We sometimes have to use an extra
> shadow buffer because mmap requires non-moving buffers. Without mmap we
> might be able to avoid some of the costly internal memcpys for some of our
> drivers.

And yeah stuff like that wouldn't be needed for drmcon either.
-Daniel

> 
> Best regards
> Thomas
> 
> > 
> > The reason for doing this is that now with simpledrm we could just boot
> > with simpledrm -> real DRM driver, without needing any legacy fbdev driver
> > (e.g: efifb or simplefb) even for the early console.
> > 
> > We want to do that in the Fedora kernel, but currently need to keep option
> > CONFIG_FB enabled and all fbdev drivers explicitly disabled, which makes
> > the configuration harder to maintain.
> > 
> > It is a RFC because I'm not that familiar with the fbdev core, but I have
> > tested and works with CONFIG_DRM_FBDEV_EMULATION=y and CONFIG_FB disabled.
> > This config automatically disables all the fbdev drivers that is our goal.
> > 
> > Patch 1/4 is just a clean up, patch 2/4 moves a couple of functions out of
> > fbsysfs.o, that are not related to sysfs attributes creation and finally
> > patch 3/4 makes the fbdev split that is mentioned above.
> > 
> > Patch 4/4 makes the DRM fbdev emulation depend on the new FB_CORE symbol
> > instead of FB. This could be done as a follow-up but for completeness is
> > also included in this series.
> > 
> > Best regards,
> > Javier
> > 
> > 
> > Javier Martinez Canillas (4):
> >    fbdev: Rename fb_*_device() functions names to match what they do
> >    fbdev: Move framebuffer_{alloc,release}() functions to fbmem.c
> >    fbdev: Split frame buffer support in FB and FB_CORE symbols
> >    drm: Make fbdev emulation depend on FB_CORE instead of FB
> > 
> >   arch/x86/Makefile                  |  2 +-
> >   arch/x86/video/Makefile            |  2 +-
> >   drivers/gpu/drm/Kconfig            |  2 +-
> >   drivers/video/console/Kconfig      |  2 +-
> >   drivers/video/fbdev/Kconfig        | 57 +++++++++++++---------
> >   drivers/video/fbdev/core/Makefile  | 13 +++--
> >   drivers/video/fbdev/core/fbmem.c   | 73 ++++++++++++++++++++++++++--
> >   drivers/video/fbdev/core/fbsysfs.c | 77 +-----------------------------
> >   include/linux/fb.h                 | 18 ++++++-
> >   9 files changed, 134 insertions(+), 112 deletions(-)
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> 




-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Javier Martinez Canillas]

Hello Daniel and Thomas,

On 8/27/21 10:20 PM, Daniel Vetter wrote:
> On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:
>>> This patch series splits the fbdev core support in two different Kconfig
>>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
>>> be disabled, while still using fbcon with the DRM fbdev emulation layer.
>>
>> I'm skeptical. DRM's fbdev emulation is not just the console emulation, it's
>> a full fbdev device. You can see the related device file as /dev/fb*.
>> Providing the file while having CONFIG_FB disabled doesn't make much sense
>> to me. I know it's not pretty, but it's consistent at least.
>>
>> If you want to remove fbdev, you could try to untangle fbdev and the console
>> emulation such that DRM can set up a console by itself. Old fbdev drives
>> would also set up the console individually.
> 
> Yeah given the horrendous security track record of all that code, and the
> maze of handover we have (stuff like flicker free boot and all that) I'm
> wondering whether typing a new drmcon wouldn't be faster and a lot more
> maintainable.
> 

We talked about a drmcon with Peter Robinson as well but then decided that a
way to disable CONFIG_FB but still having the DRM fbdev emulation could be a
intermediary step, hence these RFC patches.

But yes, I agree that a drmcon would be the proper approach for this, to not
need any fbdev support at all. We will just keep the explicit disable for the
fbdev drivers then in the meantime.

Thanks a lot for your feedback.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Daniel Vetter]

On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:
> Hello Daniel and Thomas,
> 
> On 8/27/21 10:20 PM, Daniel Vetter wrote:
> > On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:
> >>> This patch series splits the fbdev core support in two different Kconfig
> >>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
> >>> be disabled, while still using fbcon with the DRM fbdev emulation layer.
> >>
> >> I'm skeptical. DRM's fbdev emulation is not just the console emulation, it's
> >> a full fbdev device. You can see the related device file as /dev/fb*.
> >> Providing the file while having CONFIG_FB disabled doesn't make much sense
> >> to me. I know it's not pretty, but it's consistent at least.
> >>
> >> If you want to remove fbdev, you could try to untangle fbdev and the console
> >> emulation such that DRM can set up a console by itself. Old fbdev drives
> >> would also set up the console individually.
> > 
> > Yeah given the horrendous security track record of all that code, and the
> > maze of handover we have (stuff like flicker free boot and all that) I'm
> > wondering whether typing a new drmcon wouldn't be faster and a lot more
> > maintainable.
> > 
> 
> We talked about a drmcon with Peter Robinson as well but then decided that a
> way to disable CONFIG_FB but still having the DRM fbdev emulation could be a
> intermediary step, hence these RFC patches.
> 
> But yes, I agree that a drmcon would be the proper approach for this, to not
> need any fbdev support at all. We will just keep the explicit disable for the
> fbdev drivers then in the meantime.

I think the only intermediate step would be to disable the fbdev uapi
(char node and anything in sysfs), while still registering against the
fbcon layer so you have a console.

But looking at the things syzbot finds the really problematic code is all
in the fbcon and console layer in general, and /dev/fb0 seems pretty
solid.

I think for a substantial improvement here in robustness what you really
want is
- kmscon in userspace
- disable FB layer
- ideally also disable console/vt layer in the kernel
- have a minimal emergency/boot-up log thing in drm, patches for that
  floated around a few times

Otherwise it feels a bit like we're just doing Kconfig bikeshedding and
no real improvement on the attack surface :-/
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Javier Martinez Canillas]

On 8/31/21 2:35 PM, Daniel Vetter wrote:
> On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:

[snip]

>>
>> We talked about a drmcon with Peter Robinson as well but then decided that a
>> way to disable CONFIG_FB but still having the DRM fbdev emulation could be a
>> intermediary step, hence these RFC patches.
>>
>> But yes, I agree that a drmcon would be the proper approach for this, to not
>> need any fbdev support at all. We will just keep the explicit disable for the
>> fbdev drivers then in the meantime.
> 
> I think the only intermediate step would be to disable the fbdev uapi
> (char node and anything in sysfs), while still registering against the
> fbcon layer so you have a console.
>

Right, $subject disabled the sysfs interface but left the fbdev chardev. I can
try to do a v2 that also disables that interface but just keep the fbcon part.
 
> But looking at the things syzbot finds the really problematic code is all
> in the fbcon and console layer in general, and /dev/fb0 seems pretty
> solid.
>

Yes, but still would be an improvement in the sense that no legacy fbdev uAPI
will be exposed and so user-space would only depend on the DRM/KMS interface.

> I think for a substantial improvement here in robustness what you really
> want is
> - kmscon in userspace
> - disable FB layer
> - ideally also disable console/vt layer in the kernel

Earlier in the thread it was mentioned that an in-kernel drmcon could be used
instead. My worry with kmscon is that moving something as critical as console
output to user-space might make harder to troubleshoot early booting issues.

And also that will require user-space changes. An in-kernel drmcon could be a
drop-in replacement though.

> - have a minimal emergency/boot-up log thing in drm, patches for that
>   floated around a few times
>

Interesting. Do you have any pointers for this? My search-fu failed me when
trying to find these patches.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Daniel Vetter]

On Wed, Sep 01, 2021 at 11:08:10AM +0200, Javier Martinez Canillas wrote:
> On 8/31/21 2:35 PM, Daniel Vetter wrote:
> > On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:
> 
> [snip]
> 
> >>
> >> We talked about a drmcon with Peter Robinson as well but then decided that a
> >> way to disable CONFIG_FB but still having the DRM fbdev emulation could be a
> >> intermediary step, hence these RFC patches.
> >>
> >> But yes, I agree that a drmcon would be the proper approach for this, to not
> >> need any fbdev support at all. We will just keep the explicit disable for the
> >> fbdev drivers then in the meantime.
> > 
> > I think the only intermediate step would be to disable the fbdev uapi
> > (char node and anything in sysfs), while still registering against the
> > fbcon layer so you have a console.
> >
> 
> Right, $subject disabled the sysfs interface but left the fbdev chardev. I can
> try to do a v2 that also disables that interface but just keep the fbcon part.
>  
> > But looking at the things syzbot finds the really problematic code is all
> > in the fbcon and console layer in general, and /dev/fb0 seems pretty
> > solid.
> >
> 
> Yes, but still would be an improvement in the sense that no legacy fbdev uAPI
> will be exposed and so user-space would only depend on the DRM/KMS interface.
> 
> > I think for a substantial improvement here in robustness what you really
> > want is
> > - kmscon in userspace
> > - disable FB layer
> > - ideally also disable console/vt layer in the kernel
> 
> Earlier in the thread it was mentioned that an in-kernel drmcon could be used
> instead. My worry with kmscon is that moving something as critical as console
> output to user-space might make harder to troubleshoot early booting issues.
> 
> And also that will require user-space changes. An in-kernel drmcon could be a
> drop-in replacement though.

The drmcon wouldn't be a full console, but just an emergency log renderer.
See Sam's reply, he found the series again.

The real attack surface reduction is in getting rid of the console/vt uapi
implementation from the kernel.
-Daniel

> > - have a minimal emergency/boot-up log thing in drm, patches for that
> >   floated around a few times
> >
> 
> Interesting. Do you have any pointers for this? My search-fu failed me when
> trying to find these patches.
> 
> Best regards,
> -- 
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Noralf Trønnes]

> > Hi Daniel,
> >
> > >
> > > I think for a substantial improvement here in robustness what you
really
> > > want is
> > > - kmscon in userspace
> > > - disable FB layer
> > > - ideally also disable console/vt layer in the kernel
> > > - have a minimal emergency/boot-up log thing in drm, patches for that
> > >   floated around a few times
> >
> > I assume you refer to this work by David Herrmann:
> > "[RFC] drm: add kernel-log renderer"
> > https://lists.freedesktop.org/archives/dri-devel/2014-March/055136.html
> >
>
> There's also this:
>
> [PATCH v2 0/3] drm: Add panic handling
>
https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/

And here's a DRM console example that was part of the early drm_client work:

[RFC v4 25/25] drm/client: Hack: Add DRM VT console client
https://lore.kernel.org/dri-devel/20180414115318.14500-26-noralf@tronnes.org/

Noralf.

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

[Noralf Trønnes]

> Hi Daniel,
>
> >
> > I think for a substantial improvement here in robustness what you really
> > want is
> > - kmscon in userspace
> > - disable FB layer
> > - ideally also disable console/vt layer in the kernel
> > - have a minimal emergency/boot-up log thing in drm, patches for that
> >   floated around a few times
>
> I assume you refer to this work by David Herrmann:
> "[RFC] drm: add kernel-log renderer"
> https://lists.freedesktop.org/archives/dri-devel/2014-March/055136.html
>

There's also this:

[PATCH v2 0/3] drm: Add panic handling
https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/

Noralf.