From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Andy Shevchenko" <andriy.shevchenko@intel.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
"Andy Shevchenko" <andy@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"David Jander" <david@protonic.nl>
Subject: Re: [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info
Date: Fri, 6 Feb 2026 08:57:07 +0100 [thread overview]
Message-ID: <aYWe0-2KMLijFVh6@pengutronix.de> (raw)
In-Reply-To: <20260205204325.5bd09d97@jic23-huawei>
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 |
next prev parent reply other threads:[~2026-02-06 7:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 9:34 [PATCH v4 00/13] iio: dac: ds4424: add DS4402/DS4404 support and scale Oleksij Rempel
2026-02-03 9:34 ` [PATCH v4 01/13] iio: dac: ds4424: reject -128 RAW value Oleksij Rempel
2026-02-03 9:54 ` Andy Shevchenko
2026-02-03 10:28 ` Oleksij Rempel
2026-02-03 11:52 ` Andy Shevchenko
2026-02-05 20:41 ` Jonathan Cameron
2026-02-03 9:34 ` [PATCH v4 02/13] iio: dac: ds4424: refactor raw access to use bitwise operations Oleksij Rempel
2026-02-03 9:34 ` [PATCH v4 03/13] iio: dac: ds4424: ratelimit read errors and use device context Oleksij Rempel
2026-02-03 9:34 ` [PATCH v4 04/13] iio: dac: ds4424: sort headers alphabetically Oleksij Rempel
2026-02-03 9:34 ` [PATCH v4 05/13] iio: dac: ds4424: rename iio_info struct to avoid ambiguity Oleksij Rempel
2026-02-03 9:55 ` Andy Shevchenko
2026-02-03 9:34 ` [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info Oleksij Rempel
2026-02-03 10:03 ` Andy Shevchenko
2026-02-03 10:17 ` Oleksij Rempel
2026-02-03 11:51 ` Andy Shevchenko
2026-02-03 12:00 ` Oleksij Rempel
2026-02-03 14:56 ` Andy Shevchenko
2026-02-05 20:43 ` Jonathan Cameron
2026-02-06 7:57 ` Oleksij Rempel [this message]
2026-02-06 9:59 ` Andy Shevchenko
2026-02-09 9:22 ` Oleksij Rempel
2026-02-09 10:29 ` Andy Shevchenko
2026-02-03 9:34 ` [PATCH v4 07/13] iio: dac: ds4424: use fsleep() instead of usleep_range() Oleksij Rempel
2026-02-03 11:45 ` Andy Shevchenko
2026-02-03 9:34 ` [PATCH v4 08/13] dt-bindings: iio: dac: maxim,ds4424: add ds4402/ds4404 Oleksij Rempel
2026-02-03 9:34 ` [PATCH v4 09/13] iio: dac: ds4424: add DS4402/DS4404 device IDs Oleksij Rempel
2026-02-03 9:34 ` [PATCH v4 10/13] iio: dac: ds4424: support per-variant output range limits Oleksij Rempel
2026-02-03 11:46 ` Andy Shevchenko
2026-02-03 9:34 ` [PATCH v4 11/13] iio: dac: ds4424: convert to regmap Oleksij Rempel
2026-02-03 11:57 ` Andy Shevchenko
2026-02-03 9:34 ` [PATCH v4 12/13] dt-bindings: iio: dac: maxim,ds4424: add maxim,rfs-ohms property Oleksij Rempel
2026-02-03 9:34 ` [PATCH v4 13/13] iio: dac: ds4424: add Rfs-based scale and per-variant limits Oleksij Rempel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYWe0-2KMLijFVh6@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=david@protonic.nl \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox