Re: [RESEND][PATCH v1] drm: Discard pm_runtime_put() return value

[Rafael J. Wysocki]

On Thu, Jan 15, 2026 at 1:20 PM Liviu Dudau <liviu.dudau@xxxxxxx> wrote:
>
> On Wed, Jan 14, 2026 at 01:03:25PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Jan 8, 2026 at 4:38 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> > >
> > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > >
> > > Multiple DRM drivers use the pm_runtime_put() return value for printing
> > > debug or even error messages and all of those messages are at least
> > > somewhat misleading.
> > >
> > > Returning an error code from pm_runtime_put() merely means that it has
> > > not queued up a work item to check whether or not the device can be
> > > suspended and there are many perfectly valid situations in which that
> > > can happen, like after writing "on" to the devices' runtime PM "control"
> > > attribute in sysfs for one example.  It also happens when the kernel
> > > has been configured with CONFIG_PM unset.
> > >
> > > For this reason, modify all of those drivers to simply discard the
> > > pm_runtime_put() return value which is what they should be doing.
> > >
> > > This will facilitate a planned change of the pm_runtime_put() return
> > > type to void in the future.
> > >
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > > Acked-by: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx>
> > > Acked-by: Liviu Dudau <liviu.dudau@xxxxxxx>
> > > ---
> > >
> > > This patch is requisite for converting pm_runtime_put() into a void
> > > function.
> > >
> > > If you decide to pick it up, please let me know.
> > >
> > > Otherwise, an ACK or equivalent will be appreciated, but also the lack
> > > of specific criticism will be eventually regarded as consent.
> > >
> > > Originally posted here:
> > >
> > > https://lore.kernel.org/linux-pm/3045480.e9J7NaK4W3@rafael.j.wysocki/
> >
> > This is the last patch from the "discard pm_runtime_put() return
> > values" lot that has not been applied yet, AFAICS, so this is the last
> > call for objections or concerns related to it.
>
> I think you can go ahead and apply it, I don't see how the imx8 driver will
> be affected by the lack of debug messages.

Applied then, thanks!