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: <20250706175725.39e79105@jic23-huawei>
Date: Sun, 6 Jul 2025 17:57:25 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] iio: adc: ad7173: fix num_slots

On Sun, 6 Jul 2025 11:08:06 -0500
David Lechner <dlechner@...libre.com> wrote:

> On 7/6/25 5:15 AM, Jonathan Cameron wrote:
> > On Fri, 4 Jul 2025 12:04:04 -0500
> > David Lechner <dlechner@...libre.com> wrote:
> >   
> >> On 7/4/25 11:21 AM, David Lechner wrote:  
> >>> Fix the num_slots value for most chips in the ad7173 driver. The correct
> >>> value is the number of CHANNELx registers on the chip.
> >>>
> >>> In commit 4310e15b3140 ("iio: adc: ad7173: don't make copy of
> >>> ad_sigma_delta_info struct"), we refactored struct ad_sigma_delta_info
> >>> to be static const data instead of being dynamically populated during
> >>> driver probe. However, there was an existing bug in commit 76a1e6a42802
> >>> ("iio: adc: ad7173: add AD7173 driver") where num_slots was incorrectly
> >>> set to the number of CONFIGx registers instead of the number of
> >>> CHANNELx registers. This bug was partially propagated to the refactored
> >>> code in that the 16-channel chips were only given 8 slots instead of
> >>> 16 although we did managed to fix the 8-channel chips and one of the
> >>> 4-channel chips in that commit. However, we botched two of the 4-channel
> >>> chips and ended up incorrectly giving them 8 slots during the
> >>> refactoring.
> >>>
> >>> This patch fixes that mistake on the 4-channel chips and also
> >>> corrects the 16-channel chips to have 16 slots.
> >>>
> >>> Fixes: 4310e15b3140 ("iio: adc: ad7173: don't make copy of ad_sigma_delta_info struct")
> >>> Signed-off-by: David Lechner <dlechner@...libre.com>
> >>> ---
> >>> Changes in v2:
> >>> - Improve commit message.
> >>> - Link to v1: https://lore.kernel.org/r/20250703-iio-adc-ad7173-fix-num_slots-on-most-chips-v1-1-326c5d113e15@baylibre.com
> >>> ---
> >>>  drivers/iio/adc/ad7173.c | 37 +++++++++++++++++++++++++++----------
> >>>  1 file changed, 27 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c
> >>> index dd9fa35555c79ead5a1b88d1dc6cc3db122502be..9c197cea11eb955becf4b9b97246379fa9c5da13 100644
> >>> --- a/drivers/iio/adc/ad7173.c
> >>> +++ b/drivers/iio/adc/ad7173.c
> >>> @@ -771,10 +771,27 @@ static const struct ad_sigma_delta_info ad7173_sigma_delta_info_8_slots = {
> >>>  	.num_slots = 8,
> >>>  };
> >>>  
> >>> +static const struct ad_sigma_delta_info ad7173_sigma_delta_info_16_slots = {
> >>> +	.set_channel = ad7173_set_channel,
> >>> +	.append_status = ad7173_append_status,
> >>> +	.disable_all = ad7173_disable_all,
> >>> +	.disable_one = ad7173_disable_one,
> >>> +	.set_mode = ad7173_set_mode,
> >>> +	.has_registers = true,
> >>> +	.has_named_irqs = true,    
> >>  
> >>> +	.supports_spi_offload = true,    
> >>
> >> Well drat, I was too quick with the update and the bots [1] noticed that
> >> this conflicts with the in-flight patch that added this field [2].
> >>
> >> I guess we can drop this one line, but then the other patch will wait
> >> until this fix makes its way back into the togreg/testing branches.  
> > 
> > I'm lost - what would you prefer we do here?  For now I have [2] on my
> > tree but can drop just that one patch if it unwinds this complexity.  
> 
> I was hoping you would tell me. :-p
> 
> In any case, we should apply this patch, with the supports_spi_offload
> line dropped, first so that it backports cleanly to the stable release(s).
> 
> But where to apply this patch depends on if you are planning on doing
> another fixes-togreg this release cycle or not. Or we could just opt
> to take the slow path to avoid the dependency dance and just apply
> both patches to iio/togreg and let it make it's way to stable after
> the next merge cycle.

I'll almost certainly do another fixes pull, but it might not get into upstream
of my togreg branch fast enough. 

For now is just dropping patch 12 from the main series enough to avoid the
conflict?  If so send me a clean version of this and I'll apply that to the
fixes-togreg branch and we can hopefully get a round trip to pick up patch 12
on top of it.

Thanks,

Jonathan

> 
> >>
> >> [1]: https://lore.kernel.org/linux-iio/202507050018.iWEJiG04-lkp@intel.com/
> >> [2]: https://lore.kernel.org/linux-iio/20250701-iio-adc-ad7173-add-spi-offload-support-v3-12-42abb83e3dac@baylibre.com/
> >>  
> >>> +	.addr_shift = 0,
> >>> +	.read_mask = BIT(6),
> >>> +	.status_ch_mask = GENMASK(3, 0),
> >>> +	.data_reg = AD7173_REG_DATA,
> >>> +	.num_resetclks = 64,
> >>> +	.num_slots = 16,
> >>> +};
> >>> +    
> >>  
> >   
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