Re: [PATCH v1 19/23] pmdomain: imx: gpcv2: Discard pm_runtime_put() return value

[Rafael J. Wysocki]

On Fri, Feb 20, 2026 at 6:23 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Fri, Feb 20, 2026 at 5:58 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> >
> > On Fri, Feb 20, 2026 at 5:06 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> > >
> > > On Thu, 19 Feb 2026 at 15:07, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> > > >
> > > > Hi Ulf,
> > > >
> > > > On Sun, Dec 28, 2025 at 4:52 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> > > > >
> > > > > On Mon, 22 Dec 2025 at 21:37, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > > > > >
> > > > > > 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@xxxxxxxxx>
> > > > >
> > > > > 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.