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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c3e6402c-7cfe-45c1-9f28-f131cd94aa05@baylibre.com>
Date: Sun, 6 Jul 2025 12:33:45 -0500
From: David Lechner <dlechner@...libre.com>
To: Jonathan Cameron <jic23@...nel.org>
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 7/6/25 11:57 AM, Jonathan Cameron wrote:
> 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.

Yes. Drop patch 12 and I will send a new version of both patches. This
one can be applied to fixes and the other can wait.

> 
> 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