[PATCH v4 00/13] iio: dac: ds4424: add DS4402/DS4404 support and scale

[PATCH v4 00/13] iio: dac: ds4424: add DS4402/DS4404 support and scale

[Oleksij Rempel]

This series extends the ds4424 IIO DAC driver and its devicetree binding
to support the DS4402 and DS4404 current DAC variants.

DS440x devices share the same register map as DS442x but use a different
resolution (5-bit vs 7-bit) and a different full-scale current formula.
The full-scale current depends on external Rfs resistors connected to
the FS pins, so a new optional DT property is added to provide the
per-channel Rfs values and allow the driver to report a correct IIO
SCALE (mA/step).

While adding DS440x support, a few related issues were addressed:
- Port to regmap
- Reject -128 in RAW writes on DS442x, which cannot be represented with
  sign-magnitude encoding and could silently program an unintended
  output.
- Preserve preconfigured values on probe.
- Ratelimit read error logging and use device context.

David Jander (1):
  iio: dac: ds4424: add DS4402/DS4404 device IDs

Oleksij Rempel (12):
  iio: dac: ds4424: reject -128 RAW value
  iio: dac: ds4424: refactor raw access to use bitwise operations
  iio: dac: ds4424: ratelimit read errors and use device context
  iio: dac: ds4424: sort headers alphabetically
  iio: dac: ds4424: rename iio_info struct to avoid ambiguity
  iio: dac: ds4424: use device match data for chip info
  iio: dac: ds4424: use fsleep() instead of usleep_range()
  dt-bindings: iio: dac: maxim,ds4424: add ds4402/ds4404
  iio: dac: ds4424: support per-variant output range limits
  iio: dac: ds4424: convert to regmap
  dt-bindings: iio: dac: maxim,ds4424: add maxim,rfs-ohms property
  iio: dac: ds4424: add Rfs-based scale and per-variant limits

 .../bindings/iio/dac/maxim,ds4424.yaml        |  42 +-
 drivers/iio/dac/Kconfig                       |   1 +
 drivers/iio/dac/ds4424.c                      | 368 ++++++++++++------
 3 files changed, 280 insertions(+), 131 deletions(-)

--
2.47.3

[PATCH v4 01/13] iio: dac: ds4424: reject -128 RAW value

[Oleksij Rempel]

The DS442x DAC uses sign-magnitude encoding, so -128 cannot be represented
in hardware (7-bit magnitude).

Previously, passing -128 resulted in a truncated value that programmed
0mA (magnitude 0) instead of the expected maximum negative current,
effectively failing silently.

Reject -128 to avoid producing the wrong current.

