[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYMY6AHtc45l4kb3@smile.fi.intel.com>
Date: Wed, 4 Feb 2026 12:01:12 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>,
Antoniu Miclaus <antoniu.miclaus@...log.com>,
Andrew Ijano <andrew.ijano@...il.com>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
error27@...il.com
Subject: Re: [PATCH v4 next 3/6] iio: sca3000: make stop_all_interrupts()
return void
On Wed, Feb 04, 2026 at 02:50:54PM +0530, Harshit Mogalapalli wrote:
> On 04/02/26 14:33, Andy Shevchenko wrote:
> > On Tue, Feb 03, 2026 at 10:11:58PM -0800, Harshit Mogalapalli wrote:
...
> > > ret = sca3000_read_data_short(st, SCA3000_REG_INT_MASK_ADDR, 1);
> > > if (ret)
> > > - goto error_ret;
> >
> > > -error_ret:
> > > + goto out_unlock;
> >
> > > +out_unlock:
> >
> > While this is correct change semantically, it's not needed as very soon
> > the other patch drops this for good, hence leave the label name unmodified.
>
> Agree, I was doubtful on which is the preferred approach as its not really a
> return anymore. But thanks for explaining.
The common sense says that we need to avoid ping-pong coding (*) in the series.
*It's when one patch in the series adds the code that's going to be deleted or
heavily modified just later in the very same series.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists