drm/panel: simple: Clean up resources on DSI attach failure

drivers/gpu/drm/panel/panel-simple.c static int panel_simple_dsi_probe(struct mipi_dsi_device *dsi) · line 6556

[Severity: Critical]
This isn't a bug introduced by this patch, but could this error path lead to a Use-After-Free (UAF) of the panel structure?

When panel_simple_dsi_probe() calls panel_simple_probe(), the panel is allocated using devm_kzalloc() and registered globally via drm_panel_add(). At this point, it is visible to the system and a concurrent display driver can discover it via of_drm_find_panel() and store a pointer to it.

If mipi_dsi_attach() fails here, panel_simple_remove() is called to unregister it, and the probe function returns an error. Returning an error triggers the driver core's devres cleanup, completely freeing the panel structure memory. However, the concurrent display driver might still hold a dangling pointer to this freed structure, resulting in a critical UAF upon subsequent access (e.g., calling drm_panel_prepare()).

[Severity: High]
This is a pre-existing issue, but does calling panel_simple_remove() here lead to an unbalanced runtime PM state and resource leak?

Looking at panel_simple_remove():

static void panel_simple_remove(struct device *dev)

{
    ...
    panel_simple_shutdown(dev);
    pm_runtime_dont_use_autosuspend(dev);
    pm_runtime_disable(dev);
    ...
}

panel_simple_shutdown() unprepares the panel, which calls pm_runtime_put_autosuspend() to schedule an asynchronous suspend, but leaves the device in the RPM_ACTIVE state. Then, pm_runtime_dont_use_autosuspend() and pm_runtime_disable() cancel the pending autosuspend and disable runtime PM entirely.

Because a synchronous suspend (e.g., pm_runtime_suspend or pm_runtime_force_suspend) is omitted, the panel_simple_suspend() callback never executes. Will this leave the panel's regulator and GPIO permanently enabled, leading to a persistent hardware state and regulator enable count leak?

[Severity: High]
This is also a pre-existing issue, but is there a TOCTOU race in panel_simple_shutdown() (which is called by panel_simple_remove() above)?

In panel_simple_shutdown():

static void panel_simple_shutdown(struct device *dev)

{
    ...
    if (panel->base.enabled)
        drm_panel_disable(&panel->base);
    if (panel->base.prepared)
        drm_panel_unprepare(&panel->base);
    ...
}

These states are checked without holding any synchronization primitives (such as DRM modeset locks). If this runs concurrently with a DRM display controller performing a modeset (which independently calls drm_panel_disable), both threads may observe panel->base.enabled == true simultaneously.

Could this lockless race lead to double-disabling of the panel, unbalanced regulator disables, and potential hardware state corruption?