omg On Wed, 2026-08-19 at 00:07 +0000, [email protected] wrote: > > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c > > b/drivers/gpu/drm/nouveau/dispnv50/disp.c > > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > [ ... ] > > +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT > > +static inline void > > +nv50_sor_atomic_disable_backlight(struct nouveau_drm *drm, > > + struct nouveau_encoder > > *nv_encoder, > > + struct drm_atomic_commit *state) > > +{ > [ ... ] > > + if (!backlight || !backlight->uses_dpcd) > > + return; > > + > > + ret = drm_edp_backlight_disable(&nv_connector->aux, > > &backlight->edp_info); > > [Severity: High] > This is a pre-existing issue, but moving the logic into > nv50_sor_atomic_disable_backlight() preserves a potentially > problematic > sleeping call in an atomic context. > > Is it safe to call drm_edp_backlight_disable() from this path? > > Because nv50_sor_atomic_disable_backlight() is invoked by the encoder > atomic > disable callback nv50_sor_atomic_disable(), it executes in an atomic > context > where sleeping is forbidden. > > The drm_edp_backlight_disable() helper performs DPCD transactions > over the > AUX channel. These transactions require taking a hardware mutex and > can > sleep or block while waiting for hardware responses. > > Could this lead to scheduling while atomic kernel warnings or > potential > deadlocks during display disables or modesets?
This one gave me a good chuckle. This is a definite hallucination, it is getting confused by the fact that nv50_sor_atomic_disable() has the word atomic in it. > > > + if (ret < 0) > > + NV_ERROR(drm, "Failed to disable backlight on > > [CONNECTOR:%d:%s]: %d\n", > > + nv_connector->base.base.id, nv_connector- > > >base.name, ret); > > +} > > +#endif
