[PATCH v2 1/2] iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[]

[PATCH v2 1/2] iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[]

[Fabio Estevam]

From: Fabio Estevam <festevam@denx.de>

Since commit 2718f15403fb ("iio: sanity check available_scan_masks array"),
booting a board populated with a MAX11601 results in a flood of warnings:

max1363 1-0064: available_scan_mask 8 subset of 0. Never used
max1363 1-0064: available_scan_mask 9 subset of 0. Never used
max1363 1-0064: available_scan_mask 10 subset of 0. Never used
max1363 1-0064: available_scan_mask 11 subset of 0. Never used
max1363 1-0064: available_scan_mask 12 subset of 0. Never used
max1363 1-0064: available_scan_mask 13 subset of 0. Never used
...

These warnings are caused by incorrect offsets used for differential
channels in the MAX1363_4X_CHANS() and MAX1363_8X_CHANS() macros.

The max1363_mode_table[] defines the differential channel mappings as
follows:

MAX1363_MODE_DIFF_SINGLE(0, 1, 1 << 12),
MAX1363_MODE_DIFF_SINGLE(2, 3, 1 << 13),
MAX1363_MODE_DIFF_SINGLE(4, 5, 1 << 14),
MAX1363_MODE_DIFF_SINGLE(6, 7, 1 << 15),
MAX1363_MODE_DIFF_SINGLE(8, 9, 1 << 16),
MAX1363_MODE_DIFF_SINGLE(10, 11, 1 << 17),
MAX1363_MODE_DIFF_SINGLE(1, 0, 1 << 18),
MAX1363_MODE_DIFF_SINGLE(3, 2, 1 << 19),
MAX1363_MODE_DIFF_SINGLE(5, 4, 1 << 20),
MAX1363_MODE_DIFF_SINGLE(7, 6, 1 << 21),
MAX1363_MODE_DIFF_SINGLE(9, 8, 1 << 22),
MAX1363_MODE_DIFF_SINGLE(11, 10, 1 << 23),

Update the macros to follow this same pattern, ensuring that the scan masks
are valid and preventing the warnings.

Cc: stable@vger.kernel.org
Fixes: 2718f15403fb ("iio: sanity check available_scan_masks array")
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
Changes since v1:
- Fix the problem by changing the MAX1363_4X_CHANS() and MAX1363_8X_CHANS()
macros. (Jonathan)

 drivers/iio/adc/max1363.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
index a7e9912fb44a..bc44b4604ef4 100644
--- a/drivers/iio/adc/max1363.c
+++ b/drivers/iio/adc/max1363.c
@@ -511,10 +511,10 @@ static const struct iio_event_spec max1363_events[] = {
 	MAX1363_CHAN_U(1, _s1, 1, bits, ev_spec, num_ev_spec),		\
 	MAX1363_CHAN_U(2, _s2, 2, bits, ev_spec, num_ev_spec),		\
 	MAX1363_CHAN_U(3, _s3, 3, bits, ev_spec, num_ev_spec),		\
-	MAX1363_CHAN_B(0, 1, d0m1, 4, bits, ev_spec, num_ev_spec),	\
-	MAX1363_CHAN_B(2, 3, d2m3, 5, bits, ev_spec, num_ev_spec),	\
-	MAX1363_CHAN_B(1, 0, d1m0, 6, bits, ev_spec, num_ev_spec),	\
-	MAX1363_CHAN_B(3, 2, d3m2, 7, bits, ev_spec, num_ev_spec),	\
+	MAX1363_CHAN_B(0, 1, d0m1, 12, bits, ev_spec, num_ev_spec),	\
+	MAX1363_CHAN_B(2, 3, d2m3, 13, bits, ev_spec, num_ev_spec),	\
+	MAX1363_CHAN_B(1, 0, d1m0, 18, bits, ev_spec, num_ev_spec),	\
+	MAX1363_CHAN_B(3, 2, d3m2, 19, bits, ev_spec, num_ev_spec),	\
 	IIO_CHAN_SOFT_TIMESTAMP(8)					\
 	}
 
