drivers/pmdomain/imx/gpcv2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Passing pm_runtime_put() return value to the callers is not particularly
useful.
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.
Accordingly, update imx_pgc_domain_suspend() to simply discard the
return value of pm_runtime_put() and always return success to the
caller.
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@intel.com>
---
This patch is part of a series, but it doesn't depend on anything else
in that series. The last patch in the series depends on it.
It can be applied by itself and if you decide to do so, 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.
---
drivers/pmdomain/imx/gpcv2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/pmdomain/imx/gpcv2.c
+++ b/drivers/pmdomain/imx/gpcv2.c
@@ -1420,7 +1420,9 @@ static int imx_pgc_domain_suspend(struct
static int imx_pgc_domain_resume(struct device *dev)
{
- return pm_runtime_put(dev);
+ pm_runtime_put(dev);
+
+ return 0;
}
#endif
On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Passing pm_runtime_put() return value to the callers is not particularly
> useful.
>
> 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.
>
> Accordingly, update imx_pgc_domain_suspend() to simply discard the
> return value of pm_runtime_put() and always return success to the
> caller.
>
> 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@intel.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> This patch is part of a series, but it doesn't depend on anything else
> in that series. The last patch in the series depends on it.
>
> It can be applied by itself and if you decide to do so, 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.
>
> ---
> drivers/pmdomain/imx/gpcv2.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- a/drivers/pmdomain/imx/gpcv2.c
> +++ b/drivers/pmdomain/imx/gpcv2.c
> @@ -1420,7 +1420,9 @@ static int imx_pgc_domain_suspend(struct
>
> static int imx_pgc_domain_resume(struct device *dev)
> {
> - return pm_runtime_put(dev);
> + pm_runtime_put(dev);
> +
> + return 0;
> }
> #endif
>
>
>
>
Hi Ulf,
On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Passing pm_runtime_put() return value to the callers is not particularly
> > useful.
> >
> > 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.
> >
> > Accordingly, update imx_pgc_domain_suspend() to simply discard the
> > return value of pm_runtime_put() and always return success to the
> > caller.
> >
> > 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@intel.com>
>
> Applied for next, thanks!
Since you applied this one, I'm assuming no objections, so I'm going
to queue it up separately along with the patch changing
pm_runtime_put() to void because I would prefer to make that change in
7.0 to dragging it for another cycle.
An ACK would be helpful though, I think.
> > ---
> >
> > This patch is part of a series, but it doesn't depend on anything else
> > in that series. The last patch in the series depends on it.
> >
> > It can be applied by itself and if you decide to do so, 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.
> >
> > ---
> > drivers/pmdomain/imx/gpcv2.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/pmdomain/imx/gpcv2.c
> > +++ b/drivers/pmdomain/imx/gpcv2.c
> > @@ -1420,7 +1420,9 @@ static int imx_pgc_domain_suspend(struct
> >
> > static int imx_pgc_domain_resume(struct device *dev)
> > {
> > - return pm_runtime_put(dev);
> > + pm_runtime_put(dev);
> > +
> > + return 0;
> > }
> > #endif
> >
> >
> >
> >
On Thu, 19 Feb 2026 at 15:07, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> Hi Ulf,
>
> On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > Passing pm_runtime_put() return value to the callers is not particularly
> > > useful.
> > >
> > > 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.
> > >
> > > Accordingly, update imx_pgc_domain_suspend() to simply discard the
> > > return value of pm_runtime_put() and always return success to the
> > > caller.
> > >
> > > 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@intel.com>
> >
> > Applied for next, thanks!
>
> Since you applied this one, I'm assuming no objections, so I'm going
> to queue it up separately along with the patch changing
> pm_runtime_put() to void because I would prefer to make that change in
> 7.0 to dragging it for another cycle.
>
> An ACK would be helpful though, I think.
I was still hoping that Linus was considering to pull my pull-request
for pmdomain, but it seems like that may happen. Assuming that doesn't
change, I can re-base my next branch on Monday to drop $subject patch,
but please wait until my confirmation so we don't end up having two
commits in linux-next for the same change.
Kind regards
Uffe
>
> > > ---
> > >
> > > This patch is part of a series, but it doesn't depend on anything else
> > > in that series. The last patch in the series depends on it.
> > >
> > > It can be applied by itself and if you decide to do so, 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.
> > >
> > > ---
> > > drivers/pmdomain/imx/gpcv2.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > --- a/drivers/pmdomain/imx/gpcv2.c
> > > +++ b/drivers/pmdomain/imx/gpcv2.c
> > > @@ -1420,7 +1420,9 @@ static int imx_pgc_domain_suspend(struct
> > >
> > > static int imx_pgc_domain_resume(struct device *dev)
> > > {
> > > - return pm_runtime_put(dev);
> > > + pm_runtime_put(dev);
> > > +
> > > + return 0;
> > > }
> > > #endif
> > >
> > >
> > >
> > >
On Fri, Feb 20, 2026 at 5:06 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Thu, 19 Feb 2026 at 15:07, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > Hi Ulf, > > > > On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > Passing pm_runtime_put() return value to the callers is not particularly > > > > useful. > > > > > > > > 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. > > > > > > > > Accordingly, update imx_pgc_domain_suspend() to simply discard the > > > > return value of pm_runtime_put() and always return success to the > > > > caller. > > > > > > > > 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@intel.com> > > > > > > Applied for next, thanks! > > > > Since you applied this one, I'm assuming no objections, so I'm going > > to queue it up separately along with the patch changing > > pm_runtime_put() to void because I would prefer to make that change in > > 7.0 to dragging it for another cycle. > > > > An ACK would be helpful though, I think. > > I was still hoping that Linus was considering to pull my pull-request > for pmdomain, but it seems like that may happen. Assuming that doesn't > change, I can re-base my next branch on Monday to drop $subject patch, > but please wait until my confirmation so we don't end up having two > commits in linux-next for the same change. Sure, no problem.
On Fri, 20 Feb 2026 at 17:58, Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Fri, Feb 20, 2026 at 5:06 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > On Thu, 19 Feb 2026 at 15:07, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > Hi Ulf, > > > > > > On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > > > On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > > > Passing pm_runtime_put() return value to the callers is not particularly > > > > > useful. > > > > > > > > > > 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. > > > > > > > > > > Accordingly, update imx_pgc_domain_suspend() to simply discard the > > > > > return value of pm_runtime_put() and always return success to the > > > > > caller. > > > > > > > > > > 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@intel.com> > > > > > > > > Applied for next, thanks! > > > > > > Since you applied this one, I'm assuming no objections, so I'm going > > > to queue it up separately along with the patch changing > > > pm_runtime_put() to void because I would prefer to make that change in > > > 7.0 to dragging it for another cycle. > > > > > > An ACK would be helpful though, I think. > > > > I was still hoping that Linus was considering to pull my pull-request > > for pmdomain, but it seems like that may happen. Assuming that doesn't > > change, I can re-base my next branch on Monday to drop $subject patch, > > but please wait until my confirmation so we don't end up having two > > commits in linux-next for the same change. > > Sure, no problem. I have updated my next branch and dropped the $subject patch from it. Please add my ack when applying. Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Kind regards Uffe
On Mon, Feb 23, 2026 at 12:04 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Fri, 20 Feb 2026 at 17:58, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Fri, Feb 20, 2026 at 5:06 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > On Thu, 19 Feb 2026 at 15:07, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > Hi Ulf, > > > > > > > > On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > > > > > On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > > > > > Passing pm_runtime_put() return value to the callers is not particularly > > > > > > useful. > > > > > > > > > > > > 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. > > > > > > > > > > > > Accordingly, update imx_pgc_domain_suspend() to simply discard the > > > > > > return value of pm_runtime_put() and always return success to the > > > > > > caller. > > > > > > > > > > > > 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@intel.com> > > > > > > > > > > Applied for next, thanks! > > > > > > > > Since you applied this one, I'm assuming no objections, so I'm going > > > > to queue it up separately along with the patch changing > > > > pm_runtime_put() to void because I would prefer to make that change in > > > > 7.0 to dragging it for another cycle. > > > > > > > > An ACK would be helpful though, I think. > > > > > > I was still hoping that Linus was considering to pull my pull-request > > > for pmdomain, but it seems like that may happen. Assuming that doesn't > > > change, I can re-base my next branch on Monday to drop $subject patch, > > > but please wait until my confirmation so we don't end up having two > > > commits in linux-next for the same change. > > > > Sure, no problem. > > I have updated my next branch and dropped the $subject patch from it. > Please add my ack when applying. > > Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Thanks!
On Fri, Feb 20, 2026 at 5:58 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Fri, Feb 20, 2026 at 5:06 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > On Thu, 19 Feb 2026 at 15:07, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > Hi Ulf, > > > > > > On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > > > On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > > > Passing pm_runtime_put() return value to the callers is not particularly > > > > > useful. > > > > > > > > > > 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. > > > > > > > > > > Accordingly, update imx_pgc_domain_suspend() to simply discard the > > > > > return value of pm_runtime_put() and always return success to the > > > > > caller. > > > > > > > > > > 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@intel.com> > > > > > > > > Applied for next, thanks! > > > > > > Since you applied this one, I'm assuming no objections, so I'm going > > > to queue it up separately along with the patch changing > > > pm_runtime_put() to void because I would prefer to make that change in > > > 7.0 to dragging it for another cycle. > > > > > > An ACK would be helpful though, I think. > > > > I was still hoping that Linus was considering to pull my pull-request > > for pmdomain, but it seems like that may happen. Assuming that doesn't > > change, I can re-base my next branch on Monday to drop $subject patch, > > but please wait until my confirmation so we don't end up having two > > commits in linux-next for the same change. > > Sure, no problem. That said, git can cope with merging two branches carrying exactly the same patch. It just creates an empty commit for the second copy AFAICS.
On Fri, Feb 20, 2026 at 6:23 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Fri, Feb 20, 2026 at 5:58 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Fri, Feb 20, 2026 at 5:06 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > On Thu, 19 Feb 2026 at 15:07, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > Hi Ulf, > > > > > > > > On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > > > > > On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > > > > > Passing pm_runtime_put() return value to the callers is not particularly > > > > > > useful. > > > > > > > > > > > > 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. > > > > > > > > > > > > Accordingly, update imx_pgc_domain_suspend() to simply discard the > > > > > > return value of pm_runtime_put() and always return success to the > > > > > > caller. > > > > > > > > > > > > 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@intel.com> > > > > > > > > > > Applied for next, thanks! > > > > > > > > Since you applied this one, I'm assuming no objections, so I'm going > > > > to queue it up separately along with the patch changing > > > > pm_runtime_put() to void because I would prefer to make that change in > > > > 7.0 to dragging it for another cycle. > > > > > > > > An ACK would be helpful though, I think. > > > > > > I was still hoping that Linus was considering to pull my pull-request > > > for pmdomain, but it seems like that may happen. Assuming that doesn't > > > change, I can re-base my next branch on Monday to drop $subject patch, > > > but please wait until my confirmation so we don't end up having two > > > commits in linux-next for the same change. > > > > Sure, no problem. > > That said, git can cope with merging two branches carrying exactly the > same patch. It just creates an empty commit for the second copy > AFAICS. A correction on the latter: That's what rebase would do, if I'm not mistaken. A merge simply doesn't update files that are already identical in both parents.
On Mon, Dec 22, 2025 at 09:29:41PM +0100, Rafael J. Wysocki wrote: >From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > >Passing pm_runtime_put() return value to the callers is not particularly >useful. > >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. > >Accordingly, update imx_pgc_domain_suspend() to simply discard the >return value of pm_runtime_put() and always return success to the >caller. > >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@intel.com> Acked-by: Peng Fan <peng.fan@nxp.com>
© 2016 - 2026 Red Hat, Inc.