* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 16:51 UTC (permalink / raw)
To: Randy Dunlap
Cc: Peter Zijlstra, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, 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: <08b3c961-18bb-43d9-8d7f-8a87bcad0afa@infradead.org>
On Mon, 22 Jun 2026 09:40:45 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> > Did you forget your C 101 class? If you use a function, you gotta
> > include the relevant header.
>
> Also item #1 in Documentation/process/submit-checklist.rst.
What is that? Remove all trace_printk()s before you submit?
Because that is what you should do. But now you also need to remember
to remove the include <linux/trace_printk.h> too. Or, I guess if
someone uses it a lot, they may just keep it in their files without the
trace_printk()s.
-- Steve
^ permalink raw reply
* Re: [PATCH RFC v5 5/6] iio: osf: add UART transport
From: Jonathan Cameron @ 2026-06-22 16:49 UTC (permalink / raw)
To: Jinseob Kim
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-6-kimjinseob88@gmail.com>
On Tue, 16 Jun 2026 16:22:41 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:
> Add the serdev UART transport and the initial OSF core receive path.
>
> Enable the required vcc regulator with devm_regulator_get_enable()
> before opening the UART, keeping power handling limited to the simple
> probe-time requirement for this RFC.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
A few things inline.
Thanks,
Jonathan
> diff --git a/drivers/iio/opensensorfusion/Kconfig b/drivers/iio/opensensorfusion/Kconfig
> new file mode 100644
> index 000000000..d393eb3aa
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config OPEN_SENSOR_FUSION
> + tristate "Open Sensor Fusion UART IIO driver"
> + depends on IIO
> + depends on SERIAL_DEV_BUS
> + select CRC32
> + help
> + Build the Open Sensor Fusion UART receive path.
> +
> + The driver receives OSF protocol frames over a serdev UART.
> + Frames are decoded and validated before being passed to the
> + driver core.
> + This patch only adds the transport path.
> + IIO device registration is added separately.
Don't talk about a patch in here. Talk about what is supported then
if you really want to add the other bits in later patches. Mostly
this help is generic enough we don't need to modify it more than
once in a series.
> diff --git a/drivers/iio/opensensorfusion/osf_core.c b/drivers/iio/opensensorfusion/osf_core.c
> new file mode 100644
> index 000000000..137fb7166
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_core.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/errno.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +
> +#include "osf_core.h"
> +#include "osf_protocol.h"
> +
> +#define OSF_RESERVED_MSG_FIRST 0x7f00
> +#define OSF_RESERVED_MSG_LAST 0x7fff
> +#define OSF_VENDOR_PRIVATE_FIRST 0x8000
> +
> +void osf_core_init(struct osf_device *osf, struct device *dev)
> +{
> + memset(osf, 0, sizeof(*osf));
*osf = (struct osf_device){
.dev = dev,
};
is guaranteed to also clear all other fields (new C spec as
well as the options the kernel has long been built with)
so is how I would always do cases of zero then set stuff like
this.
> + osf->dev = dev;
> +}
> diff --git a/drivers/iio/opensensorfusion/osf_serdev.c b/drivers/iio/opensensorfusion/osf_serdev.c
> new file mode 100644
> index 000000000..624cb01fe
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_serdev.c
> +
> +static void osf_serdev_remove(struct serdev_device *serdev)
> +{
> + struct osf_serdev *osf_uart = serdev_device_get_drvdata(serdev);
> +
> + serdev_device_close(serdev);
> + osf_stream_reset(&osf_uart->stream);
> + osf_core_unregister_iio(&osf_uart->osf);
My gut feeling is this should be first to tear down the device
interfaces as soon as possible. They will have been initialized
after the serdev was opened so should be unregistered before it is closed.
If there is a reason for this specific order add a comment.
> +}
> +
> +static struct serdev_device_driver osf_serdev_driver = {
> + .probe = osf_serdev_probe,
> + .remove = osf_serdev_remove,
> + .driver = {
> + .name = "open-sensor-fusion-uart",
> + .of_match_table = osf_serdev_of_match,
> + },
> +};
> +
No blank line here as the macro is extremely tightly coupled
with the structure and it is nice to have the visual cue.
> +module_serdev_device_driver(osf_serdev_driver);
> +
> +MODULE_DESCRIPTION("Open Sensor Fusion IIO driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH v3 08/12] fs/resctrl: Make info/kernel_mode writable and identify the bound group
From: Reinette Chatre @ 2026-06-22 16:47 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx, bp,
dave.hansen
Cc: skhan, x86, mingo, hpa, akpm, rdunlap, pawan.kumar.gupta,
feng.tang, dapeng1.mi, kees, elver, lirongqing, paulmck, bhelgaas,
seanjc, alexandre.chartre, yazen.ghannam, peterz, chang.seok.bae,
kim.phillips, xin, naveen, thomas.lendacky, linux-doc,
linux-kernel, eranian, peternewman
In-Reply-To: <280f2dab-56be-49b9-982f-16f01727a732@amd.com>
Hi Babu,
On 6/18/26 6:29 PM, Babu Moger wrote:
> On 6/16/26 18:42, Reinette Chatre wrote:
>> On 4/30/26 4:24 PM, Babu Moger wrote:
...
>>> +/**
>>> + * rdtgroup_config_kmode_clear() - Tear down the kernel-mode binding on @rdtgrp
>>> + * @rdtgrp: Resctrl group whose kernel-mode binding is being released.
>>> + * May be %NULL when no group is currently bound, in which case
>>> + * this is a no-op.
>>> + * @kmode: Kernel-mode policy currently active on @rdtgrp, as a
>>> + * BIT(&enum resctrl_kernel_modes) value. When this is
>>> + * BIT(INHERIT_CTRL_AND_MON) the hardware tear-down is skipped
>>> + * because no MSR was previously programmed.
>>> + *
>>> + * Disables the kernel-mode binding on the CPUs @rdtgrp covers (its
>>> + * @kmode_cpu_mask, or all online CPUs when that mask is empty) and resets
>>> + * the per-group bookkeeping (@kmode and @kmode_cpu_mask). This is the
>>> + * disable counterpart of rdtgroup_config_kmode() and exists so that a write
>>> + * that transitions the active mode to BIT(INHERIT_CTRL_AND_MON) -- which
>>> + * skips rdtgroup_config_kmode() entirely -- still tears down the previously
>>> + * bound group instead of leaving stale enable bits behind.
>>> + *
>>> + * On allocation failure the function returns -ENOMEM and leaves both the
>>> + * hardware state and @rdtgrp's bookkeeping unchanged so the caller can fail
>>> + * the operation atomically and last_cmd_status reflects reality.
>>> + *
>>> + * Context: Caller must hold rdtgroup_mutex.
>>> + *
>>> + * Return: 0 on success (including the @rdtgrp == %NULL and INHERIT cases),
>>> + * -ENOMEM if cpumask allocation fails.
>>> + */
>>> +static int rdtgroup_config_kmode_clear(struct rdtgroup *rdtgrp, int kmode)
>>> +{
>>> + cpumask_var_t disable_mask;
>>> + u32 closid, rmid;
>>> +
>>> + if (!rdtgrp)
>>> + return 0;
>>> +
>>> + if (kmode == BIT(INHERIT_CTRL_AND_MON))
>>> + goto out_clear;
>>> +
>>> + if (!zalloc_cpumask_var(&disable_mask, GFP_KERNEL))
>>> + return -ENOMEM;
>>> +
>>> + if (rdtgrp->type == RDTMON_GROUP) {
>>> + closid = rdtgrp->mon.parent->closid;
>>> + rmid = rdtgrp->mon.rmid;
>>> + } else {
>>> + closid = rdtgrp->closid;
>>> + rmid = rdtgrp->mon.rmid;
>>> + }
>>
>
> I can directly use it like below. I dont need to check for RDTMON_GROUP.
>
> closid = rdtgrp->closid;
> rmid = rdtgrp->mon.rmid;
>
>
>> Same comment as above ... but actually, why is closid/rmid needed at all? This
>> function is intended to *reset* the kernel mode so needing a valid/active closid and
>> rmid does not look right.
>
> This is a bit tricky. I may need CLOSID/RMID in
> resctrl_arch_configure_kmode(). According to the specification, only
> the PLZA_EN field is allowed to differ across CPUs where PLZA is
> enabled; all other fields must remain consistent across CPUs within
> the same domain. If CLOSID/RMID are not passed, it could result in
> inconsistent values across CPUs.
I see. Let's revisit this in next version. It is not quite clear to me how
the rework of cpu_mask wrangling will impact the resctrl_arch_configure_kmode()
calls. To simplify this for now resctrl could continue to provide closid and rmid
to architecture (with the API documentation in include/linux/resctrl.h documenting
why it is provided and that it may be unused by architecture).
>>> +
>>> + /*
>>> + * Split "<mode>:group=<spec>"; the ":group=<spec>" suffix is optional
>>> + * and when omitted the default control group (&rdtgroup_default) is used.
>>> + */
>>> + group_str = strstr(buf, ":group=");
>>> + if (group_str) {
>>> + *group_str = '\0';
>>> + group_str += strlen(":group=");
>>> + }
>>> + mode_str = buf;
>>> +
>>> + mutex_lock(&rdtgroup_mutex);
>>> + rdt_last_cmd_clear();
>>> +
>>> + for (i = 0; i < RESCTRL_NUM_KERNEL_MODES; i++)
>>> + if (!strcmp(mode_str, resctrl_mode_str[i]))
>>> + break;
>>> + if (i == RESCTRL_NUM_KERNEL_MODES) {
>>> + rdt_last_cmd_puts("Unknown kernel mode\n");
>>> + ret = -EINVAL;
>>> + goto out_unlock;
>>> + }
>>> +
>>> + if (!(resctrl_kcfg.kmode & BIT(i))) {
>>> + rdt_last_cmd_puts("Kernel mode not available\n");
>>> + ret = -EINVAL;
>>> + goto out_unlock;
>>> + }
>>> +
>>> + kmode = BIT(i);
>>
>> Can kmode be of enum type to be assigned the actual enum value to avoid all these BIT(enum value) usages?
>
> You mean?
>
> enum resctrl_kernel_modes {
> INHERIT_CTRL_AND_MON = 1U << 0, /* 1 */
> GLOBAL_ASSIGN_CTRL_INHERIT_MON = 1U << 1, /* 2 */
> GLOBAL_ASSIGN_CTRL_ASSIGN_MON = 1U << 2, /* 4 */
> };
>
> #define RESCTRL_NUM_KERNEL_MODES 3
No. I mean:
enum resctrl_kernel_mode kmode;
... with a change like this code like below can be simplified:
>>> + if (kmode == BIT(GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU) &&
kmode == GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU
>>> + rdtgrp->type != RDTMON_GROUP) {
>>> + rdt_last_cmd_puts("global_assign_ctrl_assign_mon_per_cpu requires a monitor group\n");
>>> + ret = -EINVAL;
>>> + goto out_unlock;
>>> + }
>>> + if (kmode == BIT(GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU) &&
kmode == GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU
>>> + rdtgrp->type != RDTCTRL_GROUP) {
>>> + rdt_last_cmd_puts("global_assign_ctrl_inherit_mon_per_cpu requires a control group\n");
>>> + ret = -EINVAL;
>>> + goto out_unlock;
>>> + }
>>> +
Reinette
^ permalink raw reply
* Re: [PATCH RFC v5 3/6] iio: osf: add protocol decoding
From: Jonathan Cameron @ 2026-06-22 16:43 UTC (permalink / raw)
To: Jinseob Kim
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-4-kimjinseob88@gmail.com>
On Tue, 16 Jun 2026 16:22:39 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:
> Add helpers for validating and decoding Open Sensor Fusion frames and the
> message payloads used by the initial receive path.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
A few things inline.
> ---
> drivers/iio/opensensorfusion/osf_protocol.c | 249 ++++++++++++++++++++
> drivers/iio/opensensorfusion/osf_protocol.h | 97 ++++++++
> 2 files changed, 346 insertions(+)
> create mode 100644 drivers/iio/opensensorfusion/osf_protocol.c
> create mode 100644 drivers/iio/opensensorfusion/osf_protocol.h
>
> diff --git a/drivers/iio/opensensorfusion/osf_protocol.c b/drivers/iio/opensensorfusion/osf_protocol.c
> new file mode 100644
> index 000000000..5bee545f3
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_protocol.c
> +int osf_protocol_decode_frame(const u8 *buf, size_t len,
> + struct osf_frame *frame, size_t *frame_len)
> +{
> + u32 expected_crc;
> + u32 actual_crc;
> + u32 payload_len;
> + size_t total_len;
> + u8 major;
> +
> + if (!buf || !frame || !frame_len)
> + return -EINVAL;
> +
> + if (len < OSF_FRAME_MIN_LEN)
> + return -EMSGSIZE;
> +
> + if (get_unaligned_le32(buf) != OSF_FRAME_MAGIC)
> + return -EPROTO;
> +
> + major = buf[4];
> + if (major != OSF_PROTOCOL_MAJOR)
> + return -EPROTO;
> +
> + if (get_unaligned_le16(buf + 6) != OSF_FRAME_HEADER_LEN)
> + return -EPROTO;
> +
> + payload_len = get_unaligned_le32(buf + 10);
> + if (payload_len > len - OSF_FRAME_MIN_LEN)
> + return -EMSGSIZE;
> +
> + if (get_unaligned_le32(buf + 34))
> + return -EPROTO;
> +
> + total_len = OSF_FRAME_HEADER_LEN + payload_len + OSF_FRAME_CRC_LEN;
> + expected_crc = osf_crc32_ieee(buf, OSF_FRAME_HEADER_LEN + payload_len);
> + actual_crc = get_unaligned_le32(buf + OSF_FRAME_HEADER_LEN + payload_len);
> +
> + if (actual_crc != expected_crc)
> + return -EBADMSG;
> +
> + frame->protocol_minor = buf[5];
> + frame->message_type = get_unaligned_le16(buf + 8);
> + frame->payload_len = payload_len;
> + frame->sequence = get_unaligned_le64(buf + 14);
> + frame->timestamp_us = get_unaligned_le64(buf + 22);
> + frame->flags = get_unaligned_le32(buf + 30);
> + frame->payload = buf + OSF_FRAME_HEADER_LEN;
> + frame->crc = actual_crc;
Same as below wrt to to using designated initializers for these
structure fills
> + *frame_len = total_len;
> +
> + return 0;
> +}
> +
> +int osf_protocol_decode_sensor_sample(const struct osf_frame *frame,
> + struct osf_sensor_sample *sample)
> +{
> + u16 channel_count;
> + u16 sample_format;
> + u16 sensor_type;
> + size_t expected_len;
> + const u8 *payload;
> +
> + if (!frame || !sample || !frame->payload)
> + return -EINVAL;
> +
> + if (frame->message_type != OSF_MSG_SENSOR_SAMPLE)
> + return -EPROTO;
> +
> + if (frame->payload_len < OSF_SENSOR_SAMPLE_BASE_LEN)
> + return -EMSGSIZE;
> +
> + payload = frame->payload;
> + sensor_type = get_unaligned_le16(payload);
> + channel_count = get_unaligned_le16(payload + 4);
> + sample_format = get_unaligned_le16(payload + 6);
> +
> + if (!osf_sensor_type_valid(sensor_type))
> + return -EPROTO;
> +
> + if (!channel_count)
> + return -EPROTO;
> +
> + if (sample_format != OSF_SAMPLE_FORMAT_S32)
> + return -EPROTO;
> +
> + if (get_unaligned_le32(payload + 12))
> + return -EPROTO;
> +
> + if (channel_count > (SIZE_MAX - OSF_SENSOR_SAMPLE_BASE_LEN) / sizeof(s32))
> + return -EOVERFLOW;
> +
> + expected_len = OSF_SENSOR_SAMPLE_BASE_LEN + channel_count * sizeof(s32);
> + if (frame->payload_len != expected_len)
> + return -EMSGSIZE;
> +
> + sample->sensor_type = sensor_type;
> + sample->sensor_index = get_unaligned_le16(payload + 2);
> + sample->channel_count = channel_count;
> + sample->sample_format = sample_format;
> + sample->scale_nano = get_unaligned_le32(payload + 8);
> + sample->samples = payload + OSF_SENSOR_SAMPLE_BASE_LEN;
See below. Designated initializer would help readability a little here.
> +
> + return 0;
> +}
> +
> +int osf_protocol_sensor_sample_value(const struct osf_sensor_sample *sample,
> + unsigned int index, s32 *value)
Given channel count is a u16 and we can't be equal or bigger than it, perhaps
use a u16 for index as well.
> +{
> + if (!sample || !sample->samples || !value)
> + return -EINVAL;
> +
> + if (index >= sample->channel_count)
> + return -ERANGE;
> +
> + /* Samples are little-endian two's-complement signed values. */
> + *value = (s32)get_unaligned_le32(sample->samples + index * sizeof(s32));
sizeof(__le32) slightly more appropriate given that is what you are treating it
as.
> +
> + return 0;
> +}
> +
> +int osf_protocol_decode_device_status(const struct osf_frame *frame,
> + struct osf_device_status *status)
> +{
> + const u8 *payload;
> +
> + if (!frame || !status || !frame->payload)
> + return -EINVAL;
> +
> + if (frame->message_type != OSF_MSG_DEVICE_STATUS)
> + return -EPROTO;
> +
> + if (frame->payload_len != OSF_DEVICE_STATUS_LEN)
> + return -EMSGSIZE;
> +
> + payload = frame->payload;
> + if (get_unaligned_le32(payload + 16))
> + return -EPROTO;
> +
> + status->uptime_s = get_unaligned_le32(payload);
> + status->status_flags = get_unaligned_le32(payload + 4);
> + status->error_flags = get_unaligned_le32(payload + 8);
> + status->dropped_frames = get_unaligned_le32(payload + 12);
Similar to below. I'd use a designated initializer for status as it
is all written in one place.
> +
> + return 0;
> +}
> +
> +int osf_protocol_decode_capability_entry(const struct osf_capability_report *report,
> + unsigned int index,
> + struct osf_capability_entry *entry)
> +{
> + u16 sample_format;
> + u16 sensor_type;
> + u32 flags;
> + const u8 *payload;
> +
> + if (!report || !report->entries || !entry)
> + return -EINVAL;
> +
> + if (index >= report->capability_count)
Neater to size index to match capability_count. Not that
important though.
> + return -ERANGE;
> +
> + payload = report->entries + index * OSF_CAP_SENSOR_ENTRY_LEN;
> + sensor_type = get_unaligned_le16(payload);
> + sample_format = get_unaligned_le16(payload + 6);
> + flags = get_unaligned_le32(payload + 12);
> +
> + if (!osf_sensor_type_valid(sensor_type))
> + return -EPROTO;
> +
> + if (sample_format != OSF_SAMPLE_FORMAT_S32)
> + return -EPROTO;
> +
> + if (flags & ~OSF_CAPABILITY_FLAGS_MASK)
> + return -EPROTO;
> +
> + if (get_unaligned_le32(payload + 16))
> + return -EPROTO;
> +
> + entry->sensor_type = sensor_type;
> + entry->sensor_index = get_unaligned_le16(payload + 2);
> + entry->channel_count = get_unaligned_le16(payload + 4);
> + entry->sample_format = sample_format;
> + entry->scale_nano = get_unaligned_le32(payload + 8);
> + entry->flags = flags;
neater as designated initializer I think.
*entry = (struct osf_capability_entry) {
.sensor_type = sensor_type,
.sensor_index = get_unaligned_le16(payload + 2),
etc
};
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH] Docs/admin-guide/cgroup-v2: fix memory.stat doc details
From: Nhat Pham @ 2026-06-22 16:41 UTC (permalink / raw)
To: Doehyun Baek
Cc: Tejun Heo, Jonathan Corbet, Johannes Weiner, Michal Koutný,
Andrew Morton, Shakeel Butt, Roman Gushchin, Yosry Ahmed, cgroups,
linux-doc, linux-kernel
In-Reply-To: <20260620122751.388770-1-doehyunbaek@gmail.com>
On Sat, Jun 20, 2026 at 5:28 AM Doehyun Baek <doehyunbaek@gmail.com> wrote:
>
> Fix minor cgroup v2 memory.stat documentation issues. Correct the
> vmalloc per-node marker now that vmalloc uses the native NR_VMALLOC node
> stat, and document zswap_incomp as a byte-valued memory amount instead
> of as a page counter.
>
> Fixes: c466412c73c3 ("mm: memcontrol: switch to native NR_VMALLOC vmstat counter")
> Fixes: 5ad41a38c364 ("mm: zswap: add per-memcg stat for incompressible pages")
> Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
> - Number of incompressible pages currently stored in zswap
> + Amount of memory used by incompressible pages currently stored in zswap
> without compression. These pages could not be compressed to
> a size smaller than PAGE_SIZE, so they are stored as-is.
>
Good catch :)
Reviewed-by: Nhat Pham <nphamcs@gmail.com>
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Randy Dunlap @ 2026-06-22 16:40 UTC (permalink / raw)
To: Peter Zijlstra, Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
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: <20260622083440.GX49951@noisy.programming.kicks-ass.net>
On 6/22/26 1:34 AM, Peter Zijlstra wrote:
> On Sun, Jun 21, 2026 at 05:34:30AM -0400, Steven Rostedt 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.
>>
>> Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
>> use it can set and not have to always remember to add #include <linux/trace_printk.h>
>> to the files they add trace_printk() while debugging. It also means that
>> those that do not have that config set will not have to worry about wasted
>> CPU cycles as it is only include in the CFLAGS when the option is set, and
>> its completely ignored otherwise.
>
> Did you forget your C 101 class? If you use a function, you gotta
> include the relevant header.
Also item #1 in Documentation/process/submit-checklist.rst.
> You don't see userspace saying: 'Hey, you know what, perhaps we should
> add stdio.h to every other header, just in case someone wants to
> printf()' either.
>
> I really don't understand your argument. Yes, maybe someone will forget
> and then either their editor (if they have a halfway modern setup with
> LSP enabled) or their build will complain, but so what? This is all
> trivial stuff, surely we have more pressing matters to concern outselves
> with?
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 06/12] fs/resctrl: Initialize the global kernel-mode policy at subsystem init
From: Babu Moger @ 2026-06-22 16:38 UTC (permalink / raw)
To: Reinette Chatre, corbet, tony.luck, Dave.Martin, james.morse,
tglx, bp, dave.hansen
Cc: skhan, x86, mingo, hpa, akpm, rdunlap, pawan.kumar.gupta,
feng.tang, dapeng1.mi, kees, elver, lirongqing, paulmck, bhelgaas,
seanjc, alexandre.chartre, yazen.ghannam, peterz, chang.seok.bae,
kim.phillips, xin, naveen, thomas.lendacky, linux-doc,
linux-kernel, eranian, peternewman
In-Reply-To: <737a4228-52fb-4583-ac64-8efe79c107e6@intel.com>
Hi Reinette,
On 6/22/26 11:21, Reinette Chatre wrote:
> Hi Babu,
>
> On 6/18/26 10:14 AM, Babu Moger wrote:
>> On 6/16/26 18:36, Reinette Chatre wrote:
>>> On 4/30/26 4:24 PM, Babu Moger wrote:
>
>>>
>>>> - calls resctrl_arch_get_kmode_support() so each architecture ORs
>>>> BIT(<mode>) into kmode for the policies its hardware supports
>>>> (on x86, AMD PLZA contributes the two global-assign modes).
>>>>
>>>> resctrl_kmode_init() runs from resctrl_init() once the default group
>>>
>>> resctrl_kmode_init() can be dropped after changes described in response
>>> to previous patch. Apart from no longer being necessary I also find that
>>> having the kernel mode fully initialized *before* the hotplug handlers run
>>> to be simpler.
>>
>> That means resctrl_set_kmode_support() will be called from the architecture layer, likely from core.c within get_rdt_alloc_resources().
>>
>> The resctrl_set_kmode_support() handler would need to initialize both the default mode and all supported modes.
>
> I see this differently. Since resctrl_set_kmode_support() is optional for an architecture
> resctrl fs can just statically initialize the defaults. resctrl_set_kmode_support() would
> expand the defaults to also accommodate what the architecture supports.
>
Yes. We can do that.
thanks
Babu
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property
From: Javier Carrasco @ 2026-06-22 16:29 UTC (permalink / raw)
To: Flaviu Nistor, Guenter Roeck, Javier Carrasco, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, linux-kernel, devicetree, linux-doc
In-Reply-To: <20260622122200.14245-1-flaviu.nistor@gmail.com>
On Mon Jun 22, 2026 at 2:21 PM CEST, Flaviu Nistor wrote:
> 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>;
> };
> };
Hello Falviu, thank you for your patch.
Should we not add a reference to hwmon-common.yaml (with
unevelautedProperties instead of additionalProperties), as label is
defined there? I believe that Krzysztof Kozlowski did something similar
for the shunt-resistor-micro-ohms property. Could we follow suit here?
I am also not a big fan of a name like "somelabel", and a more
meaningful name from a "real" example would look better. I know that
some examples have already used "somelabel" as an example, but others
have used more meaningful names too.
Best regards,
Javier Carrasco
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-06-22 16:29 UTC (permalink / raw)
To: Nuno Sá
Cc: Rodrigo Alencar, 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 Mon, 22 Jun 2026 11:29:38 +0100
Nuno Sá <noname.nuno@gmail.com> 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).
>
> 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.
Agreed - if we have messages that address both devices at once that needs
to be a unified driver and given they are about triggering simultaneous
update of all channels it needs to look like one big device.
This ends up similar to how we handle daisy chain devices.
The question of what to do on devices that don't have this feature
is rather different. Good thing you read the datasheet :)
Jonathan
>
> - Nuno Sá
>
> >
> > --
> > Kind regards,
> >
> > Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH] Docs/admin-guide/cgroup-v2: fix memory.stat doc details
From: Michal Koutný @ 2026-06-22 16:25 UTC (permalink / raw)
To: Doehyun Baek
Cc: Tejun Heo, Jonathan Corbet, Johannes Weiner, Andrew Morton,
Shakeel Butt, Roman Gushchin, Yosry Ahmed, Nhat Pham, cgroups,
linux-doc, linux-kernel
In-Reply-To: <CAN-j9Upy=thswORWaU+QxuO2i8uJKrZxcLpt5umP5QGRhpwqaQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
On Mon, Jun 22, 2026 at 05:26:53PM +0200, Doehyun Baek <doehyunbaek@gmail.com> wrote:
> However, both zswapped and zswap_incomp are memory_stats[] entries, so
> memory.stat prints them through memcg_page_state_output(). Since
> MEMCG_ZSWAP_INCOMP is not special-cased as a raw count, the stored page
> count is multiplied by the default PAGE_SIZE unit and exported as bytes.
>
> unsigned long memcg_page_state_output(struct mem_cgroup *memcg, int item)
> {
> return memcg_page_state(memcg, item) *
> memcg_page_state_output_unit(item);
> }
Ah, I messed up how memcg_page_state_output_unit() is used. The printed
values are amounts (in bytes).
> Separately, this matches the existing documentation style for zswapped,
> whose exported value is described as a memory amount:
>
> zswapped
> Amount of application memory swapped out to zswap.
>
> Since zswap_incomp follows the same memory.stat output path, I think its
> documentation should describe the exported value as a memory amount too.
>
> I also boot-tested this in QEMU with the current tree and zswap enabled.
> With incompressible pages pushed into zswap, memory.stat showed:
>
> zswap 87822336
> zswapped 87822336
> zswap_incomp 87822336
Thanks for the test and for the fix!
>
> The zswap_incomp value there is byte-valued; it is not a plain page
> count. It also matches zswapped in this all-incompressible case, which
> is consistent with both being exported as memory amounts.
Acked-by: Michal Koutný <mkoutny@suse.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-06-22 16:24 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: <ajkILRPq_g24g4dH@nsa>
On Mon, 22 Jun 2026 11:17:56 +0100
Nuno Sá <noname.nuno@gmail.com> 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?
Nope. It is what you suggest - the implementation in the gpio layer
is to detect the reuse of the same GPIO and insert a proxy layer that
allows multiple consumers. I think that will provide different gpio
numbers (well descs really) to each of them but I haven't checked the details
that closely.
>
> 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.
Yup. As much as we have an ack on SPI. So with a write only message you'd never
know if anyone got it.
Jonathan
>
> - Nuno Sá
>
> > Jonathan
> >
> > >
> > > - Nuno Sá
> > >
> >
>
^ permalink raw reply
* Re: [PATCH v3 06/12] fs/resctrl: Initialize the global kernel-mode policy at subsystem init
From: Reinette Chatre @ 2026-06-22 16:21 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx, bp,
dave.hansen
Cc: skhan, x86, mingo, hpa, akpm, rdunlap, pawan.kumar.gupta,
feng.tang, dapeng1.mi, kees, elver, lirongqing, paulmck, bhelgaas,
seanjc, alexandre.chartre, yazen.ghannam, peterz, chang.seok.bae,
kim.phillips, xin, naveen, thomas.lendacky, linux-doc,
linux-kernel, eranian, peternewman
In-Reply-To: <416d685f-9e76-415a-bbb0-fc89f87827d9@amd.com>
Hi Babu,
On 6/18/26 10:14 AM, Babu Moger wrote:
> On 6/16/26 18:36, Reinette Chatre wrote:
>> On 4/30/26 4:24 PM, Babu Moger wrote:
>>
>>> - calls resctrl_arch_get_kmode_support() so each architecture ORs
>>> BIT(<mode>) into kmode for the policies its hardware supports
>>> (on x86, AMD PLZA contributes the two global-assign modes).
>>>
>>> resctrl_kmode_init() runs from resctrl_init() once the default group
>>
>> resctrl_kmode_init() can be dropped after changes described in response
>> to previous patch. Apart from no longer being necessary I also find that
>> having the kernel mode fully initialized *before* the hotplug handlers run
>> to be simpler.
>
> That means resctrl_set_kmode_support() will be called from the architecture layer, likely from core.c within get_rdt_alloc_resources().
>
> The resctrl_set_kmode_support() handler would need to initialize both the default mode and all supported modes.
I see this differently. Since resctrl_set_kmode_support() is optional for an architecture
resctrl fs can just statically initialize the defaults. resctrl_set_kmode_support() would
expand the defaults to also accommodate what the architecture supports.
Reinette
^ permalink raw reply
* Re: [PATCH RFC v5 2/6] Documentation: iio: add Open Sensor Fusion driver overview
From: Jonathan Cameron @ 2026-06-22 16:21 UTC (permalink / raw)
To: Jinseob Kim
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-3-kimjinseob88@gmail.com>
On Tue, 16 Jun 2026 16:22:38 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:
> Document the Linux IIO mapping for Open Sensor Fusion devices, including
> capability-driven IIO device registration and the initially supported
> receive path.
>
> Call out that OSF0 is a wire magic value, while protocol_major and
> protocol_minor carry protocol compatibility inside frames. The Linux
> compatible remains the generic Open Sensor Fusion host interface.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
Just one small thing inline.
Otherwise this look good to me.
Thanks,
Jonathan
> ---
> Documentation/iio/index.rst | 1 +
> Documentation/iio/open-sensor-fusion.rst | 71 ++++++++++++++++++++++++
> 2 files changed, 72 insertions(+)
> create mode 100644 Documentation/iio/open-sensor-fusion.rst
>
> diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
> index ba3e609c6..2713ec5e0 100644
> --- a/Documentation/iio/index.rst
> +++ b/Documentation/iio/index.rst
> @@ -38,4 +38,5 @@ Industrial I/O Kernel Drivers
> adxl345
> bno055
> ep93xx_adc
> + open-sensor-fusion
> opt4060
> diff --git a/Documentation/iio/open-sensor-fusion.rst b/Documentation/iio/open-sensor-fusion.rst
> new file mode 100644
> index 000000000..cf3bbd761
> --- /dev/null
> +++ b/Documentation/iio/open-sensor-fusion.rst
> @@ -0,0 +1,71 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +Open Sensor Fusion
> +==================
> +
> +Open Sensor Fusion is a sensor aggregation hub interface. The Linux IIO driver
> +receives OSF protocol frames from an attached device, discovers supported sensor
> +streams through capability reports, and registers matching IIO devices for the
> +sensor classes supported by the driver.
> +
> +This document is a driver-facing overview for the Linux IIO mapping. The full
> +wire protocol, firmware behavior, and hardware model details belong in the Open
> +Sensor Fusion project documentation.
> +
> +Device Model
> +------------
> +
> +An OSF device sends binary frames from the device to the host. The host driver
> +uses ``CAPABILITY_REPORT`` messages to discover which sensor streams are
> +available. Device Tree describes the attached OSF sensor aggregation hub; it does
> +not enumerate the individual sensors discovered at runtime.
> +
> +The currently supported Linux subset exposes:
> +
> +* accelerometer samples as ``IIO_ACCEL`` X/Y/Z channels,
> +* gyroscope samples as ``IIO_ANGL_VEL`` X/Y/Z channels,
> +* magnetometer samples as ``IIO_MAGN`` X/Y/Z channels, and
> +* temperature samples as ``IIO_TEMP``.
> +
> +Protocol Scope
> +---------------
> +
> +The driver supports OSF protocol major version 0 for the initial IIO receive
> +path. The current wire magic is ``OSF0``; that string is a wire-format detail and
> +is not the Linux driver identity. Device Tree keeps the generic
> +``opensensorfusion,osf`` compatible rather than naming a product such as OSF
> +GREEN or a wire magic value.
I'd remove anything that is documented elsewhere (i.e. the dt-binding)
and instead use a cross reference to it. That will reduce the chance of this getting
out of sync.
> +
> +Protocol versioning is carried by the ``protocol_major`` and ``protocol_minor``
> +fields at fixed offsets in the OSF frame header. The driver currently
> +supports ``protocol_major`` 0. ``protocol_minor`` changes within major version
> +0 are intended to remain backward-compatible within the fixed header layout.
> +Incompatible wire-format changes require a new ``protocol_major``. A future
> +device that cannot expose compatible version discovery through that fixed
> +header layout would need a different Device Tree compatible.
> +
> +The initial Linux driver handles device-to-host frames for:
> +
> +* ``SENSOR_SAMPLE`` buffered and direct-mode sample data,
> +* ``CAPABILITY_REPORT`` based IIO device registration, and
> +* ``DEVICE_STATUS`` cache updates.
> +
> +Vendor-private message types are ignored. Command transport, calibration
> +control ABI, fusion output ABI, and runtime capability removal are outside the
> +initial Linux IIO receive path.
> +
> +Timestamps
> +----------
> +
> +OSF frames include a device-side ``timestamp_us`` field. Buffered IIO samples use
> +an IIO timestamp captured on the host when samples are pushed to IIO buffers.
> +The initial driver does not correlate the device timestamp with the host IIO
> +clock.
> +
> +Compatibility Notes
> +-------------------
> +
> +The project protocol documentation should define the compatibility rules for
> +reserved fields, optional flags, and trailing extension data. Until those rules
> +are finalized, the Linux decoder keeps conservative bounds checks around the
> +currently supported message layouts.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: David Lechner @ 2026-06-22 15:36 UTC (permalink / raw)
To: Nuno Sá, Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, 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: <ajklksIDLsj0BZul@nsa>
On 6/22/26 7:20 AM, Nuno Sá wrote:
> 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á
I think I mentioned this on a previous revision, but I still think the
simplest way to go about it would be to assume that all chips treated
as an aggregate device have everything wired in parallel and just add
support for per-chip wiring on an as-needed basis. This is how we have
handled daisy-chained devices so far.
^ permalink raw reply
* Re: [PATCH] Docs/admin-guide/cgroup-v2: fix memory.stat doc details
From: Doehyun Baek @ 2026-06-22 15:26 UTC (permalink / raw)
To: Michal Koutný
Cc: Tejun Heo, Jonathan Corbet, Johannes Weiner, Andrew Morton,
Shakeel Butt, Roman Gushchin, Yosry Ahmed, Nhat Pham, cgroups,
linux-doc, linux-kernel
In-Reply-To: <ajlLhFnMZGoVxLE6@localhost.localdomain>
> ...but what do you mean by this?
> As I'm looking at the code in obj_cgroup_charge_zswap() and
> memcg_page_state_output_unit(), I'd say those are pages and the docs is
> thus alright.
>
> Thanks,
> Michal
Thanks for taking a look.
I agree that the counters are pages internally. I was talking about what
gets printed in memory.stat.
The internal updates are page-count based:
mod_memcg_state(memcg, MEMCG_ZSWAPPED, 1);
if (size == PAGE_SIZE)
mod_memcg_state(memcg, MEMCG_ZSWAP_INCOMP, 1);
However, both zswapped and zswap_incomp are memory_stats[] entries, so
memory.stat prints them through memcg_page_state_output(). Since
MEMCG_ZSWAP_INCOMP is not special-cased as a raw count, the stored page
count is multiplied by the default PAGE_SIZE unit and exported as bytes.
unsigned long memcg_page_state_output(struct mem_cgroup *memcg, int item)
{
return memcg_page_state(memcg, item) *
memcg_page_state_output_unit(item);
}
Separately, this matches the existing documentation style for zswapped,
whose exported value is described as a memory amount:
zswapped
Amount of application memory swapped out to zswap.
Since zswap_incomp follows the same memory.stat output path, I think its
documentation should describe the exported value as a memory amount too.
I also boot-tested this in QEMU with the current tree and zswap enabled.
With incompressible pages pushed into zswap, memory.stat showed:
zswap 87822336
zswapped 87822336
zswap_incomp 87822336
The zswap_incomp value there is byte-valued; it is not a plain page
count. It also matches zswapped in this all-incompressible case, which
is consistent with both being exported as memory amounts.
Best,
Doehyun Baek
^ permalink raw reply
* Re: [PATCH] Docs/admin-guide/cgroup-v2: fix memory.stat doc details
From: Michal Koutný @ 2026-06-22 14:59 UTC (permalink / raw)
To: Doehyun Baek
Cc: Tejun Heo, Jonathan Corbet, Johannes Weiner, Andrew Morton,
Shakeel Butt, Roman Gushchin, Yosry Ahmed, Nhat Pham, cgroups,
linux-doc, linux-kernel
In-Reply-To: <20260620122751.388770-1-doehyunbaek@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
On Sat, Jun 20, 2026 at 12:27:51PM +0000, Doehyun Baek <doehyunbaek@gmail.com> wrote:
> Fix minor cgroup v2 memory.stat documentation issues. Correct the
> vmalloc per-node marker now that vmalloc uses the native NR_VMALLOC node
> stat, and document zswap_incomp as a byte-valued memory amount instead
> of as a page counter.
>
> Fixes: c466412c73c3 ("mm: memcontrol: switch to native NR_VMALLOC vmstat counter")
> Fixes: 5ad41a38c364 ("mm: zswap: add per-memcg stat for incompressible pages")
> Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
> ---
> Documentation/admin-guide/cgroup-v2.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> index 993446ab66d0..ce6741f78f4f 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1570,7 +1570,7 @@ The following nested keys are defined.
> sock (npn)
> Amount of memory used in network transmission buffers
>
> - vmalloc (npn)
> + vmalloc
> Amount of memory used for vmap backed memory.
The vmalloc change looks OK...
>
> shmem
> @@ -1735,7 +1735,7 @@ The following nested keys are defined.
> Number of pages written from zswap to swap.
>
> zswap_incomp
> - Number of incompressible pages currently stored in zswap
> + Amount of memory used by incompressible pages currently stored in zswap
> without compression. These pages could not be compressed to
> a size smaller than PAGE_SIZE, so they are stored as-is.
...but what do you mean by this?
As I'm looking at the code in obj_cgroup_charge_zswap() and
memcg_page_state_output_unit(), I'd say those are pages and the docs is
thus alright.
Thanks,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] nfs: remove the fileid field from struct nfs_inode
From: Anna Schumaker @ 2026-06-22 14:45 UTC (permalink / raw)
To: Jeff Layton, Trond Myklebust, Jonathan Corbet, Shuah Khan
Cc: linux-nfs, linux-kernel, linux-doc
In-Reply-To: <d0daedc8491e046c036bfe4e6915dc677e79428e.camel@kernel.org>
Hi Jeff,
On Sat, Jun 20, 2026, at 9:06 PM, Jeff Layton wrote:
> On Tue, 2026-05-12 at 12:12 -0400, 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>
>> ---
>> Jeff Layton (4):
>> nfs: store the full NFS fileid in inode->i_ino
>> nfs: remove nfs_compat_user_ino64() and deprecate enable_ino64
>> nfs: replace NFS_FILEID() and nfsi->fileid with inode->i_ino
>> nfs: remove fileid field from struct nfs_inode
>>
>> Documentation/admin-guide/kernel-parameters.txt | 7 --
>> fs/nfs/dir.c | 4 +-
>> fs/nfs/export.c | 6 +-
>> fs/nfs/filelayout/filelayout.c | 4 +-
>> fs/nfs/flexfilelayout/flexfilelayout.c | 6 +-
>> fs/nfs/inode.c | 87 +++++++++----------------
>> fs/nfs/nfs4proc.c | 4 +-
>> fs/nfs/nfs4trace.h | 79 ++++++++++------------
>> fs/nfs/nfstrace.h | 84 ++++++++++++------------
>> fs/nfs/pagelist.c | 2 +-
>> fs/nfs/pnfs.c | 2 +-
>> fs/nfs/unlink.c | 2 +-
>> fs/nfs/write.c | 2 +-
>> include/linux/nfs_fs.h | 25 -------
>> 14 files changed, 123 insertions(+), 191 deletions(-)
>> ---
>> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
>> change-id: 20260512-nfsino-1f9a8ca2f3ed
>>
>> Best regards,
>
> Ping?
>
> i just noticed that this never made v7.2. Maybe consider for v7.3?
These are actually the first four patches in my linux-next branch for
the pull request I'm planning on sending (hopefully) later today.
Anna
> --
> Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH] Documentation: tracing: fix typo in events documentation
From: Yudistira Putra @ 2026-06-22 14:37 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
linux-trace-kernel, linux-doc, linux-kernel, Yudistira Putra
Fix a typo in the tracing events documentation: "can by built up"
should be "can be built up".
Signed-off-by: Yudistira Putra <pyudistira519@gmail.com>
---
Documentation/trace/events.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index 18d112963dec..581f2260614b 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -1064,7 +1064,7 @@ correct command type, and a pointer to an event-specific run_command()
callback that will be called to actually execute the event-specific
command function.
-Once that's done, the command string can by built up by successive
+Once that's done, the command string can be built up by successive
calls to argument-adding functions.
To add a single argument, define and initialize a struct dynevent_arg
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Marek Vasut @ 2026-06-22 14:22 UTC (permalink / raw)
To: Geert Uytterhoeven, 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: <CAMuHMdUxT87M1oQvPP_h4YX4vXFaVbbG+LCG8EdmuLTuHNtybQ@mail.gmail.com>
On 6/22/26 11:52 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +++ 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...
I will fix that in V3. Thank you !
^ permalink raw reply
* Re: [Question] 5.posting.rst use To: or Cc:
From: Krzysztof Kozlowski @ 2026-06-22 14:15 UTC (permalink / raw)
To: Jonathan Corbet, Manuel Ebner, Shuah Khan,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <87ik7o9bj0.fsf@trenco.lwn.net>
On 12/06/2026 14:41, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
>> so every time I send a mail to lists or maintainers I have to choose: To:
>> or Cc:. I did look for an answer in the Documentation but couldn't find
>> one.
>> I think if there is an answer then it could be added to 5.posting.rst .
>
> Normally you would To: the maintainers, CC: the rest, but the end result
> is the same either way - it really doesn't matter.
>
Yes and 'b4' follows that logic. I think I saw only one case when
maintainer relied on actual To/Cc difference, but it was pointed out
that it is fragile and there is no unified rule.
Regardless, just use b4 to contribute patches because it solves all such
process issues. And whenever process is different, we tend to
fix/improve b4 to implement it correctly or we should change the
process, because in general we should not have rules which cannot be
implemented in toolset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] hwmon: add Stratix 10 SoC FPGA hardware monitor driver
From: Krzysztof Kozlowski @ 2026-06-22 14:08 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <081650bc4d92e9497b7a5a926e79a067cca3519f.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:55AM -0700, tze.yee.ng@altera.com wrote:
> + dev_warn(dev, "unsupported sensor type %s\n", type);
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe_child_from_dt(struct device *dev,
> + struct device_node *child,
np
> + struct stratix10_hwmon_priv *priv)
> +{
> + struct device_node *grandchild;
child
> + const char *label;
> + u32 val;
> + int ret;
> +
> + for_each_child_of_node(child, grandchild) {
child
> + ret = of_property_read_u32(grandchild, "reg", &val);
> + if (ret) {
> + dev_err(dev, "missing reg property of %pOFn\n",
> + grandchild);
> + of_node_put(grandchild);
> + return ret;
> + }
> +
> + ret = of_property_read_string(grandchild, "label", &label);
> + if (ret)
> + label = grandchild->name;
> +
> + stratix10_hwmon_add_channel(dev, child->name, val, label, priv);
> + }
> +
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe_from_dt(struct device *dev,
> + struct stratix10_hwmon_priv *priv)
> +{
> + struct device_node *child;
> + int ret;
> +
> + if (!dev->of_node)
> + return 0;
> +
> + for_each_child_of_node(dev->of_node, child) {
Just use scoped. And why not available child node? Why do you probe
disabled channels?
> + ret = stratix10_hwmon_probe_child_from_dt(dev, child, priv);
> + if (ret) {
> + of_node_put(child);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct stratix10_hwmon_priv *priv;
> + struct device *hwmon_dev;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->client.dev = dev;
> + priv->client.priv = priv;
> + init_completion(&priv->completion);
> + mutex_init(&priv->lock);
> +
> + ret = stratix10_hwmon_probe_from_dt(dev, priv);
> + if (ret) {
> + dev_err(dev, "Unable to probe from device tree\n");
> + return ret;
> + }
> +
> + if (!priv->temperature_channels && !priv->voltage_channels) {
> + dev_err(dev, "no temperature or voltage channels in device tree\n");
> + return -ENODEV;
> + }
> +
> + priv->chan = stratix10_svc_request_channel_byname(&priv->client,
> + SVC_CLIENT_HWMON);
> + if (IS_ERR(priv->chan)) {
> + ret = PTR_ERR(priv->chan);
> + if (ret == -EPROBE_DEFER)
> + dev_dbg(dev, "service channel %s not ready, deferring probe\n",
> + SVC_CLIENT_HWMON);
> + else
> + dev_err(dev, "couldn't get service channel %s: %d\n",
> + SVC_CLIENT_HWMON, ret);
> + return ret;
> + }
> +
> + ret = stratix10_svc_add_async_client(priv->chan, false);
> + switch (ret) {
> + case 0:
> + priv->async = true;
> + break;
> + case -EINVAL:
> + dev_dbg(dev, "async operations not supported, using sync mode\n");
> + priv->async = false;
> + break;
> + default:
> + dev_err(dev, "failed to add async client: %d\n", ret);
> + stratix10_svc_free_channel(priv->chan);
> + return ret;
> + }
> +
> + dev_info(dev, "Initialized %d temperature and %d voltage channels\n",
> + priv->temperature_channels, priv->voltage_channels);
Drop, driver should be silent on success. dev_dbg might be fine, but
honestly that's static information from DT so zero usefulness.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: firmware: svc: add hwmon property
From: Krzysztof Kozlowski @ 2026-06-22 14:05 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <be798fdfb7ec76e1f7d04c1fd00126c88c8a2e31.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:53AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Altera Stratix 10 SoCFPGA supports hardware monitor access through the
> service layer mailbox. Add an optional hwmon child node to the service
> layer binding so device trees can describe the hardware monitor.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
> ---
> .../devicetree/bindings/firmware/intel,stratix10-svc.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> index b42cfa78b28b..86ffdb10132f 100644
> --- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> +++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> @@ -62,6 +62,10 @@ properties:
> $ref: /schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml
> description: Optional child node for fpga manager to perform fabric configuration.
>
> + hwmon:
> + $ref: /schemas/hwmon/altr,stratix10-hwmon.yaml
So hwmon is completely fake wrapper over two other wrappers... If in
doubts, please read slides from DTS101 presentations from OSS, including
the chapter about Linux driver design.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
From: Krzysztof Kozlowski @ 2026-06-22 14:04 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <ac5a118394e96f707823463fedd32b6a484c1ceb.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:52AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Document the device tree binding for the Altera Stratix 10 SoC FPGA
> hardware monitor, including temperature and voltage sensor nodes.
Also:
A nit, subject: drop second/last, redundant "binding". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
From: Krzysztof Kozlowski @ 2026-06-22 14:04 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <ac5a118394e96f707823463fedd32b6a484c1ceb.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:52AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Document the device tree binding for the Altera Stratix 10 SoC FPGA
> hardware monitor, including temperature and voltage sensor nodes.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
> ---
> .../bindings/hwmon/altr,stratix10-hwmon.yaml | 164 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 171 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> new file mode 100644
> index 000000000000..5bd98660ee7b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> @@ -0,0 +1,164 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/altr,stratix10-hwmon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Altera Hardware Monitor for Stratix 10 SoC FPGA
> +
> +maintainers:
> + - Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> + - Tze Yee Ng <tze.yee.ng@altera.com>
> +
> +description: |
> + The Altera Stratix 10 SoC FPGA hardware monitor unit provides on-chip
> + voltage and temperature sensors. These sensors can be used to monitor
> + external voltages and on-chip operating conditions such as internal
> + power rails and on-chip junction temperatures.
> +
> + The specific sensor configuration varies by device. Check the device
> + documentation to verify which sensors are available.
> +
> + Stratix 10 voltage sensors:
> +
> + page 0, channel 2 = 0.8V VCC
> + page 0, channel 3 = 1.8V VCCIO_SDM
> + page 0, channel 6 = 0.9V VCCERAM
> +
> + Stratix 10 temperature sensors:
> +
> + page 0, channel 0 = main die
> + page 0, channel 1 = tile bottom left
> + page 0, channel 2 = tile middle left
> + page 0, channel 3 = tile top left
> + page 0, channel 4 = tile bottom right
> + page 0, channel 5 = tile middle right
> + page 0, channel 6 = tile top right
> + page 0, channel 7 = hbm2 bottom
> + page 0, channel 8 = hbm2 top
> +
> +properties:
> + compatible:
> + const: altr,stratix10-hwmon
> +
Where are top-level properties? clocks? interrupts? power-domain,
resets? address space? Anything? Did you read writing bindings doc?
> + temperature:
> + description:
> + The temperature node specifies mappings of temperature sensor diodes on
> + the Stratix 10 SoC FPGA main die and tile die.
> + type: object
Blank line
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
Blank line
> + patternProperties:
> + "^input(@[0-9a-f]+)?$":
Unit address should not be optional.
Also, use consistent style of quotes.
> + description:
> + The input node specifies each individual temperature sensor.
> + type: object
> + properties:
> + reg:
> + description:
> + Sensor channel index in the lower 16-bits (0-15). For temperature
> + sensors, the page number is encoded in the upper 16-bits.
> + The driver encodes the SMC request argument as a channel
> + bitmask (1 << channel) in bits 0..15, with the page number
> + placed in bits 16..31. Channel values >= 16 are rejected to
> + avoid overlap with the page field. For example, reg = <2>
> + selects channel 2 and the driver passes 0x4 to the service layer.
> + label:
> + description:
> + A descriptive name for this channel (e.g. "Main Die" or
> + "Tile Bottom Left").
> + required:
> + - reg
> + additionalProperties: false
All this is difficult to read. Please open other bindings to understand
the style used in Linux kernel.
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + additionalProperties: false
> +
> + voltage:
> + description:
> + The voltage node specifies mappings of voltage sensors on the Stratix 10
> + SoC FPGA analog to digital converter of the Secure Device Manager (SDM).
> + type: object
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
> + patternProperties:
> + "^input(@[0-9a-f]+)?$":
Isn't this usually called channel?
> + description:
> + The input node specifies each individual voltage sensor.
> + type: object
> + properties:
> + reg:
> + description:
> + Sensor channel index in the lower 16-bits (0-15). The driver
> + encodes the SMC request argument as a channel bitmask
> + (1 << channel). For example, reg = <2> selects channel 2 and
> + the driver passes 0x4 to the service layer.
> + label:
> + description:
> + A descriptive name for this channel (e.g. "0.8V VCC" or
> + "1.8V VCCIO_SDM").
> + required:
> + - reg
> + additionalProperties: false
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + additionalProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hwmon {
> + compatible = "altr,stratix10-hwmon";
> +
> + voltage {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + input@2 {
> + label = "0.8V VCC";
> + reg = <2>;
> + };
> +
> + input@3 {
> + label = "1.8V VCCIO_SDM";
> + reg = <3>;
> + };
> +
> + input@6 {
> + label = "0.9V VCCERAM";
> + reg = <6>;
> + };
> + };
> +
> + temperature {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + input@0 {
> + label = "Main Die";
> + reg = <0>;
> + };
> +
> + input@1 {
> + label = "Tile Bottom Left";
> + reg = <1>;
> + };
> +
> + input@2 {
> + label = "Tile Middle Left";
> + reg = <2>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6aa3fe2ee1bb..678f6c429627 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -937,6 +937,13 @@ ALPS PS/2 TOUCHPAD DRIVER
> R: Pali Rohár <pali@kernel.org>
> F: drivers/input/mouse/alps.*
>
> +ALTERA STRATIX 10 SoC FPGA HWMON DRIVER
> +M: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> +M: Tze Yee Ng <tze.yee.ng@altera.com>
> +L: linux-hwmon@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> +
> ALTERA MAILBOX DRIVER
Does not look sorted. Please read this file before changing it.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 8/8] docs: misc: amd-sbi: Document SBTSI userspace interface
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
- Document AMD sideband IOCTL description defined
for SBTSI and its usage.
User space C-APIs are made available by esmi_oob_library [1],
which is provided by the E-SMS project [2].
Link: https://github.com/amd/esmi_oob_library [1]
Link: https://www.amd.com/en/developer/e-sms.html [2]
Include a user-space open example for /dev/sbtsi-* and list auxiliary
bus sysfs paths.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- Update misc node names info as per socket
Changes since v1:
- Elaborate the document
Documentation/misc-devices/amd-sbi.rst | 68 ++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/Documentation/misc-devices/amd-sbi.rst b/Documentation/misc-devices/amd-sbi.rst
index f91ddadefe48..fbbbc504119f 100644
--- a/Documentation/misc-devices/amd-sbi.rst
+++ b/Documentation/misc-devices/amd-sbi.rst
@@ -48,6 +48,60 @@ Access restrictions:
* APML Mailbox messages and Register xfer access are read-write,
* CPUID and MCA_MSR access is read-only.
+SBTSI device
+============
+
+sbtsi driver under the drivers/misc/amd-sbi creates miscdevice
+/dev/sbtsi-* to let user space programs run APML TSI register xfer
+commands.
+
+The driver supports both I2C and I3C transports for SB-TSI targets.
+The transport is selected by the bus where the device is enumerated.
+
+Misc device:
+ * In 1P socket 0: /dev/sbtsi-4c
+ * In 2P socket 0: /dev/sbtsi-4c, socket 1: /dev/sbtsi-48
+
+.. code-block:: bash
+
+ $ ls -al /dev/sbtsi-4c
+ crw------- 1 root root 10, 116 Apr 2 05:22 /dev/sbtsi-4c
+
+
+Access restrictions:
+ * Only root user is allowed to open the file.
+ * APML TSI Register xfer access is read-write.
+
+SBTSI hwmon interface
+=====================
+
+The sbtsi_temp auxiliary driver binds to the auxiliary device published
+by the core sbtsi driver on the auxiliary bus. The auxiliary device is
+named amd-sbtsi.temp-sensor.<addr> where <addr> is the device's dynamic
+address.
+
+It registers a hwmon device, providing a standard Linux hwmon interface
+for reading CPU temperature and managing temperature limits.
+
+The hwmon device appears under ``/sys/class/hwmon/`` when both ``sbtsi.ko``
+and ``sbtsi_temp.ko`` are loaded.
+
+Verify auxiliary bus device::
+
+ ls /sys/bus/auxiliary/devices/
+ # e.g. amd-sbtsi.temp-sensor.X
+
+Example usage::
+
+ # Read current temperature
+ cat /sys/class/hwmon/hwmon<N>/temp1_input
+
+ # Set high temperature limit to 70 °C
+ echo 70000 > /sys/class/hwmon/hwmon<N>/temp1_max
+
+ # Verify
+ cat /sys/class/hwmon/hwmon<N>/temp1_max
+
Driver IOCTLs
=============
@@ -63,6 +117,9 @@ Driver IOCTLs
.. c:macro:: SBRMI_IOCTL_REG_XFER_CMD
.. kernel-doc:: include/uapi/misc/amd-apml.h
:doc: SBRMI_IOCTL_REG_XFER_CMD
+.. c:macro:: SBTSI_IOCTL_REG_XFER_CMD
+.. kernel-doc:: include/uapi/misc/amd-apml.h
+ :doc: SBTSI_IOCTL_REG_XFER_CMD
User-space usage
================
@@ -85,6 +142,16 @@ Next thing, open the device file, as follows::
exit(1);
}
+To open SB-TSI device::
+
+ int file;
+
+ file = open("/dev/sbtsi-4c", O_RDWR);
+ if (file < 0) {
+ /* ERROR HANDLING */
+ exit(1);
+ }
+
The following IOCTLs are defined:
``#define SB_BASE_IOCTL_NR 0xF9``
@@ -92,6 +159,7 @@ The following IOCTLs are defined:
``#define SBRMI_IOCTL_CPUID_CMD _IOWR(SB_BASE_IOCTL_NR, 1, struct apml_cpuid_msg)``
``#define SBRMI_IOCTL_MCAMSR_CMD _IOWR(SB_BASE_IOCTL_NR, 2, struct apml_mcamsr_msg)``
``#define SBRMI_IOCTL_REG_XFER_CMD _IOWR(SB_BASE_IOCTL_NR, 3, struct apml_reg_xfer_msg)``
+``#define SBTSI_IOCTL_REG_XFER_CMD _IOWR(SB_BASE_IOCTL_NR, 4, struct apml_tsi_xfer_msg)``
User space C-APIs are made available by esmi_oob_library, hosted at
--
2.34.1
^ permalink raw reply related
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