@@ -609,14 +609,14 @@ static const enum max1363_modes max11608_mode_list[] = {
 	MAX1363_CHAN_U(5, _s5, 5, bits, NULL, 0),	\
 	MAX1363_CHAN_U(6, _s6, 6, bits, NULL, 0),	\
 	MAX1363_CHAN_U(7, _s7, 7, bits, NULL, 0),	\
-	MAX1363_CHAN_B(0, 1, d0m1, 8, bits, NULL, 0),	\
-	MAX1363_CHAN_B(2, 3, d2m3, 9, bits, NULL, 0),	\
-	MAX1363_CHAN_B(4, 5, d4m5, 10, bits, NULL, 0),	\
-	MAX1363_CHAN_B(6, 7, d6m7, 11, bits, NULL, 0),	\
-	MAX1363_CHAN_B(1, 0, d1m0, 12, bits, NULL, 0),	\
-	MAX1363_CHAN_B(3, 2, d3m2, 13, bits, NULL, 0),	\
-	MAX1363_CHAN_B(5, 4, d5m4, 14, bits, NULL, 0),	\
-	MAX1363_CHAN_B(7, 6, d7m6, 15, bits, NULL, 0),	\
+	MAX1363_CHAN_B(0, 1, d0m1, 12, bits, NULL, 0),	\
+	MAX1363_CHAN_B(2, 3, d2m3, 13, bits, NULL, 0),	\
+	MAX1363_CHAN_B(4, 5, d4m5, 14, bits, NULL, 0),	\
+	MAX1363_CHAN_B(6, 7, d6m7, 15, bits, NULL, 0),	\
+	MAX1363_CHAN_B(1, 0, d1m0, 18, bits, NULL, 0),	\
+	MAX1363_CHAN_B(3, 2, d3m2, 19, bits, NULL, 0),	\
+	MAX1363_CHAN_B(5, 4, d5m4, 20, bits, NULL, 0),	\
+	MAX1363_CHAN_B(7, 6, d7m6, 21, bits, NULL, 0),	\
 	IIO_CHAN_SOFT_TIMESTAMP(16)			\
 }
 static const struct iio_chan_spec max11602_channels[] = MAX1363_8X_CHANS(8);
-- 
2.34.1

[PATCH v2 2/2] iio: adc: max1363: Reorder mode_list[] entries

[Fabio Estevam]

From: Fabio Estevam <festevam@denx.de>

The IIO core issues warnings when a scan mask is a subset of a previous
entry in the available_scan_masks array.

On a board using a MAX11601, the following warning is observed:

max1363 1-0064: available_scan_mask 7 subset of 6. Never used

This occurs because the entries in the max11607_mode_list[] array are not
ordered correctly. To fix this, reorder the entries so that no scan mask is
a subset of an earlier one.

While at it, reorder the mode_list[] arrays for other supported chips as
well, to prevent similar warnings on different variants.

Cc: stable@vger.kernel.org
Fixes: 2718f15403fb ("iio: sanity check available_scan_masks array")
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
Changes since v1:
- Also reorder other mode_list entries. (Jonathan)

 drivers/iio/adc/max1363.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
index bc44b4604ef4..9dd547e62b6c 100644
--- a/drivers/iio/adc/max1363.c
+++ b/drivers/iio/adc/max1363.c
@@ -532,23 +532,23 @@ static const struct iio_chan_spec max1363_channels[] =
 /* Applies to max1236, max1237 */
 static const enum max1363_modes max1236_mode_list[] = {
 	_s0, _s1, _s2, _s3,
-	s0to1, s0to2, s0to3,
+	s0to1, s0to2, s2to3, s0to3,
 	d0m1, d2m3, d1m0, d3m2,
 	d0m1to2m3, d1m0to3m2,
-	s2to3,
 };
 
 /* Applies to max1238, max1239 */
 static const enum max1363_modes max1238_mode_list[] = {
 	_s0, _s1, _s2, _s3, _s4, _s5, _s6, _s7, _s8, _s9, _s10, _s11,
 	s0to1, s0to2, s0to3, s0to4, s0to5, s0to6,
+	s6to7, s6to8, s6to9, s6to10, s6to11,
 	s0to7, s0to8, s0to9, s0to10, s0to11,
 	d0m1, d2m3, d4m5, d6m7, d8m9, d10m11,
 	d1m0, d3m2, d5m4, d7m6, d9m8, d11m10,
-	d0m1to2m3, d0m1to4m5, d0m1to6m7, d0m1to8m9, d0m1to10m11,
-	d1m0to3m2, d1m0to5m4, d1m0to7m6, d1m0to9m8, d1m0to11m10,
-	s6to7, s6to8, s6to9, s6to10, s6to11,
-	d6m7to8m9, d6m7to10m11, d7m6to9m8, d7m6to11m10,
+	d0m1to2m3, d0m1to4m5, d0m1to6m7, d6m7to8m9,
+	d0m1to8m9, d6m7to10m11, d0m1to10m11, d1m0to3m2,
+	d1m0to5m4, d1m0to7m6, d7m6to9m8, d1m0to9m8,
+	d7m6to11m10, d1m0to11m10,
 };
 
 #define MAX1363_12X_CHANS(bits) {				\
