On Mon, Dec 02, 2019 at 12:15:50PM +0100, Thomas Zimmermann wrote: > (was: drm/ast: Fix potential NULL-pointer read during atomic mode setting) > > The CRTC's modesetting code in ast requires the format of the primary > plane's framebuffer. There's currently a segmentation fault if the > framebuffer is set to NULL. This happens when disabling the display > during suspend. > > Patch 1 moves the modesetting code behind a test for the framebuffer > in atomic_flush(). It returns if the framebuffer is NULL. This fixes > the segmentation fault in a simple and back-portable way. > > The rest of the patchset addresses problems in the code where access > between plane and CRTC state is convoluted and hard to follow. With > the changes applied, the atomic_check() functions of primary plane and > CRTC set the necessary state that is later used by atomic_flush(). > > Configurations without framebuffer cannot be rejected because this > breaks drm_framebuffer_remove(). Instead accept them and switch off > the screen to avoid garbage output. Patch 2 implements this logic for > the primary plane. > > Patches 3 to 5 implement atomic_check() for planes and introduce > struct ast_crtc_state. In patches 6 and 7, the atomic_check() functions > of CRTC and primary plane set display mode and framebuffer format in > the AST CRTC state; and atomic_flush() picks up these settings for > configuring the mode. > > The patchset has been tested by running the fbdev console, Gnome, > and Weston on an AST1100 chipset. Gnome's display has been suspended > multiple times to verify the bugfix. Disclaimer: Don't know the hardware. Can't spot any issues in the series, so Acked-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel