From: Jocelyn Falempe <[email protected]> Sent: Thursday, February 12, 2026 2:10 AM > > On 12/02/2026 10:49, Jocelyn Falempe wrote: > > On 12/02/2026 00:01, [email protected] wrote: > >> From: Jocelyn Falempe <[email protected]> Sent: Wednesday, February > >> 11, 2026 1:54 PM > >> > >> But for this patch, the issue is that drm_panic() never gets called if > >> CONFIG_PRINTK > >> isn't set. In that case, kmsg_dump_register() is a stub that returns an > >> error. So > >> drm_panic_register() never registers the callback to drm_panic(). And if > >> drm_panic() isn't going to run, responsibility for doing the VMBus unload > >> must remain with the VMBus code. It's hard to actually test this case > >> because > >> of depending on printk() for debugging output, so double-check my thinking. > > > > Ok you're right. I changed from > > atomic_notifier_chain_register(&panic_notifier_list, ...) to > > kmsg_dump_register() in the v10 of drm_panic. > > > > So I should either make DRM_PANIC depends on PRINTK, or call > > atomic_notifier_chain_register() if PRINTK is not defined. > > > > As I think kernel without PRINTK are uncommon, I'll probably do the > > first solution. > > > > FYI, I just sent the corresponding change: > > https://patchwork.freedesktop.org/series/161544/ >
Works for me. That means I can drop the CONFIG_PRINTK condition from my patch, which would be good. The current version is rather strange in that regard. I'm pretty tied up the rest of this week, so it may be next week before I resubmit my patches. Michael
