Re: [PATCH 1/6] drm/nouveau/kms/nv50-: Move DPCD backlight disable into its own function

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