All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	Aren <aren@peacevolution.org>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Samuel Holland" <samuel@sholland.org>,
	"Kaustabh Chakraborty" <kauschluss@disroot.org>,
	"Barnabás Czémán" <trabarni@gmail.com>,
	"Ondrej Jirman" <megi@xff.cz>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, "Dragan Simic" <dsimic@manjaro.org>,
	phone-devel@vger.kernel.org
Subject: Re: [PATCH v4 4/6] iio: light: stk3310: use dev_err_probe where possible
Date: Tue, 12 Nov 2024 14:28:05 +0100	[thread overview]
Message-ID: <2a4e69f3ac4fb6cb131735d3cb598223b71bc90b.camel@gmail.com> (raw)
In-Reply-To: <4ibd5tgpt3uzbmouqdiiv5pvfxebo5qsmgn3xh6rlb73qevatv@cajznxqnlca3>

On Tue, 2024-11-12 at 11:15 +0100, Uwe Kleine-König wrote:
> Hello Andy, hello Aren,
> 
> On Mon, Nov 11, 2024 at 11:44:51AM +0200, Andy Shevchenko wrote:
> > On Sun, Nov 10, 2024 at 04:34:30PM -0500, Aren wrote:
> > > On Sun, Nov 10, 2024 at 09:52:32PM +0200, Andy Shevchenko wrote:
> > > > Sun, Nov 10, 2024 at 02:14:24PM -0500, Aren kirjoitti:
> > 
> > You can do it differently
> > 
> > #define
> > STK3310_REGFIELD(name)							\
> > do
> > {										\
> > 	data->reg_##name
> > =							\
> > 		devm_regmap_field_alloc(dev, regmap,
> > stk3310_reg_field_##name);	\
> > 	if (IS_ERR(data-
> > >reg_##name))						\
> > 		return dev_err_probe(dev, PTR_ERR(data-
> > >reg_##name),		\
> > 				     "reg field alloc
> > failed.\n");		\
> > } while (0)
> > 
> > > #define STK3310_REGFIELD(name)
> > > ({						\
> > > 	data->reg_##name = devm_regmap_field_alloc(dev,
> > > regmap,			\
> > > 						  
> > > stk3310_reg_field_##name);   \
> > > 	if (IS_ERR(data-
> > > >reg_##name))						\
> > > 		return dev_err_probe(dev, PTR_ERR(data-
> > > >reg_##name),		\
> > > 				     "reg field alloc
> > > failed\n");		\
> > > })
> > 
> > I am against unneeded use of GNU extensions.
> > 
> > > > > replacing "do { } while (0)" with "({ })" and deindenting could make
> > > > > enough room to clean this up the formatting of this macro though.
> > > > 
> > > > do {} while (0) is C standard, ({}) is not.
> > > 
> > > ({ }) is used throughout the kernel, and is documented as such[1]. I
> > > don't see a reason to avoid it, if it helps readability.
> > 
> > I don't see how it makes things better here, and not everybody is familiar with
> > the concept even if it's used in the kernel here and there. Also if a tool is
> > being used in one case it doesn't mean it's suitable for another.
> 
> Just to throw in my subjective view here: I don't expect anyone with
> some base level knowledge of C will have doubts about the semantics of
> ({ ... }) and compared to that I find do { ... } while (0) less optimal,
> because it's more verbose and when spotting the "do {" part, the
> semantic only gets clear when you also see the "while (0)". Having said
> that I also dislike the "do" starting on column 0, IMHO the RHS of the
> #define should be intended.
> 
> So if you ask me, this is not an unneeded use of an extension. The
> extension is used to improve readabilty and I blame the C standard to
> not support this syntax.
> 
> While I'm in critics mode: I consider hiding a return in a macro bad
> style.
> 

Not commenting on the debate between using the extension or not but I totally agree
with Uwe about hiding the return in the macro.

- Nuno Sá
> 



  parent reply	other threads:[~2024-11-12 13:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-02 19:50 [PATCH v4 0/6] iio: light: stk3310: support powering off during suspend Aren Moynihan
2024-11-02 19:50 ` [PATCH v4 1/6] dt-bindings: iio: light: stk33xx: add vdd and leda regulators Aren Moynihan
2024-11-02 19:50 ` [PATCH v4 2/6] iio: light: stk3310: handle all remove logic with devm callbacks Aren Moynihan
2024-11-03 11:22   ` Jonathan Cameron
2024-11-03 16:23     ` Aren
2024-11-04  8:32   ` Andy Shevchenko
2024-11-10 18:38     ` Aren
2024-11-10 19:51       ` Andy Shevchenko
2024-11-10 22:37         ` Aren
2024-11-11  9:38           ` Andy Shevchenko
2024-11-02 19:50 ` [PATCH v4 3/6] iio: light: stk3310: Implement vdd and leda supplies Aren Moynihan
2024-11-03 11:31   ` Jonathan Cameron
2024-11-03 16:11     ` Aren
2024-11-04  8:37       ` Andy Shevchenko
2024-11-04  8:35   ` Andy Shevchenko
2024-11-10 18:54     ` Aren
2024-11-02 19:50 ` [PATCH v4 4/6] iio: light: stk3310: use dev_err_probe where possible Aren Moynihan
2024-11-04  8:40   ` Andy Shevchenko
2024-11-10 19:14     ` Aren
2024-11-10 19:52       ` Andy Shevchenko
2024-11-10 21:34         ` Aren
2024-11-11  9:44           ` Andy Shevchenko
2024-11-12 10:15             ` Uwe Kleine-König
2024-11-12 12:31               ` Andy Shevchenko
2024-11-12 13:28               ` Nuno Sá [this message]
2024-11-12 23:11               ` Aren
2024-11-23 14:40                 ` Jonathan Cameron
2024-11-02 19:50 ` [PATCH v4 5/6] iio: light: stk3310: log error if reading the chip id fails Aren Moynihan
2024-11-04  8:41   ` Andy Shevchenko
2024-11-10 19:16     ` Aren
2024-11-02 19:50 ` [PATCH v4 6/6] arm64: dts: allwinner: pinephone: Add power supplies to stk3311 Aren Moynihan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a4e69f3ac4fb6cb131735d3cb598223b71bc90b.camel@gmail.com \
    --to=noname.nuno@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=aren@peacevolution.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dsimic@manjaro.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jic23@kernel.org \
    --cc=kauschluss@disroot.org \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=megi@xff.cz \
    --cc=phone-devel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=samuel@sholland.org \
    --cc=trabarni@gmail.com \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.