* Re: [PATCH] Documentation: admin-guide: fix bracelets and translation issue
From: Björn Persson @ 2026-06-22 13:10 UTC (permalink / raw)
To: Manuel Ebner
Cc: Jonathan Corbet, Shuah Khan, Mauro Carvalho Chehab, linux-media,
linux-doc, linux-kernel
In-Reply-To: <20260611075513.124994-2-manuelebner@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 268 bytes --]
Manuel Ebner wrote:
> -- Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI
> +- Galaxis plug.in S [new Name: Galaxis DVB Card S CI]
If it's not German anymore, should it still have the capital N? It
doesn't look like "Name" is a name here.
Björn Persson
[-- Attachment #2: OpenPGP digital signatur --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 13:08 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <dbb5915e-6587-4de9-87f3-76bea5024da8@kernel.org>
On Mon, 22 Jun 2026 10:05:13 +0200
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
> > There's been complaints about trace_printk() being defined in kernel.h as it
> > can increase the compilation time. As it is only used by some developers for
> > debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> > cycles for those that do not ever care about it.
>
> Do we have a measurement of the increased compilation time ?
I believe Yury does.
-- Steve
^ permalink raw reply
* Re: [PATCH] docs: leds: uleds: Make the documentation match the code.
From: Björn Persson @ 2026-06-22 12:54 UTC (permalink / raw)
To: Lee Jones
Cc: Pavel Machek, Jonathan Corbet, Shuah Khan, linux-leds, linux-doc,
linux-kernel
In-Reply-To: <20260513134505.GZ305027@google.com>
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
Lee Jones wrote:
> On Sun, 10 May 2026, Björn Persson wrote:
> > If API documentation isn't allowed to name a type, then I withdraw the
> > patch.
>
> It's not that it's "not allowed".
In that case there may be a chance. I'm sending version 2.
Björn Persson
[-- Attachment #2: OpenPGP digital signatur --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Harry Yoo @ 2026-06-22 12:56 UTC (permalink / raw)
To: Catalin Marinas
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajU-b32dmwS7XOg4@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]
On 6/19/26 10:04 PM, Catalin Marinas wrote:
> On Thu, Jun 18, 2026 at 11:05:43PM +0900, Harry Yoo wrote:
>> On 6/18/26 10:35 PM, Harry Yoo wrote:
>>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>>> Introduce a boot option to tag only at allocation time of the objects. This
>>>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>>>> catching bugs.
>>>
>>> I think most of overhead when enabling MTE comes from loading and
>>> validing tags for every memory access (either in SYNC or ASYNC mode),
>>> rather than from storing tags.
>>
>> Is there any reason not to use STGM instead of STG + DC GVA when
>> setting/clearing tags for large sizes when we know they are properly
>> aligned?
>
> STGM is intended for copying tags when paired with LDGM. Have you seen
> hardware where STGM is faster than STG or DC GVA?
No, I haven't. It was a question I had after learning that there are
multiple ways to store tags ;)
> For properly aligned
> buffers, I'd expect DC GVA to behave at least on par with STGM.
Thanks for answering!
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2] docs: leds: uleds: Make the documentation match the code.
From: Björn Persson @ 2026-06-22 11:18 UTC (permalink / raw)
To: Lee Jones, Pavel Machek
Cc: Jonathan Corbet, Shuah Khan, linux-leds, linux-doc, linux-kernel
From: Björn Persson <Bjorn@Rombobjörn.se>
The description in uleds.rst omits the field max_brightness and claims
falsely that the maximum brightness is always 255. Leaving max_brightness
uninitialized or omitting it when writing to /dev/uleds won't work. It
must be given a value, and that value becomes the maximum brightness.
The document is also wrong about the type of brightness values. It says
that a single byte shall be read at a time. That's actually not allowed.
Then the word "unsigned" gives the impression that the type is unsigned.
In fact a signed type is used even though the values are never negative.
Change the document to describe the true API.
Signed-off-by: Björn Persson <Bjorn@Rombobjörn.se>
---
Changes in v2:
Replaced "given" with "specified" to prevent misinterpretation of "given name", avoided mentioning a type name outside of C code fragments, and rewrote the commit message to read more like speech, as requested.
Documentation/leds/uleds.rst | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/leds/uleds.rst b/Documentation/leds/uleds.rst
index 83221098009c..f985048c641f 100644
--- a/Documentation/leds/uleds.rst
+++ b/Documentation/leds/uleds.rst
@@ -17,16 +17,23 @@ structure to it (found in kernel public header file linux/uleds.h)::
struct uleds_user_dev {
char name[LED_MAX_NAME_SIZE];
+ int max_brightness;
};
-A new LED class device will be created with the name given. The name can be
-any valid sysfs device node name, but consider using the LED class naming
-convention of "devicename:color:function".
+A new LED class device will be created with the specified name and maximum
+brightness. The name can be any valid sysfs device node name, but consider
+using the LED class naming convention of "devicename:color:function".
-The current brightness is found by reading a single byte from the character
-device. Values are unsigned: 0 to 255. Reading will block until the brightness
-changes. The device node can also be polled to notify when the brightness value
-changes.
+Although max_brightness is signed, only positive values are valid: 1 to INT_MAX.
+
+The current brightness shall be read from the character device like so::
+
+ int brightness;
+ result = read(file, &brightness, sizeof(brightness));
+
+The possible values are 0 to max_brightness. Reading will block until the
+brightness changes. The device node can also be polled to notify when the
+brightness value changes.
The LED class device will be removed when the open file handle to /dev/uleds
is closed.
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-22 12:50 UTC (permalink / raw)
To: Janani Sunil
Cc: Nuno Sá, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <013aba24-c30c-44a8-8511-96278edb3f4a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
On Mon, Jun 22, 2026 at 02:39:21PM +0200, Janani Sunil wrote:
>
> On 6/22/26 14:14, Conor Dooley wrote:
> > On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote:
> > > > > > > Why do you think the microchip devices won't work? Does the spi core
> > > > > > > reject multiple devices with the same chip select being registered or
> > > > > > > something like that?
> > > > > > Not sure how things work atm. But I'm fairly sure it used to be like
> > > > > > that. SPI would reject devices on the same controller and CS. Now that
> > > > > > we support more than one CS per controller, not sure how things work.
> > > > > We always supported more than one per CS per controller. I guess you mean
> > > > > per device.
> > > > Obviously :)
> > > > > > Janani, maybe you can give it a try?
> > > > > I think we'd need to get it to work with shared gpio proxy which maybe
> > > > > will just get set up under the hood. This used to be opt in, but seems
> > > > > that changed fairly recently so maybe some of us are working with out
> > > > > of date knowledge! I haven't played with it yet, so might not be
> > > > > that simple.
> > > > >
> > > > What I meant for Janani was basically testing two devices on the same CS
> > > > as in my pseudo DT. For the GPIO, you mean having a way to select
> > > > between devices on the same CS?
> > > >
> > > > For these devices the pin id numbers get's setted up as part of the spi message
> > > > so my assumption is that all of them will receive the message but only one acks it.
> > > >
> > > > - Nuno Sá
> > > Hi Everyone,
> > >
> > > I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
> > > https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
> >
> > Can you try again, but delete that check and allow the code to continue?
> > Worth knowing if the problem is policy (which makes sense for 99.99% of
> > devices that cannot share a chip select) or actually not supported by
> > the spi core code.
>
> Hi Conor,
>
> The CS conflict check is only a part of the problem. Even after removing it, the second device fails at the sysfs layer.
> The device naming in spi_dev_set_name() produces spi{bus}.{cs}. Both devices register as spi0.0 here, making it a duplicate directory.
That doesn't seem insurmountable, since these devices would really need
to be registered with a flag that notes sharing the cs is okay to solve
the problem in spi_dev_check_cs() which could be re-employed in
spi_dev_set_name() to append something.
Something could very well be the top bits of the address field used for
differentiation for spi{bus}.{cs}.{addr7..6}.
Whatever about this being the correct approach for your devices, there's
existing devices for which this would be needed to fully support, and
that doesn't seem like all that much work to do, if that's all that
prevents it.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Harry Yoo @ 2026-06-22 12:42 UTC (permalink / raw)
To: Catalin Marinas
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajVByfkLbetzA8bB@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 2477 bytes --]
Hi Catalin,
On 6/19/26 10:19 PM, Catalin Marinas wrote:
> On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>> Introduce a boot option to tag only at allocation time of the objects. This
>>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>>> catching bugs.
>>
>> I think most of overhead when enabling MTE comes from loading and
>> validing tags for every memory access (either in SYNC or ASYNC mode),
>> rather than from storing tags.
>
> I guess it depends on the workload. Lots of allocations for short-lived
> buffers (e.g. network traffic) may notice the additional tagging more
> than the actual tag checking.
Agreed. Likely depends on lifetime and size of objects.
> Of course, it would be nice to get some numbers from those who have
> access to MTE capable hardware.
Agreed! (I don't have one, unfortunately. It's pretty new hardware
feature)
>>> Now, when a memory object will be freed, it will retain the random tag it
>>> had at allocation time. This compromises on catching UAF bugs, till the
>>> time the object is not reallocated, at which point it will have a new
>>> random tag.
>>>
>>> Hence, not catching "use-after-free-before-reallocation" and not catching
>>> "double-free" will be the compromise for reduced KASAN overhead.
>>
>> I doubt users who care about security enough to enable HW_TAGS KASAN
>> are willing to compromise on security just to save a few instructions
>> to store tags in the free path.
>>
>> To me, it looks like too much of a compromise on security for little
>> performance gain.
>
> I don't think there's much compromise on security for use-after-free.
I think it depends... OH, WAIT! I see what you mean.
You mean use-after-free before reallocation does not lead to much
compromise on security because objects are initialized after allocation?
You're probably right.
Hmm, but stores to e.g.) free pointer, fields initialized by
constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
will be undiscovered if they happen before reallocation.
Not sure what are security implications of that,
but sounds worth discussing.
> The buffer will be re-tagged later so use-after-realloc should be
> caught, especially if we ensure that a different tag will be used (I
> don't think Dev's patches do this).
Agreed that it'll be nice to ensure that.
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil @ 2026-06-22 12:39 UTC (permalink / raw)
To: Conor Dooley
Cc: Nuno Sá, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260622-overbid-yonder-3fdfee9eda7a@spud>
On 6/22/26 14:14, Conor Dooley wrote:
> On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote:
>>>>>> Why do you think the microchip devices won't work? Does the spi core
>>>>>> reject multiple devices with the same chip select being registered or
>>>>>> something like that?
>>>>> Not sure how things work atm. But I'm fairly sure it used to be like
>>>>> that. SPI would reject devices on the same controller and CS. Now that
>>>>> we support more than one CS per controller, not sure how things work.
>>>> We always supported more than one per CS per controller. I guess you mean
>>>> per device.
>>> Obviously :)
>>>>> Janani, maybe you can give it a try?
>>>> I think we'd need to get it to work with shared gpio proxy which maybe
>>>> will just get set up under the hood. This used to be opt in, but seems
>>>> that changed fairly recently so maybe some of us are working with out
>>>> of date knowledge! I haven't played with it yet, so might not be
>>>> that simple.
>>>>
>>> What I meant for Janani was basically testing two devices on the same CS
>>> as in my pseudo DT. For the GPIO, you mean having a way to select
>>> between devices on the same CS?
>>>
>>> For these devices the pin id numbers get's setted up as part of the spi message
>>> so my assumption is that all of them will receive the message but only one acks it.
>>>
>>> - Nuno Sá
>> Hi Everyone,
>>
>> I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
>> https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
>
> Can you try again, but delete that check and allow the code to continue?
> Worth knowing if the problem is policy (which makes sense for 99.99% of
> devices that cannot share a chip select) or actually not supported by
> the spi core code.
Hi Conor,
The CS conflict check is only a part of the problem. Even after removing it, the second device fails at the sysfs layer.
The device naming in spi_dev_set_name() produces spi{bus}.{cs}. Both devices register as spi0.0 here, making it a duplicate directory.
- Janani Sunil
^ permalink raw reply
* [PATCH 2/2] hwmon: (chipcap2) Add support for label
From: Flaviu Nistor @ 2026-06-22 12:22 UTC (permalink / raw)
To: Guenter Roeck, Javier Carrasco, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: Flaviu Nistor, linux-hwmon, linux-kernel, devicetree, linux-doc
In-Reply-To: <20260622122200.14245-1-flaviu.nistor@gmail.com>
Add support for label sysfs attribute similar to other hwmon devices.
This is particularly useful for systems with multiple sensors on the
same board, where identifying individual sensors is much easier since
labels can be defined via device tree.
Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
Documentation/hwmon/chipcap2.rst | 2 ++
drivers/hwmon/chipcap2.c | 25 +++++++++++++++++++++++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/hwmon/chipcap2.rst b/Documentation/hwmon/chipcap2.rst
index dc165becc64c..c38d87b91b69 100644
--- a/Documentation/hwmon/chipcap2.rst
+++ b/Documentation/hwmon/chipcap2.rst
@@ -70,4 +70,6 @@ humidity1_min_hyst: RW humidity low hystersis
humidity1_max_hyst: RW humidity high hystersis
humidity1_min_alarm: RO humidity low alarm indicator
humidity1_max_alarm: RO humidity high alarm indicator
+humidity1_label: RO descriptive name for the sensor
+temp1_label: RO descriptive name for the sensor
=============================== ======= ========================================
diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
index 4aecf463180f..086571d556b7 100644
--- a/drivers/hwmon/chipcap2.c
+++ b/drivers/hwmon/chipcap2.c
@@ -22,6 +22,8 @@
#include <linux/irq.h>
#include <linux/module.h>
#include <linux/regulator/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/property.h>
#define CC2_START_CM 0xA0
#define CC2_START_NOM 0x80
@@ -83,6 +85,7 @@ struct cc2_data {
struct i2c_client *client;
struct regulator *regulator;
const char *name;
+ const char *label;
int irq_ready;
int irq_low;
int irq_high;
@@ -449,6 +452,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
switch (attr) {
case hwmon_humidity_input:
return 0444;
+ case hwmon_humidity_label:
+ return cc2->label ? 0444 : 0;
case hwmon_humidity_min_alarm:
return cc2->rh_alarm.low_alarm_visible ? 0444 : 0;
case hwmon_humidity_max_alarm:
@@ -466,6 +471,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
switch (attr) {
case hwmon_temp_input:
return 0444;
+ case hwmon_temp_label:
+ return cc2->label ? 0444 : 0;
default:
return 0;
}
@@ -552,6 +559,16 @@ static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
return 0;
}
+static int cc2_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ struct cc2_data *data = dev_get_drvdata(dev);
+
+ *str = data->label;
+
+ return 0;
+}
+
static int cc2_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
@@ -670,8 +687,9 @@ static int cc2_request_alarm_irqs(struct cc2_data *data, struct device *dev)
}
static const struct hwmon_channel_info *cc2_info[] = {
- HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
- HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_MIN | HWMON_H_MAX |
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_LABEL |
+ HWMON_H_MIN | HWMON_H_MAX |
HWMON_H_MIN_HYST | HWMON_H_MAX_HYST |
HWMON_H_MIN_ALARM | HWMON_H_MAX_ALARM),
NULL
@@ -680,6 +698,7 @@ static const struct hwmon_channel_info *cc2_info[] = {
static const struct hwmon_ops cc2_hwmon_ops = {
.is_visible = cc2_is_visible,
.read = cc2_read,
+ .read_string = cc2_read_string,
.write = cc2_write,
};
@@ -710,6 +729,8 @@ static int cc2_probe(struct i2c_client *client)
return dev_err_probe(dev, PTR_ERR(data->regulator),
"Failed to get regulator\n");
+ device_property_read_string(dev, "label", &data->label);
+
ret = cc2_request_ready_irq(data, dev);
if (ret)
return dev_err_probe(dev, ret, "Failed to request ready irq\n");
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property
From: Flaviu Nistor @ 2026-06-22 12:21 UTC (permalink / raw)
To: Guenter Roeck, Javier Carrasco, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: Flaviu Nistor, linux-hwmon, linux-kernel, devicetree, linux-doc
Add support for an optional label property similar to other hwmon devices.
This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
distinct names to each instance.
Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
.../devicetree/bindings/hwmon/amphenol,chipcap2.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
index 17351fdbefce..f00b5a4b14dd 100644
--- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
+++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
@@ -33,6 +33,10 @@ properties:
reg:
maxItems: 1
+ label:
+ description:
+ A descriptive name for this channel, like "ambient" or "psu".
+
interrupts:
items:
- description: measurement ready indicator
@@ -72,6 +76,7 @@ examples:
<5 IRQ_TYPE_EDGE_RISING>,
<6 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "ready", "low", "high";
+ label = "somelabel";
vdd-supply = <®_vdd>;
};
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: David Hildenbrand (Arm) @ 2026-06-22 12:20 UTC (permalink / raw)
To: Cristian Marussi
Cc: Christian Brauner, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek, d-gole,
jic23, elif.topuz, lukasz.luba, philip.radford,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <ajU7UqwPZBlwRGkf@pluto>
>>>
>>> There is more stuff that indeed is configurable per the SCMI spec
>>> but these additional params are hidden into the SCMI Telemetry protocol
>>> layer (the initial patches in this series) and NOT made available to
>>> the driver/users of the protocol (like the SCMI FS driver that sits on
>>> top)
>>
>> Do you assume that there will get significantly more config options added in the
>> future for user space to configure?
>
> No, I dont think so...the only planned extensions were to support more
> performant read access mechanisms, i.e. direct mmap'ability of FW/Kernel
> SCMI Telemetry shared memory areas...BUT that will immediately dump all
> the bulk of the lower layer protocol work into the tools domain...and
Right. I guess you would hide that in library code, and provide a stable API
towards tools such that they won't have to worry about the implementation
details regarding how the values are obtained exactly.
[...]
>>>
>>> ...most of the other entries in the tree are simply RO properties of the DEs
>>> that have been discovered at enumeration time.
>>
>> Is this bulk-reading relevant for performance or just a "nice to have" ?
>>
>
> I suppose depends on your usage pattern: it is definitely relevant
> because the main collection mechanism are shared memory areas (SHMTIs)
> between the platform firmware and the Kernel: such areas being accessed
> from 2 differnt worlds concurrently come with a SCMI-specified
> synchro/consistency mechanism based simply on a pair of sequence numbers
> placed at the start and at the end of the SHMTI, so that the FW increases
> such magic numbers in a well-known way before and after updating the SHMTI
> values, so that the kernel can detect (without any interlocking mechanism)
> if a platform write happened in the middle of its reads...
Okay, so sequence counters to detect concurrent changes and retry.
>
> ...so if you read one single DE 64bit value, under the hood the kernel
> would have had to really perform at leats 3 reads from the SHMTI to check
> the consistecy of that single read...
>
> ... while if you do a bulk_read the overhead due to the consistecy
> checks gets 'spread' across a number of DEs because the kernel will snapshot
> the whole SHMTIs (potentially KBytes) between the 2 consistency reads
That makes sense.
I guess a user space library could implement some kind of caching (bulk-read,
then provide clean access to individual DEs) to hide the details from the tools?
>
> ...the good side effect of all of this is that I can leverage such
> sequence number to optimize reads..i.e. do NOT even try to read anything
> if the new sequnce number is unchanged from the last one I cached on the
> last successfull read of this value...
Right.
>
> So at the end I would say it is NOT simply a nice to have BUT it is
> certainly only the first step towards a more performant alternative access
> (like with mmaps)...it depends on the usage pattern...I am not sure what
> mechanism is used by our tools more...
Okay.
>>
>> Yes. How high-priority is the fs side? Or would a tool using a library to access
>> this information also work in the first step?
>>
>
> I have to sync with tools on this...because they are stiil probably
> using currently the FS, but it was already planned for the future to move to
> a more low level access (ioctl/mmap)...
>
> ...my aim would be, at this point, to favour this transition without sudden
> breaking their current world (and have to expatriate :P)
>
> ..from my personal point of view, I would certainly like to still have the
> FUSE layer for ease of testing and verification on my side...but it is just
> a nice to have...
Okay, what I thought. I assume the most important part is to be able to grab
telemetry data in an efficient way on a system to then share it with some
monitoring agent. Manually digging through the FS to inspect data (debugging,
..) is probably less relevant for the target use case.
>> Okay, so a single writer (admin) changing stuff could get picked up my possibly
>> many concurrent readers?
>
> Mmm...not sure what you mean here...
>
> If you configure your Telemetry as you desire and start collecting data via
> readers, BUT then some other process changes configs under your belt, that is
> allowed as said, and so your analisys could be impacted...(something turned off
> as an example, or update interval changed)...
I was rather wondering about "turning on more" concurrently. But yeah, makes sense.
(it's the same situation other system-wide settings. If one app enables KSM and
the another one disables KSM, inconsistency is unavoidable)
>>
>
> Thanks a lot, David !
Let's hope for some guidance regarding the FS side soon.
But yeah, avoiding the in-kernel FS sounds completely reasonable at this point.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 12:20 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <pifhwgj3cp2vc7ia4m6penh52iekzjljrp75y5b7j57vvtooad@32wfqruiqqjl>
On Mon, Jun 22, 2026 at 12:51:20PM +0100, Rodrigo Alencar wrote:
> On 22/06/26 11:29, Nuno Sá wrote:
> > On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> > > On 21/06/26 15:33, Jonathan Cameron wrote:
> > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > >
> > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > >
> > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > >
> > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > spi {
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > > };
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > >
> > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > >
> > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > >
> > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > >
> > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > >
> > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > >
> > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > see if I can find what I am thinking of...
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > slightly different properties.
> > > > > > > >
> > > > > > > > microchip,device-addr:
> > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > default: 0
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,hw-device-address:
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > minimum: 0
> > > > > > > > maximum: 3
> > > > > > > > description:
> > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > which is first one on the wire).
> > > > > > > >
> > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > here?
> > > > > > > >
> > > > > > >
> > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > about solving this at the spi level.
> > > > > > >
> > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > together in the same bus.
> > > > > >
> > > > > > I'm definitely missing something, because that property for the
> > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > are completely different devices with different drivers. They have
> > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > spi bus.
> > > > >
> > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > devices on the same CS right? Because for this chip we would need
> > > > > something like:
> > > > >
> > > > > spi {
> > > > > dac@0 {
> > > > > reg = <0>;
> > > > > adi,pin-id = <0>;
> > > > > };
> > > > >
> > > > > dac@1 {
> > > > > reg = <0>; // which seems already problematic?
> > > > > adi,pin-id <1>;
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > //up to 4
> > > > > };
> > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > (I suspect it doesn't!)
> > > >
> > > > Just thinking as I type, but could we do something a bit nasty with
> > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > shared? Given this is all tied to the spi bus that should all happen
> > > > under serializing locks.
> > > >
> > > > Agreed though that this would be nicer as an SPI thing that let
> > > > us specify that a single CS is share by multiple devices and their
> > > > is some other signal acting to select which one we are talking to.
> > > >
> > >
> > > If the device-addressing on the same chip-select is to be handled
> > > by the spi framework, wouldn't we lose device-specific features?
> > >
> > > I understand that this multi-device feature is there mostly to extend the
> > > channel count from 16 to 32, 48 or 64. I suppose the command:
> > >
> > > "MULTI DEVICE SW LDAC MODE"
> > >
> > > exists so that software can update channel values accross multiple devices.
> >
> > Right! You do have a point! I agree the main driver for a feature like
> > this is likely to extend the channel count and effectively "aggregate"
> > devices.
> >
> > But I would say that even with the spi solution the MULTI DEVICE stuff
> > should be doable (as we still need a sort of adi,pin-id property).
>
> I don't think we can have something like an IIO buffer shared by multiple
> devices. Synchronizing separate devices would be doable with proper hardware
> support for this (probably involving an FGPA).
True!
>
> > But yes, I do feel that the whole feature is for aggregation so seeing
> > one device with 32 channels is the expectation here? Rather than seeing
> > two devices with 16 channels.
>
> Yes, I think aggregation is the whole point there... so that the IIO driver
> is multi-device-aware.
Which makes me feel that different pins per device might be possible
from an HW point of view but does not make much sense. For example, for
the buffer example I would expect LDAC to be shared between all the
devices.
- Nuno Sá
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-22 12:14 UTC (permalink / raw)
To: Janani Sunil
Cc: Nuno Sá, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <caa54d52-72db-4c58-ae3f-1d1343bd7845@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote:
> > > > > Why do you think the microchip devices won't work? Does the spi core
> > > > > reject multiple devices with the same chip select being registered or
> > > > > something like that?
> > > > Not sure how things work atm. But I'm fairly sure it used to be like
> > > > that. SPI would reject devices on the same controller and CS. Now that
> > > > we support more than one CS per controller, not sure how things work.
> > > We always supported more than one per CS per controller. I guess you mean
> > > per device.
> > Obviously :)
> > > > Janani, maybe you can give it a try?
> > > I think we'd need to get it to work with shared gpio proxy which maybe
> > > will just get set up under the hood. This used to be opt in, but seems
> > > that changed fairly recently so maybe some of us are working with out
> > > of date knowledge! I haven't played with it yet, so might not be
> > > that simple.
> > >
> > What I meant for Janani was basically testing two devices on the same CS
> > as in my pseudo DT. For the GPIO, you mean having a way to select
> > between devices on the same CS?
> >
> > For these devices the pin id numbers get's setted up as part of the spi message
> > so my assumption is that all of them will receive the message but only one acks it.
> >
> > - Nuno Sá
>
> Hi Everyone,
>
> I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
> https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
Can you try again, but delete that check and allow the code to continue?
Worth knowing if the problem is policy (which makes sense for 99.99% of
devices that cannot share a chip select) or actually not supported by
the spi core code.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil @ 2026-06-22 11:54 UTC (permalink / raw)
To: Nuno Sá, Jonathan Cameron
Cc: Conor Dooley, Rodrigo Alencar, Janani Sunil, Lars-Peter Clausen,
Michael Hennerich, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-doc, Mark Brown
In-Reply-To: <ajkILRPq_g24g4dH@nsa>
On 6/22/26 12:17, Nuno Sá wrote:
> On Mon, Jun 22, 2026 at 10:27:22AM +0100, Jonathan Cameron wrote:
>> On Mon, 22 Jun 2026 10:07:01 +0100
>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>
>>> On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
>>>> On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
>>>>> On Fri, 19 Jun 2026 16:54:11 +0100
>>>>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>>>>
>>>>>> On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
>>>>>>> On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
>>>>>>>> On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
>>>>>>>>> On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
>>>>>>>>>> On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
>>>>>>>>>>> On 6/14/26 21:44, Jonathan Cameron wrote:
>>>>>>>>>>>> On Tue, 9 Jun 2026 16:47:23 +0200
>>>>>>>>>>>> Janani Sunil <jan.sun97@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/26/26 15:11, Rodrigo Alencar wrote:
>>>>>>>>>>>>>> On 26/05/19 05:42PM, Janani Sunil wrote:
>>>>>>>>>>>>>>> Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
>>>>>>>>>>>>>>> buffered voltage output digital-to-analog converter (DAC) with an
>>>>>>>>>>>>>>> integrated precision reference.
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> Probably others may comment on that, but...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This parent node may support device addressing for multi-device support through
>>>>>>>>>>>>>> those ID pins. I suppose that each device may have its own power supplies or
>>>>>>>>>>>>>> other resources like the toggle pins or reset and enable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That way I suppose that an example would look like...
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +patternProperties:
>>>>>>>>>>>>>>> + "^channel@([0-9]|1[0-5])$":
>>>>>>>>>>>>>>> + type: object
>>>>>>>>>>>>>>> + description: Child nodes for individual channel configuration
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + properties:
>>>>>>>>>>>>>>> + reg:
>>>>>>>>>>>>>>> + description: Channel number.
>>>>>>>>>>>>>>> + minimum: 0
>>>>>>>>>>>>>>> + maximum: 15
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + adi,output-range-microvolt:
>>>>>>>>>>>>>>> + description: |
>>>>>>>>>>>>>>> + Output voltage range for this channel as [min, max] in microvolts.
>>>>>>>>>>>>>>> + If not specified, defaults to 0V to 5V range.
>>>>>>>>>>>>>>> + oneOf:
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: 0
>>>>>>>>>>>>>>> + - enum: [5000000, 10000000, 20000000, 40000000]
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -5000000
>>>>>>>>>>>>>>> + - const: 5000000
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -10000000
>>>>>>>>>>>>>>> + - const: 10000000
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -15000000
>>>>>>>>>>>>>>> + - const: 15000000
>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>> + - const: -20000000
>>>>>>>>>>>>>>> + - const: 20000000
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + required:
>>>>>>>>>>>>>>> + - reg
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + additionalProperties: false
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +required:
>>>>>>>>>>>>>>> + - compatible
>>>>>>>>>>>>>>> + - reg
>>>>>>>>>>>>>>> + - vdd-supply
>>>>>>>>>>>>>>> + - avdd-supply
>>>>>>>>>>>>>>> + - hvdd-supply
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +dependencies:
>>>>>>>>>>>>>>> + spi-cpha: [ spi-cpol ]
>>>>>>>>>>>>>>> + spi-cpol: [ spi-cpha ]
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +allOf:
>>>>>>>>>>>>>>> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +unevaluatedProperties: false
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +examples:
>>>>>>>>>>>>>>> + - |
>>>>>>>>>>>>>>> + #include <dt-bindings/gpio/gpio.h>
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + spi {
>>>>>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + dac@0 {
>>>>>>>>>>>>>>> + compatible = "adi,ad5529r-16";
>>>>>>>>>>>>>>> + reg = <0>;
>>>>>>>>>>>>>>> + spi-max-frequency = <25000000>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>>> + avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>>> + hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>>> + hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + channel@0 {
>>>>>>>>>>>>>>> + reg = <0>;
>>>>>>>>>>>>>>> + adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + channel@1 {
>>>>>>>>>>>>>>> + reg = <1>;
>>>>>>>>>>>>>>> + adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + channel@2 {
>>>>>>>>>>>>>>> + reg = <2>;
>>>>>>>>>>>>>>> + adi,output-range-microvolt = <0 40000000>;
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> spi {
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> multi-dac@0 {
>>>>>>>>>>>>>> compatible = "adi,ad5529r-16";
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> spi-max-frequency = <25000000>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> dac@0 {
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>> avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>> hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>> hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@0 {
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@1 {
>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@2 {
>>>>>>>>>>>>>> reg = <2>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <0 40000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> dac@1 {
>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>> vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>> avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>> hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>> hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@0 {
>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> channel@1 {
>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>> adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> then you might need something like:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> patternProperties:
>>>>>>>>>>>>>> "^dac@[0-3]$":
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and put most of the things under this node pattern.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So the main driver that you're putting together might need to handle up to four instances.
>>>>>>>>>>>>>> Even if your current driver cannot handle this, the dt-bindings might need cover that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Need to double check if each dac node needs a separate compatible, so you would maybe populate
>>>>>>>>>>>>>> a platform data to be shared with the child nodes, which would be a separate driver.
>>>>>>>>>>>>>> (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
>>>>>>>>>>>>> Hi Rodrigo,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for looking at this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
>>>>>>>>>>>>> hardware/use case we have only needs one device node and the driver is written around that model as well.
>>>>>>>>>>>>> While the device addressing pins could allow multi-device topology, we do not have an actual platform using
>>>>>>>>>>>>> that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
>>>>>>>>>>>>> speculatively without a validating use case.
>>>>>>>>>>>> Interesting feature - kind of similar to address control on a typical i2c bus device, or
>>>>>>>>>>>> looking at it another way a kind of distributed SPI mux.
>>>>>>>>>>>>
>>>>>>>>>>>> Challenge of a binding is we need to anticipate the future. So I think we do need something
>>>>>>>>>>>> like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
>>>>>>>>>>>> That would leave the path open to supporting the addressing at a later date.
>>>>>>>>>>>> An alternative might be to look at it like a chained device setup. In those we pretend there
>>>>>>>>>>>> is just one device with a lot of channels etc. The snag is that here things are more loosely
>>>>>>>>>>>> coupled whereas for those devices it tends to be you have to read / write the same register
>>>>>>>>>>>> in all devices in the chain as one big SPI message.
>>>>>>>>>>>>
>>>>>>>>>>>> +CC Mark Brown as he may know of some precedence for this feature. For his reference..
>>>>>>>>>>>> - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
>>>>>>>>>>>> value that matches that or they are ignored. Thus a single bus + 1 chip select can
>>>>>>>>>>>> be used to talk to 4 devices. Question is what that looks like in device tree + I guess
>>>>>>>>>>>> longer term how to support it cleanly in SPI.
>>>>>>>>>> I'd swear I have seen this before, from some Microchip devices. Let me
>>>>>>>>>> see if I can find what I am thinking of...
>>>>>>>>>
>>>>>>>>> microchip,mcp3911 and microchip,mcp3564 both seem to do this with
>>>>>>>>> slightly different properties.
>>>>>>>>>
>>>>>>>>> microchip,device-addr:
>>>>>>>>> description: Device address when multiple MCP3911 chips are present on the same SPI bus.
>>>>>>>>> $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>>>> enum: [0, 1, 2, 3]
>>>>>>>>> default: 0
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> microchip,hw-device-address:
>>>>>>>>> $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>>>> minimum: 0
>>>>>>>>> maximum: 3
>>>>>>>>> description:
>>>>>>>>> The address is set on a per-device basis by fuses in the factory,
>>>>>>>>> configured on request. If not requested, the fuses are set for 0x1.
>>>>>>>>> The device address is part of the device markings to avoid
>>>>>>>>> potential confusion. This address is coded on two bits, so four possible
>>>>>>>>> addresses are available when multiple devices are present on the same
>>>>>>>>> SPI bus with only one Chip Select line for all devices.
>>>>>>>>> Each device communication starts by a CS falling edge, followed by the
>>>>>>>>> clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
>>>>>>>>> which is first one on the wire).
>>>>>>>>>
>>>>>>>>> This sounds exactly like the sort of feature that you're dealing with
>>>>>>>>> here?
>>>>>>>>>
>>>>>>>> The core idea yes but for this chip, things are a bit more annoying (but
>>>>>>>> Janani can correct me if I'm wrong). Here, each device can, in theory,
>>>>>>>> have it's own supplies, pins and at the very least, channels with maybe
>>>>>>>> different scales. That is why Janani is proposing dac nodes. Given I
>>>>>>>> honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
>>>>>>>> about solving this at the spi level.
>>>>>>>>
>>>>>>>> Ah and to make it more annoying, we can also mix 12 and 16 bits variants
>>>>>>>> together in the same bus.
>>>>>>> I'm definitely missing something, because that property for the
>>>>>>> microchip devices is not impacted what else is on the bus. AFAICT, you
>>>>>>> could have an mcp3911 and an mcp3564 on the same bus even though both
>>>>>>> are completely different devices with different drivers. They have
>>>>>>> individual device nodes and their own supplies etc etc. These aren't
>>>>>>> per-channel properties on an adc or dac, they're per child device on a
>>>>>>> spi bus.
>>>>>> Maybe I'm the one missing something :). IIRC, spi would not allow two
>>>>>> devices on the same CS right? Because for this chip we would need
>>>>>> something like:
>>>>>>
>>>>>> spi {
>>>>>> dac@0 {
>>>>>> reg = <0>;
>>>>>> adi,pin-id = <0>;
>>>>>> };
>>>>>>
>>>>>> dac@1 {
>>>>>> reg = <0>; // which seems already problematic?
>>>>>> adi,pin-id <1>;
>>>>>> };
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> //up to 4
>>>>>> };
>>>>> Yeah. It's not clear to me how that works for the microchip devices
>>>>> (I suspect it doesn't!)
>>>>>
>>>>> Just thinking as I type, but could we do something a bit nasty with
>>>>> a gpio mux that doesn't actually switch but represents the GPIO being
>>>>> shared? Given this is all tied to the spi bus that should all happen
>>>>> under serializing locks.
>>>>>
>>>>> Agreed though that this would be nicer as an SPI thing that let
>>>>> us specify that a single CS is share by multiple devices and their
>>>>> is some other signal acting to select which one we are talking to.
>>>> Whether it works or not, I think it is the more correct approach. Messing
>>>> with gpio muxes seems completely wrong, given the chip select may not be
>>>> a gpio at all.
>>>>
>>>> Why do you think the microchip devices won't work? Does the spi core
>>>> reject multiple devices with the same chip select being registered or
>>>> something like that?
>>> Not sure how things work atm. But I'm fairly sure it used to be like
>>> that. SPI would reject devices on the same controller and CS. Now that
>>> we support more than one CS per controller, not sure how things work.
>> We always supported more than one per CS per controller. I guess you mean
>> per device.
> Obviously :)
>>> Janani, maybe you can give it a try?
>> I think we'd need to get it to work with shared gpio proxy which maybe
>> will just get set up under the hood. This used to be opt in, but seems
>> that changed fairly recently so maybe some of us are working with out
>> of date knowledge! I haven't played with it yet, so might not be
>> that simple.
>>
> What I meant for Janani was basically testing two devices on the same CS
> as in my pseudo DT. For the GPIO, you mean having a way to select
> between devices on the same CS?
>
> For these devices the pin id numbers get's setted up as part of the spi message
> so my assumption is that all of them will receive the message but only one acks it.
>
> - Nuno Sá
Hi Everyone,
I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
-Janani Sunil
>
>> Jonathan
>>
>>> - Nuno Sá
>>>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Rodrigo Alencar @ 2026-06-22 11:51 UTC (permalink / raw)
To: Nuno Sá, Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajkMBh-R_7pYaoAn@nsa>
On 22/06/26 11:29, Nuno Sá wrote:
> On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> > On 21/06/26 15:33, Jonathan Cameron wrote:
> > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > >
> > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > >
> > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > ...
> > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > >
> > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > >
> > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + required:
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +required:
> > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > + - |
> > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > > spi {
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > > };
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > >
> > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > >
> > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > >
> > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > >
> > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > >
> > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > >
> > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > >
> > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > >
> > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > see if I can find what I am thinking of...
> > > > > > >
> > > > > > >
> > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > slightly different properties.
> > > > > > >
> > > > > > > microchip,device-addr:
> > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > enum: [0, 1, 2, 3]
> > > > > > > default: 0
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > >
> > > > > > > microchip,hw-device-address:
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > minimum: 0
> > > > > > > maximum: 3
> > > > > > > description:
> > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > The device address is part of the device markings to avoid
> > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > which is first one on the wire).
> > > > > > >
> > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > here?
> > > > > > >
> > > > > >
> > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > about solving this at the spi level.
> > > > > >
> > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > together in the same bus.
> > > > >
> > > > > I'm definitely missing something, because that property for the
> > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > are completely different devices with different drivers. They have
> > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > spi bus.
> > > >
> > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > devices on the same CS right? Because for this chip we would need
> > > > something like:
> > > >
> > > > spi {
> > > > dac@0 {
> > > > reg = <0>;
> > > > adi,pin-id = <0>;
> > > > };
> > > >
> > > > dac@1 {
> > > > reg = <0>; // which seems already problematic?
> > > > adi,pin-id <1>;
> > > > };
> > > >
> > > > ...
> > > >
> > > > //up to 4
> > > > };
> > > Yeah. It's not clear to me how that works for the microchip devices
> > > (I suspect it doesn't!)
> > >
> > > Just thinking as I type, but could we do something a bit nasty with
> > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > shared? Given this is all tied to the spi bus that should all happen
> > > under serializing locks.
> > >
> > > Agreed though that this would be nicer as an SPI thing that let
> > > us specify that a single CS is share by multiple devices and their
> > > is some other signal acting to select which one we are talking to.
> > >
> >
> > If the device-addressing on the same chip-select is to be handled
> > by the spi framework, wouldn't we lose device-specific features?
> >
> > I understand that this multi-device feature is there mostly to extend the
> > channel count from 16 to 32, 48 or 64. I suppose the command:
> >
> > "MULTI DEVICE SW LDAC MODE"
> >
> > exists so that software can update channel values accross multiple devices.
>
> Right! You do have a point! I agree the main driver for a feature like
> this is likely to extend the channel count and effectively "aggregate"
> devices.
>
> But I would say that even with the spi solution the MULTI DEVICE stuff
> should be doable (as we still need a sort of adi,pin-id property).
I don't think we can have something like an IIO buffer shared by multiple
devices. Synchronizing separate devices would be doable with proper hardware
support for this (probably involving an FGPA).
> But yes, I do feel that the whole feature is for aggregation so seeing
> one device with 32 channels is the expectation here? Rather than seeing
> two devices with 16 channels.
Yes, I think aggregation is the whole point there... so that the IIO driver
is multi-device-aware.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 0/4] nfs: remove the fileid field from struct nfs_inode
From: Benjamin Coddington @ 2026-06-22 11:23 UTC (permalink / raw)
To: Jeff Layton
Cc: Trond Myklebust, Anna Schumaker, Jonathan Corbet, Shuah Khan,
linux-nfs, linux-kernel, linux-doc
In-Reply-To: <20260512-nfsino-v1-0-284720522f4c@kernel.org>
On 12 May 2026, at 12:12, Jeff Layton wrote:
> v7.1-rc1 contains patches to make inode->i_ino to be a u64. With this
> change, there is no need to keep a separate "fileid" field in struct
> nfs_inode.
>
> This patchset eliminiates that field, and the inode number hashing
> machinery that is no longer needed. This shaves 8 bytes off of each
> nfs_inode.
>
> Trond/Anna: please consider this for v7.2.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Looks good,
Reviewed-by: Benjamin Coddington <bcodding@hammerspace.com>
Ben
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 10:29 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <5u4dnsgxwcwie45f24cacyzf3dko4srhyyyhcpom6tsvhqtmpc@y7d7gmex6n7k>
On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> On 21/06/26 15:33, Jonathan Cameron wrote:
> > On Fri, 19 Jun 2026 16:54:11 +0100
> > Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > >
> > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > ...
> > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > >
> > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > >
> > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > +
> > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > + type: object
> > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > +
> > > > > > > > > > > > + properties:
> > > > > > > > > > > > + reg:
> > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > +
> > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > + description: |
> > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > +
> > > > > > > > > > > > + required:
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > +
> > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +required:
> > > > > > > > > > > > + - compatible
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > +
> > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > +
> > > > > > > > > > > > +allOf:
> > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > +
> > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +examples:
> > > > > > > > > > > > + - |
> > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > +
> > > > > > > > > > > > + spi {
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > > spi {
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > dac@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@2 {
> > > > > > > > > > > reg = <2>;
> > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > dac@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > > };
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > then you might need something like:
> > > > > > > > > > >
> > > > > > > > > > > patternProperties:
> > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > >
> > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > >
> > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > >
> > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > Hi Rodrigo,
> > > > > > > > > >
> > > > > > > > > > Thank you for looking at this.
> > > > > > > > > >
> > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > >
> > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > >
> > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > >
> > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > see if I can find what I am thinking of...
> > > > > >
> > > > > >
> > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > slightly different properties.
> > > > > >
> > > > > > microchip,device-addr:
> > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > enum: [0, 1, 2, 3]
> > > > > > default: 0
> > > > > >
> > > > > > and
> > > > > >
> > > > > >
> > > > > > microchip,hw-device-address:
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > minimum: 0
> > > > > > maximum: 3
> > > > > > description:
> > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > The device address is part of the device markings to avoid
> > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > addresses are available when multiple devices are present on the same
> > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > which is first one on the wire).
> > > > > >
> > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > here?
> > > > > >
> > > > >
> > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > about solving this at the spi level.
> > > > >
> > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > together in the same bus.
> > > >
> > > > I'm definitely missing something, because that property for the
> > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > are completely different devices with different drivers. They have
> > > > individual device nodes and their own supplies etc etc. These aren't
> > > > per-channel properties on an adc or dac, they're per child device on a
> > > > spi bus.
> > >
> > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > devices on the same CS right? Because for this chip we would need
> > > something like:
> > >
> > > spi {
> > > dac@0 {
> > > reg = <0>;
> > > adi,pin-id = <0>;
> > > };
> > >
> > > dac@1 {
> > > reg = <0>; // which seems already problematic?
> > > adi,pin-id <1>;
> > > };
> > >
> > > ...
> > >
> > > //up to 4
> > > };
> > Yeah. It's not clear to me how that works for the microchip devices
> > (I suspect it doesn't!)
> >
> > Just thinking as I type, but could we do something a bit nasty with
> > a gpio mux that doesn't actually switch but represents the GPIO being
> > shared? Given this is all tied to the spi bus that should all happen
> > under serializing locks.
> >
> > Agreed though that this would be nicer as an SPI thing that let
> > us specify that a single CS is share by multiple devices and their
> > is some other signal acting to select which one we are talking to.
> >
>
> If the device-addressing on the same chip-select is to be handled
> by the spi framework, wouldn't we lose device-specific features?
>
> I understand that this multi-device feature is there mostly to extend the
> channel count from 16 to 32, 48 or 64. I suppose the command:
>
> "MULTI DEVICE SW LDAC MODE"
>
> exists so that software can update channel values accross multiple devices.
Right! You do have a point! I agree the main driver for a feature like
this is likely to extend the channel count and effectively "aggregate"
devices.
But I would say that even with the spi solution the MULTI DEVICE stuff
should be doable (as we still need a sort of adi,pin-id property).
But yes, I do feel that the whole feature is for aggregation so seeing
one device with 32 channels is the expectation here? Rather than seeing
two devices with 16 channels.
- Nuno Sá
>
> --
> Kind regards,
>
> Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 10:17 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260622102722.5900592f@jic23-huawei>
On Mon, Jun 22, 2026 at 10:27:22AM +0100, Jonathan Cameron wrote:
> On Mon, 22 Jun 2026 10:07:01 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
> > > On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > >
> > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > >
> > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > >
> > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > spi {
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > > };
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > >
> > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > >
> > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > >
> > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > >
> > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > >
> > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > >
> > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > see if I can find what I am thinking of...
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > slightly different properties.
> > > > > > > >
> > > > > > > > microchip,device-addr:
> > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > default: 0
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,hw-device-address:
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > minimum: 0
> > > > > > > > maximum: 3
> > > > > > > > description:
> > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > which is first one on the wire).
> > > > > > > >
> > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > here?
> > > > > > > >
> > > > > > >
> > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > about solving this at the spi level.
> > > > > > >
> > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > together in the same bus.
> > > > > >
> > > > > > I'm definitely missing something, because that property for the
> > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > are completely different devices with different drivers. They have
> > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > spi bus.
> > > > >
> > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > devices on the same CS right? Because for this chip we would need
> > > > > something like:
> > > > >
> > > > > spi {
> > > > > dac@0 {
> > > > > reg = <0>;
> > > > > adi,pin-id = <0>;
> > > > > };
> > > > >
> > > > > dac@1 {
> > > > > reg = <0>; // which seems already problematic?
> > > > > adi,pin-id <1>;
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > //up to 4
> > > > > };
> > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > (I suspect it doesn't!)
> > > >
> > > > Just thinking as I type, but could we do something a bit nasty with
> > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > shared? Given this is all tied to the spi bus that should all happen
> > > > under serializing locks.
> > > >
> > > > Agreed though that this would be nicer as an SPI thing that let
> > > > us specify that a single CS is share by multiple devices and their
> > > > is some other signal acting to select which one we are talking to.
> > >
> > > Whether it works or not, I think it is the more correct approach. Messing
> > > with gpio muxes seems completely wrong, given the chip select may not be
> > > a gpio at all.
> > >
> > > Why do you think the microchip devices won't work? Does the spi core
> > > reject multiple devices with the same chip select being registered or
> > > something like that?
> >
> > Not sure how things work atm. But I'm fairly sure it used to be like
> > that. SPI would reject devices on the same controller and CS. Now that
> > we support more than one CS per controller, not sure how things work.
> We always supported more than one per CS per controller. I guess you mean
> per device.
Obviously :)
>
> >
> > Janani, maybe you can give it a try?
>
> I think we'd need to get it to work with shared gpio proxy which maybe
> will just get set up under the hood. This used to be opt in, but seems
> that changed fairly recently so maybe some of us are working with out
> of date knowledge! I haven't played with it yet, so might not be
> that simple.
>
What I meant for Janani was basically testing two devices on the same CS
as in my pseudo DT. For the GPIO, you mean having a way to select
between devices on the same CS?
For these devices the pin id numbers get's setted up as part of the spi message
so my assumption is that all of them will receive the message but only one acks it.
- Nuno Sá
> Jonathan
>
> >
> > - Nuno Sá
> >
>
^ permalink raw reply
* Re: [PATCH v4 0/5] mm/zswap: Implement per-cgroup proactive writeback
From: Youngjun Park @ 2026-06-22 10:04 UTC (permalink / raw)
To: Hao Jia
Cc: Muchun Song, yosry, akpm, tj, hannes, shakeel.butt, mhocko,
mkoutny, nphamcs, chengming.zhou, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <26a034b3-9cfa-e4f5-eea1-e69fbfff02b4@gmail.com>
On Mon, Jun 22, 2026 at 02:08:49PM +0800, Hao Jia wrote:
>
>
> On 2026/6/21 12:20, Muchun Song wrote:
> >
> >
> > > On Jun 18, 2026, at 12:48, Hao Jia <jiahao.kernel@gmail.com> wrote:
> > >
> > > From: Hao Jia <jiahao1@lixiang.com>
> > >
> > > Zswap currently writes back pages to backing swap reactively, triggered
> > > either by the shrinker or by the pool reaching its size limit. Although
> > > proactive memory reclaim can automatically write back a portion of zswap
> > > pages via the shrinker, it cannot explicitly control the amount of
> > > writeback for a specific memory cgroup. Moreover, proactive memory reclaim
> > > may not always be triggered during a steady state.
> > >
> > > In certain scenarios, it is desirable to trigger writeback in advance to
> > > free up memory. For example, users may want to prepare for an upcoming
> > > memory-intensive workload by flushing cold memory to the backing storage
> > > when the system is relatively idle.
> > >
> > > This patch series introduces a "zswap_writeback_only" key to memory.reclaim
> > > cgroup interface, allowing users to proactively write back cold compressed
> > > data from zswap to the backing swap device. When specified, this key
> > > bypasses standard memory reclaim and exclusively performs proactive zswap
> > > writeback up to the requested budget. If omitted, the default reclaim
> > > behavior remains unchanged.
> > >
> > > Example usage:
> > > # Write back 10MB of compressed data from zswap to the backing swap
> > > echo "10M zswap_writeback_only" > memory.reclaim
> >
> > I’m not entirely sure if other candidate names were already brought up
> > in previous discussions, so my apologies if I'm repeating something here!
> > I do think expanding memory.reclaim is a great approach. That said, I
> > was wondering if we could make the interface a bit more concise while
> > keeping it flexible for future extensions.
> >
> > Essentially, what we want is to control the specific targets of the reclaim
> > process—such as file, anon, or zswap. What do you think about using
> > something like "source=zswap"? For instance, if we want to reclaim 10M from
> > zswap, the command would look like this:
> >
> > echo "10M source=zswap" > memory.reclaim
> >
>
> Thanks for the suggestion. TBH, I personally think your approach makes more
> sense than "zswap_writeback_only".
> Hi YoungJun and Yosry,
>
> I am not sure if this suggestion from Muchun could decouple zswap proactive
> writeback from the swap tiers, or make it easier to migrate to swap tiers in
> the future:
>
> echo "10M source=zswap" > memory.reclaim
> For now, we only specify the source. Later on, the swap tiers feature could
> extend this to control whether to demote to SSD swap, HDD swap, or other
> tiers.
>
> Thanks,
> Hao
Hi Hao!
I also preferred sharing the `memory.reclaim` interface in the future swap demotion,
since it already takes `zswap_writeback_only`.
https://lore.kernel.org/all/aieUQUBHI+E3uNPW@yjaykim-PowerEdge-T330/
Alternatively, we could use a separate interface as Yosry suggested
(e.g. 'swap.tiers.demote'?).
But as Nhat pointed out, allowing user-triggered demotion from the swap tier
perspective could lead to issues like LRU inversion. We probably need to
discuss whether this kind of user-triggered tier demotion will actually be
supported at all.
https://lore.kernel.org/linux-mm/CAKEwX=NfSy0XiD_UMsDOHGCwpE7sYmBmhV4Y9vk_cbnnr6J6PQ@mail.gmail.com/
So, IMHO..
1. If swap tier demotion is NOT exposed.
We can simply choose between "source=" and `zswap_writeback_only` based
on preference. (since there is no need to consider "swap_tier" demotion.)
However, "source=" seems to offer better extensibility if it is expanded
to file and anon use cases in the future.
2. If swap tier demotion IS exposed.
We need to consider integration vs decoupling.
(In my view, This is a design consideration. avoiding potentially
redundant interfaces vs adding a new one if it is architecturally correct.)
2.1 Integration
- Integrating into 'memory.reclaim':
- "source=": Seems easier to integrate by explicitly specifying the target. (Your suggestion)
- 'zswap_writeback_only': Harder to integrate than "source=".
- Integrating into 'memory.swap.tiers.demote'
- 'memory.swap.tiers.demote' could absorb the memory.reclaim functionality.
(But since we only want to allow tiering for vswap+zswap cases like
the zswap writeback feature as we discussed, the reclaim interface behavior might
still need to stay for zswap only.)
2.2 Decoupling
- 'memory.swap.tiers.demote' handles other swap devices (excluding zswap),
while "source=" or 'zswap_writeback_only' handles only zswap.
I think future discussions might lean toward "integrating into
'memory.swap.tiers.demote'". Therefore, from this perspective, either
direction seems fine. However, I slightly prefer "source=" due to its
potential for other extensions.
I don't have a strong preference, though!
Thanks
Youngjun
> If we only want to reclaim 10M from file pages, we could easily extend the
> syntax:
>
> echo "10M source=file" > memory.reclaim
>
> And of course, we could even combine them down the road:
>
> echo "10M source=anon,file" > memory.reclaim
>
> to only reclaim anon and file but bypass zswap.
>
> Just some thoughts of mine.
^ permalink raw reply
* Re: [PATCH v6 15/19] drm/connector: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-06-22 9:53 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance, dri-devel, linux-doc,
linux-kernel, Daniel Stone, intel-gfx, intel-xe, linux-arm-kernel,
linux-sunxi, Laurent Pinchart
In-Reply-To: <DJD5YZ2K1047.3UJ5QMMLQO6UY@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5721 bytes --]
On Fri, Jun 19, 2026 at 06:24:46PM +0200, Luca Ceresoli wrote:
> Hello Maxime, Dmitry, all,
>
> On Tue May 26, 2026 at 6:46 PM CEST, Maxime Ripard wrote:
> > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> > to drm_private_obj") introduced a new pattern for allocating drm object
> > states.
> >
> > Instead of relying on the reset() callback, it created a new
> > atomic_create_state hook. This is helpful because reset is a bit
> > overloaded: it's used to create the initial software state, reset it,
> > but also reset the hardware.
> >
> > It can also be used either at probe time, to create the initial state
> > and possibly reset the hardware to an expected default, but also during
> > suspend/resume.
> >
> > Both these cases come with different expectations too: during the
> > initialization, we want to initialize all states, but during
> > suspend/resume, drm_private_states for example are expected to be kept
> > around.
> >
> > reset() also isn't fallible, which makes it harder to handle
> > initialization errors properly. This is only really relevant for some
> > drivers though, since all the helpers for reset only create a new
> > state, and don't touch the hardware at all.
> >
> > It was thus decided to create a new hook that would allocate and
> > initialize a pristine state without any side effect:
> > atomic_create_state to untangle a bit some of it, and to separate the
> > initialization with the actual reset one might need during a
> > suspend/resume.
> >
> > Continue the transition to the new pattern with connectors.
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
>
> As I'm rebasing another series on current drm-misc-next, which now includes
> this patch, I ran into troubles and I'm not sure what is the right thing to
> do. I hope you can help me clarify this. See below for my question.
>
> FTR the series I'm rebasing is "drm bridge hotplug", but the question is
> not specific to that series.
>
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -616,11 +616,19 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
> >
> > /*
> > * drm_connector_attach_max_bpc_property() requires the
> > * connector to have a state.
> > */
> > - if (connector->funcs->reset)
> > + if (connector->funcs->atomic_create_state) {
> > + struct drm_connector_state *state;
> > +
> > + state = connector->funcs->atomic_create_state(connector);
> > + if (IS_ERR(state))
> > + return PTR_ERR(state);
> > +
> > + connector->state = state;
> > + } else if (connector->funcs->reset)
> > connector->funcs->reset(connector);
>
> Here a state is added to connector->state, and that's fine.
>
> However non-HDMI connectors don't get a state created by default.
That's true, but I don't see how this particular patch affects it? The
call sites of reset are now falling back to atomic_create_state, but it
doesn't change anything wrt when reset is (or was?) called, which seems
to be what you're talking about.
> I was hit by this with the drm_bridge_connector which it can add either an
> HDMI or a non-HDMI connector [0]. In the former case it calls
> drmm_connector_hdmi_init(), which creates the state (in the hunk quoted
> above). In the latter case, as I experienced at runtime and confirmed by
> code inspection, it does not create a state: no one calls
> connector->funcs->atomic_create_state.
>
> I suspect this is related to patch 19/19 which converted the
> drm_bridge_connector from drm_atomic_helper_connector_reset() to
> drm_atomic_helper_connector_create_state(), and only the former sets
> 'connector->state = conn_state'.
But it's pretty much the same story here? it changes the implementation,
but it should be called at the same time it used to.
> Generally speaking, looks like a state is created only for HDMI
> connectors.
>
> The hardware I have uses the drm_bridge_connector in the non-HDMI case, so
> the state is not created and this results in a NULL pointer deref later on,
> in my case it's in in drm_atomic_connector_get_property().
>
> Am I missing anything obvious?
>
> For now I've come up with a quick workaround, adding (roughly after
> connector init at [1]):
>
> if (!connector->state)
> connector->state = drm_bridge_connector_create_state(connector);
>
> I'm not sure which would be the best solution. Maybe taking the whole
> atomic_create_state/reset state creation calls [2] from
> drmm_connector_hdmi_init() and hoist them up into
> drmm_connector_init(), so all connectors benefit?
Generally speaking, either drm_mode_config_reset() or
drm_mode_config_create_initial_state will fill $object->state on most
drivers. For dynamic connectors, you'll need to create the initial state
when creating the new connector.
That's what intel (in intel_connector_alloc()) is doing
https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/i915/display/intel_dp_mst.c#L1684
amdgpu through the call to amdgpu_dm_connector_funcs_reset():
https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c#L632
nouveau through the call to mstc->connector.funcs->reset()
https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/nouveau/dispnv50/disp.c#L1262
Would it be possible that it's not a regression but rather that you just noticed it?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Geert Uytterhoeven @ 2026-06-22 9:52 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Marc Zyngier, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Fri, 19 Jun 2026 at 00:04, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The GIC600 implementation is now known to be used on multiple 64-bit
> SoCs, where it has address width for AXI or APB interface configured
> to 32 bit, and it can access only the first 4GiB of physical address
> space.
>
> Rework the handling of the quirk to work around this limitation such
> that new entries can be added purely as new compatible strings, with
> no need to add additional functions or new its_quirk array entries.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4890,10 +4890,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_32bit_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
__maybe_unused can be dropped...
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_32bit_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4968,14 +4975,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
... as the #ifdef is removed.
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: dac: Add AD5529R DAC driver support
From: Jonathan Cameron @ 2026-06-22 9:31 UTC (permalink / raw)
To: Philipp Zabel
Cc: Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil
In-Reply-To: <9c5104eb504e390c2267e0a17762fdb6d73d75a4.camel@pengutronix.de>
On Mon, 22 Jun 2026 11:12:19 +0200
Philipp Zabel <p.zabel@pengutronix.de> wrote:
> On Di, 2026-05-19 at 17:42 +0200, Janani Sunil wrote:
> > Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
> >
> > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/iio/dac/Kconfig | 17 ++
> > drivers/iio/dac/Makefile | 1 +
> > drivers/iio/dac/ad5529r.c | 527 ++++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 546 insertions(+)
> >
> [...]
> > diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
> > new file mode 100644
> > index 000000000000..9bb63030db95
> > --- /dev/null
> > +++ b/drivers/iio/dac/ad5529r.c
> > @@ -0,0 +1,527 @@
> [...]
> > +static int ad5529r_reset(struct ad5529r_state *st)
> > +{
> > + struct reset_control *rst;
> > + int ret;
> > +
> > + rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
>
> Consider using devm_reset_control_get_optional_exclusive_deasserted()
> to save a few lines, and to make sure the reset line is asserted again
> when the driver is unbound.
Given we can't assume it's a gpio reset at this level (it is but meh,
we shouldn't use the API that way), we can't guarantee it was ever asserted
so we probably have to do a dance of assert then deassert.
This is one of Sashiko's favourite things to complain about so
we ended up doing some digging into that path a few weeks back.
I'd really like that not to be the case so maybe that analysis is wrong.
Jonathan
>
> > + if (IS_ERR(rst))
> > + return PTR_ERR(rst);
> > +
> > + if (rst) {
> > + ret = reset_control_deassert(rst);
> > + if (ret)
> > + return ret;
>
> This branch could then be removed.
>
> > + } else {
> > + ret = regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
> > + AD5529R_INTERFACE_CONFIG_A_SW_RESET);
> > + if (ret)
> > + return ret;
> > + }
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH v4 0/2] cpufreq: CPPC: add autonomous mode boot parameter support
From: Sumit Gupta @ 2026-06-22 9:28 UTC (permalink / raw)
To: Pierre Gondois, Viresh Kumar
Cc: rafael, ionela.voinescu, zhenglifeng1, zhanjie9, corbet, skhan,
rdunlap, mario.limonciello, linux-pm, linux-doc, linux-kernel,
linux-tegra, treding, jonathanh, vsethi, ksitaraman, sanjayc,
mochs, bbasu, sumitg
In-Reply-To: <35458c15-73b3-45f1-91fe-aa81d85a3efd@arm.com>
On 19/06/26 14:59, Pierre Gondois wrote:
> External email: Use caution opening links or attachments
>
>
> On 6/18/26 07:28, Viresh Kumar wrote:
>> On 16-06-26, 18:22, Sumit Gupta wrote:
>>> The dependency it was waiting on, the "cpufreq: Set policy->min and
>>> max as real QoS constraints" series, is now in linux-pm (linux-next).
>>> I rebased on top and verified autonomous mode works as expected, and
>>> it applies cleanly on the current linux-next.
>>>
>>> The [1] reference in patch 2/2 points to v2 of that series; the merged
>>> version is v3 [2].
>>>
>>> If there are no further comments, please consider acking and queuing
>>> this for the next cycle.
>> I was waiting for CPPC reviewers to provide some feedback.i
>>
>> Jie / Lifeng / Pierre ?
>>
> I think the patchset has the same issue described at:
>
> https://lore.kernel.org/all/86780f97-29ee-4a72-b311-38c89434b707@arm.com/
>
> I don't know if this is important to other persons,
> but IMO it would be preferable to have a solution to this issue
> before adding more functionalities relying on registers that are left
> in an unknown state.
>
> If there are any other opinion ?
>
The concern is valid, but this isn't a new gap. The registers the boot
parameter programs are already writable via existing sysfs:
- auto_sel via auto_select
- EPP via energy_performance_preference_val
So userspace can already leave these in a non-default state across
unload / CPU hotplug in mainline. The boot parameter just sets the
same registers at boot via the same paths.
I am already working on the save/restore change we discussed on
the ospm_nominal_perf thread, as a dedicated follow-up grouping
all OSPM-set registers (ospm_nominal_perf, auto_sel, EPP) together.
I think doing it once uniformly is cleaner.
Both features are already under review, so my preference is to take
them first and add the save/restore on top, rather than merging it
first and respinning both features under it. Either order works for me
if you and the maintainers prefer infra-first.
Thanks,
Sumit
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-06-22 9:27 UTC (permalink / raw)
To: Nuno Sá
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajj6nEb4tATM3C7b@nsa>
On Mon, 22 Jun 2026 10:07:01 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
> > On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > >
> > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > >
> > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > ...
> > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > >
> > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > >
> > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + required:
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +required:
> > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > + - |
> > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > > spi {
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > > };
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > >
> > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > >
> > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > >
> > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > >
> > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > >
> > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > >
> > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > >
> > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > >
> > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > see if I can find what I am thinking of...
> > > > > > >
> > > > > > >
> > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > slightly different properties.
> > > > > > >
> > > > > > > microchip,device-addr:
> > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > enum: [0, 1, 2, 3]
> > > > > > > default: 0
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > >
> > > > > > > microchip,hw-device-address:
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > minimum: 0
> > > > > > > maximum: 3
> > > > > > > description:
> > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > The device address is part of the device markings to avoid
> > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > which is first one on the wire).
> > > > > > >
> > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > here?
> > > > > > >
> > > > > >
> > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > about solving this at the spi level.
> > > > > >
> > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > together in the same bus.
> > > > >
> > > > > I'm definitely missing something, because that property for the
> > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > are completely different devices with different drivers. They have
> > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > spi bus.
> > > >
> > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > devices on the same CS right? Because for this chip we would need
> > > > something like:
> > > >
> > > > spi {
> > > > dac@0 {
> > > > reg = <0>;
> > > > adi,pin-id = <0>;
> > > > };
> > > >
> > > > dac@1 {
> > > > reg = <0>; // which seems already problematic?
> > > > adi,pin-id <1>;
> > > > };
> > > >
> > > > ...
> > > >
> > > > //up to 4
> > > > };
> > > Yeah. It's not clear to me how that works for the microchip devices
> > > (I suspect it doesn't!)
> > >
> > > Just thinking as I type, but could we do something a bit nasty with
> > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > shared? Given this is all tied to the spi bus that should all happen
> > > under serializing locks.
> > >
> > > Agreed though that this would be nicer as an SPI thing that let
> > > us specify that a single CS is share by multiple devices and their
> > > is some other signal acting to select which one we are talking to.
> >
> > Whether it works or not, I think it is the more correct approach. Messing
> > with gpio muxes seems completely wrong, given the chip select may not be
> > a gpio at all.
> >
> > Why do you think the microchip devices won't work? Does the spi core
> > reject multiple devices with the same chip select being registered or
> > something like that?
>
> Not sure how things work atm. But I'm fairly sure it used to be like
> that. SPI would reject devices on the same controller and CS. Now that
> we support more than one CS per controller, not sure how things work.
We always supported more than one per CS per controller. I guess you mean
per device.
>
> Janani, maybe you can give it a try?
I think we'd need to get it to work with shared gpio proxy which maybe
will just get set up under the hood. This used to be opt in, but seems
that changed fairly recently so maybe some of us are working with out
of date knowledge! I haven't played with it yet, so might not be
that simple.
Jonathan
>
> - Nuno Sá
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Rodrigo Alencar @ 2026-06-22 9:24 UTC (permalink / raw)
To: Jonathan Cameron, Nuno Sá
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260621153330.79b6600c@jic23-huawei>
On 21/06/26 15:33, Jonathan Cameron wrote:
> On Fri, 19 Jun 2026 16:54:11 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > >
> > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > integrated precision reference.
> > > > > > > > > > ...
> > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > >
> > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > >
> > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > +
> > > > > > > > > > > +patternProperties:
> > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > + type: object
> > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > +
> > > > > > > > > > > + properties:
> > > > > > > > > > > + reg:
> > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > + minimum: 0
> > > > > > > > > > > + maximum: 15
> > > > > > > > > > > +
> > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > + description: |
> > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > + oneOf:
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: 0
> > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > +
> > > > > > > > > > > + required:
> > > > > > > > > > > + - reg
> > > > > > > > > > > +
> > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +required:
> > > > > > > > > > > + - compatible
> > > > > > > > > > > + - reg
> > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > +
> > > > > > > > > > > +dependencies:
> > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > +
> > > > > > > > > > > +allOf:
> > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > +
> > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +examples:
> > > > > > > > > > > + - |
> > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > +
> > > > > > > > > > > + spi {
> > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > +
> > > > > > > > > > > + dac@0 {
> > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > +
> > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > +
> > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > +
> > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > +
> > > > > > > > > > > + channel@0 {
> > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > +
> > > > > > > > > > > + channel@1 {
> > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > +
> > > > > > > > > > > + channel@2 {
> > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > + };
> > > > > > > > > > > + };
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > spi {
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > multi-dac@0 {
> > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > reg = <0>;
> > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > dac@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > >
> > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > channel@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@2 {
> > > > > > > > > > reg = <2>;
> > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > };
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > dac@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > >
> > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > channel@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > };
> > > > > > > > > > }
> > > > > > > > > > };
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > then you might need something like:
> > > > > > > > > >
> > > > > > > > > > patternProperties:
> > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > >
> > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > >
> > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > >
> > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > Hi Rodrigo,
> > > > > > > > >
> > > > > > > > > Thank you for looking at this.
> > > > > > > > >
> > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > speculatively without a validating use case.
> > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > >
> > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > >
> > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > longer term how to support it cleanly in SPI.
> > > > > >
> > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > see if I can find what I am thinking of...
> > > > >
> > > > >
> > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > slightly different properties.
> > > > >
> > > > > microchip,device-addr:
> > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > enum: [0, 1, 2, 3]
> > > > > default: 0
> > > > >
> > > > > and
> > > > >
> > > > >
> > > > > microchip,hw-device-address:
> > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > minimum: 0
> > > > > maximum: 3
> > > > > description:
> > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > The device address is part of the device markings to avoid
> > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > addresses are available when multiple devices are present on the same
> > > > > SPI bus with only one Chip Select line for all devices.
> > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > which is first one on the wire).
> > > > >
> > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > here?
> > > > >
> > > >
> > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > about solving this at the spi level.
> > > >
> > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > together in the same bus.
> > >
> > > I'm definitely missing something, because that property for the
> > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > are completely different devices with different drivers. They have
> > > individual device nodes and their own supplies etc etc. These aren't
> > > per-channel properties on an adc or dac, they're per child device on a
> > > spi bus.
> >
> > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > devices on the same CS right? Because for this chip we would need
> > something like:
> >
> > spi {
> > dac@0 {
> > reg = <0>;
> > adi,pin-id = <0>;
> > };
> >
> > dac@1 {
> > reg = <0>; // which seems already problematic?
> > adi,pin-id <1>;
> > };
> >
> > ...
> >
> > //up to 4
> > };
> Yeah. It's not clear to me how that works for the microchip devices
> (I suspect it doesn't!)
>
> Just thinking as I type, but could we do something a bit nasty with
> a gpio mux that doesn't actually switch but represents the GPIO being
> shared? Given this is all tied to the spi bus that should all happen
> under serializing locks.
>
> Agreed though that this would be nicer as an SPI thing that let
> us specify that a single CS is share by multiple devices and their
> is some other signal acting to select which one we are talking to.
>
If the device-addressing on the same chip-select is to be handled
by the spi framework, wouldn't we lose device-specific features?
I understand that this multi-device feature is there mostly to extend the
channel count from 16 to 32, 48 or 64. I suppose the command:
"MULTI DEVICE SW LDAC MODE"
exists so that software can update channel values accross multiple devices.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox