Message-ID: <f3643c19-c250-4927-b39d-37d2494c7c84@suse.de>
Date: Fri, 16 Jan 2026 08:58:28 +0100
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Zack Rusin <zack.rusin@...adcom.com>
Cc: dri-devel@...ts.freedesktop.org, Alex Deucher
 <alexander.deucher@....com>, amd-gfx@...ts.freedesktop.org,
 Ard Biesheuvel <ardb@...nel.org>, Ce Sun <cesun102@....com>,
 Chia-I Wu <olvaffe@...il.com>, Christian König
 <christian.koenig@....com>, Danilo Krummrich <dakr@...nel.org>,
 Dave Airlie <airlied@...hat.com>, Deepak Rawat <drawat.floss@...il.com>,
 Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 Gerd Hoffmann <kraxel@...hat.com>,
 Gurchetan Singh <gurchetansingh@...omium.org>,
 Hans de Goede <hansg@...nel.org>, Hawking Zhang <Hawking.Zhang@....com>,
 Helge Deller <deller@....de>, intel-gfx@...ts.freedesktop.org,
 intel-xe@...ts.freedesktop.org, Jani Nikula <jani.nikula@...ux.intel.com>,
 Javier Martinez Canillas <javierm@...hat.com>,
 Jocelyn Falempe <jfalempe@...hat.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
 Lijo Lazar <lijo.lazar@....com>, linux-efi@...r.kernel.org,
 linux-fbdev@...r.kernel.org, linux-hyperv@...r.kernel.org,
 linux-kernel@...r.kernel.org, Lucas De Marchi <lucas.demarchi@...el.com>,
 Lyude Paul <lyude@...hat.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 "Mario Limonciello (AMD)" <superm1@...nel.org>,
 Mario Limonciello <mario.limonciello@....com>,
 Maxime Ripard <mripard@...nel.org>, nouveau@...ts.freedesktop.org,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Simona Vetter <simona@...ll.ch>,
 spice-devel@...ts.freedesktop.org,
 Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
 Timur Kristóf <timur.kristof@...il.com>,
 Tvrtko Ursulin <tursulin@...ulin.net>, virtualization@...ts.linux.dev,
 Vitaly Prosyak <vitaly.prosyak@....com>
Subject: Re: [PATCH 00/12] Recover sysfb after DRM probe failure

Hi

Am 16.01.26 um 04:59 schrieb Zack Rusin:
> On Thu, Jan 15, 2026 at 6:02 AM Thomas Zimmermann <tzimmermann@...e.de> wrote:
>> That's really not going to work. For example, in the current series, you
>> invoke devm_aperture_remove_conflicting_pci_devices_done() after
>> drm_mode_reset(), drm_dev_register() and drm_client_setup().
> That's perfectly fine,
> devm_aperture_remove_conflicting_pci_devices_done is removing the
> reload behavior not doing anything.
>
> This series, essentially, just adds a "defer" statement to
> aperture_remove_conflicting_pci_devices that says
>
> "reload sysfb if this driver unloads".
>
> devm_aperture_remove_conflicting_pci_devices_done just cancels that defer.

Exactly. And if that reload happens after the hardware state has been 
changed, the result is undefined.

>
> You could ask why have
> devm_aperture_remove_conflicting_pci_devices_done at all then and it's
> because I didn't want to change the default behavior of anything.
>
> There are three cases:
> 1) Driver fails to load before
> aperture_remove_conflicting_pci_devices, in which case sysfb is still
> active and there's no problem,
> 2) Driver fails to load after aperture_remove_conflicting_pci_devices,
> in which case sysfb is gone and the screen is blank
> 3) Driver is unloaded after the probe succeeded. igt tests this too.
>
> Without devm_aperture_remove_conflicting_pci_devices_done we'd try to
> reload sysfb in #3, which, in general makes sense to me and I'd
> probably remove it in my drivers, but there might be people or tests
> (again, igt does it and we don't need to flip-flop between sysfb and
> the driver there) that depend on specifically that behavior of not
> having anything driving fb so I didn't want to change it.
>
> So with this series the worst case scenario is that the driver that
> failed after aperture_remove_conflicting_pci_devices changed the
> hardware state so much that sysfb can't recover and the fb is blank.
> So it was blank before and this series can't fix it because the driver
> in its cleanup routine will need to do more unwinding for sysfb to
> reload (i.e. we'd need an extra patch to unwind the driver state).

The current recovery/reload is not reliable in any case. A number of 
high-profile devs have also said that it doesn't work with their driver. 
The same is true for ast. So the current approach is not going to happen.

> There also might be the case of some crazy behavior, e.g. pci bar
> resize in the driver makes the vga hardware crash or something, in
> which case, yea, we should definitely skip this patch, at least until
> those drivers properly cleanup on exit.

There's nothing crazy here. It's standard probing code.

If you want to to move forward, my suggestion is to look at the proposal 
with the aperture_funcs callbacks that control sysfb device access. And 
from there, build a full prototype with one or two drivers.

Best regards
Thomas


>
> z

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

Powered by blists - more mailing lists