linux-kernel - Re: [PATCH v3 3/4] iio: adc: ad7380: add support for adaq4370-4 and adaq4380-4

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]

Message-ID: <20241027092958.79e9f945@jic23-huawei>
Date: Sun, 27 Oct 2024 09:29:58 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Julien Stephan <jstephan@...libre.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Nuno Sá <nuno.sa@...log.com>,
 David Lechner <dlechner@...libre.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Jonathan Corbet <corbet@....net>,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 3/4] iio: adc: ad7380: add support for adaq4370-4 and
 adaq4380-4

On Thu, 24 Oct 2024 10:16:58 +0200
Julien Stephan <jstephan@...libre.com> wrote:

> adaq4370-4 (2MSPS) and adaq4380-4 (4MSPS) are quad-channel precision data
> acquisition signal chain μModule solutions compatible with the ad738x
> family, with the following differences:
> 
> - pin selectable gain in front of each 4 adc
> - internal reference is 3V derived from refin-supply (5V)
> - additional supplies
> 
> This implies that IIO_CHAN_INFO_SCALE can not be shared by type.
If respinning for other reasons, maybe 
"by type for these new devices." or I can tweak whilst applying.
> 
> Signed-off-by: Julien Stephan <jstephan@...libre.com>
Looks good to me. Only comment is a 'maybe' for pulling out a local
dev variable to shave a few characters off some long lines.
May not be worth the effort.

> @@ -1104,6 +1186,42 @@ static int ad7380_probe(struct spi_device *spi)
>  		st->vcm_mv[i] = ret / 1000;
>  	}
>  
> +	for (i = 0; i < MAX_NUM_CHANNELS; i++)
> +		st->gain_milli[i] = AD7380_DEFAULT_GAIN_MILLI;
> +
> +	if (st->chip_info->has_hardware_gain) {
> +		device_for_each_child_node_scoped(&spi->dev, node) {
> +			unsigned int channel, gain;
> +			int gain_idx;
> +
> +			ret = fwnode_property_read_u32(node, "reg", &channel);
> +			if (ret)
> +				return dev_err_probe(&spi->dev, ret,
Hmm. It might be worth a precursor patch to add
struct device *dev = &spi->dev; for probe to shorten all these a little
(+ a bunch of existing cases)

Up to you though.

> +						     "Failed to read reg property\n");
> +
> +			if (channel >= st->chip_info->num_channels - 1)
> +				return dev_err_probe(&spi->dev, -EINVAL,
> +						     "Invalid channel number %i\n",
> +						     channel);
> +
> +			ret = fwnode_property_read_u32(node, "adi,gain-milli",
> +						       &gain);
> +			if (ret && ret != -EINVAL)
> +				return dev_err_probe(&spi->dev, ret,
> +						     "Failed to read gain for channel %i\n",
> +						     channel);
> +			if (ret != -EINVAL) {
> +				/*
> +				 * Match gain value from dt to one of supported
> +				 * gains
> +				 */
> +				gain_idx = find_closest(gain, ad7380_gains,
> +							ARRAY_SIZE(ad7380_gains));
> +				st->gain_milli[channel] = ad7380_gains[gain_idx];
> +			}
> +		}
> +	}
> +