* [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor
@ 2025-04-20 1:49 Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
` (5 more replies)
0 siblings, 6 replies; 12+ messages in thread
From: Gabriel Shahrouzi @ 2025-04-20 1:49 UTC (permalink / raw)
To: gregkh, jic23, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier
Cc: gshahrouzi, skhan, linux-kernel-mentees
The original patch combined a functional fix (allowing channel 7) with
several refactoring steps (introducing chip_info, renaming structs,
improving validation). As requested, these have now been separated.
The series proceeds as follows:
1. Fix: Allow diagnostic channel 7 for all device variants.
2. Refactor: Rename the main state structure for clarity before introducing
the new chip_info struct.
3. Refactor: Introduce struct ad7816_chip_info to hold static per-variant
data, update ID tables to store pointers, and switch to using
device_get_match_data() for firmware-independent identification.
This removes the old enum/id mechanism.
4. Refactor: Add has_busy_pin to chip_info and use this flag to
determine BUSY pin handling, replacing pointer comparisons.
5. Refactor: Simplify channel validation logic using
chip_info->max_channels, removing strcmp() checks.
Regarding the 'fixes' tag: I've applied it only to the first commit
containing the core fix, primarily to make backporting easier. Is this
the standard practice, or should the tag typically be applied to
subsequent commits that build upon or are related to the fix as well?
Changes in v5:
- Use correct patch version.
Changes in v4:
- Include missing bracket for condtional statement.
Chainges in v3:
- Split the patch into smaller patches. Make the fix first
followed by clean up.
- Include missing channel for channel selection.
- Address specific feedback regarding enums vs. chip_info data.
- Use device_get_match_data() for device identification.
- Move BUSY pin capability check into chip_info data.
- Simplify channel validation using chip_info data.
Changes in v2:
- Refactor by adding chip_info struct which simplifies
conditional logic.
Gabriel Shahrouzi (5):
staging: iio: adc: ad7816: Allow channel 7 for all devices
staging: iio: adc: ad7816: Rename state structure
staging: iio: adc: ad7816: Introduce chip_info and use pointer
matching
staging: iio: adc: ad7816: Use chip_info for device capabilities
staging: iio: adc: ad7816: Simplify channel validation using chip_info
drivers/staging/iio/adc/ad7816.c | 94 ++++++++++++++++++--------------
1 file changed, 54 insertions(+), 40 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
@ 2025-04-20 1:49 ` Gabriel Shahrouzi
2025-04-21 12:29 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 2/5] staging: iio: adc: ad7816: Rename state structure Gabriel Shahrouzi
` (4 subsequent siblings)
5 siblings, 1 reply; 12+ messages in thread
From: Gabriel Shahrouzi @ 2025-04-20 1:49 UTC (permalink / raw)
To: gregkh, jic23, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier
Cc: gshahrouzi, skhan, linux-kernel-mentees, stable
According to the datasheet on page 9 under the channel selection table,
all devices (AD7816/7/8) are able to use the channel marked as 7. This
channel is used for diagnostic purposes by routing the internal 1.23V
bandgap source through the MUX to the input of the ADC.
Modify the channel validation logic to permit channel 7 for all
supported device types.
Fixes: 7924425db04a ("staging: iio: adc: new driver for AD7816 devices")
Cc: stable@vger.kernel.org
Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
---
drivers/staging/iio/adc/ad7816.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index 6c14d7bcdd675..a44b0c8c82b12 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -190,11 +190,11 @@ static ssize_t ad7816_store_channel(struct device *dev,
dev_err(&chip->spi_dev->dev, "Invalid channel id %lu for %s.\n",
data, indio_dev->name);
return -EINVAL;
- } else if (strcmp(indio_dev->name, "ad7818") == 0 && data > 1) {
+ } else if (strcmp(indio_dev->name, "ad7818") == 0 && data > 1 && data != AD7816_CS_MASK) {
dev_err(&chip->spi_dev->dev,
"Invalid channel id %lu for ad7818.\n", data);
return -EINVAL;
- } else if (strcmp(indio_dev->name, "ad7816") == 0 && data > 0) {
+ } else if (strcmp(indio_dev->name, "ad7816") == 0 && data > 0 && data != AD7816_CS_MASK) {
dev_err(&chip->spi_dev->dev,
"Invalid channel id %lu for ad7816.\n", data);
return -EINVAL;
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v5 2/5] staging: iio: adc: ad7816: Rename state structure
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
@ 2025-04-20 1:49 ` Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching Gabriel Shahrouzi
` (3 subsequent siblings)
5 siblings, 0 replies; 12+ messages in thread
From: Gabriel Shahrouzi @ 2025-04-20 1:49 UTC (permalink / raw)
To: gregkh, jic23, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier
Cc: gshahrouzi, skhan, linux-kernel-mentees
Rename the main driver state structure from 'ad7816_chip_info' to
'ad7816_state' to avoid confusion with the upcoming structure that will
hold static, per-device-type information.
This is purely a mechanical rename with no functional changes.
Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
---
drivers/staging/iio/adc/ad7816.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index a44b0c8c82b12..cad2e55aff3f9 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -38,10 +38,10 @@
#define AD7816_TEMP_FLOAT_MASK 0x3
/*
- * struct ad7816_chip_info - chip specific information
+ * struct ad7816_state - chip specific information
*/
-struct ad7816_chip_info {
+struct ad7816_state {
kernel_ulong_t id;
struct spi_device *spi_dev;
struct gpio_desc *rdwr_pin;
@@ -61,7 +61,7 @@ enum ad7816_type {
/*
* ad7816 data access by SPI
*/
-static int ad7816_spi_read(struct ad7816_chip_info *chip, u16 *data)
+static int ad7816_spi_read(struct ad7816_state *chip, u16 *data)
{
struct spi_device *spi_dev = chip->spi_dev;
int ret;
@@ -102,7 +102,7 @@ static int ad7816_spi_read(struct ad7816_chip_info *chip, u16 *data)
return ret;
}
-static int ad7816_spi_write(struct ad7816_chip_info *chip, u8 data)
+static int ad7816_spi_write(struct ad7816_state *chip, u8 data)
{
struct spi_device *spi_dev = chip->spi_dev;
int ret;
@@ -121,7 +121,7 @@ static ssize_t ad7816_show_mode(struct device *dev,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
- struct ad7816_chip_info *chip = iio_priv(indio_dev);
+ struct ad7816_state *chip = iio_priv(indio_dev);
if (chip->mode)
return sprintf(buf, "power-save\n");
@@ -134,7 +134,7 @@ static ssize_t ad7816_store_mode(struct device *dev,
size_t len)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
- struct ad7816_chip_info *chip = iio_priv(indio_dev);
+ struct ad7816_state *chip = iio_priv(indio_dev);
if (strcmp(buf, "full")) {
gpiod_set_value(chip->rdwr_pin, 1);
@@ -167,7 +167,7 @@ static ssize_t ad7816_show_channel(struct device *dev,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
- struct ad7816_chip_info *chip = iio_priv(indio_dev);
+ struct ad7816_state *chip = iio_priv(indio_dev);
return sprintf(buf, "%d\n", chip->channel_id);
}
@@ -178,7 +178,7 @@ static ssize_t ad7816_store_channel(struct device *dev,
size_t len)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
- struct ad7816_chip_info *chip = iio_priv(indio_dev);
+ struct ad7816_state *chip = iio_priv(indio_dev);
unsigned long data;
int ret;
@@ -215,7 +215,7 @@ static ssize_t ad7816_show_value(struct device *dev,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
- struct ad7816_chip_info *chip = iio_priv(indio_dev);
+ struct ad7816_state *chip = iio_priv(indio_dev);
u16 data;
s8 value;
int ret;
@@ -271,7 +271,7 @@ static ssize_t ad7816_show_oti(struct device *dev,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
- struct ad7816_chip_info *chip = iio_priv(indio_dev);
+ struct ad7816_state *chip = iio_priv(indio_dev);
int value;
if (chip->channel_id > AD7816_CS_MAX) {
@@ -292,7 +292,7 @@ static inline ssize_t ad7816_set_oti(struct device *dev,
size_t len)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
- struct ad7816_chip_info *chip = iio_priv(indio_dev);
+ struct ad7816_state *chip = iio_priv(indio_dev);
long value;
u8 data;
int ret;
@@ -351,7 +351,7 @@ static const struct iio_info ad7816_info = {
static int ad7816_probe(struct spi_device *spi_dev)
{
- struct ad7816_chip_info *chip;
+ struct ad7816_state *chip;
struct iio_dev *indio_dev;
int i, ret;
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 2/5] staging: iio: adc: ad7816: Rename state structure Gabriel Shahrouzi
@ 2025-04-20 1:49 ` Gabriel Shahrouzi
2025-04-21 12:34 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities Gabriel Shahrouzi
` (2 subsequent siblings)
5 siblings, 1 reply; 12+ messages in thread
From: Gabriel Shahrouzi @ 2025-04-20 1:49 UTC (permalink / raw)
To: gregkh, jic23, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier
Cc: gshahrouzi, skhan, linux-kernel-mentees
Introduce struct ad7816_chip_info to centralize static properties (e.g.
name, max channels) that differ between chip variants (AD7816/7/8) but
are constant for any specific type.
Store pointers to these instances in the of_device_id (.data) and
spi_device_id (driver_data) tables. Retrieve the pointer in probe()
using the firmware-independent device_get_match_data() and store it in
the ad7816_state struct.
Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
---
drivers/staging/iio/adc/ad7816.c | 55 +++++++++++++++++++++-----------
1 file changed, 37 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index cad2e55aff3f9..39310ade770d0 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -41,8 +41,28 @@
* struct ad7816_state - chip specific information
*/
+struct ad7816_chip_info {
+ const char *name;
+ u8 max_channels;
+};
+
+static const struct ad7816_chip_info ad7816_info_ad7816 = {
+ .name = "ad7816",
+ .max_channels = 0,
+};
+
+static const struct ad7816_chip_info ad7817_info_ad7817 = {
+ .name = "ad7817",
+ .max_channels = 3,
+};
+
+static const struct ad7816_chip_info ad7818_info_ad7818 = {
+ .name = "ad7818",
+ .max_channels = 1,
+};
+
struct ad7816_state {
- kernel_ulong_t id;
+ const struct ad7816_chip_info *chip_info;
struct spi_device *spi_dev;
struct gpio_desc *rdwr_pin;
struct gpio_desc *convert_pin;
@@ -52,12 +72,6 @@ struct ad7816_state {
u8 mode;
};
-enum ad7816_type {
- ID_AD7816,
- ID_AD7817,
- ID_AD7818,
-};
-
/*
* ad7816 data access by SPI
*/
@@ -84,7 +98,7 @@ static int ad7816_spi_read(struct ad7816_state *chip, u16 *data)
gpiod_set_value(chip->convert_pin, 1);
}
- if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
+ if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {
while (gpiod_get_value(chip->busy_pin))
cpu_relax();
}
@@ -353,6 +367,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
{
struct ad7816_state *chip;
struct iio_dev *indio_dev;
+ const struct ad7816_chip_info *info;
int i, ret;
indio_dev = devm_iio_device_alloc(&spi_dev->dev, sizeof(*chip));
@@ -362,11 +377,15 @@ static int ad7816_probe(struct spi_device *spi_dev)
/* this is only used for device removal purposes */
dev_set_drvdata(&spi_dev->dev, indio_dev);
+ info = device_get_match_data(&spi_dev->dev);
+ if (!info)
+ return -ENODEV;
+ chip->chip_info = info;
+
chip->spi_dev = spi_dev;
for (i = 0; i <= AD7816_CS_MAX; i++)
chip->oti_data[i] = 203;
- chip->id = spi_get_device_id(spi_dev)->driver_data;
chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_OUT_HIGH);
if (IS_ERR(chip->rdwr_pin)) {
ret = PTR_ERR(chip->rdwr_pin);
@@ -382,7 +401,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
ret);
return ret;
}
- if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
+ if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {
chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy",
GPIOD_IN);
if (IS_ERR(chip->busy_pin)) {
@@ -393,7 +412,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
}
}
- indio_dev->name = spi_get_device_id(spi_dev)->name;
+ indio_dev->name = chip->chip_info->name;
indio_dev->info = &ad7816_info;
indio_dev->modes = INDIO_DIRECT_MODE;
@@ -420,18 +439,18 @@ static int ad7816_probe(struct spi_device *spi_dev)
}
static const struct of_device_id ad7816_of_match[] = {
- { .compatible = "adi,ad7816", },
- { .compatible = "adi,ad7817", },
- { .compatible = "adi,ad7818", },
+ { .compatible = "adi,ad7816", .data = &ad7816_info_ad7816 },
+ { .compatible = "adi,ad7817", .data = &ad7817_info_ad7817 },
+ { .compatible = "adi,ad7818", .data = &ad7818_info_ad7818 },
{ }
};
MODULE_DEVICE_TABLE(of, ad7816_of_match);
static const struct spi_device_id ad7816_id[] = {
- { "ad7816", ID_AD7816 },
- { "ad7817", ID_AD7817 },
- { "ad7818", ID_AD7818 },
- {}
+ { "ad7816", (kernel_ulong_t)&ad7816_info_ad7816 },
+ { "ad7817", (kernel_ulong_t)&ad7817_info_ad7817 },
+ { "ad7818", (kernel_ulong_t)&ad7818_info_ad7818 },
+ { }
};
MODULE_DEVICE_TABLE(spi, ad7816_id);
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
` (2 preceding siblings ...)
2025-04-20 1:49 ` [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching Gabriel Shahrouzi
@ 2025-04-20 1:49 ` Gabriel Shahrouzi
2025-04-21 12:35 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info Gabriel Shahrouzi
2025-04-21 11:31 ` [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Jonathan Cameron
5 siblings, 1 reply; 12+ messages in thread
From: Gabriel Shahrouzi @ 2025-04-20 1:49 UTC (permalink / raw)
To: gregkh, jic23, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier
Cc: gshahrouzi, skhan, linux-kernel-mentees
Move device-specific capability information, like the presence of a
BUSY pin, into the ad7816_chip_info structure.
Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
---
drivers/staging/iio/adc/ad7816.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index 39310ade770d0..ab7520a8a3da9 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -44,21 +44,25 @@
struct ad7816_chip_info {
const char *name;
u8 max_channels;
+ bool has_busy_pin;
};
static const struct ad7816_chip_info ad7816_info_ad7816 = {
.name = "ad7816",
.max_channels = 0,
+ .has_busy_pin = true,
};
static const struct ad7816_chip_info ad7817_info_ad7817 = {
.name = "ad7817",
.max_channels = 3,
+ .has_busy_pin = true,
};
static const struct ad7816_chip_info ad7818_info_ad7818 = {
.name = "ad7818",
.max_channels = 1,
+ .has_busy_pin = false,
};
struct ad7816_state {
@@ -98,7 +102,7 @@ static int ad7816_spi_read(struct ad7816_state *chip, u16 *data)
gpiod_set_value(chip->convert_pin, 1);
}
- if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {
+ if (chip->chip_info->has_busy_pin) {
while (gpiod_get_value(chip->busy_pin))
cpu_relax();
}
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
` (3 preceding siblings ...)
2025-04-20 1:49 ` [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities Gabriel Shahrouzi
@ 2025-04-20 1:49 ` Gabriel Shahrouzi
2025-04-21 12:37 ` Jonathan Cameron
2025-04-21 11:31 ` [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Jonathan Cameron
5 siblings, 1 reply; 12+ messages in thread
From: Gabriel Shahrouzi @ 2025-04-20 1:49 UTC (permalink / raw)
To: gregkh, jic23, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier
Cc: gshahrouzi, skhan, linux-kernel-mentees
Refactor the channel validation logic within ad7816_store_channel() to
leverage the max_channels field previously introduced in the
ad7816_chip_info structure.
Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
---
drivers/staging/iio/adc/ad7816.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index ab7520a8a3da9..7a59cfbcc6e33 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -204,17 +204,9 @@ static ssize_t ad7816_store_channel(struct device *dev,
if (ret)
return ret;
- if (data > AD7816_CS_MAX && data != AD7816_CS_MASK) {
+ if (data > chip->chip_info->max_channels && data != AD7816_CS_MASK) {
dev_err(&chip->spi_dev->dev, "Invalid channel id %lu for %s.\n",
- data, indio_dev->name);
- return -EINVAL;
- } else if (strcmp(indio_dev->name, "ad7818") == 0 && data > 1 && data != AD7816_CS_MASK) {
- dev_err(&chip->spi_dev->dev,
- "Invalid channel id %lu for ad7818.\n", data);
- return -EINVAL;
- } else if (strcmp(indio_dev->name, "ad7816") == 0 && data > 0 && data != AD7816_CS_MASK) {
- dev_err(&chip->spi_dev->dev,
- "Invalid channel id %lu for ad7816.\n", data);
+ data, chip->chip_info->name);
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
` (4 preceding siblings ...)
2025-04-20 1:49 ` [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info Gabriel Shahrouzi
@ 2025-04-21 11:31 ` Jonathan Cameron
2025-04-21 13:49 ` Gabriel Shahrouzi
5 siblings, 1 reply; 12+ messages in thread
From: Jonathan Cameron @ 2025-04-21 11:31 UTC (permalink / raw)
To: Gabriel Shahrouzi
Cc: gregkh, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier, skhan,
linux-kernel-mentees
On Sat, 19 Apr 2025 21:49:05 -0400
Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:
> The original patch combined a functional fix (allowing channel 7) with
> several refactoring steps (introducing chip_info, renaming structs,
> improving validation). As requested, these have now been separated.
>
> The series proceeds as follows:
> 1. Fix: Allow diagnostic channel 7 for all device variants.
> 2. Refactor: Rename the main state structure for clarity before introducing
> the new chip_info struct.
> 3. Refactor: Introduce struct ad7816_chip_info to hold static per-variant
> data, update ID tables to store pointers, and switch to using
> device_get_match_data() for firmware-independent identification.
> This removes the old enum/id mechanism.
> 4. Refactor: Add has_busy_pin to chip_info and use this flag to
> determine BUSY pin handling, replacing pointer comparisons.
> 5. Refactor: Simplify channel validation logic using
> chip_info->max_channels, removing strcmp() checks.
>
> Regarding the 'fixes' tag: I've applied it only to the first commit
> containing the core fix, primarily to make backporting easier. Is this
> the standard practice, or should the tag typically be applied to
> subsequent commits that build upon or are related to the fix as well?
>
> Changes in v5:
> - Use correct patch version.
Generally I wouldn't resend for this. Instead a single email in
reply to the messed up version saying it is infact v4 would have
done the job.
Alternatively a quick reply to that thread to say it was messed
up and please look for v5 would have worked to make a reader
move on directly to the newer version
Jonathan
> Changes in v4:
> - Include missing bracket for condtional statement.
> Chainges in v3:
> - Split the patch into smaller patches. Make the fix first
> followed by clean up.
> - Include missing channel for channel selection.
> - Address specific feedback regarding enums vs. chip_info data.
> - Use device_get_match_data() for device identification.
> - Move BUSY pin capability check into chip_info data.
> - Simplify channel validation using chip_info data.
> Changes in v2:
> - Refactor by adding chip_info struct which simplifies
> conditional logic.
>
> Gabriel Shahrouzi (5):
> staging: iio: adc: ad7816: Allow channel 7 for all devices
> staging: iio: adc: ad7816: Rename state structure
> staging: iio: adc: ad7816: Introduce chip_info and use pointer
> matching
> staging: iio: adc: ad7816: Use chip_info for device capabilities
> staging: iio: adc: ad7816: Simplify channel validation using chip_info
>
> drivers/staging/iio/adc/ad7816.c | 94 ++++++++++++++++++--------------
> 1 file changed, 54 insertions(+), 40 deletions(-)
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices
2025-04-20 1:49 ` [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
@ 2025-04-21 12:29 ` Jonathan Cameron
0 siblings, 0 replies; 12+ messages in thread
From: Jonathan Cameron @ 2025-04-21 12:29 UTC (permalink / raw)
To: Gabriel Shahrouzi
Cc: gregkh, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier, skhan,
linux-kernel-mentees, stable
On Sat, 19 Apr 2025 21:49:06 -0400
Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:
> According to the datasheet on page 9 under the channel selection table,
> all devices (AD7816/7/8) are able to use the channel marked as 7. This
> channel is used for diagnostic purposes by routing the internal 1.23V
> bandgap source through the MUX to the input of the ADC.
>
> Modify the channel validation logic to permit channel 7 for all
> supported device types.
>
> Fixes: 7924425db04a ("staging: iio: adc: new driver for AD7816 devices")
Adding a missing channel is not a fix. It is a feature enhancement.
Not appropriate for backporting in general (though obviously someone wanting
to use it might do so).
> Cc: stable@vger.kernel.org
> Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
> ---
> drivers/staging/iio/adc/ad7816.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
> index 6c14d7bcdd675..a44b0c8c82b12 100644
> --- a/drivers/staging/iio/adc/ad7816.c
> +++ b/drivers/staging/iio/adc/ad7816.c
> @@ -190,11 +190,11 @@ static ssize_t ad7816_store_channel(struct device *dev,
> dev_err(&chip->spi_dev->dev, "Invalid channel id %lu for %s.\n",
> data, indio_dev->name);
> return -EINVAL;
> - } else if (strcmp(indio_dev->name, "ad7818") == 0 && data > 1) {
> + } else if (strcmp(indio_dev->name, "ad7818") == 0 && data > 1 && data != AD7816_CS_MASK) {
Why use the mask? I think this is something entirely unrelated that just happens to have
the value 7.
> dev_err(&chip->spi_dev->dev,
> "Invalid channel id %lu for ad7818.\n", data);
> return -EINVAL;
> - } else if (strcmp(indio_dev->name, "ad7816") == 0 && data > 0) {
> + } else if (strcmp(indio_dev->name, "ad7816") == 0 && data > 0 && data != AD7816_CS_MASK) {
> dev_err(&chip->spi_dev->dev,
> "Invalid channel id %lu for ad7816.\n", data);
> return -EINVAL;
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching
2025-04-20 1:49 ` [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching Gabriel Shahrouzi
@ 2025-04-21 12:34 ` Jonathan Cameron
0 siblings, 0 replies; 12+ messages in thread
From: Jonathan Cameron @ 2025-04-21 12:34 UTC (permalink / raw)
To: Gabriel Shahrouzi
Cc: gregkh, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier, skhan,
linux-kernel-mentees
On Sat, 19 Apr 2025 21:49:08 -0400
Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:
> Introduce struct ad7816_chip_info to centralize static properties (e.g.
> name, max channels) that differ between chip variants (AD7816/7/8) but
> are constant for any specific type.
>
> Store pointers to these instances in the of_device_id (.data) and
> spi_device_id (driver_data) tables. Retrieve the pointer in probe()
> using the firmware-independent device_get_match_data() and store it in
> the ad7816_state struct.
>
> Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
Hi Gabriel
A few minor things inline.
I think this went a little too far in splitting up changes and you should combine
patches 3 and 4 to avoid a nasty intermediate bit of code.
Jonathan
> ---
> drivers/staging/iio/adc/ad7816.c | 55 +++++++++++++++++++++-----------
> 1 file changed, 37 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
> index cad2e55aff3f9..39310ade770d0 100644
> --- a/drivers/staging/iio/adc/ad7816.c
> +++ b/drivers/staging/iio/adc/ad7816.c
> @@ -41,8 +41,28 @@
> * struct ad7816_state - chip specific information
> */
>
> +struct ad7816_chip_info {
> + const char *name;
> + u8 max_channels;
Something called max_channels should be the number of channels.
If you called it max_channel then it could be used for the maximum channel
number present. I assume that is what you have here as otherwise the
ad7816 has no channels which seems odd!
> +};
> +
> +static const struct ad7816_chip_info ad7816_info_ad7816 = {
> + .name = "ad7816",
> + .max_channels = 0,
> +};
> +
> +static const struct ad7816_chip_info ad7817_info_ad7817 = {
> + .name = "ad7817",
> + .max_channels = 3,
> +};
> +
> +static const struct ad7816_chip_info ad7818_info_ad7818 = {
> + .name = "ad7818",
> + .max_channels = 1,
> +};
> +
> struct ad7816_state {
> - kernel_ulong_t id;
> + const struct ad7816_chip_info *chip_info;
> struct spi_device *spi_dev;
> struct gpio_desc *rdwr_pin;
> struct gpio_desc *convert_pin;
> @@ -52,12 +72,6 @@ struct ad7816_state {
> u8 mode;
> };
>
> -enum ad7816_type {
> - ID_AD7816,
> - ID_AD7817,
> - ID_AD7818,
> -};
> -
> /*
> * ad7816 data access by SPI
> */
> @@ -84,7 +98,7 @@ static int ad7816_spi_read(struct ad7816_state *chip, u16 *data)
> gpiod_set_value(chip->convert_pin, 1);
> }
>
> - if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
> + if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {
Hmm. I'd be tempted to squash the next patch with this one simply to avoid this
horrible intermediate state where you match on pointers.
It is all part of moving from the enum over to data so I think is
fine in one patch.
> while (gpiod_get_value(chip->busy_pin))
> cpu_relax();
> }
> @@ -353,6 +367,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
> {
> struct ad7816_state *chip;
> struct iio_dev *indio_dev;
> + const struct ad7816_chip_info *info;
> int i, ret;
>
> indio_dev = devm_iio_device_alloc(&spi_dev->dev, sizeof(*chip));
> @@ -362,11 +377,15 @@ static int ad7816_probe(struct spi_device *spi_dev)
> /* this is only used for device removal purposes */
> dev_set_drvdata(&spi_dev->dev, indio_dev);
>
> + info = device_get_match_data(&spi_dev->dev);
> + if (!info)
> + return -ENODEV;
> + chip->chip_info = info;
> +
> chip->spi_dev = spi_dev;
> for (i = 0; i <= AD7816_CS_MAX; i++)
> chip->oti_data[i] = 203;
>
> - chip->id = spi_get_device_id(spi_dev)->driver_data;
> chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_OUT_HIGH);
> if (IS_ERR(chip->rdwr_pin)) {
> ret = PTR_ERR(chip->rdwr_pin);
> @@ -382,7 +401,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
> ret);
> return ret;
> }
> - if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
> + if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {
> chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy",
> GPIOD_IN);
> if (IS_ERR(chip->busy_pin)) {
> @@ -393,7 +412,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
> }
> }
>
> - indio_dev->name = spi_get_device_id(spi_dev)->name;
> + indio_dev->name = chip->chip_info->name;
> indio_dev->info = &ad7816_info;
> indio_dev->modes = INDIO_DIRECT_MODE;
>
> @@ -420,18 +439,18 @@ static int ad7816_probe(struct spi_device *spi_dev)
> }
>
> static const struct of_device_id ad7816_of_match[] = {
> - { .compatible = "adi,ad7816", },
> - { .compatible = "adi,ad7817", },
> - { .compatible = "adi,ad7818", },
> + { .compatible = "adi,ad7816", .data = &ad7816_info_ad7816 },
> + { .compatible = "adi,ad7817", .data = &ad7817_info_ad7817 },
> + { .compatible = "adi,ad7818", .data = &ad7818_info_ad7818 },
> { }
> };
> MODULE_DEVICE_TABLE(of, ad7816_of_match);
>
> static const struct spi_device_id ad7816_id[] = {
> - { "ad7816", ID_AD7816 },
> - { "ad7817", ID_AD7817 },
> - { "ad7818", ID_AD7818 },
> - {}
> + { "ad7816", (kernel_ulong_t)&ad7816_info_ad7816 },
> + { "ad7817", (kernel_ulong_t)&ad7817_info_ad7817 },
> + { "ad7818", (kernel_ulong_t)&ad7818_info_ad7818 },
> + { }
> };
>
> MODULE_DEVICE_TABLE(spi, ad7816_id);
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities
2025-04-20 1:49 ` [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities Gabriel Shahrouzi
@ 2025-04-21 12:35 ` Jonathan Cameron
0 siblings, 0 replies; 12+ messages in thread
From: Jonathan Cameron @ 2025-04-21 12:35 UTC (permalink / raw)
To: Gabriel Shahrouzi
Cc: gregkh, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier, skhan,
linux-kernel-mentees
On Sat, 19 Apr 2025 21:49:09 -0400
Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:
> Move device-specific capability information, like the presence of a
> BUSY pin, into the ad7816_chip_info structure.
>
> Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
> ---
> drivers/staging/iio/adc/ad7816.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
> index 39310ade770d0..ab7520a8a3da9 100644
> --- a/drivers/staging/iio/adc/ad7816.c
> +++ b/drivers/staging/iio/adc/ad7816.c
> @@ -44,21 +44,25 @@
> struct ad7816_chip_info {
> const char *name;
> u8 max_channels;
> + bool has_busy_pin;
> };
>
> static const struct ad7816_chip_info ad7816_info_ad7816 = {
> .name = "ad7816",
> .max_channels = 0,
> + .has_busy_pin = true,
> };
>
> static const struct ad7816_chip_info ad7817_info_ad7817 = {
> .name = "ad7817",
> .max_channels = 3,
> + .has_busy_pin = true,
> };
>
> static const struct ad7816_chip_info ad7818_info_ad7818 = {
> .name = "ad7818",
> .max_channels = 1,
> + .has_busy_pin = false,
> };
>
> struct ad7816_state {
> @@ -98,7 +102,7 @@ static int ad7816_spi_read(struct ad7816_state *chip, u16 *data)
> gpiod_set_value(chip->convert_pin, 1);
> }
>
> - if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {
> + if (chip->chip_info->has_busy_pin) {
There are two places in the previous patch that have this pattern, but only one is
being converted here. Why not replace the one in probe() as well?
> while (gpiod_get_value(chip->busy_pin))
> cpu_relax();
> }
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info
2025-04-20 1:49 ` [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info Gabriel Shahrouzi
@ 2025-04-21 12:37 ` Jonathan Cameron
0 siblings, 0 replies; 12+ messages in thread
From: Jonathan Cameron @ 2025-04-21 12:37 UTC (permalink / raw)
To: Gabriel Shahrouzi
Cc: gregkh, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier, skhan,
linux-kernel-mentees
On Sat, 19 Apr 2025 21:49:10 -0400
Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:
> Refactor the channel validation logic within ad7816_store_channel() to
> leverage the max_channels field previously introduced in the
> ad7816_chip_info structure.
>
> Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
Carries forward the odd mask usage from patch 1. So fix that up and then
I think this is fine. Given you introduce max_channels just for this, ideal
would be to only introduce it in this patch (with a better name - see
earlier comment)
Jonathan
> ---
> drivers/staging/iio/adc/ad7816.c | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
> index ab7520a8a3da9..7a59cfbcc6e33 100644
> --- a/drivers/staging/iio/adc/ad7816.c
> +++ b/drivers/staging/iio/adc/ad7816.c
> @@ -204,17 +204,9 @@ static ssize_t ad7816_store_channel(struct device *dev,
> if (ret)
> return ret;
>
> - if (data > AD7816_CS_MAX && data != AD7816_CS_MASK) {
> + if (data > chip->chip_info->max_channels && data != AD7816_CS_MASK) {
> dev_err(&chip->spi_dev->dev, "Invalid channel id %lu for %s.\n",
> - data, indio_dev->name);
> - return -EINVAL;
> - } else if (strcmp(indio_dev->name, "ad7818") == 0 && data > 1 && data != AD7816_CS_MASK) {
> - dev_err(&chip->spi_dev->dev,
> - "Invalid channel id %lu for ad7818.\n", data);
> - return -EINVAL;
> - } else if (strcmp(indio_dev->name, "ad7816") == 0 && data > 0 && data != AD7816_CS_MASK) {
> - dev_err(&chip->spi_dev->dev,
> - "Invalid channel id %lu for ad7816.\n", data);
> + data, chip->chip_info->name);
> return -EINVAL;
> }
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor
2025-04-21 11:31 ` [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Jonathan Cameron
@ 2025-04-21 13:49 ` Gabriel Shahrouzi
0 siblings, 0 replies; 12+ messages in thread
From: Gabriel Shahrouzi @ 2025-04-21 13:49 UTC (permalink / raw)
To: Jonathan Cameron
Cc: gregkh, lars, linux-iio, linux-kernel, linux-staging,
Michael.Hennerich, sonic.zhang, vapier, skhan,
linux-kernel-mentees
On Mon, Apr 21, 2025 at 7:31 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Sat, 19 Apr 2025 21:49:05 -0400
> Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:
>
> > The original patch combined a functional fix (allowing channel 7) with
> > several refactoring steps (introducing chip_info, renaming structs,
> > improving validation). As requested, these have now been separated.
> >
> > The series proceeds as follows:
> > 1. Fix: Allow diagnostic channel 7 for all device variants.
> > 2. Refactor: Rename the main state structure for clarity before introducing
> > the new chip_info struct.
> > 3. Refactor: Introduce struct ad7816_chip_info to hold static per-variant
> > data, update ID tables to store pointers, and switch to using
> > device_get_match_data() for firmware-independent identification.
> > This removes the old enum/id mechanism.
> > 4. Refactor: Add has_busy_pin to chip_info and use this flag to
> > determine BUSY pin handling, replacing pointer comparisons.
> > 5. Refactor: Simplify channel validation logic using
> > chip_info->max_channels, removing strcmp() checks.
> >
> > Regarding the 'fixes' tag: I've applied it only to the first commit
> > containing the core fix, primarily to make backporting easier. Is this
> > the standard practice, or should the tag typically be applied to
> > subsequent commits that build upon or are related to the fix as well?
> >
> > Changes in v5:
> > - Use correct patch version.
> Generally I wouldn't resend for this. Instead a single email in
> reply to the messed up version saying it is infact v4 would have
> done the job.
Got it.
>
> Alternatively a quick reply to that thread to say it was messed
> up and please look for v5 would have worked to make a reader
> move on directly to the newer version
Got it.
>
>
> Jonathan
>
> > Changes in v4:
> > - Include missing bracket for condtional statement.
> > Chainges in v3:
> > - Split the patch into smaller patches. Make the fix first
> > followed by clean up.
> > - Include missing channel for channel selection.
> > - Address specific feedback regarding enums vs. chip_info data.
> > - Use device_get_match_data() for device identification.
> > - Move BUSY pin capability check into chip_info data.
> > - Simplify channel validation using chip_info data.
> > Changes in v2:
> > - Refactor by adding chip_info struct which simplifies
> > conditional logic.
> >
> > Gabriel Shahrouzi (5):
> > staging: iio: adc: ad7816: Allow channel 7 for all devices
> > staging: iio: adc: ad7816: Rename state structure
> > staging: iio: adc: ad7816: Introduce chip_info and use pointer
> > matching
> > staging: iio: adc: ad7816: Use chip_info for device capabilities
> > staging: iio: adc: ad7816: Simplify channel validation using chip_info
> >
> > drivers/staging/iio/adc/ad7816.c | 94 ++++++++++++++++++--------------
> > 1 file changed, 54 insertions(+), 40 deletions(-)
> >
>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-04-21 13:49 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-20 1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
2025-04-21 12:29 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 2/5] staging: iio: adc: ad7816: Rename state structure Gabriel Shahrouzi
2025-04-20 1:49 ` [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching Gabriel Shahrouzi
2025-04-21 12:34 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities Gabriel Shahrouzi
2025-04-21 12:35 ` Jonathan Cameron
2025-04-20 1:49 ` [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info Gabriel Shahrouzi
2025-04-21 12:37 ` Jonathan Cameron
2025-04-21 11:31 ` [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Jonathan Cameron
2025-04-21 13:49 ` Gabriel Shahrouzi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox