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] [thread-next>] [day] [month] [year] [list]
Date: Fri, 07 Jun 2024 12:29:36 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: "Ceclan, Dumitru" <mitrutzceclan@...il.com>, dumitru.ceclan@...log.com
Cc: Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Jonathan Cameron <jic23@...nel.org>, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
 David Lechner <dlechner@...libre.com>,  linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 6/9] iio: adc: ad7173: add support for special inputs

On Fri, 2024-06-07 at 12:34 +0300, Ceclan, Dumitru wrote:
> On 07/06/2024 12:06, Nuno Sá wrote:
> > On Thu, 2024-06-06 at 19:07 +0300, Dumitru Ceclan via B4 Relay wrote:
> > > From: Dumitru Ceclan <dumitru.ceclan@...log.com>
> > > 
> > >  Add support for selecting REF+ and REF- inputs on all models.
> > >  Add support for selecting ((AVDD1 − AVSS)/5) inputs
> > >   on supported models.
> > > 
> > > Signed-off-by: Dumitru Ceclan <dumitru.ceclan@...log.com>
> > > ---
> > >  drivers/iio/adc/ad7173.c | 29 +++++++++++++++++++++++++++--
> > >  1 file changed, 27 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c
> > > index 4040edbd1c32..d16fa081a285 100644
> > > --- a/drivers/iio/adc/ad7173.c
> > > +++ b/drivers/iio/adc/ad7173.c
> > > @@ -66,6 +66,13 @@
> > >  	 FIELD_PREP(AD7173_CH_SETUP_AINNEG_MASK, neg))
> > >  #define AD7173_AIN_TEMP_POS	17
> > >  #define AD7173_AIN_TEMP_NEG	18
> > > +#define AD7173_AIN_POW_MON_POS	19
> > > +#define AD7173_AIN_POW_MON_NEG	20
> > > +#define AD7173_AIN_REF_POS	21
> > > +#define AD7173_AIN_REF_NEG	22
> > > +
> > > +#define AD7173_IS_REF_INPUT(x)		((x) == AD7173_AIN_REF_POS || \
> > > +					(x) == AD7173_AIN_REF_NEG)
> > >  
> > >  #define AD7172_2_ID			0x00d0
> > >  #define AD7175_ID			0x0cd0
> > > @@ -146,6 +153,8 @@ struct ad7173_device_info {
> > >  	unsigned int id;
> > >  	char *name;
> > >  	bool has_temp;
> > > +	/* ((AVDD1 − AVSS)/5) */
> > > +	bool has_pow_supply_monitoring;
> > >  	bool has_input_buf;
> > >  	bool has_int_ref;
> > >  	bool has_ref2;
> > > @@ -216,6 +225,7 @@ static const struct ad7173_device_info
> > > ad7173_device_info[] = {
> > >  		.has_temp = true,
> > >  		.has_input_buf = true,
> > >  		.has_int_ref = true,
> > > +		.has_pow_supply_monitoring = true,
> > >  		.clock = 2 * HZ_PER_MHZ,
> > >  		.sinc5_data_rates = ad7173_sinc5_data_rates,
> > >  		.num_sinc5_data_rates =
> > > ARRAY_SIZE(ad7173_sinc5_data_rates),
> > > @@ -230,6 +240,7 @@ static const struct ad7173_device_info
> > > ad7173_device_info[] = {
> > >  		.has_temp = false,
> > >  		.has_input_buf = true,
> > >  		.has_ref2 = true,
> > > +		.has_pow_supply_monitoring = true,
> > >  		.clock = 2 * HZ_PER_MHZ,
> > >  		.sinc5_data_rates = ad7173_sinc5_data_rates,
> > >  		.num_sinc5_data_rates =
> > > ARRAY_SIZE(ad7173_sinc5_data_rates),
> > > @@ -245,6 +256,7 @@ static const struct ad7173_device_info
> > > ad7173_device_info[] = {
> > >  		.has_input_buf = true,
> > >  		.has_int_ref = true,
> > >  		.has_ref2 = true,
> > > +		.has_pow_supply_monitoring = false,
> > 
> > No need to set the 'false' cases...
> > 
> > 
> > - Nuno Sá
> 
> This was suggested by David Lechner to ensure consistency with has_temp
> regarding another field, I considered that it would apply here as well.
> https://lore.kernel.org/all/CAMknhBGaJxXvsQ8cZkgDsKLVjOY5y2pzox-99hdOCrUaoZdsxg@mail.gmail.com/
> 

Well, I would argue that the has_temp flag being set to 0 is also unneeded and
can be removed (in another patch).
> This would also increase visibility towards what features does a specific
> model support as it is clearly stated with "= false" rather than looking
> for what fields are not set within the struct.

IMO, the omission of the flag is already pretty clear that the feature is not
available. Typically we don't initialize things that do not need to be
initialized (less LOC)...

- Nuno Sá


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