[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230914223017.GC5492@noisy.programming.kicks-ass.net>
Date: Fri, 15 Sep 2023 00:30:17 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Andy Shevchenko <andy@...nel.org>,
Mitchell Levy <levymitchell0@...il.com>
Subject: Re: guard coding style (was: Re: [PATCH v1 05/10] gpio: pca953x:
Simplify code with cleanup helpers)
On Thu, Sep 14, 2023 at 09:47:07AM +0200, Geert Uytterhoeven wrote:
> > > > + scoped_guard(mutex, &chip->i2c_lock)
> > > > + ret = regmap_read(chip->regmap, inreg, ®_val);
> > >
> > > I can't say I'm thrilled about the lack of curly braces. I was also
> > > surprised to discover that checkpatch nor gcc W=1 complain about the
> > > indentation change.
So in my kernel/events/core.c changes (that I still need to re-post and
aren't yet upstream) I have found a single instance where I've done the
same lack of curlies:
scoped_guard (rcu)
pmu = idr_find(&pmu_idr, type);
clearly self-consistency mandates I should not object to this style.
That said, I see the argument for having them, they do more clearly
demarcate the scope.
As with everything, small variations in style are bound to happen from
one maintainer to another... (or one self to itself over time).
Powered by blists - more mailing lists