Fixes: d632a2bd8ffc ("iio: dac: ds4422/ds4424 dac driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>

---
changes v4:
- Restore v1 implementation: Keep this patch as a minimal fix suitable
  for stable backports
- Move the refactoring (bitwise operations and GENMASK usage) to a
  separate follow-up patch.
changes v3:
- (Merged into refactoring patch in v3, now split again)
---
 drivers/iio/dac/ds4424.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index a8198ba4f98a..059acca45f64 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -141,7 +141,7 @@ static int ds4424_write_raw(struct iio_dev *indio_dev,
 
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
-		if (val < S8_MIN || val > S8_MAX)
+		if (val <= S8_MIN || val > S8_MAX)
 			return -EINVAL;
 
 		if (val > 0) {
-- 
2.47.3

[PATCH v4 02/13] iio: dac: ds4424: refactor raw access to use bitwise operations

[Oleksij Rempel]

Refactor the raw access logic to use standard GENMASK() and BIT()
macros. Use abs() for magnitude calculation to simplify the logic and
make the data flow clearer.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
changes v4:
- Split patch: The functional fix for -128 was moved to the previous
  patch (1/9) for stable backporting.
- This patch now contains only the refactoring (GENMASK/BIT/abs) on top
  of the fix.
changes v3:
- Remove "Rebase on top of regmap" note as this is now patch 1/8.
- Add #include <linux/bits.h>
- Clarify 0mA sink/source behavior in comments
- Remove redundant blank line in write_raw
changes v2:
- Replace S8_MIN/MAX checks with abs() > DS4424_DAC_MASK to enforce the
  correct [-127, 127] physical range.
- Refactor read_raw/write_raw to use symmetrical bitwise operations,
  removing the custom bitfield union.
- Rebase on top of regmap port
---
 drivers/iio/dac/ds4424.c | 55 +++++++++++++++-------------------------
 1 file changed, 21 insertions(+), 34 deletions(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 059acca45f64..596ff5999271 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2017 Maxim Integrated
  */
 
+#include <linux/bits.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/i2c.h>
@@ -19,9 +20,10 @@
 #define DS4422_MAX_DAC_CHANNELS		2
 #define DS4424_MAX_DAC_CHANNELS		4
 
+#define DS4424_DAC_MASK			GENMASK(6, 0)
+#define DS4424_DAC_SOURCE		BIT(7)
+
 #define DS4424_DAC_ADDR(chan)   ((chan) + 0xf8)
-#define DS4424_SOURCE_I		1
-#define DS4424_SINK_I		0
 
 #define DS4424_CHANNEL(chan) { \
 	.type = IIO_CURRENT, \
@@ -31,22 +33,6 @@
 	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
 }
 
-/*
- * DS4424 DAC control register 8 bits
- * [7]		0: to sink; 1: to source
- * [6:0]	steps to sink/source
- * bit[7] looks like a sign bit, but the value of the register is
- * not a two's complement code considering the bit[6:0] is a absolute
- * distance from the zero point.
- */
-union ds4424_raw_data {
-	struct {
-		u8 dx:7;
-		u8 source_bit:1;
-	};
-	u8 bits;
-};
-
 enum ds4424_device_ids {
 	ID_DS4422,
 	ID_DS4424,
@@ -108,21 +94,21 @@ static int ds4424_read_raw(struct iio_dev *indio_dev,
 			   struct iio_chan_spec const *chan,
 			   int *val, int *val2, long mask)
 {
-	union ds4424_raw_data raw;
-	int ret;
+	int ret, regval;
 
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
-		ret = ds4424_get_value(indio_dev, val, chan->channel);
+		ret = ds4424_get_value(indio_dev, &regval, chan->channel);
 		if (ret < 0) {
 			pr_err("%s : ds4424_get_value returned %d\n",
 							__func__, ret);
 			return ret;
 		}
-		raw.bits = *val;
-		*val = raw.dx;
-		if (raw.source_bit == DS4424_SINK_I)
+
+		*val = regval & DS4424_DAC_MASK;
+		if (!(regval & DS4424_DAC_SOURCE))
 			*val = -*val;
+
 		return IIO_VAL_INT;
 
 	default:
@@ -134,25 +120,26 @@ static int ds4424_write_raw(struct iio_dev *indio_dev,
 			     struct iio_chan_spec const *chan,
 			     int val, int val2, long mask)
 {
-	union ds4424_raw_data raw;
+	unsigned int abs_val;
 
 	if (val2 != 0)
 		return -EINVAL;
 
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
-		if (val <= S8_MIN || val > S8_MAX)
+		abs_val = abs(val);
+		if (abs_val > DS4424_DAC_MASK)
 			return -EINVAL;
 
-		if (val > 0) {
-			raw.source_bit = DS4424_SOURCE_I;
-			raw.dx = val;
-		} else {
-			raw.source_bit = DS4424_SINK_I;
-			raw.dx = -val;
-		}
+		/*
+		 * Currents exiting the IC (Source) are positive. 0 is a valid
+		 * value for no current flow; the direction bit (Source vs Sink)
+		 * is treated as don't-care by the hardware at 0.
+		 */
+		if (val > 0)
+			abs_val |= DS4424_DAC_SOURCE;
 
-		return ds4424_set_value(indio_dev, raw.bits, chan);
+		return ds4424_set_value(indio_dev, abs_val, chan);
 
 	default:
 		return -EINVAL;
-- 
2.47.3

[PATCH v4 03/13] iio: dac: ds4424: ratelimit read errors and use device context

[Oleksij Rempel]

Replace pr_err() with dev_err_ratelimited() in the RAW read path to avoid
log spam on repeated I2C failures and to include the device context.

Use %pe to print errno names for faster debugging. Use the parent
device context to identify the physical hardware causing the error.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
changes v4:
- no changes
changes v3:
- Use indio_dev->dev.parent to reference the physical device.
- Remove redundant space in error message: "channel %d: %pe".
- This patch now precedes regmap refactoring.
changes v2:
- Update error message
- Rebase against regmap refactoring
---
 drivers/iio/dac/ds4424.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 596ff5999271..36286e4923af 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -100,8 +100,9 @@ static int ds4424_read_raw(struct iio_dev *indio_dev,
 	case IIO_CHAN_INFO_RAW:
 		ret = ds4424_get_value(indio_dev, &regval, chan->channel);
 		if (ret < 0) {
-			pr_err("%s : ds4424_get_value returned %d\n",
-							__func__, ret);
+			dev_err_ratelimited(indio_dev->dev.parent,
+					    "Failed to read channel %d: %pe\n",
+					    chan->channel, ERR_PTR(ret));
 			return ret;
 		}
 
-- 
2.47.3

[PATCH v4 04/13] iio: dac: ds4424: sort headers alphabetically

[Oleksij Rempel]

Sort the header inclusions alphabetically. This improves readability and
simplifies adding new includes in the future.

Group subsystem-specific headers (linux/iio/*) separately at the end
to clarify subsystem context.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
changes v4:
- no changes
changes v3:
- Keep linux/iio/* headers in a separate group at the end of the includes.
changes v2:
- new patch
---
 drivers/iio/dac/ds4424.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 36286e4923af..c03051dc763e 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -6,16 +6,17 @@
  */
 
 #include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
-#include <linux/i2c.h>
 #include <linux/regulator/consumer.h>
-#include <linux/err.h>
-#include <linux/delay.h>
-#include <linux/iio/iio.h>
+
+#include <linux/iio/consumer.h>
 #include <linux/iio/driver.h>
+#include <linux/iio/iio.h>
 #include <linux/iio/machine.h>
-#include <linux/iio/consumer.h>
 
 #define DS4422_MAX_DAC_CHANNELS		2
 #define DS4424_MAX_DAC_CHANNELS		4
-- 
2.47.3

[PATCH v4 05/13] iio: dac: ds4424: rename iio_info struct to avoid ambiguity

[Oleksij Rempel]

Rename the static `ds4424_info` structure to `ds4424_iio_info`.

The previous name was generic and could be confused with chip-specific
data structures (like the upcoming `ds4424_chip_info`). The new name
explicitly indicates that this structure holds the IIO framework
callbacks.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
changes v4:
- New patch
---
 drivers/iio/dac/ds4424.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index c03051dc763e..3385f39521d9 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -197,7 +197,7 @@ static int ds4424_resume(struct device *dev)
 
 static DEFINE_SIMPLE_DEV_PM_OPS(ds4424_pm_ops, ds4424_suspend, ds4424_resume);
 
-static const struct iio_info ds4424_info = {
+static const struct iio_info ds4424_iio_info = {
 	.read_raw = ds4424_read_raw,
 	.write_raw = ds4424_write_raw,
 };
@@ -252,7 +252,7 @@ static int ds4424_probe(struct i2c_client *client)
 
 	indio_dev->channels = ds4424_channels;
 	indio_dev->modes = INDIO_DIRECT_MODE;
-	indio_dev->info = &ds4424_info;
+	indio_dev->info = &ds4424_iio_info;
 
 	ret = iio_device_register(indio_dev);
 	if (ret < 0) {
-- 
2.47.3

[PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Oleksij Rempel]

Refactor the driver to use device match data instead of checking ID enums
in a switch statement.

Define a `ds4424_chip_info` structure to hold variant-specific attributes
(currently just the channel count) and attach it directly to the I2C and
OF device ID tables.

Use `client->name` instead of `id->name` to decouple the probe function
from the legacy `i2c_device_id` structure.

This simplifies the probe function and makes it easier to add support for
new variants like DS4402/DS4404.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
changes v4:
- New patch
---
 drivers/iio/dac/ds4424.c | 44 +++++++++++++++++++---------------------
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 3385f39521d9..5709d8a39d7b 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -34,9 +34,16 @@
 	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
 }
 
-enum ds4424_device_ids {
-	ID_DS4422,
-	ID_DS4424,
+struct ds4424_chip_info {
+	u8 num_channels;
+};
+
+static const struct ds4424_chip_info ds4422_info = {
+	.num_channels = DS4422_MAX_DAC_CHANNELS,
+};
+
+static const struct ds4424_chip_info ds4424_info = {
+	.num_channels = DS4424_MAX_DAC_CHANNELS,
 };
 
 struct ds4424_data {
@@ -204,11 +211,15 @@ static const struct iio_info ds4424_iio_info = {
 
 static int ds4424_probe(struct i2c_client *client)
 {
-	const struct i2c_device_id *id = i2c_client_get_device_id(client);
+	const struct ds4424_chip_info *chip_info;
 	struct ds4424_data *data;
 	struct iio_dev *indio_dev;
 	int ret;
 
+	chip_info = i2c_get_match_data(client);
+	if (!chip_info)
+		return -ENODEV;
+
 	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
 	if (!indio_dev)
 		return -ENOMEM;
@@ -216,7 +227,6 @@ static int ds4424_probe(struct i2c_client *client)
 	data = iio_priv(indio_dev);
 	i2c_set_clientdata(client, indio_dev);
 	data->client = client;
-	indio_dev->name = id->name;
 
 	data->vcc_reg = devm_regulator_get(&client->dev, "vcc");
 	if (IS_ERR(data->vcc_reg))
@@ -236,20 +246,8 @@ static int ds4424_probe(struct i2c_client *client)
 	if (ret < 0)
 		goto fail;
 
-	switch (id->driver_data) {
-	case ID_DS4422:
-		indio_dev->num_channels = DS4422_MAX_DAC_CHANNELS;
-		break;
-	case ID_DS4424:
-		indio_dev->num_channels = DS4424_MAX_DAC_CHANNELS;
-		break;
-	default:
-		dev_err(&client->dev,
-				"ds4424: Invalid chip id.\n");
-		ret = -ENXIO;
-		goto fail;
-	}
-
+	indio_dev->name = client->name;
+	indio_dev->num_channels = chip_info->num_channels;
 	indio_dev->channels = ds4424_channels;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	indio_dev->info = &ds4424_iio_info;
@@ -278,16 +276,16 @@ static void ds4424_remove(struct i2c_client *client)
 }
 
 static const struct i2c_device_id ds4424_id[] = {
-	{ "ds4422", ID_DS4422 },
-	{ "ds4424", ID_DS4424 },
+	{ "ds4422", (kernel_ulong_t)&ds4422_info },
+	{ "ds4424", (kernel_ulong_t)&ds4424_info },
 	{ }
 };
 
 MODULE_DEVICE_TABLE(i2c, ds4424_id);
 
 static const struct of_device_id ds4424_of_match[] = {
-	{ .compatible = "maxim,ds4422" },
-	{ .compatible = "maxim,ds4424" },
+	{ .compatible = "maxim,ds4422", .data = &ds4422_info },
+	{ .compatible = "maxim,ds4424", .data = &ds4424_info },
 	{ }
 };
 
-- 
2.47.3

[PATCH v4 07/13] iio: dac: ds4424: use fsleep() instead of usleep_range()

[Oleksij Rempel]

The DS4422/DS4424 and DS4402/DS4404 datasheets do not specify a minimum
delay between power-up (POR) and the availability of the I2C interface.

The driver previously used `usleep_range(1000, 1200)` to enforce a ~1ms
delay. Replace this with `fsleep(1000)` to allow the kernel to select the
most efficient sleep mechanism (usleep or msleep) while retaining the
existing conservative delay to ensure device readiness.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
changes v4:
- New patch
---
 drivers/iio/dac/ds4424.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 5709d8a39d7b..94803885d735 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -241,7 +241,13 @@ static int ds4424_probe(struct i2c_client *client)
 		return ret;
 	}
 
-	usleep_range(1000, 1200);
+	/*
+	 * The datasheet does not specify a power-up to I2C ready time.
+	 * Maintain the existing conservative 1ms delay to ensure the
+	 * device is ready for communication.
+	 */
+	fsleep(1000);
+
 	ret = ds4424_verify_chip(indio_dev);
 	if (ret < 0)
 		goto fail;
-- 
2.47.3

[PATCH v4 08/13] dt-bindings: iio: dac: maxim,ds4424: add ds4402/ds4404

[Oleksij Rempel]

Add compatible strings for Maxim DS4402 and DS4404 current DACs.
These devices are 5-bit variants of the DS4422/DS4424 family.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
changes v3:
- No changes.
changes v2:
  - add Acked-by: Conor ..
---
 .../devicetree/bindings/iio/dac/maxim,ds4424.yaml          | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
index 264fa7c5fe3a..efe63e6cb55d 100644
--- a/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
@@ -4,18 +4,21 @@
 $id: http://devicetree.org/schemas/iio/dac/maxim,ds4424.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Maxim Integrated DS4422/DS4424 7-bit Sink/Source Current DAC
+title: Maxim Integrated DS4402/DS4404 and DS4422/DS4424 Current DACs
 
 maintainers:
   - Ismail Kose <ihkose@gmail.com>
 
 description: |
-  Datasheet publicly available at:
+  Datasheets publicly available at:
+  https://datasheets.maximintegrated.com/en/ds/DS4402-DS4404.pdf
   https://datasheets.maximintegrated.com/en/ds/DS4422-DS4424.pdf
 
 properties:
   compatible:
     enum:
+      - maxim,ds4402
+      - maxim,ds4404
       - maxim,ds4422
       - maxim,ds4424
 
-- 
2.47.3

[PATCH v4 09/13] iio: dac: ds4424: add DS4402/DS4404 device IDs

[Oleksij Rempel]

From: David Jander <david@protonic.nl>

Add I2C/OF IDs for DS4402 and DS4404 and set the correct channel count.
Follow-up changes add per-variant scaling based on external Rfs.

Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: David Jander <david@protonic.nl>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
changes v3:
- Reset author to David Jander and added Co-developed-by tag for
  Oleksij Rempel to clarify roles
changes v2:
  - No changes.
---
 drivers/iio/dac/ds4424.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 94803885d735..31dcf6632b58 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -38,6 +38,14 @@ struct ds4424_chip_info {
 	u8 num_channels;
 };
 
+static const struct ds4424_chip_info ds4402_info = {
+	.num_channels = DS4422_MAX_DAC_CHANNELS,
+};
+
+static const struct ds4424_chip_info ds4404_info = {
+	.num_channels = DS4424_MAX_DAC_CHANNELS,
+};
+
 static const struct ds4424_chip_info ds4422_info = {
 	.num_channels = DS4422_MAX_DAC_CHANNELS,
 };
@@ -282,6 +290,8 @@ static void ds4424_remove(struct i2c_client *client)
 }
 
 static const struct i2c_device_id ds4424_id[] = {
+	{ "ds4402", (kernel_ulong_t)&ds4402_info },
+	{ "ds4404", (kernel_ulong_t)&ds4404_info },
 	{ "ds4422", (kernel_ulong_t)&ds4422_info },
 	{ "ds4424", (kernel_ulong_t)&ds4424_info },
 	{ }
@@ -290,6 +300,8 @@ static const struct i2c_device_id ds4424_id[] = {
 MODULE_DEVICE_TABLE(i2c, ds4424_id);
 
 static const struct of_device_id ds4424_of_match[] = {
+	{ .compatible = "maxim,ds4402", .data = &ds4402_info },
+	{ .compatible = "maxim,ds4404", .data = &ds4404_info },
 	{ .compatible = "maxim,ds4422", .data = &ds4422_info },
 	{ .compatible = "maxim,ds4424", .data = &ds4424_info },
 	{ }
-- 
2.47.3

[PATCH v4 10/13] iio: dac: ds4424: support per-variant output range limits

[Oleksij Rempel]

The DS4402/DS4404 variants operate with a 5-bit resolution (31 steps),
whereas the DS4422/DS4424 support 7-bit (127 steps).

Previously, the driver enforced a hardcoded 7-bit mask (DS4424_DAC_MASK)
for all variants. This allowed users to write values exceeding the 5-bit
range to DS4402/DS4404 devices, resulting in silent truncation or
undefined behavior.

Add a `result_mask` field to the chip_info structure to define the valid
data range for each variant. Use this mask to:
1. Correctly mask register values in read_raw().
2. Return -EINVAL in write_raw() if the input value exceeds the
   variant's capabilities.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
changes v4:
- New patch
- Split from the original patch (v3) to isolate 5-bit vs 7-bit handling.
---
 drivers/iio/dac/ds4424.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 31dcf6632b58..43a622575cb5 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -22,6 +22,7 @@
 #define DS4424_MAX_DAC_CHANNELS		4
 
 #define DS4424_DAC_MASK			GENMASK(6, 0)
+#define DS4404_DAC_MASK			GENMASK(4, 0)
 #define DS4424_DAC_SOURCE		BIT(7)
 
 #define DS4424_DAC_ADDR(chan)   ((chan) + 0xf8)
@@ -35,22 +36,27 @@
 }
 
 struct ds4424_chip_info {
+	u8 result_mask;
 	u8 num_channels;
 };
 
 static const struct ds4424_chip_info ds4402_info = {
+	.result_mask = DS4404_DAC_MASK,
 	.num_channels = DS4422_MAX_DAC_CHANNELS,
 };
 
 static const struct ds4424_chip_info ds4404_info = {
+	.result_mask = DS4404_DAC_MASK,
 	.num_channels = DS4424_MAX_DAC_CHANNELS,
 };
 
 static const struct ds4424_chip_info ds4422_info = {
+	.result_mask = DS4424_DAC_MASK,
 	.num_channels = DS4422_MAX_DAC_CHANNELS,
 };
 
 static const struct ds4424_chip_info ds4424_info = {
+	.result_mask = DS4424_DAC_MASK,
 	.num_channels = DS4424_MAX_DAC_CHANNELS,
 };
 
@@ -60,6 +66,7 @@ struct ds4424_data {
 	uint8_t save[DS4424_MAX_DAC_CHANNELS];
 	struct regulator *vcc_reg;
 	uint8_t raw[DS4424_MAX_DAC_CHANNELS];
+	const struct ds4424_chip_info *chip_info;
 };
 
 static const struct iio_chan_spec ds4424_channels[] = {
@@ -110,6 +117,7 @@ static int ds4424_read_raw(struct iio_dev *indio_dev,
 			   struct iio_chan_spec const *chan,
 			   int *val, int *val2, long mask)
 {
+	struct ds4424_data *data = iio_priv(indio_dev);
 	int ret, regval;
 
 	switch (mask) {
@@ -122,7 +130,7 @@ static int ds4424_read_raw(struct iio_dev *indio_dev,
 			return ret;
 		}
 
-		*val = regval & DS4424_DAC_MASK;
+		*val = regval & data->chip_info->result_mask;
 		if (!(regval & DS4424_DAC_SOURCE))
 			*val = -*val;
 
@@ -137,6 +145,7 @@ static int ds4424_write_raw(struct iio_dev *indio_dev,
 			     struct iio_chan_spec const *chan,
 			     int val, int val2, long mask)
 {
+	struct ds4424_data *data = iio_priv(indio_dev);
 	unsigned int abs_val;
 
 	if (val2 != 0)
@@ -145,7 +154,7 @@ static int ds4424_write_raw(struct iio_dev *indio_dev,
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
 		abs_val = abs(val);
-		if (abs_val > DS4424_DAC_MASK)
+		if (abs_val > data->chip_info->result_mask)
 			return -EINVAL;
 
 		/*
@@ -235,6 +244,7 @@ static int ds4424_probe(struct i2c_client *client)
 	data = iio_priv(indio_dev);
 	i2c_set_clientdata(client, indio_dev);
 	data->client = client;
+	data->chip_info = chip_info;
 
 	data->vcc_reg = devm_regulator_get(&client->dev, "vcc");
 	if (IS_ERR(data->vcc_reg))
-- 
2.47.3

[PATCH v4 11/13] iio: dac: ds4424: convert to regmap

[Oleksij Rempel]

Refactor the driver to use the regmap API.

Replace the driver-specific mutex and manual shadow buffers with the
standard regmap infrastructure for locking and caching.

This ensures the cache is populated from hardware at probe, preventing
state desynchronization (e.g. across suspend/resume).

Define access tables to validate the different register maps of DS44x2
and DS44x4.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Sander Vanheule <sander@svanheule.net>
---
changes v4:
- Split patch: Moved fsleep() conversion to a separate cleanup patch
- Style fix: Add parentheses to function name in comments
- Cleanup: Remove redundant comment in regmap_config
- Fix typo: Change error message to "Failed to read hardware values"
changes v3:
- Switch to REGCACHE_MAPLE to efficiently handle the sparse register map
  (offset 0xF8) and avoid allocating memory for the unused 0x00-0xF7 range.
- Use explicit regmap_bulk_read() in probe to seed the cache with the
  bootloader configuration. This avoids the invalid read from address 0x00
  that occurred with generic cache defaults.
- Remove ds4424_verify_chip(); devm_regmap_init_i2c() and the subsequent
  bulk read implicitly validate the device presence.
- Use regmap_bulk_write() in ds4424_suspend() to efficiently zero all
  channels.
- Adopt fsleep() for delays and include <linux/array_size.h>.
- Use dev_err_ratelimited() with the physical device context in the read
  path (incorporating feedback aimed at v2 patch 8).
changes v2:
- new patch
---
 drivers/iio/dac/Kconfig  |   1 +
 drivers/iio/dac/ds4424.c | 162 +++++++++++++++++++++------------------
 2 files changed, 90 insertions(+), 73 deletions(-)

diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 7cd3caec1262..dbbbc45e8718 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -408,6 +408,7 @@ config DPOT_DAC
 config DS4424
 	tristate "Maxim Integrated DS4422/DS4424 DAC driver"
 	depends on I2C
+	select REGMAP_I2C
 	help
 	  If you say yes here you get support for Maxim chips DS4422, DS4424.
 
diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index 43a622575cb5..d7ccf031b234 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -5,12 +5,14 @@
  * Copyright (C) 2017 Maxim Integrated
  */
 
+#include <linux/array_size.h>
 #include <linux/bits.h>
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/i2c.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
 #include <linux/iio/consumer.h>
@@ -61,11 +63,8 @@ static const struct ds4424_chip_info ds4424_info = {
 };
 
 struct ds4424_data {
-	struct i2c_client *client;
-	struct mutex lock;
-	uint8_t save[DS4424_MAX_DAC_CHANNELS];
+	struct regmap *regmap;
 	struct regulator *vcc_reg;
-	uint8_t raw[DS4424_MAX_DAC_CHANNELS];
 	const struct ds4424_chip_info *chip_info;
 };
 
@@ -76,41 +75,72 @@ static const struct iio_chan_spec ds4424_channels[] = {
 	DS4424_CHANNEL(3),
 };
 
-static int ds4424_get_value(struct iio_dev *indio_dev,
-			     int *val, int channel)
-{
-	struct ds4424_data *data = iio_priv(indio_dev);
-	int ret;
+static const struct regmap_range ds44x2_ranges[] = {
+	regmap_reg_range(DS4424_DAC_ADDR(0), DS4424_DAC_ADDR(1)),
+};
 
-	mutex_lock(&data->lock);
-	ret = i2c_smbus_read_byte_data(data->client, DS4424_DAC_ADDR(channel));
-	if (ret < 0)
-		goto fail;
+static const struct regmap_range ds44x4_ranges[] = {
+	regmap_reg_range(DS4424_DAC_ADDR(0), DS4424_DAC_ADDR(3)),
+};
 
-	*val = ret;
+static const struct regmap_access_table ds44x2_table = {
+	.yes_ranges = ds44x2_ranges,
+	.n_yes_ranges = ARRAY_SIZE(ds44x2_ranges),
+};
 
-fail:
-	mutex_unlock(&data->lock);
-	return ret;
-}
+static const struct regmap_access_table ds44x4_table = {
+	.yes_ranges = ds44x4_ranges,
+	.n_yes_ranges = ARRAY_SIZE(ds44x4_ranges),
+};
 
-static int ds4424_set_value(struct iio_dev *indio_dev,
-			     int val, struct iio_chan_spec const *chan)
+static const struct regmap_config ds44x2_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.cache_type = REGCACHE_MAPLE,
+	.max_register = DS4424_DAC_ADDR(1),
+	.rd_table = &ds44x2_table,
+	.wr_table = &ds44x2_table,
+};
+
+static const struct regmap_config ds44x4_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.cache_type = REGCACHE_MAPLE,
+	.max_register = DS4424_DAC_ADDR(3),
+	.rd_table = &ds44x4_table,
+	.wr_table = &ds44x4_table,
+};
+
+static int ds4424_init_regmap(struct i2c_client *client,
+			      struct iio_dev *indio_dev)
 {
 	struct ds4424_data *data = iio_priv(indio_dev);
+	const struct regmap_config *regmap_config;
+	u8 vals[DS4424_MAX_DAC_CHANNELS];
 	int ret;
 
-	mutex_lock(&data->lock);
-	ret = i2c_smbus_write_byte_data(data->client,
-			DS4424_DAC_ADDR(chan->channel), val);
-	if (ret < 0)
-		goto fail;
+	if (indio_dev->num_channels == DS4424_MAX_DAC_CHANNELS)
+		regmap_config = &ds44x4_regmap_config;
+	else
+		regmap_config = &ds44x2_regmap_config;
 
-	data->raw[chan->channel] = val;
+	data->regmap = devm_regmap_init_i2c(client, regmap_config);
+	if (IS_ERR(data->regmap))
+		return dev_err_probe(&client->dev, PTR_ERR(data->regmap),
+				     "Failed to init regmap.\n");
 
-fail:
-	mutex_unlock(&data->lock);
-	return ret;
+	/*
+	 * Prime the cache with the bootloader's configuration.
+	 * regmap_bulk_read() will automatically populate the cache with
+	 * the values read from the hardware.
+	 */
+	ret = regmap_bulk_read(data->regmap, DS4424_DAC_ADDR(0), vals,
+			       indio_dev->num_channels);
+	if (ret)
+		return dev_err_probe(&client->dev, ret,
+				     "Failed to read hardware values\n");
+
+	return 0;
 }
 
 static int ds4424_read_raw(struct iio_dev *indio_dev,
@@ -118,11 +148,13 @@ static int ds4424_read_raw(struct iio_dev *indio_dev,
 			   int *val, int *val2, long mask)
 {
 	struct ds4424_data *data = iio_priv(indio_dev);
-	int ret, regval;
+	unsigned int regval;
+	int ret;
 
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
-		ret = ds4424_get_value(indio_dev, &regval, chan->channel);
+		ret = regmap_read(data->regmap, DS4424_DAC_ADDR(chan->channel),
+				  &regval);
 		if (ret < 0) {
 			dev_err_ratelimited(indio_dev->dev.parent,
 					    "Failed to read channel %d: %pe\n",
@@ -165,58 +197,44 @@ static int ds4424_write_raw(struct iio_dev *indio_dev,
 		if (val > 0)
 			abs_val |= DS4424_DAC_SOURCE;
 
-		return ds4424_set_value(indio_dev, abs_val, chan);
+		return regmap_write(data->regmap, DS4424_DAC_ADDR(chan->channel),
+				    abs_val);
 
 	default:
 		return -EINVAL;
 	}
 }
 
-static int ds4424_verify_chip(struct iio_dev *indio_dev)
-{
-	int ret, val;
-
-	ret = ds4424_get_value(indio_dev, &val, 0);
-	if (ret < 0)
-		dev_err(&indio_dev->dev,
-				"%s failed. ret: %d\n", __func__, ret);
-
-	return ret;
-}
-
 static int ds4424_suspend(struct device *dev)
 {
-	struct i2c_client *client = to_i2c_client(dev);
-	struct iio_dev *indio_dev = i2c_get_clientdata(client);
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
 	struct ds4424_data *data = iio_priv(indio_dev);
-	int ret = 0;
-	int i;
-
-	for (i = 0; i < indio_dev->num_channels; i++) {
-		data->save[i] = data->raw[i];
-		ret = ds4424_set_value(indio_dev, 0,
-				&indio_dev->channels[i]);
-		if (ret < 0)
-			return ret;
+	u8 zero_buf[DS4424_MAX_DAC_CHANNELS] = { 0 };
+	int ret;
+
+	/* Disable all outputs, bypass cache so the '0' isn't saved */
+	regcache_cache_bypass(data->regmap, true);
+	ret = regmap_bulk_write(data->regmap, DS4424_DAC_ADDR(0),
+				zero_buf, indio_dev->num_channels);
+	regcache_cache_bypass(data->regmap, false);
+	if (ret) {
+		dev_err(dev, "Failed to zero outputs: %pe\n", ERR_PTR(ret));
+		return ret;
 	}
-	return ret;
+
+	regcache_cache_only(data->regmap, true);
+	regcache_mark_dirty(data->regmap);
+
+	return 0;
 }
 
 static int ds4424_resume(struct device *dev)
 {
-	struct i2c_client *client = to_i2c_client(dev);
-	struct iio_dev *indio_dev = i2c_get_clientdata(client);
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
 	struct ds4424_data *data = iio_priv(indio_dev);
-	int ret = 0;
-	int i;
 
-	for (i = 0; i < indio_dev->num_channels; i++) {
-		ret = ds4424_set_value(indio_dev, data->save[i],
-				&indio_dev->channels[i]);
-		if (ret < 0)
-			return ret;
-	}
-	return ret;
+	regcache_cache_only(data->regmap, false);
+	return regcache_sync(data->regmap);
 }
 
 static DEFINE_SIMPLE_DEV_PM_OPS(ds4424_pm_ops, ds4424_suspend, ds4424_resume);
@@ -243,7 +261,6 @@ static int ds4424_probe(struct i2c_client *client)
 
 	data = iio_priv(indio_dev);
 	i2c_set_clientdata(client, indio_dev);
-	data->client = client;
 	data->chip_info = chip_info;
 
 	data->vcc_reg = devm_regulator_get(&client->dev, "vcc");
@@ -251,7 +268,6 @@ static int ds4424_probe(struct i2c_client *client)
 		return dev_err_probe(&client->dev, PTR_ERR(data->vcc_reg),
 				     "Failed to get vcc-supply regulator.\n");
 
-	mutex_init(&data->lock);
 	ret = regulator_enable(data->vcc_reg);
 	if (ret < 0) {
 		dev_err(&client->dev,
@@ -266,16 +282,16 @@ static int ds4424_probe(struct i2c_client *client)
 	 */
 	fsleep(1000);
 
-	ret = ds4424_verify_chip(indio_dev);
-	if (ret < 0)
-		goto fail;
-
 	indio_dev->name = client->name;
 	indio_dev->num_channels = chip_info->num_channels;
 	indio_dev->channels = ds4424_channels;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	indio_dev->info = &ds4424_iio_info;
 
+	ret = ds4424_init_regmap(client, indio_dev);
+	if (ret)
+		goto fail;
+
 	ret = iio_device_register(indio_dev);
 	if (ret < 0) {
 		dev_err(&client->dev,
-- 
2.47.3

[PATCH v4 12/13] dt-bindings: iio: dac: maxim,ds4424: add maxim,rfs-ohms property

[Oleksij Rempel]

The Maxim DS4422/DS4424 and DS4402/DS4404 current DACs determine their
full-scale output current via external resistors (Rfs) connected to the
FSx pins. Without knowing these values, the full-scale range of the
hardware is undefined.

Add the 'maxim,rfs-ohms' property to describe these physical components.
This property is required to provide a complete description of the
hardware configuration.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
changes v3:
- Moved minItems and maxItems to the main property definition
- Refined property description to state that values depend on chip
  variant and hardware requirements, deliberately avoiding specific
  "typical" ranges to prevent unnecessary hard-limit enforcement.
- Corrected the rfs-ohms example to use a plausible value within
  datasheet typical range.
- Removed redundant constraint definitions from the allOf logic.
changes v2:
- make maxim,rfs-ohms a required property as the hardware range is undefined
  without external resistors.
- add allOf constraints to enforce 2 vs 4 items in maxim,rfs-ohms based on
  compatible string.
- drop explicit $ref for maxim,rfs-ohms to fix dt_binding_check warning.
- update example in binding to include the new required property.
---
 .../bindings/iio/dac/maxim,ds4424.yaml        | 35 +++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
index efe63e6cb55d..4323df2036ac 100644
--- a/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
@@ -27,9 +27,43 @@ properties:
 
   vcc-supply: true
 
+  maxim,rfs-ohms:
+    description: |
+      Array of resistance values in Ohms for the external Rfs resistors
+      connected to the FS pins. These values determine the full-scale
+      output current. The actual resistance depends on the chip variant
+      and specific hardware design requirements.
+    minItems: 2
+    maxItems: 4
+
 required:
   - compatible
   - reg
+  - maxim,rfs-ohms
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - maxim,ds4402
+              - maxim,ds4422
+    then:
+      properties:
+        maxim,rfs-ohms:
+          maxItems: 2
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - maxim,ds4404
+              - maxim,ds4424
+    then:
+      properties:
+        maxim,rfs-ohms:
+          minItems: 4
 
 additionalProperties: false
 
@@ -43,6 +77,7 @@ examples:
             compatible = "maxim,ds4424";
             reg = <0x10>; /* When A0, A1 pins are ground */
             vcc-supply = <&vcc_3v3>;
+            maxim,rfs-ohms = <40000>, <40000>, <40000>, <40000>;
         };
     };
 ...
-- 
2.47.3

[PATCH v4 13/13] iio: dac: ds4424: add Rfs-based scale and per-variant limits

[Oleksij Rempel]

Parse optional maxim,rfs-ohms values to derive the per-channel output
current scale (mA per step) for the IIO current ABI.

Behavior changes:
- If maxim,rfs-ohms is present, IIO_CHAN_INFO_SCALE becomes available
  and reports mA/step derived from Rfs.
- If maxim,rfs-ohms is missing, SCALE is not exposed to keep older DTs
  working without requiring updates.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
changes v4:
- Split series: moved infrastructure and RAW limit fixes to a preceding patch.
- Replaced dynamic channel allocation (devm_kmemdup_array()) with static
  const arrays (ds4424_channels_with_scale) to handle the two states.
- Removed log message when maxim,rfs-ohms is missing.
changes v3:
- Added explicit check for negative return from device_property_count_u32().
- Rename vref_mv to vref_mV
- Use devm_kmemdup_array() instead of devm_kmemdup()
- Use %u for unsigned index in Rfs error logs.
- Consolidated Rfs parse logs to a single line.
changes v2:
- Reorder struct ds4424_chip_info members to optimize padding.
- Use GENMASK() for chip variant masks instead of hex constants.
- Simplify ds4424_setup_channels: use direct devm_kmemdup to avoid stack
  usage and memcpy.
- Use local 'dev' pointer and dev_err_probe() in ds4424_parse_rfs for
  cleaner error handling.
- Rename the static iio_info struct to ds4424_iio_info to prevent name
  collision with the new hardware chip_info structs.
- Use unsigned int for loop counters.
- Rebase on top of regmap and symmetrical raw_access refactoring.
---
 drivers/iio/dac/ds4424.c | 81 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index d7ccf031b234..e34a8c3fba87 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -12,6 +12,7 @@
 #include <linux/i2c.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/property.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
@@ -37,27 +38,46 @@
 	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
 }
 
+#define DS4424_CHANNEL_WITH_SCALE(chan) { \
+	.type = IIO_CURRENT, \
+	.indexed = 1, \
+	.output = 1, \
+	.channel = chan, \
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+			      BIT(IIO_CHAN_INFO_SCALE), \
+}
+
 struct ds4424_chip_info {
+	int vref_mV;
+	int scale_denom;
 	u8 result_mask;
 	u8 num_channels;
 };
 
 static const struct ds4424_chip_info ds4402_info = {
+	.vref_mV = 1230,
+	.scale_denom = 4,
 	.result_mask = DS4404_DAC_MASK,
 	.num_channels = DS4422_MAX_DAC_CHANNELS,
 };
 
 static const struct ds4424_chip_info ds4404_info = {
+	.vref_mV = 1230,
+	.scale_denom = 4,
 	.result_mask = DS4404_DAC_MASK,
 	.num_channels = DS4424_MAX_DAC_CHANNELS,
 };
 
 static const struct ds4424_chip_info ds4422_info = {
+	.vref_mV = 976,
+	.scale_denom = 16,
 	.result_mask = DS4424_DAC_MASK,
 	.num_channels = DS4422_MAX_DAC_CHANNELS,
 };
 
 static const struct ds4424_chip_info ds4424_info = {
+	.vref_mV = 976,
+	.scale_denom = 16,
 	.result_mask = DS4424_DAC_MASK,
 	.num_channels = DS4424_MAX_DAC_CHANNELS,
 };
@@ -66,6 +86,8 @@ struct ds4424_data {
 	struct regmap *regmap;
 	struct regulator *vcc_reg;
 	const struct ds4424_chip_info *chip_info;
+	u32 rfs_ohms[DS4424_MAX_DAC_CHANNELS];
+	bool has_rfs;
 };
 
 static const struct iio_chan_spec ds4424_channels[] = {
@@ -75,6 +97,13 @@ static const struct iio_chan_spec ds4424_channels[] = {
 	DS4424_CHANNEL(3),
 };
 
+static const struct iio_chan_spec ds4424_channels_with_scale[] = {
+	DS4424_CHANNEL_WITH_SCALE(0),
+	DS4424_CHANNEL_WITH_SCALE(1),
+	DS4424_CHANNEL_WITH_SCALE(2),
+	DS4424_CHANNEL_WITH_SCALE(3),
+};
+
 static const struct regmap_range ds44x2_ranges[] = {
 	regmap_reg_range(DS4424_DAC_ADDR(0), DS4424_DAC_ADDR(1)),
 };
@@ -167,6 +196,15 @@ static int ds4424_read_raw(struct iio_dev *indio_dev,
 			*val = -*val;
 
 		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		if (!data->has_rfs)
+			return -EINVAL;
+
+		/* SCALE is mA/step: mV / Ohm = mA. */
+		*val = data->chip_info->vref_mV;
+		*val2 = data->rfs_ohms[chan->channel] *
+			data->chip_info->scale_denom;
+		return IIO_VAL_FRACTIONAL;
 
 	default:
 		return -EINVAL;
@@ -205,6 +243,39 @@ static int ds4424_write_raw(struct iio_dev *indio_dev,
 	}
 }
 
+static int ds4424_parse_rfs(struct i2c_client *client,
+			    struct ds4424_data *data,
+			    struct iio_dev *indio_dev)
+{
+	struct device *dev = &client->dev;
+	int count, ret;
+
+	if (!device_property_present(dev, "maxim,rfs-ohms"))
+		return 0;
+
+	count = device_property_count_u32(dev, "maxim,rfs-ohms");
+	if (count < 0)
+		return dev_err_probe(dev, count, "Failed to count maxim,rfs-ohms entries\n");
+	if (count != indio_dev->num_channels)
+		return dev_err_probe(dev, -EINVAL, "maxim,rfs-ohms must have %u entries\n",
+				     indio_dev->num_channels);
+
+	ret = device_property_read_u32_array(dev, "maxim,rfs-ohms",
+					     data->rfs_ohms,
+					     indio_dev->num_channels);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to read maxim,rfs-ohms property\n");
+
+	for (unsigned int i = 0; i < indio_dev->num_channels; i++) {
+		if (!data->rfs_ohms[i])
+			return dev_err_probe(dev, -EINVAL, "maxim,rfs-ohms entry %u is zero\n", i);
+	}
+
+	data->has_rfs = true;
+
+	return 0;
+}
+
 static int ds4424_suspend(struct device *dev)
 {
 	struct iio_dev *indio_dev = dev_get_drvdata(dev);
@@ -284,7 +355,6 @@ static int ds4424_probe(struct i2c_client *client)
 
 	indio_dev->name = client->name;
 	indio_dev->num_channels = chip_info->num_channels;
-	indio_dev->channels = ds4424_channels;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	indio_dev->info = &ds4424_iio_info;
 
@@ -292,6 +362,15 @@ static int ds4424_probe(struct i2c_client *client)
 	if (ret)
 		goto fail;
 
+	ret = ds4424_parse_rfs(client, data, indio_dev);
+	if (ret)
+		goto fail;
+
+	if (data->has_rfs)
+		indio_dev->channels = ds4424_channels_with_scale;
+	else
+		indio_dev->channels = ds4424_channels;
+
 	ret = iio_device_register(indio_dev);
 	if (ret < 0) {
 		dev_err(&client->dev,
-- 
2.47.3

Re: [PATCH v4 01/13] iio: dac: ds4424: reject -128 RAW value

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 10:34:21AM +0100, Oleksij Rempel wrote:
> The DS442x DAC uses sign-magnitude encoding, so -128 cannot be represented
> in hardware (7-bit magnitude).
> 
> Previously, passing -128 resulted in a truncated value that programmed
> 0mA (magnitude 0) instead of the expected maximum negative current,
> effectively failing silently.
> 
> Reject -128 to avoid producing the wrong current.

...

>  	case IIO_CHAN_INFO_RAW:
> -		if (val < S8_MIN || val > S8_MAX)
> +		if (val <= S8_MIN || val > S8_MAX)
>  			return -EINVAL;

I still consider using -127, 127 is better than type _MIN/_MAX.
This is all due to '='.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 05/13] iio: dac: ds4424: rename iio_info struct to avoid ambiguity

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 10:34:25AM +0100, Oleksij Rempel wrote:
> Rename the static `ds4424_info` structure to `ds4424_iio_info`.
> 
> The previous name was generic and could be confused with chip-specific
> data structures (like the upcoming `ds4424_chip_info`). The new name
> explicitly indicates that this structure holds the IIO framework
> callbacks.

OK,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 10:34:26AM +0100, Oleksij Rempel wrote:
> Refactor the driver to use device match data instead of checking ID enums
> in a switch statement.
> 
> Define a `ds4424_chip_info` structure to hold variant-specific attributes
> (currently just the channel count) and attach it directly to the I2C and
> OF device ID tables.
> 
> Use `client->name` instead of `id->name` to decouple the probe function
> from the legacy `i2c_device_id` structure.
> 
> This simplifies the probe function and makes it easier to add support for
> new variants like DS4402/DS4404.

...

> -	indio_dev->name = id->name;

> +	indio_dev->name = client->name;

Isn't this an ABI breakage?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Oleksij Rempel]

On Tue, Feb 03, 2026 at 12:03:23PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 03, 2026 at 10:34:26AM +0100, Oleksij Rempel wrote:
> > Refactor the driver to use device match data instead of checking ID enums
> > in a switch statement.
> > 
> > Define a `ds4424_chip_info` structure to hold variant-specific attributes
> > (currently just the channel count) and attach it directly to the I2C and
> > OF device ID tables.
> > 
> > Use `client->name` instead of `id->name` to decouple the probe function
> > from the legacy `i2c_device_id` structure.
> > 
> > This simplifies the probe function and makes it easier to add support for
> > new variants like DS4402/DS4404.
> 
> ...
> 
> > -	indio_dev->name = id->name;
> 
> > +	indio_dev->name = client->name;
> 
> Isn't this an ABI breakage?

I can't confirm it.

before all patches:
root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
ds4424

after:
root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
ds4424



-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 01/13] iio: dac: ds4424: reject -128 RAW value

[Oleksij Rempel]

On Tue, Feb 03, 2026 at 11:54:35AM +0200, Andy Shevchenko wrote:
> On Tue, Feb 03, 2026 at 10:34:21AM +0100, Oleksij Rempel wrote:
> > The DS442x DAC uses sign-magnitude encoding, so -128 cannot be represented
> > in hardware (7-bit magnitude).
> > 
> > Previously, passing -128 resulted in a truncated value that programmed
> > 0mA (magnitude 0) instead of the expected maximum negative current,
> > effectively failing silently.
> > 
> > Reject -128 to avoid producing the wrong current.
> 
> ...
> 
> >  	case IIO_CHAN_INFO_RAW:
> > -		if (val < S8_MIN || val > S8_MAX)
> > +		if (val <= S8_MIN || val > S8_MAX)
> >  			return -EINVAL;
> 
> I still consider using -127, 127 is better than type _MIN/_MAX.
> This is all due to '='.

The use of S8_MIN here is intentional to satisfy the requirement for a minimal
stable backport, as requested by Jonathan:
https://lore.kernel.org/all/20260201144226.218a43cb@jic23-huawei/

This patch: Strict "Fix only" for stable. Uses minimal logic changes (<=
S8_MIN) to avoid introducing new bugs during backporting.

N++ patch: Full refactoring.

Can we accept this temporary state to facilitate the stable process?

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 07/13] iio: dac: ds4424: use fsleep() instead of usleep_range()

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 10:34:27AM +0100, Oleksij Rempel wrote:
> The DS4422/DS4424 and DS4402/DS4404 datasheets do not specify a minimum
> delay between power-up (POR) and the availability of the I2C interface.
> 
> The driver previously used `usleep_range(1000, 1200)` to enforce a ~1ms
> delay. Replace this with `fsleep(1000)` to allow the kernel to select the

> most efficient sleep mechanism (usleep or msleep) while retaining the

Information in the parentheses is not needed and may be confusing in the future
if kernel gets some Xsleep on top of the given list (which by the fact misses
udelay).

> existing conservative delay to ensure device readiness.

There is a couple of nit-picks, otherwise LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

> +	/*
> +	 * The datasheet does not specify a power-up to I2C ready time.
> +	 * Maintain the existing conservative 1ms delay to ensure the
> +	 * device is ready for communication.
> +	 */
> +	fsleep(1000);

Perhaps use 1 * USEC_PER_MSEC as an argument?


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 10/13] iio: dac: ds4424: support per-variant output range limits

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 10:34:30AM +0100, Oleksij Rempel wrote:
> The DS4402/DS4404 variants operate with a 5-bit resolution (31 steps),
> whereas the DS4422/DS4424 support 7-bit (127 steps).
> 
> Previously, the driver enforced a hardcoded 7-bit mask (DS4424_DAC_MASK)
> for all variants. This allowed users to write values exceeding the 5-bit
> range to DS4402/DS4404 devices, resulting in silent truncation or
> undefined behavior.
> 
> Add a `result_mask` field to the chip_info structure to define the valid
> data range for each variant. Use this mask to:
> 1. Correctly mask register values in read_raw().
> 2. Return -EINVAL in write_raw() if the input value exceeds the
>    variant's capabilities.

Makes sense.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 11:17:42AM +0100, Oleksij Rempel wrote:
> On Tue, Feb 03, 2026 at 12:03:23PM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 03, 2026 at 10:34:26AM +0100, Oleksij Rempel wrote:

...

> > > -	indio_dev->name = id->name;
> > 
> > > +	indio_dev->name = client->name;
> > 
> > Isn't this an ABI breakage?
> 
> I can't confirm it.
> 
> before all patches:
> root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> ds4424
> 
> after:
> root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> ds4424

In ACPI case it might look differently, but I have no means to test this.

id->name comes strictly from an i2c table, while client->name is constructed
using specifics of the firmware enumeration. In DT due to some (historical?)
reasons the client->name has no vendor substring and hence matches 1:1 to
id->name. In ACPI, IIRC, the client->name is ACPI device instance name,
something like ABCD0123:00.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/13] iio: dac: ds4424: reject -128 RAW value

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 11:28:45AM +0100, Oleksij Rempel wrote:
> On Tue, Feb 03, 2026 at 11:54:35AM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 03, 2026 at 10:34:21AM +0100, Oleksij Rempel wrote:

...

> > >  	case IIO_CHAN_INFO_RAW:
> > > -		if (val < S8_MIN || val > S8_MAX)
> > > +		if (val <= S8_MIN || val > S8_MAX)
> > >  			return -EINVAL;
> > 
> > I still consider using -127, 127 is better than type _MIN/_MAX.
> > This is all due to '='.
> 
> The use of S8_MIN here is intentional to satisfy the requirement for a minimal
> stable backport, as requested by Jonathan:
> https://lore.kernel.org/all/20260201144226.218a43cb@jic23-huawei/
> 
> This patch: Strict "Fix only" for stable. Uses minimal logic changes (<=
> S8_MIN) to avoid introducing new bugs during backporting.
> 
> N++ patch: Full refactoring.
> 
> Can we accept this temporary state to facilitate the stable process?

Ah, if it's request by the maintainer, I can't and won't overrule it.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 11/13] iio: dac: ds4424: convert to regmap

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 10:34:31AM +0100, Oleksij Rempel wrote:
> Refactor the driver to use the regmap API.
> 
> Replace the driver-specific mutex and manual shadow buffers with the
> standard regmap infrastructure for locking and caching.
> 
> This ensures the cache is populated from hardware at probe, preventing
> state desynchronization (e.g. across suspend/resume).
> 
> Define access tables to validate the different register maps of DS44x2
> and DS44x4.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

...

> +#include <linux/array_size.h>
>  #include <linux/bits.h>
>  #include <linux/delay.h>
>  #include <linux/err.h>
>  #include <linux/i2c.h>

>  #include <linux/kernel.h>

Side note: I expect at some point see this inclusion to be gone.

>  #include <linux/module.h>
> +#include <linux/regmap.h>
>  #include <linux/regulator/consumer.h>

+ types.h // exempli gratia, u8 vals[] in the code

...

> +	u8 zero_buf[DS4424_MAX_DAC_CHANNELS] = { 0 };

'0' is not needed.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Oleksij Rempel]

On Tue, Feb 03, 2026 at 01:51:23PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 03, 2026 at 11:17:42AM +0100, Oleksij Rempel wrote:
> > On Tue, Feb 03, 2026 at 12:03:23PM +0200, Andy Shevchenko wrote:
> > > On Tue, Feb 03, 2026 at 10:34:26AM +0100, Oleksij Rempel wrote:
> 
> ...
> 
> > > > -	indio_dev->name = id->name;
> > > 
> > > > +	indio_dev->name = client->name;
> > > 
> > > Isn't this an ABI breakage?
> > 
> > I can't confirm it.
> > 
> > before all patches:
> > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > ds4424
> > 
> > after:
> > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > ds4424
> 
> In ACPI case it might look differently, but I have no means to test this.
> 
> id->name comes strictly from an i2c table, while client->name is constructed
> using specifics of the firmware enumeration. In DT due to some (historical?)
> reasons the client->name has no vendor substring and hence matches 1:1 to
> id->name. In ACPI, IIRC, the client->name is ACPI device instance name,
> something like ABCD0123:00.

Ok, I see. Should I revert this line?

Thank you,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Andy Shevchenko]

On Tue, Feb 03, 2026 at 01:00:02PM +0100, Oleksij Rempel wrote:
> On Tue, Feb 03, 2026 at 01:51:23PM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 03, 2026 at 11:17:42AM +0100, Oleksij Rempel wrote:
> > > On Tue, Feb 03, 2026 at 12:03:23PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Feb 03, 2026 at 10:34:26AM +0100, Oleksij Rempel wrote:

...

> > > > > -	indio_dev->name = id->name;
> > > > 
> > > > > +	indio_dev->name = client->name;
> > > > 
> > > > Isn't this an ABI breakage?
> > > 
> > > I can't confirm it.
> > > 
> > > before all patches:
> > > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > > ds4424
> > > 
> > > after:
> > > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > > ds4424
> > 
> > In ACPI case it might look differently, but I have no means to test this.
> > 
> > id->name comes strictly from an i2c table, while client->name is constructed
> > using specifics of the firmware enumeration. In DT due to some (historical?)
> > reasons the client->name has no vendor substring and hence matches 1:1 to
> > id->name. In ACPI, IIRC, the client->name is ACPI device instance name,
> > something like ABCD0123:00.
> 
> Ok, I see. Should I revert this line?

Just do not introduce that change (change of the ->name field) in the original
patch, in that case no revert churn would be needed.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/13] iio: dac: ds4424: reject -128 RAW value

[Jonathan Cameron]

On Tue, 3 Feb 2026 13:52:59 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Tue, Feb 03, 2026 at 11:28:45AM +0100, Oleksij Rempel wrote:
> > On Tue, Feb 03, 2026 at 11:54:35AM +0200, Andy Shevchenko wrote:  
> > > On Tue, Feb 03, 2026 at 10:34:21AM +0100, Oleksij Rempel wrote:  
> 
> ...
> 
> > > >  	case IIO_CHAN_INFO_RAW:
> > > > -		if (val < S8_MIN || val > S8_MAX)
> > > > +		if (val <= S8_MIN || val > S8_MAX)
> > > >  			return -EINVAL;  
> > > 
> > > I still consider using -127, 127 is better than type _MIN/_MAX.
> > > This is all due to '='.  
> > 
> > The use of S8_MIN here is intentional to satisfy the requirement for a minimal
> > stable backport, as requested by Jonathan:
> > https://lore.kernel.org/all/20260201144226.218a43cb@jic23-huawei/
> > 
> > This patch: Strict "Fix only" for stable. Uses minimal logic changes (<=
> > S8_MIN) to avoid introducing new bugs during backporting.
> > 
> > N++ patch: Full refactoring.
> > 
> > Can we accept this temporary state to facilitate the stable process?  
> 
> Ah, if it's request by the maintainer, I can't and won't overrule it.

FWIW I didn't really feel strongly about the -127 vs <= S8_MIN
was more after a trivial backportable fix.  

Meh, it's temporary state for upstream (if not stable). Let's not worry about it.

Thanks

Jonathan

> 

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Jonathan Cameron]

On Tue, 3 Feb 2026 16:56:00 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Tue, Feb 03, 2026 at 01:00:02PM +0100, Oleksij Rempel wrote:
> > On Tue, Feb 03, 2026 at 01:51:23PM +0200, Andy Shevchenko wrote:  
> > > On Tue, Feb 03, 2026 at 11:17:42AM +0100, Oleksij Rempel wrote:  
> > > > On Tue, Feb 03, 2026 at 12:03:23PM +0200, Andy Shevchenko wrote:  
> > > > > On Tue, Feb 03, 2026 at 10:34:26AM +0100, Oleksij Rempel wrote:  
> 
> ...
> 
> > > > > > -	indio_dev->name = id->name;  
> > > > >   
> > > > > > +	indio_dev->name = client->name;  
> > > > > 
> > > > > Isn't this an ABI breakage?  
> > > > 
> > > > I can't confirm it.
> > > > 
> > > > before all patches:
> > > > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > > > ds4424
> > > > 
> > > > after:
> > > > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > > > ds4424  
> > > 
> > > In ACPI case it might look differently, but I have no means to test this.
> > > 
> > > id->name comes strictly from an i2c table, while client->name is constructed
> > > using specifics of the firmware enumeration. In DT due to some (historical?)
> > > reasons the client->name has no vendor substring and hence matches 1:1 to
> > > id->name. In ACPI, IIRC, the client->name is ACPI device instance name,
> > > something like ABCD0123:00.  
> > 
> > Ok, I see. Should I revert this line?  
> 
> Just do not introduce that change (change of the ->name field) in the original
> patch, in that case no revert churn would be needed.
> 
I think this got dealt with in discussion of next version but
safest route is just have an extra copy of the name in the
chip_info structure.  Then we know it's stable against different
firmware types etc.

The few places we have client->name are all ancient bugs that
are really hard to fix years later without risk :(

Jonathan

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Oleksij Rempel]

On Thu, Feb 05, 2026 at 08:43:25PM +0000, Jonathan Cameron wrote:
> On Tue, 3 Feb 2026 16:56:00 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
> > On Tue, Feb 03, 2026 at 01:00:02PM +0100, Oleksij Rempel wrote:
> > > On Tue, Feb 03, 2026 at 01:51:23PM +0200, Andy Shevchenko wrote:  
> > > > On Tue, Feb 03, 2026 at 11:17:42AM +0100, Oleksij Rempel wrote:  
> > > > > On Tue, Feb 03, 2026 at 12:03:23PM +0200, Andy Shevchenko wrote:  
> > > > > > On Tue, Feb 03, 2026 at 10:34:26AM +0100, Oleksij Rempel wrote:  
> > 
> > ...
> > 
> > > > > > > -	indio_dev->name = id->name;  
> > > > > >   
> > > > > > > +	indio_dev->name = client->name;  
> > > > > > 
> > > > > > Isn't this an ABI breakage?  
> > > > > 
> > > > > I can't confirm it.
> > > > > 
> > > > > before all patches:
> > > > > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > > > > ds4424
> > > > > 
> > > > > after:
> > > > > root@DistroKit:~ cat /sys/bus/iio/devices/iio:device3/name 
> > > > > ds4424  
> > > > 
> > > > In ACPI case it might look differently, but I have no means to test this.
> > > > 
> > > > id->name comes strictly from an i2c table, while client->name is constructed
> > > > using specifics of the firmware enumeration. In DT due to some (historical?)
> > > > reasons the client->name has no vendor substring and hence matches 1:1 to
> > > > id->name. In ACPI, IIRC, the client->name is ACPI device instance name,
> > > > something like ABCD0123:00.  
> > > 
> > > Ok, I see. Should I revert this line?  
> > 
> > Just do not introduce that change (change of the ->name field) in the original
> > patch, in that case no revert churn would be needed.
> > 
> I think this got dealt with in discussion of next version but
> safest route is just have an extra copy of the name in the
> chip_info structure.  Then we know it's stable against different
> firmware types etc.

Something like this?

diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index ccf36d3e0443..ffa65b22a1fd 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -50,6 +50,7 @@
 }
 
 struct ds4424_chip_info {
+	const char *name;
 	int vref_mV;
 	int scale_denom;
 	u8 result_mask;
@@ -57,6 +58,7 @@ struct ds4424_chip_info {
 };
 
 static const struct ds4424_chip_info ds4402_info = {
+	.name = "ds4402",
 	.vref_mV = 1230,
 	.scale_denom = 4,
 	.result_mask = DS4404_DAC_MASK,
@@ -64,6 +66,7 @@ static const struct ds4424_chip_info ds4402_info = {
 };
 
 static const struct ds4424_chip_info ds4404_info = {
+	.name = "ds4404",
 	.vref_mV = 1230,
 	.scale_denom = 4,
 	.result_mask = DS4404_DAC_MASK,
@@ -71,6 +74,7 @@ static const struct ds4424_chip_info ds4404_info = {
 };
 
 static const struct ds4424_chip_info ds4422_info = {
+	.name = "ds4422",
 	.vref_mV = 976,
 	.scale_denom = 16,
 	.result_mask = DS4424_DAC_MASK,
@@ -78,6 +82,7 @@ static const struct ds4424_chip_info ds4422_info = {
 };
 
 static const struct ds4424_chip_info ds4424_info = {
+	.name = "ds4424",
 	.vref_mV = 976,
 	.scale_denom = 16,
 	.result_mask = DS4424_DAC_MASK,
@@ -335,7 +340,7 @@ static int ds4424_probe(struct i2c_client *client)
 
 	data = iio_priv(indio_dev);
 	i2c_set_clientdata(client, indio_dev);
-	indio_dev->name = id->name;
+	indio_dev->name = chip_info->name;
 	data->chip_info = chip_info;
 
 	data->vcc_reg = devm_regulator_get(&client->dev, "vcc");


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Andy Shevchenko]

On Fri, Feb 06, 2026 at 08:57:07AM +0100, Oleksij Rempel wrote:
> On Thu, Feb 05, 2026 at 08:43:25PM +0000, Jonathan Cameron wrote:
> > On Tue, 3 Feb 2026 16:56:00 +0200
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

...

> > > Just do not introduce that change (change of the ->name field) in the original
> > > patch, in that case no revert churn would be needed.
> > > 
> > I think this got dealt with in discussion of next version but
> > safest route is just have an extra copy of the name in the
> > chip_info structure.  Then we know it's stable against different
> > firmware types etc.
> 
> Something like this?

Yes, but make it in the patch that introduces DT support.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Oleksij Rempel]

Hi Andy,

On Fri, Feb 06, 2026 at 11:59:50AM +0200, Andy Shevchenko wrote:
> On Fri, Feb 06, 2026 at 08:57:07AM +0100, Oleksij Rempel wrote:
> > On Thu, Feb 05, 2026 at 08:43:25PM +0000, Jonathan Cameron wrote:
> > > On Tue, 3 Feb 2026 16:56:00 +0200
> > > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
> ...
> 
> > > > Just do not introduce that change (change of the ->name field) in the original
> > > > patch, in that case no revert churn would be needed.
> > > > 
> > > I think this got dealt with in discussion of next version but
> > > safest route is just have an extra copy of the name in the
> > > chip_info structure.  Then we know it's stable against different
> > > firmware types etc.
> > 
> > Something like this?
> 
> Yes, but make it in the patch that introduces DT support.

Hm, I'm not sure what do you mean. There is no patch which "introduces
DT support" in this series. Do you mean, this one:
https://lore.kernel.org/all/20260204140045.390677-7-o.rempel@pengutronix.de/

Or should it be better a separate patch?

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info

[Andy Shevchenko]

On Mon, Feb 09, 2026 at 10:22:13AM +0100, Oleksij Rempel wrote:
> On Fri, Feb 06, 2026 at 11:59:50AM +0200, Andy Shevchenko wrote:
> > On Fri, Feb 06, 2026 at 08:57:07AM +0100, Oleksij Rempel wrote:
> > > On Thu, Feb 05, 2026 at 08:43:25PM +0000, Jonathan Cameron wrote:
> > > > On Tue, 3 Feb 2026 16:56:00 +0200
> > > > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

...

> > > > > Just do not introduce that change (change of the ->name field) in the original
> > > > > patch, in that case no revert churn would be needed.
> > > > > 
> > > > I think this got dealt with in discussion of next version but
> > > > safest route is just have an extra copy of the name in the
> > > > chip_info structure.  Then we know it's stable against different
> > > > firmware types etc.
> > > 
> > > Something like this?
> > 
> > Yes, but make it in the patch that introduces DT support.
> 
> Hm, I'm not sure what do you mean. There is no patch which "introduces
> DT support" in this series. Do you mean, this one:
> https://lore.kernel.org/all/20260204140045.390677-7-o.rempel@pengutronix.de/

Yes, I meant that one.

> Or should it be better a separate patch?

Perhaps just after the above mentioned one. Either works for me.

-- 
With Best Regards,
Andy Shevchenko