@@ -584,16 +584,15 @@ static const struct iio_chan_spec max1238_channels[] = MAX1363_12X_CHANS(12);
 
 static const enum max1363_modes max11607_mode_list[] = {
 	_s0, _s1, _s2, _s3,
-	s0to1, s0to2, s0to3,
-	s2to3,
+	s0to1, s0to2, s2to3,
+	s0to3,
 	d0m1, d2m3, d1m0, d3m2,
 	d0m1to2m3, d1m0to3m2,
 };
 
 static const enum max1363_modes max11608_mode_list[] = {
 	_s0, _s1, _s2, _s3, _s4, _s5, _s6, _s7,
-	s0to1, s0to2, s0to3, s0to4, s0to5, s0to6, s0to7,
-	s6to7,
+	s0to1, s0to2, s0to3, s0to4, s0to5, s0to6, s6to7, s0to7,
 	d0m1, d2m3, d4m5, d6m7,
 	d1m0, d3m2, d5m4, d7m6,
 	d0m1to2m3, d0m1to4m5, d0m1to6m7,
-- 
2.34.1

Re: [PATCH v2 2/2] iio: adc: max1363: Reorder mode_list[] entries

[Matti Vaittinen]

On 16/05/2025 20:39, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> The IIO core issues warnings when a scan mask is a subset of a previous
> entry in the available_scan_masks array.
> 
> On a board using a MAX11601, the following warning is observed:
> 
> max1363 1-0064: available_scan_mask 7 subset of 6. Never used
> 
> This occurs because the entries in the max11607_mode_list[] array are not
> ordered correctly. To fix this, reorder the entries so that no scan mask is
> a subset of an earlier one.
> 
> While at it, reorder the mode_list[] arrays for other supported chips as
> well, to prevent similar warnings on different variants.
> 
> Cc: stable@vger.kernel.org
> Fixes: 2718f15403fb ("iio: sanity check available_scan_masks array")

Same comment as for patch1/2

Yours,
	-- Matti

Re: [PATCH v2 2/2] iio: adc: max1363: Reorder mode_list[] entries

[Jonathan Cameron]

On Mon, 19 May 2025 08:02:33 +0300
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> On 16/05/2025 20:39, Fabio Estevam wrote:
> > From: Fabio Estevam <festevam@denx.de>
> > 
> > The IIO core issues warnings when a scan mask is a subset of a previous
> > entry in the available_scan_masks array.
> > 
> > On a board using a MAX11601, the following warning is observed:
> > 
> > max1363 1-0064: available_scan_mask 7 subset of 6. Never used
> > 
> > This occurs because the entries in the max11607_mode_list[] array are not
> > ordered correctly. To fix this, reorder the entries so that no scan mask is
> > a subset of an earlier one.
> > 
> > While at it, reorder the mode_list[] arrays for other supported chips as
> > well, to prevent similar warnings on different variants.
> > 
> > Cc: stable@vger.kernel.org
> > Fixes: 2718f15403fb ("iio: sanity check available_scan_masks array")  
> 
> Same comment as for patch1/2
> 
> Yours,
> 	-- Matti
Likewise, dropped the fixes tag.  Admittedly that's the somewhat lazy
option.  I'd less fussed than normal on this because the worst that
happens is we print warnings and sample more channels than strictly
necessary.

Jonathan

Re: [PATCH v2 1/2] iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[]

[Matti Vaittinen]

On 16/05/2025 20:38, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> Since commit 2718f15403fb ("iio: sanity check available_scan_masks array"),
> booting a board populated with a MAX11601 results in a flood of warnings:
> 
> max1363 1-0064: available_scan_mask 8 subset of 0. Never used
> max1363 1-0064: available_scan_mask 9 subset of 0. Never used
> max1363 1-0064: available_scan_mask 10 subset of 0. Never used
> max1363 1-0064: available_scan_mask 11 subset of 0. Never used
> max1363 1-0064: available_scan_mask 12 subset of 0. Never used
> max1363 1-0064: available_scan_mask 13 subset of 0. Never used
> ...
> 
> These warnings are caused by incorrect offsets used for differential
> channels in the MAX1363_4X_CHANS() and MAX1363_8X_CHANS() macros.
> 
> The max1363_mode_table[] defines the differential channel mappings as
> follows:
> 
> MAX1363_MODE_DIFF_SINGLE(0, 1, 1 << 12),
> MAX1363_MODE_DIFF_SINGLE(2, 3, 1 << 13),
> MAX1363_MODE_DIFF_SINGLE(4, 5, 1 << 14),
> MAX1363_MODE_DIFF_SINGLE(6, 7, 1 << 15),
> MAX1363_MODE_DIFF_SINGLE(8, 9, 1 << 16),
> MAX1363_MODE_DIFF_SINGLE(10, 11, 1 << 17),
> MAX1363_MODE_DIFF_SINGLE(1, 0, 1 << 18),
> MAX1363_MODE_DIFF_SINGLE(3, 2, 1 << 19),
> MAX1363_MODE_DIFF_SINGLE(5, 4, 1 << 20),
> MAX1363_MODE_DIFF_SINGLE(7, 6, 1 << 21),
> MAX1363_MODE_DIFF_SINGLE(9, 8, 1 << 22),
> MAX1363_MODE_DIFF_SINGLE(11, 10, 1 << 23),
> 
> Update the macros to follow this same pattern, ensuring that the scan masks
> are valid and preventing the warnings.
> 
> Cc: stable@vger.kernel.org
> Fixes: 2718f15403fb ("iio: sanity check available_scan_masks array")

I could argue the problem which is fixed is not related to the 
2718f15403fb. I'd say the problem has been the commit which introduced 
the 'offending' masks instead. The 2718f15403fb is not fixed by this 
change. It could help identifying the faulty releases if correct commit 
was pointed here.

Yours,
	-- Matti

Re: [PATCH v2 1/2] iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[]

[Fabio Estevam]

Hi Matti,

On Mon, May 19, 2025 at 2:01 AM Matti Vaittinen
<mazziesaccount@gmail.com> wrote:

> I could argue the problem which is fixed is not related to the
> 2718f15403fb. I'd say the problem has been the commit which introduced
> the 'offending' masks instead. The 2718f15403fb is not fixed by this
> change. It could help identifying the faulty releases if correct commit
> was pointed here.

Fair enough, thanks.

I am going through this driver's history, and it looks like the masks
have been always wrong, since the beginning.

I was not able to point to an exact commit, though.

Maybe I can remove the Fixes line. Jonathan?

Re: [PATCH v2 1/2] iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[]

[Jonathan Cameron]

On Mon, 19 May 2025 21:31:22 -0300
Fabio Estevam <festevam@gmail.com> wrote:

> Hi Matti,
> 
> On Mon, May 19, 2025 at 2:01 AM Matti Vaittinen
> <mazziesaccount@gmail.com> wrote:
> 
> > I could argue the problem which is fixed is not related to the
> > 2718f15403fb. I'd say the problem has been the commit which introduced
> > the 'offending' masks instead. The 2718f15403fb is not fixed by this
> > change. It could help identifying the faulty releases if correct commit
> > was pointed here.  
> 
> Fair enough, thanks.
> 
> I am going through this driver's history, and it looks like the masks
> have been always wrong, since the beginning.
> 
> I was not able to point to an exact commit, though.
> 
> Maybe I can remove the Fixes line. Jonathan?

Hmm.  I agree this one is misleading and the history
get it right complex (and depends on introduction of various devices
over time.

I'll drop the fixes tag and apply. Note this will only go upstream
after rc1.