If, for whatever reason, we're trying process adreno_runtime_resume()
at the same time that a6xx_destroy() is running then things can go
boom. Specifically adreno_runtime_resume() will eventually call
a6xx_pm_resume() and that may try to resume the gmu.
Let's grab the GMU lock as we're destroying the GMU. That will solve
the race because a6xx_pm_resume() grabs the same lock. That makes the
access of `gmu->initialized` in a6xx_gmu_resume() safe.
We'll also return an error code in a6xx_gmu_resume() if we see that
`gmu->initialized` was false. If this happens we'll bail out of the
rest of a6xx_pm_resume(), which is good because the rest of that
function is also not good to do if we're racing with a6xx_destroy().
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/521232/
Link: https://lore.kernel.org/r/20230202104822.1.I0e49003bf4dd1dead9be4a29dbee41f3b1236e48@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>
        int status, ret;
 
        if (WARN(!gmu->initialized, "The GMU is not set up yet\n"))
-               return 0;
+               return -EINVAL;
 
        gmu->hung = false;
 
 
 
        a6xx_llc_slices_destroy(a6xx_gpu);
 
+       mutex_lock(&a6xx_gpu->gmu.lock);
        a6xx_gmu_remove(a6xx_gpu);
+       mutex_unlock(&a6xx_gpu->gmu.lock);
 
        adreno_gpu_cleanup(adreno_gpu);