linux-kernel - Re: [PATCH v1 2/2] iio: temperature: add support for MCP998X

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aDCgiQKL3ySfpkZr@smile.fi.intel.com>
Date: Fri, 23 May 2025 19:21:29 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Victor.Duicu@...rochip.com
Cc: Marius.Cristea@...rochip.com, jic23@...nel.org, dlechner@...libre.com,
	linux-iio@...r.kernel.org, nuno.sa@...log.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] iio: temperature: add support for MCP998X

On Thu, May 22, 2025 at 09:18:06AM +0000, Victor.Duicu@...rochip.com wrote:
> On Tue, 2025-04-15 at 22:05 +0300, Andy Shevchenko wrote:
> > On Tue, Apr 15, 2025 at 4:27 PM <victor.duicu@...rochip.com> wrote:

...

> > > +#define MCP9982_CHAN(index, si, __address) ({ \
> > > +       struct iio_chan_spec __chan = { \
> > > +               .type = IIO_TEMP, \
> > > +               .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> > > +               .info_mask_shared_by_all_available =
> > > BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > > +               .info_mask_shared_by_all =
> > > BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > > +               .channel = index, \
> > > +               .address = __address, \
> > > +               .scan_index = si, \
> > > +               .scan_type = { \
> > > +                       .sign = 'u', \
> > > +                       .realbits = 8, \
> > > +                       .storagebits = 8, \
> > > +                       .endianness = IIO_CPU \
> > > +               }, \
> > > +               .indexed = 1, \
> > > +       }; \
> > > +       __chan; \
> > 
> > Why in this form and not as a compound literal?
> 
> I can have up to 5 channels, which have very similar specifications.
> I use this define to simplify definition of channels and avoid
> repeating code.
> Is it now preferable to use compound literal?
> I could implement something like this:
> 
> #define put_channel_defaults \
> 	.type = IIO_TEMP \
> ...
> 
> priv->iio_chan[0] = ((struct iio_chan_spec){put_channel_defaults,
> 					   .channel = x,
> ...
> 
> This way when initializing the channels I don't have
> to repeat the common properties.
> Do you find this approach agreeable?

No, just find how the compound literal macros are written in the kernel,
e.g., PINCTRL_PIN_FUNCTION().


-- 
With Best Regards,
Andy Shevchenko