linux-kernel - Re: [PATCH v5 6/9] iio: adc: ad7606: rework available attributes for SW channels

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: <20240907160356.3de047b0@jic23-huawei>
Date: Sat, 7 Sep 2024 16:03:56 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Alexandru Ardelean <aardelean@...libre.com>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, krzk+dt@...nel.org, robh@...nel.org,
 lars@...afoo.de, michael.hennerich@...log.com, gstols@...libre.com
Subject: Re: [PATCH v5 6/9] iio: adc: ad7606: rework available attributes
 for SW channels

On Sat,  7 Sep 2024 09:50:39 +0300
Alexandru Ardelean <aardelean@...libre.com> wrote:

> For SW mode, the oversampling and scales attributes are always present.
> So, they can be implemented via a 'read_avail' hook in iio_info.
> 
> For HW mode, it's a bit tricky, as these attributes get assigned based on
> GPIO definitions.
> 
> So, for SW mode, we define a separate AD7606_SW_CHANNEL() macro, and use
> that for the SW channels.
> And 'ad7606_info_os_range_and_debug' can be renamed to
> 'ad7606_info_sw_mode' as it is only used for SW mode.
> 
> For the 'read_avail' hook, we'll need to allocate the SW scales, so that
> they are just returned userspace without any extra processing.
> The allocation will happen when then ad7606_state struct is allocated.
> The oversampling available parameters don't need any extra processing; they
> can just be passed back to userspace (as they are).
> 
> Signed-off-by: Alexandru Ardelean <aardelean@...libre.com>

One question inline.

>  
>  int ad7606_probe(struct device *dev, int irq, void __iomem *base_address,
> diff --git a/drivers/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
> index 635407c2acc0..fa175cff256c 100644
> --- a/drivers/iio/adc/ad7606.h
> +++ b/drivers/iio/adc/ad7606.h

>  #define AD7616_CHANNEL(num)	AD7606_SW_CHANNEL(num, 16)
>  
>  /**
> @@ -65,11 +84,15 @@ struct ad7606_chip_info {
>  /**
>   * struct ad7606_chan_scale - channel scale configuration
>   * @scale_avail		pointer to the array which stores the available scales
> + * @scale_avail_show	a duplicate of 'scale_avail' which is readily formatted
> + *			such that it can be read via the 'read_avail' hook
>   * @num_scales		number of elements stored in the scale_avail array
>   * @range		voltage range selection, selects which scale to apply
>   */
>  struct ad7606_chan_scale {
> +#define AD760X_MAX_SCALE_SHOW		(AD760X_MAX_CHANNELS * 2)

Why is the number of scales dependent on the number of channels?

>  	const unsigned int		*scale_avail;
> +	int				scale_avail_show[AD760X_MAX_SCALE_SHOW];
>  	unsigned int			num_scales;
>  	unsigned int			range;
>  };