On 10/24/26 1:19 AM, Dmitry Baryshkov wrote:
> mdp5_kms_init() returns straight away when one of its later steps fails,
> leaving behind the kms, the runtime PM reference taken around the address
> space setup and the address space itself, and lets the ->destroy()
> callback, which the caller runs afterwards, clean up. When mdp5_init()
> fails, however, it has already run mdp5_destroy() itself, and ->destroy()
> runs it a second time: the global state object is finalised twice.
>
> Undo the steps which have completed, in the reverse order, drop the
> runtime PM reference on the error path as well, and tell the caller not
> to run ->destroy() after a failed init. Fold the hardware setup, which
> can't fail, into mdp5_kms_init().
>
> Fixes: 8d58ef346f30 ("drm/msm/mdp5: Add global state as a private atomic
> object")
> Assisted-by: LLM
> Signed-off-by: Dmitry Baryshkov <[email protected]>
> ---
Acked-by: Konrad Dybcio <[email protected]>
Konrad
