Re: [PATCH 01/15] counter: rz-mtu3-cnt: put runtime PM on initialization error path

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 17 Sep 2026 06:36:45 +0000
Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> wrote:

> > From: Jonathan Cameron <jic23@kernel.org>
> > Sent: Thursday, September 17, 2026 3:46 AM
> > 
> > On Mon, 14 Sep 2026 23:36:00 +0300
> > Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> wrote:
> >   
> > > If rz_mtu3_initialize_counter() fails, the runtime PM usage count is not
> > > decremented.
> > >
> > > rz_mtu3_initialize_counter() will fail if the requested channel is busy.
> > >
> > > Call pm_runtime_put() in the error path to decrement the usage count,
> > > and flip the check to keep the success path straightforward.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 0be8907359df ("counter: Add Renesas RZ/G2L MTU3a counter driver")
> > > Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> > > ---
> > >  drivers/counter/rz-mtu3-cnt.c | 8 ++++++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/counter/rz-mtu3-cnt.c b/drivers/counter/rz-mtu3-cnt.c
> > > index 7bfb6979193c..48f183f0b54f 100644
> > > --- a/drivers/counter/rz-mtu3-cnt.c
> > > +++ b/drivers/counter/rz-mtu3-cnt.c
> > > @@ -506,8 +506,12 @@ static int rz_mtu3_count_enable_write(struct counter_device *counter,
> > >  	if (enable) {
> > >  		pm_runtime_get_sync(counter->parent);
> > >  		ret = rz_mtu3_initialize_counter(counter, count->id);
> > > -		if (ret == 0)
> > > -			priv->count_is_enabled[count->id] = true;
> > > +		if (ret) {
> > > +			pm_runtime_put(counter->parent);
> > > +			goto exit;  
> > 
> > I'd use a guard() for the mutex and return here and one more case
> > above. Not quite the minimal fix, but will give a more readable result.
> >   
> 
> Hi Jonathan. I did the minimal fix here so it can be backported easily.
> Patch 14/15 does the guard() conversion for the mutexes. Is that okay?

Not my subsystem / problem ;)   General rule for fixes is do the cleanest
for what is 'now' upstream then if backports need to do something different
go ahead and do it.

For cases like this it doesn't really matter either way

Thanks,
Jonathan

>