* [PATCH v3 2/3] PM: dpm_watchdog: Allow disabling DPM watchdog by default
From: Tzung-Bi Shih @ 2026-06-08 2:15 UTC (permalink / raw)
To: Jonathan Corbet, Rafael J. Wysocki, Greg Kroah-Hartman,
Danilo Krummrich
Cc: Shuah Khan, Pavel Machek, Len Brown, tzungbi, linux-doc,
linux-kernel, linux-pm, driver-core, tfiga, senozhatsky,
Randy Dunlap
In-Reply-To: <20260608021526.1023248-1-tzungbi@kernel.org>
Introduce the CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED Kconfig option to
allow the device suspend/resume watchdog (DPM watchdog) to be disabled
by default at compile time.
Additionally, introduce the "dpm_watchdog_enabled" module parameter to
allow the watchdog to be enabled or disabled at boot time (via
"power.dpm_watchdog_enabled") and at runtime (via sysfs).
This provides flexibility for systems that want the watchdog code
compiled in but inactive by default, allowing it to be enabled only when
needed.
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
---
v3:
- Add "PM" tag (was missing).
- Update the format and specify dependencies in kernel-parameters.txt.
- Update the help message in Kconfig to reflect that dpm_watchdog_enabled
can be set at runtime as well.
v2: https://lore.kernel.org/all/20260604090756.2884671-3-tzungbi@kernel.org
- Use module parameter and bool for dpm_watchdog_enabled.
- Use IS_ENABLED().
v1: https://lore.kernel.org/all/20260528103215.505795-1-tzungbi@kernel.org
Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++
drivers/base/power/main.c | 11 +++++++++++
kernel/power/Kconfig | 10 ++++++++++
3 files changed, 29 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 00375193bd26..f2620764c28e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -47,6 +47,7 @@
PCI PCI bus support is enabled.
PCIE PCI Express support is enabled.
PCMCIA The PCMCIA subsystem is enabled.
+ PM Power Management support is enabled.
PNP Plug & Play support is enabled.
PPC PowerPC architecture is enabled.
PPT Parallel port support is enabled.
@@ -5399,6 +5400,13 @@ Kernel parameters
function to NULL. On Idle the CPU just reduces
execution priority.
+ power.dpm_watchdog_enabled=
+ [PM] Enable or disable the device suspend/resume
+ watchdog (DPM watchdog). Requires CONFIG_PM_SLEEP and
+ CONFIG_DPM_WATCHDOG enabled.
+ Format: <bool>
+ Default value is set by CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED.
+
ppc_strict_facility_enable
[PPC,ENABLE] This option catches any kernel floating point,
Altivec, VSX and SPE outside of regions specifically
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index cd864f3a2799..7822c29b7c8d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -534,6 +534,11 @@ module_param(dpm_watchdog_all_cpu_backtrace, bool, 0644);
MODULE_PARM_DESC(dpm_watchdog_all_cpu_backtrace,
"Backtrace all CPUs on DPM watchdog timeout");
+static bool __read_mostly dpm_watchdog_enabled =
+ IS_ENABLED(CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED);
+module_param(dpm_watchdog_enabled, bool, 0644);
+MODULE_PARM_DESC(dpm_watchdog_enabled, "Enable DPM watchdog");
+
/**
* dpm_watchdog_handler - Driver suspend / resume watchdog handler.
* @t: The timer that PM watchdog depends on.
@@ -577,6 +582,9 @@ static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
{
struct timer_list *timer = &wd->timer;
+ if (!dpm_watchdog_enabled)
+ return;
+
wd->dev = dev;
wd->tsk = current;
wd->fatal = CONFIG_DPM_WATCHDOG_TIMEOUT == CONFIG_DPM_WATCHDOG_WARNING_TIMEOUT;
@@ -595,6 +603,9 @@ static void dpm_watchdog_clear(struct dpm_watchdog *wd)
{
struct timer_list *timer = &wd->timer;
+ if (!dpm_watchdog_enabled)
+ return;
+
timer_delete_sync(timer);
timer_destroy_on_stack(timer);
}
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 530c897311d4..b16bd159074a 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -268,6 +268,16 @@ config DPM_WATCHDOG
captured in pstore device for inspection in subsequent
boot session.
+config DPM_WATCHDOG_DEFAULT_ENABLED
+ bool "Enable DPM watchdog by default"
+ depends on DPM_WATCHDOG
+ default y
+ help
+ If you say Y here, the DPM watchdog will be enabled by default.
+ If you say N, it will be compiled in but disabled. It can be
+ enabled at boot time via the "power.dpm_watchdog_enabled" kernel
+ parameter or at runtime via sysfs.
+
config DPM_WATCHDOG_TIMEOUT
int "Watchdog timeout to panic in seconds"
range 1 120
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v3 1/3] PM: core: Rename module parameters prefix to "power"
From: Tzung-Bi Shih @ 2026-06-08 2:15 UTC (permalink / raw)
To: Jonathan Corbet, Rafael J. Wysocki, Greg Kroah-Hartman,
Danilo Krummrich
Cc: Shuah Khan, Pavel Machek, Len Brown, tzungbi, linux-doc,
linux-kernel, linux-pm, driver-core, tfiga, senozhatsky,
Randy Dunlap
In-Reply-To: <20260608021526.1023248-1-tzungbi@kernel.org>
Currently, the module parameters defined in drivers/base/power/main.c
use the default prefix "main" (derived from the filename). The prefix
"main" is too generic and non-descriptive for power management
parameters.
Redefine MODULE_PARAM_PREFIX to "power." at the beginning of the file
to group the module parameters under the "power" namespace instead.
This makes the parameters more descriptive.
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
---
v3:
- No changes.
v2: https://lore.kernel.org/all/20260604090756.2884671-2-tzungbi@kernel.org
- New to the series.
v1: Doesn't exist.
drivers/base/power/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index ed48c292f575..cd864f3a2799 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -40,6 +40,9 @@
#include "../base.h"
#include "power.h"
+#undef MODULE_PARAM_PREFIX
+#define MODULE_PARAM_PREFIX "power."
+
typedef int (*pm_callback_t)(struct device *);
/*
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v3 0/3] PM: dpm_watchdog: Improve DPM watchdog configurability
From: Tzung-Bi Shih @ 2026-06-08 2:15 UTC (permalink / raw)
To: Jonathan Corbet, Rafael J. Wysocki, Greg Kroah-Hartman,
Danilo Krummrich
Cc: Shuah Khan, Pavel Machek, Len Brown, tzungbi, linux-doc,
linux-kernel, linux-pm, driver-core, tfiga, senozhatsky,
Randy Dunlap
This series improves the configurability of the DPM watchdog.
Currently, the DPM watchdog timeouts are fixed at compile time, and the
watchdog is always enabled if compiled in. Also, the module parameters
defined in drivers/base/power/main.c use the generic and non-descriptive
"main" prefix.
This series addresses these limitations.
Patch 1 renames the module parameter prefix for drivers/base/power/main.c
from "main" to "power".
Patch 2 introduces the CONFIG_DPM_WATCHDOG_DEFAULT_ENABLED to allow the DPM
watchdog to be disabled by default at compile time. It also exposes the
"power.dpm_watchdog_enabled" module parameter to allow enabling/disabling
the watchdog at boot time and runtime.
Patch 3 introduces sysctl knobs under /proc/sys/kernel/ to allow
configuring the DPM watchdog timeouts at runtime.
---
v3:
- Address review comments on patch 2.
v2: https://lore.kernel.org/all/20260604090756.2884671-1-tzungbi@kernel.org
- Form a new series.
v1: Doesn't exist.
Tzung-Bi Shih (3):
PM: core: Rename module parameters prefix to "power"
PM: dpm_watchdog: Allow disabling DPM watchdog by default
PM: dpm_watchdog: Add sysctl interface for DPM watchdog timeouts
.../admin-guide/kernel-parameters.txt | 8 ++
drivers/base/power/main.c | 75 ++++++++++++++++++-
kernel/power/Kconfig | 10 +++
3 files changed, 89 insertions(+), 4 deletions(-)
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply
* Re: [PATCH 0/2] docs/zh: update DAMON usage sysfs documentation
From: Dongliang Mu @ 2026-06-08 2:12 UTC (permalink / raw)
To: Doehyun Baek, Alex Shi, Yanteng Si, Hu Haowen
Cc: Jonathan Corbet, Shuah Khan, SeongJae Park, linux-doc,
linux-kernel, damon
In-Reply-To: <20260523094420.741003-1-doehyunbaek@gmail.com>
On 5/23/26 5:44 PM, Doehyun Baek wrote:
> Hi,
>
> The Simplified and Traditional Chinese DAMON usage translations are
> missing selected updates that are already documented in the English file.
> As a result, parts of the translated sysfs hierarchy and descriptions are
> stale, and the translations also lack the newer introduction of DAMON's
> special-purpose modules.
Hi Doehyun,
Thanks for your patch. To track the translation status of the
documentation in different locales, we define a uniform format in
how-to.rst [1]. Please revise the commit message of two patches.
docs/zh_CN: Add/Update self-protection index Chinese translation
Translate .../security/self-protection.rst into Chinese.
Update the translation through commit b080e52110ea
("docs: update self-protection __ro_after_init status")
# 请执行 git log --oneline <您翻译的英文文档路径>，并替换上述内容
Signed-off-by: Yanteng Si <si.yanteng@linux.dev>
# 如果您前面的步骤正确执行，该行会自动显示，否则请检查 gitconfig 文件
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/translations/zh_CN/how-to.rst#n252
>
> The gaps correspond to the following English documentation commits:
>
> commit a7bb1e754559 ("Docs/admin-guide/mm/damon/usage: document 'nid' file")
> commit e85e965bdbec ("Docs/admin-guide/mm/damon/usage: document refresh_ms file")
> commit e0c725455fd5 ("Docs/admin-guide/mm/damon/usage: document addr_unit file")
> commit e06469cdf1fd ("Docs/admin-guide/mm/damon/usage: document obsolete_target file")
> commit 2584dd7496c5 ("Docs/admin-guide/mm/damon/usage: update for max_nr_snapshots")
> commit 652fd06d20da ("Docs/admin-guide/mm/damon/usage: update stats update process for refresh_ms")
> commit e7df7a0bfc90 ("Docs/admin-guide/mm/damon/usage: introduce DAMON modules at the beginning")
> commit d9cfe515d36e ("Docs/admin-guide/mm/damon/usage: document goal_tuner sysfs file")
>
> Update both translations only for those stale DAMON usage entries,
> including refresh_ms, addr_unit, obsolete_target, goal_tuner, nid, and
> max_nr_snapshots.
>
> Doehyun Baek (2):
> docs/zh_CN: update DAMON usage sysfs documentation
> docs/zh_TW: update DAMON usage sysfs documentation
>
> .../zh_CN/admin-guide/mm/damon/usage.rst | 56 +++++++++++++------
> .../zh_TW/admin-guide/mm/damon/usage.rst | 56 +++++++++++++------
> 2 files changed, 80 insertions(+), 32 deletions(-)
>
>
> base-commit: 79bd2dded182b1d458b18e62684b7f82ffc682e5
^ permalink raw reply
* Re: [PATCH v6 03/11] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Binbin Wu @ 2026-06-08 2:11 UTC (permalink / raw)
To: Rick Edgecombe
Cc: bp, dave.hansen, hpa, kas, kvm, linux-coco, linux-doc,
linux-kernel, mingo, nik.borisov, pbonzini, seanjc, tglx,
vannapurve, x86, chao.gao, yan.y.zhao, kai.huang,
Kirill A. Shutemov
In-Reply-To: <20260526023515.288829-4-rick.p.edgecombe@intel.com>
On 5/26/2026 10:35 AM, Rick Edgecombe wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>
> Add helpers to use when allocating or preparing pages that are handed to
> the TDX-Module for use as control/S-EPT pages, and thus need Dynamic PAMT
> adjustments.
>
> The TDX module tracks some state for each page of physical memory that it
> might use. It calls this state the PAMT. It includes separate state for
> each page size a physical page could be utilized at within the TDX module
> (1GB, 2MB, 4KB). In Dynamic PAMT, only the 4KB page size state is
> allocated dynamically. So for pages that TDX will use as 2MB physically
> contiguous pages, Dynamic PAMT backing is not needed.
>
> KVM will need to hand pages to the TDX module that it will use at 4KB
> granularity. So these pages will need Dynamic PAMT backing added before
> they are used by the TDX module, and removed afterwards.
>
> Add tdx_alloc_control_page() and tdx_free_control_page() to handle both
> page allocation and Dynamic PAMT installation. Make them behave like
> normal alloc/free functions where allocation can fail in the case of no
> memory, but free (with any necessary Dynamic PAMT release) always
> succeeds. Do this so they can support the existing TDX flows that require
> teardowns to succeed.
>
> Also create tdx_pamt_get/put() to handle installing Dynamic PAMT 4KB
> backing for pages that are already allocated (such as KVM's use of S-EPT
> page tables or guest private memory). Have them take a pfn instead of a
> struct page, as future changes will want to use these helpers for guest
> pages which are tracked by PFN.
>
> Don't CLFLUSH the Dynamic PAMT pages handed to the TDX module, as is done
> for some other SEAMCALLs, as the TDX docs specify that this is only
> needed on "TD private memory or TD control structure page".
>
> Since these allocations will be easily user triggerable, account the
> memory.
>
> Leave logic to handle concurrency issues for future changes.
>
> Assisted-by: GitHub Copilot:claude-opus-4-6 Claude:claude-opus-4-7 Sashiko:claude-opus-4-6
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
One comment below.
>
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index 82dc27aecf297..74e75db5728c7 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -37,6 +37,7 @@
>
> #include <uapi/asm/mce.h>
> #include <asm/tdx_global_metadata.h>
> +#include <linux/mm.h>
I think the header is not needed here.
> #include <linux/pgtable.h>
>
> /*
> @@ -160,6 +161,12 @@ void tdx_guest_keyid_free(unsigned int keyid);
>
> void tdx_quirk_reset_paddr(unsigned long base, unsigned long size);
>
> +/* Number PAMT pages to be provided to TDX module per 2MB region of PA */
> +#define TDX_DPAMT_ENTRY_PAGE_CNT 2
> +
> +struct page *tdx_alloc_control_page(void);
> +void tdx_free_control_page(struct page *page);
> +
> struct tdx_td {
> /* TD root structure: */
> struct page *tdr_page;
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 9ebd192cb5c17..9e0812d87ab06 100644[...]
^ permalink raw reply
* Re: [PATCH v3 1/6] alloc_tag: add ioctl to /proc/allocinfo
From: Hao Ge @ 2026-06-08 1:52 UTC (permalink / raw)
To: Abhishek Bapat, Suren Baghdasaryan, Andrew Morton,
Kent Overstreet
Cc: Shuah Khan, Jonathan Corbet, linux-doc, linux-kernel, linux-mm,
Sourav Panda
In-Reply-To: <0e91fdd3a88dbe5220d15c4c8ff7b8f66e86af7c.1780701922.git.abhishekbapat@google.com>
Hi Suren and Abhishek
Thanks for the new version.
On 2026/6/6 07:36, Abhishek Bapat wrote:
> From: Suren Baghdasaryan <surenb@google.com>
>
> Add the following ioctl commands for /proc/allocinfo file:
>
> ALLOCINFO_IOC_CONTENT_ID - gets content identifier which can be used
> to check whether the file content has changed specifically due to module
> load/unload. Every time a module is loaded / unloaded, the returned
> value will be different. By comparing the identifier value at the
> beginning and at the end of the content retrieval operation, users can
> validate retrieved information for consistency.
>
> ALLOCINFO_IOC_GET_AT - gets the record at the specified position. This
> is the position of a record in /proc/allocinfo.
>
> ALLOCINFO_IOC_GET_NEXT - gets the record next to the last retrieved
> one. If no records were previously retrieved, returns the first
> record.
>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
> ---
> Documentation/mm/allocation-profiling.rst | 5 +
> .../userspace-api/ioctl/ioctl-number.rst | 2 +
> MAINTAINERS | 1 +
> include/linux/codetag.h | 2 +
> include/uapi/linux/alloc_tag.h | 54 ++++
> lib/alloc_tag.c | 232 +++++++++++++++++-
> lib/codetag.c | 18 ++
> 7 files changed, 312 insertions(+), 2 deletions(-)
> create mode 100644 include/uapi/linux/alloc_tag.h
>
> diff --git a/Documentation/mm/allocation-profiling.rst b/Documentation/mm/allocation-profiling.rst
> index 5389d241176a..c3a28467955f 100644
> --- a/Documentation/mm/allocation-profiling.rst
> +++ b/Documentation/mm/allocation-profiling.rst
> @@ -46,6 +46,11 @@ sysctl:
> Runtime info:
> /proc/allocinfo
>
> + Profiling data can be retrieved either by reading `/proc/allocinfo` directly as
> + text or programmatically via `ioctl()` calls defined in `<uapi/linux/alloc_tag.h>`.
> + The ioctl interface supports structured binary data extraction as well as filtering
> + by module name, function, file, line number, accuracy, or allocation size limits.
> +
> Example output::
>
> root@moria-kvm:~# sort -g /proc/allocinfo|tail|numfmt --to=iec
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 331223761fff..84f6808a8578 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -349,6 +349,8 @@ Code Seq# Include File Comments
> <mailto:luzmaximilian@gmail.com>
> 0xA5 20-2F linux/surface_aggregator/dtx.h Microsoft Surface DTX driver
> <mailto:luzmaximilian@gmail.com>
> +0xA6 00-0F uapi/linux/alloc_tag.h Memory allocation profiling
> + <mailto:surenb@google.com>
> 0xAA 00-3F linux/uapi/linux/userfaultfd.h
> 0xAB 00-1F linux/nbd.h
> 0xAC 00-1F linux/raw.h
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a31f6f207afd..77f3fc487691 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16711,6 +16711,7 @@ S: Maintained
> F: Documentation/mm/allocation-profiling.rst
> F: include/linux/alloc_tag.h
> F: include/linux/pgalloc_tag.h
> +F: include/uapi/linux/alloc_tag.h
> F: lib/alloc_tag.c
>
> MEMORY CONTROLLER DRIVERS
> diff --git a/include/linux/codetag.h b/include/linux/codetag.h
> index ddae7484ca45..a25a085c2df1 100644
> --- a/include/linux/codetag.h
> +++ b/include/linux/codetag.h
> @@ -77,6 +77,8 @@ struct codetag_iterator {
> void codetag_lock_module_list(struct codetag_type *cttype);
> bool codetag_trylock_module_list(struct codetag_type *cttype);
> void codetag_unlock_module_list(struct codetag_type *cttype);
> +unsigned long codetag_get_content_id(struct codetag_type *cttype);
> +unsigned int codetag_get_count(struct codetag_type *cttype);
> struct codetag_iterator codetag_get_ct_iter(struct codetag_type *cttype);
> struct codetag *codetag_next_ct(struct codetag_iterator *iter);
>
> diff --git a/include/uapi/linux/alloc_tag.h b/include/uapi/linux/alloc_tag.h
> new file mode 100644
> index 000000000000..901199bad514
> --- /dev/null
> +++ b/include/uapi/linux/alloc_tag.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * include/linux/alloc_tag.h
nit: it should be include/uapi/linux/alloc_tag.h
(I guess you may have missed the comment I brought up before. It is not
a critical problem though.)
> + */
> +
> +#ifndef _UAPI_ALLOC_TAG_H
> +#define _UAPI_ALLOC_TAG_H
> +
> +#include <linux/types.h>
> +
> +#define ALLOCINFO_STR_SIZE 64
> +
> +struct allocinfo_content_id {
> + __u64 id;
> +};
> +
> +struct allocinfo_tag {
> + /* Longer names are trimmed */
> + char modname[ALLOCINFO_STR_SIZE];
> + char function[ALLOCINFO_STR_SIZE];
> + char filename[ALLOCINFO_STR_SIZE];
> + __u64 lineno;
> +};
> +
> +/* The alignment ensures 32-bit compatible interfaces are not broken */
> +struct allocinfo_counter {
> + __u64 bytes;
> + __u64 calls;
> + __u8 accurate;
> +} __attribute__((aligned(8)));
> +
> +struct allocinfo_tag_data {
> + struct allocinfo_tag tag;
> + struct allocinfo_counter counter;
> +};
> +
> +struct allocinfo_get_at {
> + __u64 pos; /* input */
> + struct allocinfo_tag_data data;
> +};
> +
> +#define _ALLOCINFO_IOC_CONTENT_ID 0
> +#define _ALLOCINFO_IOC_GET_AT 1
> +#define _ALLOCINFO_IOC_GET_NEXT 2
> +
> +#define ALLOCINFO_IOC_BASE 0xA6
> +#define ALLOCINFO_IOC_CONTENT_ID _IOR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_CONTENT_ID, \
> + struct allocinfo_content_id)
> +#define ALLOCINFO_IOC_GET_AT _IOWR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_GET_AT, \
> + struct allocinfo_get_at)
> +#define ALLOCINFO_IOC_GET_NEXT _IOR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_GET_NEXT, \
> + struct allocinfo_tag_data)
> +
> +#endif /* _UAPI_ALLOC_TAG_H */
> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
> index d9be1cf5187d..a0577215eb3d 100644
> --- a/lib/alloc_tag.c
> +++ b/lib/alloc_tag.c
> @@ -5,6 +5,7 @@
> #include <linux/gfp.h>
> #include <linux/kallsyms.h>
> #include <linux/module.h>
> +#include <linux/mutex.h>
> #include <linux/page_ext.h>
> #include <linux/pgalloc_tag.h>
> #include <linux/proc_fs.h>
> @@ -14,6 +15,7 @@
> #include <linux/string_choices.h>
> #include <linux/vmalloc.h>
> #include <linux/kmemleak.h>
> +#include <uapi/linux/alloc_tag.h>
>
> #define ALLOCINFO_FILE_NAME "allocinfo"
> #define MODULE_ALLOC_TAG_VMAP_SIZE (100000UL * sizeof(struct alloc_tag))
> @@ -47,6 +49,10 @@ struct allocinfo_private {
> struct codetag_iterator iter;
> struct codetag_iterator reported_iter;
> bool print_header;
> + /* ioctl uses a separate iterator not to interfere with reads */
> + struct codetag_iterator ioctl_iter;
> + bool positioned; /* seq_open_private() sets to 0 */
> + struct mutex ioctl_lock;
> };
>
> static void *allocinfo_start(struct seq_file *m, loff_t *pos)
> @@ -130,6 +136,229 @@ static const struct seq_operations allocinfo_seq_op = {
> .show = allocinfo_show,
> };
>
> +/*
> + * Initializes seq_file operations and allocates private state when opening
> + * the /proc/allocinfo procfs entry.
> + */
> +static int allocinfo_open(struct inode *inode, struct file *file)
> +{
> + int ret;
> +
> + ret = seq_open_private(file, &allocinfo_seq_op,
> + sizeof(struct allocinfo_private));
> + if (!ret) {
> + struct seq_file *m = file->private_data;
> + struct allocinfo_private *priv = m->private;
> +
> + mutex_init(&priv->ioctl_lock);
> + }
> + return ret;
> +}
> +
> +/*
> + * Cleans up the seq_file state and frees up the private state allocated in
> + * allocinfo_open() when closing the /proc/allocinfo file descriptor.
> + */
> +static int allocinfo_release(struct inode *inode, struct file *file)
> +{
> + return seq_release_private(inode, file);
> +}
> +
> +/*
> + * Returns a pointer to the suffix of a string so that its length fits within
> + * ALLOCINFO_STR_SIZE, preserving the trailing characters.
> + */
> +static const char *allocinfo_str(const char *str)
> +{
> + size_t len = strlen(str);
> +
> + /* Keep an extra space for the trailing NULL. */
> + if (len >= ALLOCINFO_STR_SIZE)
> + str += (len - ALLOCINFO_STR_SIZE) + 1;
> + return str;
> +}
> +
> +/* Copy a string and trim from the beginning if it's too long */
> +static void allocinfo_copy_str(char *dest, const char *src)
> +{
> + strscpy_pad(dest, allocinfo_str(src), ALLOCINFO_STR_SIZE);
> +}
> +
> +/*
> + * Populates the UAPI allocinfo_tag_data structure with active runtime
> + * profiling counters extracted from the given kernel codetag.
> + */
> +static void allocinfo_to_params(struct codetag *ct,
> + struct allocinfo_tag_data *data)
> +{
> + struct alloc_tag *tag = ct_to_alloc_tag(ct);
> + struct alloc_tag_counters counter = alloc_tag_read(tag);
> +
> + if (ct->modname)
> + allocinfo_copy_str(data->tag.modname, ct->modname);
> + else
> + data->tag.modname[0] = '\0';
> + allocinfo_copy_str(data->tag.function, ct->function);
> + allocinfo_copy_str(data->tag.filename, ct->filename);
> + data->tag.lineno = ct->lineno;
> + data->counter.bytes = counter.bytes;
> + data->counter.calls = counter.calls;
> + data->counter.accurate = !alloc_tag_is_inaccurate(tag);
> +}
> +
> +/*
> + * Retrieves the unique content ID representing the current allocation tag module
> + * layout, allowing userspace to detect if modules were loaded / unloaded.
> + */
> +static int allocinfo_ioctl_get_content_id(struct seq_file *m, void __user *arg)
> +{
> + struct allocinfo_content_id params;
> +
> + codetag_lock_module_list(alloc_tag_cttype);
> + params.id = codetag_get_content_id(alloc_tag_cttype);
> + codetag_unlock_module_list(alloc_tag_cttype);
> + if (copy_to_user(arg, ¶ms, sizeof(params)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +/*
> + * Seeks the ioctl iterator to the specified 0-indexed tag position, reads its
> + * profiling data and returns it to userspace.
> + */
> +static int allocinfo_ioctl_get_at(struct seq_file *m, void __user *arg)
> +{
> + struct allocinfo_private *priv;
> + struct codetag *ct;
> + __u64 pos;
> + struct allocinfo_get_at params = {0};
> +
> + if (copy_from_user(¶ms, arg, sizeof(params)))
> + return -EFAULT;
> +
> + priv = m->private;
> + pos = params.pos;
> +
> + mutex_lock(&priv->ioctl_lock);
> + codetag_lock_module_list(alloc_tag_cttype);
> +
> + if (pos >= codetag_get_count(alloc_tag_cttype)) {
> + codetag_unlock_module_list(alloc_tag_cttype);
> + mutex_unlock(&priv->ioctl_lock);
> + return -ENOENT;
> + }
> +
> + /* Find the codetag */
> + priv->ioctl_iter = codetag_get_ct_iter(alloc_tag_cttype);
> + ct = codetag_next_ct(&priv->ioctl_iter);
> + while (ct && pos--)
> + ct = codetag_next_ct(&priv->ioctl_iter);
> + if (ct) {
> + allocinfo_to_params(ct, ¶ms.data);
> + priv->positioned = true;
> + }
> +
> + codetag_unlock_module_list(alloc_tag_cttype);
> + mutex_unlock(&priv->ioctl_lock);
> +
> + if (!ct)
> + return -ENOENT;
> +
> + if (copy_to_user(arg, ¶ms, sizeof(params)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +/*
> + * Advances the ioctl iterator to the next allocation tag in the sequence and
> + * returns its profiling data to userspace.
> + */
> +static int allocinfo_ioctl_get_next(struct seq_file *m, void __user *arg)
> +{
> + struct allocinfo_private *priv;
> + struct codetag *ct;
> + struct allocinfo_tag_data params;
> + int ret = 0;
> +
> + memset(¶ms, 0, sizeof(params));
> + priv = m->private;
> +
> + mutex_lock(&priv->ioctl_lock);
> + codetag_lock_module_list(alloc_tag_cttype);
> +
> + if (!priv->positioned) {
> + priv->ioctl_iter = codetag_get_ct_iter(alloc_tag_cttype);
> + priv->positioned = true;
> + }
> +
> + ct = codetag_next_ct(&priv->ioctl_iter);
> + if (ct)
> + allocinfo_to_params(ct, ¶ms);
> +
> + if (!ct) {
> + priv->positioned = false;
> + ret = -ENOENT;
> + }
> + codetag_unlock_module_list(alloc_tag_cttype);
> + mutex_unlock(&priv->ioctl_lock);
> +
> + if (ret == 0) {
> + if (copy_to_user(arg, ¶ms, sizeof(params)))
> + return -EFAULT;
> + }
> + return ret;
> +}
> +
> +/*
> + * Entry point ioctl function for /proc/allocinfo routing requests to fetch the
> + * layout content ID, seek to a specific tag, or read sequential tags.
> + */
> +static long allocinfo_ioctl(struct file *file, unsigned int cmd,
> + unsigned long __arg)
> +{
> + void __user *arg = (void __user *)__arg;
> + int ret;
> +
> + switch (cmd) {
> + case ALLOCINFO_IOC_CONTENT_ID:
> + ret = allocinfo_ioctl_get_content_id(file->private_data, arg);
> + break;
> + case ALLOCINFO_IOC_GET_AT:
> + ret = allocinfo_ioctl_get_at(file->private_data, arg);
> + break;
> + case ALLOCINFO_IOC_GET_NEXT:
> + ret = allocinfo_ioctl_get_next(file->private_data, arg);
> + break;
> + default:
> + ret = -ENOIOCTLCMD;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +#ifdef CONFIG_COMPAT
> +static long allocinfo_compat_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + return allocinfo_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
> +}
> +#endif
> +
> +static const struct proc_ops allocinfo_proc_ops = {
> + .proc_open = allocinfo_open,
> + .proc_read_iter = seq_read_iter,
> + .proc_lseek = seq_lseek,
> + .proc_release = allocinfo_release,
> + .proc_ioctl = allocinfo_ioctl,
> +#ifdef CONFIG_COMPAT
> + .proc_compat_ioctl = allocinfo_compat_ioctl,
> +#endif
> +
> +};
> +
> size_t alloc_tag_top_users(struct codetag_bytes *tags, size_t count, bool can_sleep)
> {
> struct codetag_iterator iter;
> @@ -993,8 +1222,7 @@ static int __init alloc_tag_init(void)
> return 0;
> }
>
> - if (!proc_create_seq_private(ALLOCINFO_FILE_NAME, 0400, NULL, &allocinfo_seq_op,
> - sizeof(struct allocinfo_private), NULL)) {
> + if (!proc_create(ALLOCINFO_FILE_NAME, 0400, NULL, &allocinfo_proc_ops)) {
> pr_err("Failed to create %s file\n", ALLOCINFO_FILE_NAME);
> shutdown_mem_profiling(false);
> return -ENOMEM;
> diff --git a/lib/codetag.c b/lib/codetag.c
> index 4001a7ea6675..a9cda4c962a3 100644
> --- a/lib/codetag.c
> +++ b/lib/codetag.c
> @@ -19,6 +19,8 @@ struct codetag_type {
> struct codetag_type_desc desc;
> /* generates unique sequence number for module load */
> unsigned long next_mod_seq;
> + /* bumped on every module load and unload */
> + unsigned long content_id;
> };
>
> struct codetag_range {
> @@ -50,6 +52,20 @@ void codetag_unlock_module_list(struct codetag_type *cttype)
> up_read(&cttype->mod_lock);
> }
>
> +unsigned long codetag_get_content_id(struct codetag_type *cttype)
> +{
> + lockdep_assert_held(&cttype->mod_lock);
> +
> + return cttype->content_id;
> +}
> +
> +unsigned int codetag_get_count(struct codetag_type *cttype)
> +{
> + lockdep_assert_held(&cttype->mod_lock);
> +
> + return cttype->count;
> +}
> +
> struct codetag_iterator codetag_get_ct_iter(struct codetag_type *cttype)
> {
> struct codetag_iterator iter = {
> @@ -204,6 +220,7 @@ static int codetag_module_init(struct codetag_type *cttype, struct module *mod)
>
> down_write(&cttype->mod_lock);
> cmod->mod_seq = ++cttype->next_mod_seq;
> + ++cttype->content_id;
I have a comment on the content_id bump placement.
++cttype->content_id is placed before idr_alloc and the module_load
callback. If idr_alloc fails or module_load returns an error
(While the chance of this occurring is very low.), the idr entry gets
rolled back but content_id has already been bumped. The actual
content didn't change in this case, so userspace would see a
different content_id and assume the data is inconsistent when it
isn't.
Thanks
Best Regards
Hao
> mod_id = idr_alloc(&cttype->mod_idr, cmod, 0, 0, GFP_KERNEL);
> if (mod_id >= 0) {
> if (cttype->desc.module_load) {
> @@ -368,6 +385,7 @@ void codetag_unload_module(struct module *mod)
> cttype->count -= range_size(cttype, &cmod->range);
> idr_remove(&cttype->mod_idr, mod_id);
> kfree(cmod);
> + ++cttype->content_id;
> }
> up_write(&cttype->mod_lock);
> if (found && cttype->desc.free_section_mem)
^ permalink raw reply
* Re: [PATCH v2] docs/zh_CN: update admin-guide/index.rst translation
From: Alex Shi @ 2026-06-08 1:40 UTC (permalink / raw)
To: dzm91
Cc: alexs, corbet, frederic, gpiccoli, jani.nikula, kees, linux-doc,
linux-kernel, longman, mchehab+huawei, si.yanteng, skhan,
tony.luck, zhuyan2015
In-Reply-To: <4534170c-700d-43b5-ad32-6b91455b3f14@hust.edu.cn>
Applied, Thanks!
^ permalink raw reply
* Re: [PATCH v2 1/6] alloc_tag: add ioctl to /proc/allocinfo
From: Hao Ge @ 2026-06-08 1:34 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Abhishek Bapat, Andrew Morton, Kent Overstreet, Shuah Khan,
Jonathan Corbet, linux-doc, linux-kernel, linux-mm, Sourav Panda
In-Reply-To: <CAJuCfpGUEUVprws-VQ0xWWeFSSMTeRv5MKtQ5BVH3HN9=mOcjg@mail.gmail.com>
On 2026/6/4 03:59, Suren Baghdasaryan wrote:
> On Sun, May 24, 2026 at 7:21 PM Hao Ge <hao.ge@linux.dev> wrote:
>> Hi Abhishek
>>
>>
>> Thanks for this patch. I had a few questions/comments after going
>>
>> through it.
>>
>>
>> On 2026/5/23 01:45, Abhishek Bapat wrote:
>>> From: Suren Baghdasaryan <surenb@google.com>
>>>
>>> Add the following ioctl commands for /proc/allocinfo file:
>>>
>>> ALLOCINFO_IOC_CONTENT_ID - gets content identifier which can be used
>>> to check whether the file content has changed specifically due to module
>>> load/unload. Every time a module is loaded / unloaded, the returned
>>> value will be different. By comparing the identifier value at the
>>> beginning and at the end of the content retrieval operation, users can
>>> validate retrieved information for consistency.
>> codetag_get_content_id() does not reflect module unload
>>
>> codetag_get_content_id() returns cttype->next_mod_seq:
>>
>> unsigned long codetag_get_content_id(struct codetag_type *cttype)
>>
>> {
>>
>> return cttype->next_mod_seq;
>>
>> }
>>
>> However, next_mod_seq is only bumped in codetag_module_init(),
>>
>> i.e.the module load path:
>>
>> https://elixir.bootlin.com/linux/v7.1-rc4/source/lib/codetag.c#L204
>>
>> codetag_unload_module() does not increment next_mod_seq. This means
>>
>> that if only a module unload happens (without a subsequent load),
>>
>> content_id stays the same, so users comparing the id before and after
>>
>> won't detect that the content has changed. The commit message says
>>
>> "Every time a module is loaded / unloaded" -- I was wondering if this
>>
>> is intentional? If not, would it make sense to also bump next_mod_seq
>>
>> in the unload path?
> Good point. I overlooked that when I wrote the prototype for this patch.
> We should not bump next_mod_seq in the unload path but instead use a
> separate seq_count that gets bumped every time
> codetag_load_module/codetag_unload_module is called.
Make sense. I looked through the code with the question of why we should
not bump next_mod_seq in the unload path.
I've now found the answer.
next_mod_seq is used as a sequence number allocator.
Every newly loaded module gets assigned ++cttype->next_mod_seq as its
mod_seq.
The iterator then uses this mod_seq to detect module replacement at a
given idr slot:
https://elixir.bootlin.com/linux/v7.1-rc6/source/lib/codetag.c#L102
Bumping it in the unload path would compromise the mod_seq uniqueness
relied upon by the iterator.
Thanks for this.
Best Regards
Hao
>>
>>> ALLOCINFO_IOC_GET_AT - gets the record at the specified position. This
>>> is the position of a record in /proc/allocinfo.
>>>
>>> ALLOCINFO_IOC_GET_NEXT - gets the record next to the last retrieved
>>> one. If no records were previously retrieved, returns the first
>>> record.
>>>
>>> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
>>> Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
>>> ---
>>> .../userspace-api/ioctl/ioctl-number.rst | 2 +
>>> MAINTAINERS | 1 +
>>> include/linux/codetag.h | 1 +
>>> include/uapi/linux/alloc_tag.h | 54 +++++
>>> lib/alloc_tag.c | 193 +++++++++++++++++-
>>> lib/codetag.c | 11 +
>>> 6 files changed, 260 insertions(+), 2 deletions(-)
>>> create mode 100644 include/uapi/linux/alloc_tag.h
>>>
>>> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
>>> index 331223761fff..84f6808a8578 100644
>>> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
>>> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
>>> @@ -349,6 +349,8 @@ Code Seq# Include File Comments
>>> <mailto:luzmaximilian@gmail.com>
>>> 0xA5 20-2F linux/surface_aggregator/dtx.h Microsoft Surface DTX driver
>>> <mailto:luzmaximilian@gmail.com>
>>> +0xA6 00-0F uapi/linux/alloc_tag.h Memory allocation profiling
>>> + <mailto:surenb@google.com>
>>> 0xAA 00-3F linux/uapi/linux/userfaultfd.h
>>> 0xAB 00-1F linux/nbd.h
>>> 0xAC 00-1F linux/raw.h
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 46ed0f0e76d8..d176bde8fbfc 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -16709,6 +16709,7 @@ S: Maintained
>>> F: Documentation/mm/allocation-profiling.rst
>>> F: include/linux/alloc_tag.h
>>> F: include/linux/pgalloc_tag.h
>>> +F: include/uapi/linux/alloc_tag.h
>>> F: lib/alloc_tag.c
>>>
>>> MEMORY CONTROLLER DRIVERS
>>> diff --git a/include/linux/codetag.h b/include/linux/codetag.h
>>> index 8ea2a5f7c98a..2bcd4e7c809e 100644
>>> --- a/include/linux/codetag.h
>>> +++ b/include/linux/codetag.h
>>> @@ -76,6 +76,7 @@ struct codetag_iterator {
>>>
>>> void codetag_lock_module_list(struct codetag_type *cttype, bool lock);
>>> bool codetag_trylock_module_list(struct codetag_type *cttype);
>>> +unsigned long codetag_get_content_id(struct codetag_type *cttype);
>>> struct codetag_iterator codetag_get_ct_iter(struct codetag_type *cttype);
>>> struct codetag *codetag_next_ct(struct codetag_iterator *iter);
>>>
>>> diff --git a/include/uapi/linux/alloc_tag.h b/include/uapi/linux/alloc_tag.h
>>> new file mode 100644
>>> index 000000000000..e9a5b55fcc7a
>>> --- /dev/null
>>> +++ b/include/uapi/linux/alloc_tag.h
>>> @@ -0,0 +1,54 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>>> +/*
>>> + * include/linux/alloc_tag.h
>> nit: it should be include/uapi/linux/alloc_tag.h
>>> + */
>>> +
>>> +#ifndef _UAPI_ALLOC_TAG_H
>>> +#define _UAPI_ALLOC_TAG_H
>>> +
>>> +#include <linux/types.h>
>>> +
>>> +#define ALLOCINFO_STR_SIZE 64
>>> +
>>> +struct allocinfo_content_id {
>>> + __u64 id;
>>> +};
>>> +
>>> +struct allocinfo_tag {
>>> + /* Longer names are trimmed */
>>> + char modname[ALLOCINFO_STR_SIZE];
>>> + char function[ALLOCINFO_STR_SIZE];
>>> + char filename[ALLOCINFO_STR_SIZE];
>>> + __u64 lineno;
>>> +};
>>> +
>>> +struct allocinfo_counter {
>>> + __u64 bytes;
>>> + __u64 calls;
>>> + __u8 accurate;
>>> + __u8 pad[7]; /* Add alignment to not break the 32-bit compatible interface */
>>> +};
>>> +
>>> +struct allocinfo_tag_data {
>>> + struct allocinfo_tag tag;
>>> + struct allocinfo_counter counter;
>>> +};
>>> +
>>> +struct allocinfo_get_at {
>>> + __u64 pos; /* input */
>>> + struct allocinfo_tag_data data;
>>> +};
>>> +
>>> +#define _ALLOCINFO_IOC_CONTENT_ID 0
>>> +#define _ALLOCINFO_IOC_GET_AT 1
>>> +#define _ALLOCINFO_IOC_GET_NEXT 2
>>> +
>>> +#define ALLOCINFO_IOC_BASE 0xA6
>>> +#define ALLOCINFO_IOC_CONTENT_ID _IOR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_CONTENT_ID, \
>>> + struct allocinfo_content_id)
>>> +#define ALLOCINFO_IOC_GET_AT _IOWR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_GET_AT, \
>>> + struct allocinfo_get_at)
>>> +#define ALLOCINFO_IOC_GET_NEXT _IOR(ALLOCINFO_IOC_BASE, _ALLOCINFO_IOC_GET_NEXT, \
>>> + struct allocinfo_tag_data)
>>> +
>>> +#endif /* _UAPI_ALLOC_TAG_H */
>>> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
>>> index b9ca95d1f506..3598735b6c93 100644
>>> --- a/lib/alloc_tag.c
>>> +++ b/lib/alloc_tag.c
>>> @@ -5,6 +5,7 @@
>>> #include <linux/gfp.h>
>>> #include <linux/kallsyms.h>
>>> #include <linux/module.h>
>>> +#include <linux/mutex.h>
>>> #include <linux/page_ext.h>
>>> #include <linux/pgalloc_tag.h>
>>> #include <linux/proc_fs.h>
>>> @@ -14,6 +15,7 @@
>>> #include <linux/string_choices.h>
>>> #include <linux/vmalloc.h>
>>> #include <linux/kmemleak.h>
>>> +#include <uapi/linux/alloc_tag.h>
>>>
>>> #define ALLOCINFO_FILE_NAME "allocinfo"
>>> #define MODULE_ALLOC_TAG_VMAP_SIZE (100000UL * sizeof(struct alloc_tag))
>>> @@ -46,6 +48,10 @@ int alloc_tag_ref_offs;
>>> struct allocinfo_private {
>>> struct codetag_iterator iter;
>>> bool print_header;
>>> + /* ioctl uses a separate iterator not to interfere with reads */
>>> + struct codetag_iterator ioctl_iter;
>>> + bool positioned; /* seq_open_private() sets to 0 */
>>> + struct mutex ioctl_lock;
>>> };
>>>
>>> static void *allocinfo_start(struct seq_file *m, loff_t *pos)
>>> @@ -125,6 +131,190 @@ static const struct seq_operations allocinfo_seq_op = {
>>> .show = allocinfo_show,
>>> };
>>>
>>> +static int allocinfo_open(struct inode *inode, struct file *file)
>>> +{
>>> + int ret;
>>> +
>>> + ret = seq_open_private(file, &allocinfo_seq_op,
>>> + sizeof(struct allocinfo_private));
>>> + if (!ret) {
>>> + struct seq_file *m = file->private_data;
>>> + struct allocinfo_private *priv = m->private;
>>> +
>>> + mutex_init(&priv->ioctl_lock);
>>> + }
>>> + return ret;
>>> +}
>>> +
>>> +static int allocinfo_release(struct inode *inode, struct file *file)
>>> +{
>>> + return seq_release_private(inode, file);
>>> +}
>>> +
>>> +static const char *allocinfo_str(const char *str)
>>> +{
>>> + size_t len = strlen(str);
>>> +
>>> + /* Keep an extra space for the trailing NULL. */
>>> + if (len >= ALLOCINFO_STR_SIZE)
>>> + str += (len - ALLOCINFO_STR_SIZE) + 1;
>>> + return str;
>>> +}
>>> +
>>> +/* Copy a string and trim from the beginning if it's too long */
>>> +static void allocinfo_copy_str(char *dest, const char *src)
>>> +{
>>> + strscpy(dest, allocinfo_str(src), ALLOCINFO_STR_SIZE);
>>> +}
>>> +
>>> +static void allocinfo_to_params(struct codetag *ct,
>>> + struct allocinfo_tag_data *data)
>>> +{
>>> + struct alloc_tag *tag = ct_to_alloc_tag(ct);
>>> + struct alloc_tag_counters counter = alloc_tag_read(tag);
>>> +
>>> + if (ct->modname)
>>> + allocinfo_copy_str(data->tag.modname, ct->modname);
>>> + else
>>> + data->tag.modname[0] = '\0';
>>> + allocinfo_copy_str(data->tag.function, ct->function);
>>> + allocinfo_copy_str(data->tag.filename, ct->filename);
>>> + data->tag.lineno = ct->lineno;
>>> + data->counter.bytes = counter.bytes;
>>> + data->counter.calls = counter.calls;
>>> + data->counter.accurate = !alloc_tag_is_inaccurate(tag);
>>> +}
>>> +
>>> +static int allocinfo_ioctl_get_content_id(struct seq_file *m, void __user *arg)
>>> +{
>>> + struct allocinfo_content_id params;
>>> +
>>> + codetag_lock_module_list(alloc_tag_cttype, true);
>>> + params.id = codetag_get_content_id(alloc_tag_cttype);
>>> + codetag_lock_module_list(alloc_tag_cttype, false);
>>> + if (copy_to_user(arg, ¶ms, sizeof(params)))
>>> + return -EFAULT;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int allocinfo_ioctl_get_at(struct seq_file *m, void __user *arg)
>>> +{
>>> + struct allocinfo_private *priv;
>>> + struct codetag *ct;
>>> + __u64 pos;
>>> + struct allocinfo_get_at params = {0};
>>> +
>>> + if (copy_from_user(¶ms, arg, sizeof(params)))
>>> + return -EFAULT;
>>> +
>>> + priv = (struct allocinfo_private *)m->private;
>>> + pos = params.pos;
>>> +
>>> + mutex_lock(&priv->ioctl_lock);
>>> + codetag_lock_module_list(alloc_tag_cttype, true);
>>> +
>>> + /* Find the codetag */
>>> + priv->ioctl_iter = codetag_get_ct_iter(alloc_tag_cttype);
>>> + ct = codetag_next_ct(&priv->ioctl_iter);
>>> + while (ct && pos--)
>>> + ct = codetag_next_ct(&priv->ioctl_iter);
>> No upper bound check on pos in ALLOCINFO_IOC_GET_AT:
>>
>> pos comes straight from userspace (__u64) with no validation.
>>
>> If the system has 10000 tags and someone passes pos=10001,
>>
>> the loop will still walk all 10000 tags just to return ENOENT
>>
>> -- all while holding ioctl_lock and mod_lock. It might be worth
>>
>> checking pos against the total tag count early. struct codetag_type
>>
>> is not exposed outside codetag.c though, so this would need a small helper.
> Ack.
>
>>
>> Thanks
>>
>> Best Regards
>>
>> Hao
>>
>>> + if (ct) {
>>> + allocinfo_to_params(ct, ¶ms.data);
>>> + priv->positioned = true;
>>> + }
>>> +
>>> + codetag_lock_module_list(alloc_tag_cttype, false);
>>> + mutex_unlock(&priv->ioctl_lock);
>>> +
>>> + if (!ct)
>>> + return -ENOENT;
>>> +
>>> + if (copy_to_user(arg, ¶ms, sizeof(params)))
>>> + return -EFAULT;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int allocinfo_ioctl_get_next(struct seq_file *m, void __user *arg)
>>> +{
>>> + struct allocinfo_private *priv;
>>> + struct codetag *ct;
>>> + struct allocinfo_tag_data params = {0};
>>> + int ret = 0;
>>> +
>>> + priv = (struct allocinfo_private *)m->private;
>>> +
>>> + mutex_lock(&priv->ioctl_lock);
>>> + codetag_lock_module_list(alloc_tag_cttype, true);
>>> +
>>> + if (!priv->positioned) {
>>> + priv->ioctl_iter = codetag_get_ct_iter(alloc_tag_cttype);
>>> + priv->positioned = true;
>>> + }
>>> +
>>> + ct = codetag_next_ct(&priv->ioctl_iter);
>>> + if (ct)
>>> + allocinfo_to_params(ct, ¶ms);
>>> +
>>> + if (!ct) {
>>> + priv->positioned = false;
>>> + ret = -ENOENT;
>>> + }
>>> + codetag_lock_module_list(alloc_tag_cttype, false);
>>> + mutex_unlock(&priv->ioctl_lock);
>>> +
>>> + if (ret == 0) {
>>> + if (copy_to_user(arg, ¶ms, sizeof(params)))
>>> + return -EFAULT;
>>> + }
>>> + return ret;
>>> +}
>>> +
>>> +static long allocinfo_ioctl(struct file *file, unsigned int cmd,
>>> + unsigned long __arg)
>>> +{
>>> + void __user *arg = (void __user *)__arg;
>>> + int ret;
>>> +
>>> + switch (cmd) {
>>> + case ALLOCINFO_IOC_CONTENT_ID:
>>> + ret = allocinfo_ioctl_get_content_id(file->private_data, arg);
>>> + break;
>>> + case ALLOCINFO_IOC_GET_AT:
>>> + ret = allocinfo_ioctl_get_at(file->private_data, arg);
>>> + break;
>>> + case ALLOCINFO_IOC_GET_NEXT:
>>> + ret = allocinfo_ioctl_get_next(file->private_data, arg);
>>> + break;
>>> + default:
>>> + ret = -ENOIOCTLCMD;
>>> + break;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +#ifdef CONFIG_COMPAT
>>> +static long allocinfo_compat_ioctl(struct file *file, unsigned int cmd,
>>> + unsigned long arg)
>>> +{
>>> + return allocinfo_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
>>> +}
>>> +#endif
>>> +
>>> +static const struct proc_ops allocinfo_proc_ops = {
>>> + .proc_open = allocinfo_open,
>>> + .proc_read_iter = seq_read_iter,
>>> + .proc_lseek = seq_lseek,
>>> + .proc_release = allocinfo_release,
>>> + .proc_ioctl = allocinfo_ioctl,
>>> +#ifdef CONFIG_COMPAT
>>> + .proc_compat_ioctl = allocinfo_compat_ioctl,
>>> +#endif
>>> +
>>> +};
>>> +
>>> size_t alloc_tag_top_users(struct codetag_bytes *tags, size_t count, bool can_sleep)
>>> {
>>> struct codetag_iterator iter;
>>> @@ -989,8 +1179,7 @@ static int __init alloc_tag_init(void)
>>> return 0;
>>> }
>>>
>>> - if (!proc_create_seq_private(ALLOCINFO_FILE_NAME, 0400, NULL, &allocinfo_seq_op,
>>> - sizeof(struct allocinfo_private), NULL)) {
>>> + if (!proc_create(ALLOCINFO_FILE_NAME, 0400, NULL, &allocinfo_proc_ops)) {
>>> pr_err("Failed to create %s file\n", ALLOCINFO_FILE_NAME);
>>> shutdown_mem_profiling(false);
>>> return -ENOMEM;
>>> diff --git a/lib/codetag.c b/lib/codetag.c
>>> index 304667897ad4..93aa30991563 100644
>>> --- a/lib/codetag.c
>>> +++ b/lib/codetag.c
>>> @@ -48,6 +48,17 @@ bool codetag_trylock_module_list(struct codetag_type *cttype)
>>> return down_read_trylock(&cttype->mod_lock) != 0;
>>> }
>>>
>>> +unsigned long codetag_get_content_id(struct codetag_type *cttype)
>>> +{
>>> + lockdep_assert_held(&cttype->mod_lock);
>>> +
>>> + /*
>>> + * next_mod_seq is updated on every load, so can be used to identify
>>> + * content changes.
>>> + */
>>> + return cttype->next_mod_seq;
>>> +}
>>> +
>>> struct codetag_iterator codetag_get_ct_iter(struct codetag_type *cttype)
>>> {
>>> struct codetag_iterator iter = {
^ permalink raw reply
* Re: [PATCH] docs/zh_TW: replace 接口 with 介面 in stable-api-nonsense.rst
From: Alex Shi @ 2026-06-08 1:34 UTC (permalink / raw)
To: Dongliang Mu, panzhipop, Hu Haowen
Cc: Jonathan Corbet, Shuah Khan, linux-doc, linux-kernel, Alex Shi,
Yanteng Si
In-Reply-To: <7b6913d0-921f-4f46-8d97-adf18eddb5d1@hust.edu.cn>
On 2026/6/5 21:02, Dongliang Mu wrote:
>
> On 6/4/26 3:34 AM, panzhipop wrote:
>> In Taiwan's standard terminology, as defined by the National Academy
>> for Educational Research (NAER) term bank (https://terms.naer.edu.tw/),
>> the correct Traditional Chinese translation for "interface" is "介面",
>> not "接口" (which is used in Simplified Chinese/Mainland China).
>>
>> Update the zh_TW translation of stable-api-nonsense.rst to use
>> the proper Taiwanese terminology.
> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
>>
>> Signed-off-by: panzhipop <kipp455187@gmail.com>
>> ---
Applied to git remote set-url linuxdoc
git@gitolite.kernel.org:pub/scm/linux/kernel/git/alexs/linux.git.
Thanks!
^ permalink raw reply
* Re: [PATCH] Documentation: ABI: sysfs-class-reboot-mode-reboot_modes: fix doc warnings
From: Randy Dunlap @ 2026-06-08 1:04 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pm, linux-arm-kernel, Sebastian Reichel, Shivendra Pratap,
linux-doc, linux-kernel
In-Reply-To: <d7cd7bb3-520f-4e80-8242-583f689f60db@infradead.org>
On 5/24/26 3:48 PM, Randy Dunlap wrote:
> Sebastian,
>
> On 4/27/26 2:11 AM, Bartosz Golaszewski wrote:
>> On Mon, 27 Apr 2026 01:27:05 +0200, Randy Dunlap <rdunlap@infradead.org> said:
>>> Repair the docs build warnings in this file by unindenting the description,
>>> adding blank lines, and using `` to quote *arg.
>>>
>>> WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description
>>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
>>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
>>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: WARNING: Inline emphasis start-string without end-string. [docutils]
>>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
>>>
>>> Fixes: d3da03025e6d ("Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes")
>>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>>> ---
>>
>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> This build warning is now in mainline.
> Will you be merging this patch soon?
ping.
> thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation/arch/x86: remove obsolete vdso32=2 compatibility note
From: Randy Dunlap @ 2026-06-08 0:54 UTC (permalink / raw)
To: Thorsten Blum, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Andrew Morton,
Jonathan Corbet, Shuah Khan
Cc: x86, linux-doc, linux-kernel
In-Reply-To: <20260607151614.79567-8-thorsten.blum@linux.dev>
On 6/7/26 8:16 AM, Thorsten Blum wrote:
> Commit b0b49f2673f0 ("x86, vdso: Remove compat vdso support") removed
> compat vDSO support and documented vdso32=2 as an alias for vdso32=0.
>
> However, since commit c06989da39cd ("x86/vdso: Ensure vdso32_enabled
> gets set to valid values only"), vdso32_setup() accepts only 0 and 1.
>
> Remove the obsolete vdso32=2 compatibility note and document only the
> supported values.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Great to see that we are keeping the docs up-to-date.
Thanks.
> ---
> Documentation/admin-guide/kernel-parameters.txt | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 97007f4f69d4..ce1c630d6859 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -8249,15 +8249,12 @@ Kernel parameters
>
> vdso32= [X86] Control the 32-bit vDSO
> vdso32=1: enable 32-bit VDSO
> - vdso32=0 or vdso32=2: disable 32-bit VDSO
> + vdso32=0: disable 32-bit VDSO
>
> See the help text for CONFIG_COMPAT_VDSO for more
> details. If CONFIG_COMPAT_VDSO is set, the default is
> vdso32=0; otherwise, the default is vdso32=1.
>
> - For compatibility with older kernels, vdso32=2 is an
> - alias for vdso32=0.
> -
> Try vdso32=0 if you encounter an error that says:
> dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
>
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 0/7] seg6: add SRv6 Mobile User Plane (RFC 9433) behaviors
From: Andrea Mayer @ 2026-06-08 0:39 UTC (permalink / raw)
To: Yuya Kusakabe
Cc: David S. Miller, Eric Dumazet, David Ahern, Jakub Kicinski,
Paolo Abeni, Simon Horman, Justin Iurman, Shuah Khan,
Jonathan Corbet, Shuah Khan, linux-kernel, netdev,
linux-kselftest, linux-doc, stefano.salsano, ahabdels,
Andrea Mayer, andrea
In-Reply-To: <CAGCJULPdm8jbveZsUm467_LBHRf5g=Jqd=XvCVKdNE1F2U99jg@mail.gmail.com>
On Wed, 20 May 2026 12:12:08 +0900
Yuya Kusakabe <yuya.kusakabe@gmail.com> wrote:
Hi Yuya,
Thanks for the reply. Inline answers below.
> On Sun, May 17, 2026 at 1:26 AM Andrea Mayer <andrea.mayer@uniroma2.it>
> wrote:
>
> > RFC 9433 Section 6 is titled "SRv6 Segment Endpoint Mobility
> > Behaviors", but Section 6.7 defines H.M.GTP4.D as "SR Policy Headend
> > with tunnel decapsulation and map to an SRv6 policy". This behavior
> > receives IPv4 packets and is not bound to any SID, so it does not fit
> > the endpoint model that seg6_local implements. Placing it there
> > required relaxing the ETH_P_IPV6 guard to accept ETH_P_IP and adding
> > input_family to seg6_action_desc, for a single behavior that does not
> > share the endpoint model.
> >
> > seg6_local is not the natural place for this behavior. The UAPI cannot
> > be undone once merged, so where it should live needs discussion on the
> > list before we proceed.
> >
> > Given the volume, moving the MUP code into a separate seg6_mobile.c
> > (say CONFIG_IPV6_SEG6_MUP) would keep seg6_local focused on the RFC
> > 8986 endpoint framework.
>
> I will move the MUP code out of seg6_local into a new
> net/ipv6/seg6_mobile.c under a new Kconfig symbol, and register the
> behaviors under a new lwtunnel encap type rather than
> LWTUNNEL_ENCAP_SEG6_LOCAL.
>
On the placement, the new lwtunnel encap type you propose could be a way to
implement the seg6_mobile.c separation. Since this touches UAPI in
include/uapi/linux/lwtunnel.h beyond the SRv6 subsystem and cannot be
undone once merged, it needs careful design.
> For naming I was thinking CONFIG_IPV6_SEG6_MOBILE and
> LWTUNNEL_ENCAP_SEG6_MOBILE to match the file name, but I have no strong
> preference over CONFIG_IPV6_SEG6_MUP if the list prefers that.
On the Kconfig symbol I agree, CONFIG_IPV6_SEG6_MOBILE matches the RFC 9433
Section 6 terminology better than CONFIG_IPV6_SEG6_MUP. Section 6 is titled
"SRv6 Segment Endpoint Mobility Behaviors".
> Once LWTUNNEL_ENCAP_SEG6_MOBILE is its own encap type, it feels
> natural to me to put H.M.GTP4.D there too rather than adding a
> separate LWTUNNEL_ENCAP_SEG6_MOBILE_HEADEND. What do you think?
H.M.GTP4.D in v2 shares the SEG6_LOCAL_MOBILE_* attributes and processing
helpers with the End.M.* behaviors. A separate
LWTUNNEL_ENCAP_SEG6_MOBILE_HEADEND would require its own attribute set,
lwtunnel_encap_ops, and iproute2 parser, similar to the current
implementation of RFC 8986 in the kernel (seg6 and seg6local).
As far as I can see, RFC 9433 has only one Headend behavior, and no L2 or
reduced variants. So a single LWTUNNEL_ENCAP_SEG6_MOBILE handling both
End.M.* and H.M.GTP4.D could be viable if accepting both input families
(ETH_P_IPV6 for End.M.*, ETH_P_IP for H.M.GTP4.D) is treated as a design
choice of the new encap type, not a stretching of the seg6_local endpoint
processing model.
These trade-offs are worth weighing in the final design. The patchset
rework (shared helper functions, the layout of the new UAPI attributes,
etc.) feeds into this decision. Like the encap type above, this is a UAPI
choice and cannot be undone once merged. I think the lwtunnel direction
will need feedback and comments from its community and maintainers.
> Will do, following the End.DT4/End.DT6/End.DT46 model: one patchset
> per behavior, with the behavior, helpers, and selftest as separate
> patches. The new code will be aligned with seg6_local.c style as
> part of this rework.
Sounds good.
> The mobile behaviors will define their own SEG6_MOBILE_* attribute
> namespace under LWTUNNEL_ENCAP_SEG6_MOBILE, with no reuse of any
> SEG6_LOCAL_* attribute. That keeps the established SEG6_LOCAL_*
> semantics untouched.
If LWTUNNEL_ENCAP_SEG6_MOBILE is added, using SEG6_MOBILE_* attributes
instead of SEG6_LOCAL_* removes the NH6/SRH/OIF overload raised in v2.
After solving the above, additional issues remain in the patchset,
for example src is overloaded across MUP behaviors, and v4_mask_len
needs revision. These are independent of the lwtunnel decision.
> I will drop VRF support from the initial behaviors and revisit it
> later as a separate optional attribute.
OK.
> Good idea. The prep patchset would introduce the SRv6-level reasons
> (SEG6_INVALID_SRH, SEG6_HMAC, ...) and convert the existing
> seg6_local and seg6_iptunnel call sites to use them. The
> mobile-specific reasons (BAD_SID, BAD_GTPU) would then be added
> together with the first behavior that uses them and reused by
> subsequent behaviors. NOMEM and MTU_EXCEEDED would be dropped in
> favor of the existing generic reasons, and the current
> INVALID_SRH_SL / BAD_INNER misuses would be replaced by the new
> SRv6-level reasons from the prep patchset.
>
> Would you prefer to lead on the prep patchset yourself, or would you
> like me to prepare it?
I can lead it. I have been evaluating the SRv6 drop reasons with my
research group, alongside other pending SRv6 patches.
We can sync offline on which SRv6 reasons fit your MUP behaviors, which
v2 MUP-specific reasons would fit better as SRv6 or generic, and what
stays MUP-specific.
> I will replace the python3/scapy heredocs with a statically compiled
> C helper for packet construction and validation, and extend the
> selftests to cover the cases you mention (SRH / no-SRH input paths,
> missing SRH where required, malformed SRH, and invalid attribute
> values).
Thanks. Maybe also worth covering bad packets, like fragmented input or
malformed GTP-U extensions.
> Thanks for taking that on. Given the cb/dst issues you described, I
> am inclined to drop NF_HOOK support from the initial mobile
> behaviors and add it in a follow-up patchset once your fix lands.
> The initial behaviors would then do a direct input -> output flow
> without the cb-context/finish-callback pattern, which avoids the
> issues entirely on day one and decouples this series from the
> pre-existing fix. Does that work for you, or would you prefer
> NF_HOOK to be present from the start and rebased on top of your fix?
Works for me. What matters is that the upcoming patches are well structured
so NF_HOOK can be wired in cleanly in the follow-up.
I am already working on the fix.
Thanks,
Andrea
P.S. I am temporarily writing from another address due to a mail
delivery issue at my @uniroma2.it address. Please always Cc my default
andrea.mayer@uniroma2.it address on replies.
^ permalink raw reply
* Re: [PATCH] hwmon: (asus-ec-sensors) add ROG STRIX B850-E GAMING WIFI
From: Guenter Roeck @ 2026-06-08 0:22 UTC (permalink / raw)
To: Eugene Shalygin
Cc: Jonathan Corbet, Shuah Khan, open list:HARDWARE MONITORING,
open list:DOCUMENTATION, open list
In-Reply-To: <20260607123626.100630-1-eugene.shalygin@gmail.com>
On Sun, Jun 07, 2026 at 02:36:16PM +0200, Eugene Shalygin wrote:
> The board has a similar sensor configuration to the
> ROG STRIX B850-I GAMING WIFI, but includes an additional
> T-Sensor header. The patch was provided via GitHub [1].
>
> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Applied.
Thanks,
Guenter
>
> [1] https://github.com/zeule/asus-ec-sensors/pull/105
> ---
> Documentation/hwmon/asus_ec_sensors.rst | 1 +
> drivers/hwmon/asus-ec-sensors.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
> index 9ad3f0a57f55..9669e729bb8b 100644
> --- a/Documentation/hwmon/asus_ec_sensors.rst
> +++ b/Documentation/hwmon/asus_ec_sensors.rst
> @@ -32,6 +32,7 @@ Supported boards:
> * ROG STRIX B550-E GAMING
> * ROG STRIX B550-I GAMING
> * ROG STRIX B650E-I GAMING WIFI
> + * ROG STRIX B850-E GAMING WIFI
> * ROG STRIX B850-I GAMING WIFI
> * ROG STRIX X470-F GAMING
> * ROG STRIX X470-I GAMING
> diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
> index b5d97a27f80d..27e39138011e 100644
> --- a/drivers/hwmon/asus-ec-sensors.c
> +++ b/drivers/hwmon/asus-ec-sensors.c
> @@ -628,6 +628,14 @@ static const struct ec_board_info board_info_strix_b650e_i_gaming = {
> .family = family_amd_600_series,
> };
>
> +static const struct ec_board_info board_info_strix_b850_e_gaming_wifi = {
> + .sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
> + SENSOR_TEMP_MB | SENSOR_TEMP_VRM |
> + SENSOR_TEMP_T_SENSOR | SENSOR_FAN_CPU_OPT,
> + .mutex_path = ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0,
> + .family = family_amd_800_series,
> +};
> +
> static const struct ec_board_info board_info_strix_b850_i_gaming_wifi = {
> .sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
> SENSOR_TEMP_MB | SENSOR_TEMP_VRM,
> @@ -868,6 +876,8 @@ static const struct dmi_system_id dmi_table[] = {
> &board_info_strix_b550_i_gaming),
> DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B650E-I GAMING WIFI",
> &board_info_strix_b650e_i_gaming),
> + DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-E GAMING WIFI",
> + &board_info_strix_b850_e_gaming_wifi),
> DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-I GAMING WIFI",
> &board_info_strix_b850_i_gaming_wifi),
> DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX X470-F GAMING",
^ permalink raw reply
* Re: [PATCH v2 1/1] hwmon: (asus-ec-sensors) add ROG STRIX B650E-E GAMING WIFI
From: Guenter Roeck @ 2026-06-08 0:21 UTC (permalink / raw)
To: Eugene Shalygin
Cc: Veronika Kossmann, Oleg Tsvetkov, Jonathan Corbet, Shuah Khan,
open list:HARDWARE MONITORING, open list:DOCUMENTATION, open list
In-Reply-To: <20260607110702.84599-2-eugene.shalygin@gmail.com>
On Sun, Jun 07, 2026 at 01:06:10PM +0200, Eugene Shalygin wrote:
> From: Veronika Kossmann <nanodesuu@gmail.com>
>
> Add support for ROG STRIX B650E-E GAMING WIFI
>
> Signed-off-by: Veronika Kossmann <nanodesuu@gmail.com>
> Co-developed-by: Oleg Tsvetkov <oleg-tsv@yandex.ru>
> Signed-off-by: Oleg Tsvetkov <oleg-tsv@yandex.ru>
> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Applied.
Thanks,
Guenter
> ---
> Documentation/hwmon/asus_ec_sensors.rst | 1 +
> drivers/hwmon/asus-ec-sensors.c | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
> index 9ad3f0a57f55..e14419811aac 100644
> --- a/Documentation/hwmon/asus_ec_sensors.rst
> +++ b/Documentation/hwmon/asus_ec_sensors.rst
> @@ -31,6 +31,7 @@ Supported boards:
> * ROG MAXIMUS Z690 FORMULA
> * ROG STRIX B550-E GAMING
> * ROG STRIX B550-I GAMING
> + * ROG STRIX B650E-E GAMING WIFI
> * ROG STRIX B650E-I GAMING WIFI
> * ROG STRIX B850-I GAMING WIFI
> * ROG STRIX X470-F GAMING
> diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
> index 070bb368f2b7..f351bcfc5679 100644
> --- a/drivers/hwmon/asus-ec-sensors.c
> +++ b/drivers/hwmon/asus-ec-sensors.c
> @@ -274,7 +274,7 @@ static const struct ec_sensor_info sensors_family_amd_600[] = {
> [ec_sensor_temp_cpu_package] =
> EC_SENSOR("CPU Package", hwmon_temp, 1, 0x00, 0x31),
> [ec_sensor_temp_mb] =
> - EC_SENSOR("Motherboard", hwmon_temp, 1, 0x00, 0x32),
> + EC_SENSOR("Motherboard", hwmon_temp, 1, 0x00, 0x32),
> [ec_sensor_temp_vrm] =
> EC_SENSOR("VRM", hwmon_temp, 1, 0x00, 0x33),
> [ec_sensor_temp_t_sensor] =
> @@ -616,6 +616,14 @@ static const struct ec_board_info board_info_strix_b550_i_gaming = {
> .family = family_amd_500_series,
> };
>
> +static const struct ec_board_info board_info_strix_b650e_e_gaming = {
> + .sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
> + SENSOR_TEMP_MB | SENSOR_TEMP_VRM |
> + SENSOR_FAN_CPU_OPT,
> + .mutex_path = ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0,
> + .family = family_amd_600_series,
> +};
> +
> static const struct ec_board_info board_info_strix_b650e_i_gaming = {
> .sensors = SENSOR_TEMP_VRM | SENSOR_TEMP_T_SENSOR |
> SENSOR_SET_TEMP_CHIPSET_CPU_MB | SENSOR_IN_CPU_CORE,
> @@ -861,6 +869,8 @@ static const struct dmi_system_id dmi_table[] = {
> &board_info_strix_b550_e_gaming),
> DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B550-I GAMING",
> &board_info_strix_b550_i_gaming),
> + DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B650E-E GAMING WIFI",
> + &board_info_strix_b650e_e_gaming),
> DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B650E-I GAMING WIFI",
> &board_info_strix_b650e_i_gaming),
> DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-I GAMING WIFI",
^ permalink raw reply
* Re: [RFC] hwmon: add a driver for the temp/voltage sensor on PolarFire SoC
From: Guenter Roeck @ 2026-06-07 23:56 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-hwmon, Lars Randers, Conor Dooley, Jonathan Corbet,
Shuah Khan, Daire McNamara, linux-doc, linux-kernel, linux-riscv,
Valentina.FernandezAlanis
In-Reply-To: <20260528-defog-lasso-84891a72775a@spud>
On 5/28/26 15:34, Conor Dooley wrote:
> On Wed, May 27, 2026 at 09:07:20PM -0700, Guenter Roeck wrote:
>> On Wed, May 27, 2026 at 10:06:11AM +0100, Conor Dooley wrote:
>>> From: Lars Randers <lranders@mail.dk>
>>>
>>> Add a driver for the temperature and voltage sensors on PolarFire SoC.
>>> The temperature reports how hot the die is, and the voltages are the
>>> SoC's 1.05, 1.8 and 2.5 volt rails respectively.
>>>
>>> The hardware supports alarms in theory, but there is an unconfirmed
>>> erratum that prevents clearing them once triggered, so no support is
>>> added.
>>>
>>> The hardware measures voltage with 16 bits, of which 1 is a sign bit and
>>> the remainder holds the voltage as a fixed point integer value. It's
>>> improbable that the hardware will work if the voltages are negative, so
>>> the driver ignores the sign bits.
>>>
>>> There's no dt support etc here because this is the child of a simple-mfd
>>> syscon.
>>>
>>> Signed-off-by: Lars Randers <lranders@mail.dk>
>>> Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>>> ---
>>> Guenter, there's one question here about the unit that update_interval
>>> is in, I didn't see anyone else using us, but I assume that's okay since
>>> the resolution that ms would give would be 8 steps only?
>>> RFC cos the question is also in the driver as a comment.
>>>
>>
>> That just came up in a different context. We'll add a new standard attribute
>> update_interval_us. The existing attribute MUST use ms. Everything else
>> would be an ABI violation.
>
> Cool. Sounds like Ferdinand is working on that based on the other
> thread.
>
> Do you think I should support both update_interval and update_interval_us in
> this driver?
>
I have been thinking about only supporting one for a given driver, but that
doesn't work because there are existing drivers which would benefit from
supporting microsecond-based intervals, so both it is (unless you want to
wait for _us support to be available and then just support that).
> If yes, should I do the ms version now and add the us version later once
> Ferdinand's work is complete?
>
Yes, that is what I would recommend.
Thanks,
Guenter
^ permalink raw reply
* [PATCH RFC v4 6/6] iio: osf: register IIO devices from capabilities
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Clean up the IIO sample push path.
Drop the redundant temperature scan mask.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/osf_core.c | 9 +++++----
drivers/iio/opensensorfusion/osf_iio.c | 15 +++------------
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/opensensorfusion/osf_core.c b/drivers/iio/opensensorfusion/osf_core.c
index e0a12de01..61ef55646 100644
--- a/drivers/iio/opensensorfusion/osf_core.c
+++ b/drivers/iio/opensensorfusion/osf_core.c
@@ -293,10 +293,11 @@ int osf_core_read_latest_sample(struct osf_device *osf, u16 sensor_type,
latest->sensor_index != sensor_index)
continue;
- if (latest->valid && channel < latest->channel_count) {
- *value = latest->values[channel];
- ret = 0;
- }
+ if (!latest->valid || channel >= latest->channel_count)
+ break;
+
+ *value = latest->values[channel];
+ ret = 0;
break;
}
mutex_unlock(&osf->latest_lock);
diff --git a/drivers/iio/opensensorfusion/osf_iio.c b/drivers/iio/opensensorfusion/osf_iio.c
index 5e5099878..3da3f2bda 100644
--- a/drivers/iio/opensensorfusion/osf_iio.c
+++ b/drivers/iio/opensensorfusion/osf_iio.c
@@ -6,7 +6,6 @@
#include <linux/iio/buffer.h>
#include <linux/iio/iio.h>
#include <linux/iio/kfifo_buf.h>
-#include <linux/string.h>
#include <linux/types.h>
#include <linux/units.h>
@@ -89,10 +88,6 @@ static const unsigned long osf_3axis_available_scan_masks[] = {
0
};
-static const unsigned long osf_temp_available_scan_masks[] = {
- BIT(0),
- 0
-};
static const struct osf_iio_sensor_spec osf_iio_sensor_specs[] = {
{
@@ -125,7 +120,6 @@ static const struct osf_iio_sensor_spec osf_iio_sensor_specs[] = {
.name = "osf-temp",
.channels = osf_temp_channels,
.num_channels = ARRAY_SIZE(osf_temp_channels),
- .available_scan_masks = osf_temp_available_scan_masks,
},
};
@@ -265,21 +259,18 @@ int osf_iio_push_sample(struct iio_dev *indio_dev, const s32 *values,
unsigned int channel_count)
{
struct osf_iio_state *state = iio_priv(indio_dev);
- s32 scan[OSF_MAX_SAMPLE_CHANNELS] = { };
s64 timestamp;
if (channel_count != state->spec->channel_count)
return -EPROTO;
- memcpy(scan, values, channel_count * sizeof(*values));
-
- /* Buffer state can change here; IIO rechecks it during the push path. */
+ /* This is only a fast path; IIO rechecks buffer state while pushing. */
if (!iio_buffer_enabled(indio_dev))
return 0;
timestamp = iio_get_time_ns(indio_dev);
- return iio_push_to_buffers_with_ts_unaligned(indio_dev, scan,
- channel_count * sizeof(*scan),
+ return iio_push_to_buffers_with_ts_unaligned(indio_dev, values,
+ channel_count * sizeof(*values),
timestamp);
}
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 5/6] iio: osf: add UART transport
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Use the generic Open Sensor Fusion compatible.
Avoid board-specific DT compatibles.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/Kconfig | 4 ++--
drivers/iio/opensensorfusion/osf_serdev.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/opensensorfusion/Kconfig b/drivers/iio/opensensorfusion/Kconfig
index 957caed2b..8b9376d28 100644
--- a/drivers/iio/opensensorfusion/Kconfig
+++ b/drivers/iio/opensensorfusion/Kconfig
@@ -10,5 +10,5 @@ config OPEN_SENSOR_FUSION
help
Build the Open Sensor Fusion UART IIO driver.
- The driver receives OSF0 frames over a serdev UART and registers
- IIO devices for supported capability entries.
+ The driver receives OSF protocol frames over a serdev UART and
+ registers IIO devices for supported capability entries.
diff --git a/drivers/iio/opensensorfusion/osf_serdev.c b/drivers/iio/opensensorfusion/osf_serdev.c
index 1ac93548d..fd36acd1b 100644
--- a/drivers/iio/opensensorfusion/osf_serdev.c
+++ b/drivers/iio/opensensorfusion/osf_serdev.c
@@ -91,7 +91,7 @@ static void osf_serdev_remove(struct serdev_device *serdev)
}
static const struct of_device_id osf_serdev_of_match[] = {
- { .compatible = "opensensorfusion,osf-green" },
+ { .compatible = "opensensorfusion,osf" },
{ }
};
MODULE_DEVICE_TABLE(of, osf_serdev_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 4/6] iio: osf: add stream parser
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Keep the parser focused on frame assembly.
Let the core decode complete frames once.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/osf_stream.c | 38 ++++++-----------------
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/drivers/iio/opensensorfusion/osf_stream.c b/drivers/iio/opensensorfusion/osf_stream.c
index a2739c987..957f73716 100644
--- a/drivers/iio/opensensorfusion/osf_stream.c
+++ b/drivers/iio/opensensorfusion/osf_stream.c
@@ -62,8 +62,6 @@ static size_t osf_stream_discard_to_magic(struct osf_stream *stream)
static int osf_stream_process(struct osf_stream *stream)
{
- struct osf_frame frame;
- size_t decoded_len;
size_t discarded;
size_t frame_len;
u32 payload_len;
@@ -82,10 +80,8 @@ static int osf_stream_process(struct osf_stream *stream)
if (!stream->len)
break;
- if (stream->len < OSF_FRAME_HEADER_LEN) {
- stream->stats.partial_frames++;
+ if (stream->len < OSF_FRAME_HEADER_LEN)
break;
- }
if (get_unaligned_le16(stream->buf + 6) !=
OSF_FRAME_HEADER_LEN) {
@@ -106,34 +102,18 @@ static int osf_stream_process(struct osf_stream *stream)
}
frame_len = OSF_FRAME_HEADER_LEN + payload_len + OSF_FRAME_CRC_LEN;
- if (stream->len < frame_len) {
- stream->stats.partial_frames++;
+ if (stream->len < frame_len)
break;
- }
-
- ret = osf_protocol_decode_frame(stream->buf, frame_len, &frame,
- &decoded_len);
- if (ret) {
- if (ret == -EBADMSG)
- stream->stats.bad_crc_frames++;
- stream->stats.dropped_bytes++;
- osf_stream_drop_invalid_head(stream);
- if (!first_err)
- first_err = ret;
- continue;
- }
-
- if (decoded_len != frame_len) {
- stream->stats.dropped_bytes++;
- osf_stream_drop_invalid_head(stream);
- if (!first_err)
- first_err = -EMSGSIZE;
- continue;
- }
ret = osf_core_receive_frame(stream->osf, stream->buf, frame_len);
if (ret) {
- osf_stream_discard(stream, frame_len);
+ if (ret == -EBADMSG) {
+ stream->stats.bad_crc_frames++;
+ stream->stats.dropped_bytes++;
+ osf_stream_drop_invalid_head(stream);
+ } else {
+ osf_stream_discard(stream, frame_len);
+ }
if (!first_err)
first_err = ret;
continue;
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 3/6] iio: osf: add protocol decoding
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Use a FourCC-style wire magic comparison.
Document signed little-endian sample handling.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/osf_protocol.c | 4 +++-
drivers/iio/opensensorfusion/osf_protocol.h | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/opensensorfusion/osf_protocol.c b/drivers/iio/opensensorfusion/osf_protocol.c
index ed91d3dd5..5bee545f3 100644
--- a/drivers/iio/opensensorfusion/osf_protocol.c
+++ b/drivers/iio/opensensorfusion/osf_protocol.c
@@ -11,6 +11,7 @@
#define OSF_CRC32_INIT GENMASK(31, 0)
#define OSF_CRC32_XOROUT GENMASK(31, 0)
+#define OSF_FRAME_MAGIC 0x3046534f /* "OSF0" little-endian */
static bool osf_sensor_type_valid(u16 sensor_type)
{
@@ -38,7 +39,7 @@ int osf_protocol_decode_frame(const u8 *buf, size_t len,
if (len < OSF_FRAME_MIN_LEN)
return -EMSGSIZE;
- if (buf[0] != 'O' || buf[1] != 'S' || buf[2] != 'F' || buf[3] != '0')
+ if (get_unaligned_le32(buf) != OSF_FRAME_MAGIC)
return -EPROTO;
major = buf[4];
@@ -136,6 +137,7 @@ int osf_protocol_sensor_sample_value(const struct osf_sensor_sample *sample,
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));
return 0;
diff --git a/drivers/iio/opensensorfusion/osf_protocol.h b/drivers/iio/opensensorfusion/osf_protocol.h
index 4b6fb131a..c62c2c254 100644
--- a/drivers/iio/opensensorfusion/osf_protocol.h
+++ b/drivers/iio/opensensorfusion/osf_protocol.h
@@ -2,6 +2,7 @@
#ifndef _OSF_PROTOCOL_H
#define _OSF_PROTOCOL_H
+#include <linux/bits.h>
#include <linux/types.h>
#define OSF_PROTOCOL_MAJOR 0
@@ -14,7 +15,7 @@
#define OSF_DEVICE_STATUS_LEN 20
#define OSF_CAP_REPORT_BASE_LEN 4
#define OSF_CAP_SENSOR_ENTRY_LEN 20
-#define OSF_CAPABILITY_FLAGS_MASK 0x00000003U
+#define OSF_CAPABILITY_FLAGS_MASK GENMASK(1, 0)
enum osf_message_type {
OSF_MSG_SENSOR_SAMPLE = 0x0001,
@@ -44,6 +45,7 @@ struct osf_frame {
u64 sequence;
u64 timestamp_us;
u32 flags;
+ /* payload points into the caller-owned frame buffer. */
const u8 *payload;
u32 crc;
};
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 2/6] Documentation: iio: add Open Sensor Fusion driver overview
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Add a short driver-facing overview.
Leave full protocol details to project docs.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
Documentation/iio/index.rst | 1 +
.../iio/open-sensor-fusion-protocol-v0.rst | 308 ------------------
Documentation/iio/open-sensor-fusion.rst | 62 ++++
MAINTAINERS | 3 +-
4 files changed, 64 insertions(+), 310 deletions(-)
delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
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-protocol-v0.rst b/Documentation/iio/open-sensor-fusion-protocol-v0.rst
deleted file mode 100644
index 80852f4cf..000000000
--- a/Documentation/iio/open-sensor-fusion-protocol-v0.rst
+++ /dev/null
@@ -1,308 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0-only
-
-Open Sensor Fusion protocol v0
-==============================
-
-This document describes the OSF0 UART wire format used by the Open Sensor
-Fusion Linux IIO driver. It is a wire format reference for the host driver. It
-is not a firmware programming interface.
-
-Background
-----------
-
-Open Sensor Fusion is an open hardware project for sensor aggregation devices
-and Linux IIO host support. It is not a generic sensor protocol standard. The
-first concrete hardware target is OSF GREEN, an STM32F405-based board that
-streams OSF0 frames to a Linux host.
-
-Public project documentation is available at:
-
-- https://www.opensensorfusion.org/
-- https://github.com/opensensorfusion
-- https://github.com/opensensorfusion/opensensorfusion-hardware
-- https://github.com/opensensorfusion/opensensorfusion-linux
-
-Wire format and driver subset
------------------------------
-
-OSF0 defines a small device-to-host UART frame format. The current RFC driver
-supports only the subset needed to expose OSF GREEN raw sensor data through
-IIO:
-
-- ``SENSOR_SAMPLE`` frames for accelerometer, gyroscope, magnetometer, and
- temperature samples.
-- ``CAPABILITY_REPORT`` frames used to create the supported IIO devices.
-- ``DEVICE_STATUS`` frames cached for diagnostics.
-
-The driver ignores vendor private message types and does not implement command
-transport, calibration controls, USB transport, fusion output, or runtime
-capability removal.
-
-Device model
-------------
-
-An OSF0 device is a sensor aggregation device. It sends binary frames from the
-device to the host. The host driver decodes the frames and maps supported
-sensors to IIO devices.
-
-The hardware used for smoke testing is an OSF GREEN prototype with an
-STM32F405RGT6 MCU, an ICM42688P-class IMU, and an MMC5983MA magnetometer. That
-hardware is the first supported target for the RFC driver.
-
-Transport
----------
-
-The transport is UART at 115200 baud, 8 data bits, no parity, and 1 stop bit.
-The Linux transport is serdev. The v0 upstream driver covers device-to-host
-frames. Flow control is not used by the tested stream.
-
-Byte order
-----------
-
-All multi-byte integer fields are little-endian. Samples use signed 32-bit
-little-endian integers when ``sample_format`` is ``s32``.
-
-Frame format
-------------
-
-Each frame has a fixed 38-byte header, a payload, and a 4-byte CRC.
-
-.. list-table::
- :header-rows: 1
-
- * - Offset
- - Size
- - Field
- - Description
- * - 0
- - 4
- - magic
- - ASCII ``OSF0``
- * - 4
- - 1
- - protocol_major
- - Must be ``0``
- * - 5
- - 1
- - protocol_minor
- - Minor version
- * - 6
- - 2
- - header_len
- - Must be ``38``
- * - 8
- - 2
- - message_type
- - Message type
- * - 10
- - 4
- - payload_len
- - Payload length in bytes
- * - 14
- - 8
- - sequence
- - Monotonic device sequence
- * - 22
- - 8
- - timestamp_us
- - Device timestamp in microseconds
- * - 30
- - 4
- - flags
- - Message flags
- * - 34
- - 4
- - reserved
- - Must be zero for v0
- * - 38
- - payload_len
- - payload
- - Message payload
- * - 38 + payload_len
- - 4
- - crc32
- - CRC32 over header and payload
-
-The frame CRC is IEEE CRC32 as implemented by ``crc32_le()`` with initial
-value ``0xffffffff`` and final XOR value ``0xffffffff``. The CRC field is not
-included in the CRC input.
-
-Message types
--------------
-
-.. list-table::
- :header-rows: 1
-
- * - Value
- - Name
- - Direction
- * - ``0x0001``
- - ``SENSOR_SAMPLE``
- - device to host
- * - ``0x0002``
- - ``DEVICE_STATUS``
- - device to host
- * - ``0x0003``
- - ``CAPABILITY_REPORT``
- - device to host
-
-Message types ``0x7f00`` through ``0x7fff`` are reserved. Values at or above
-``0x8000`` are vendor private and are ignored by the current RFC driver.
-
-``SENSOR_SAMPLE`` payload
--------------------------
-
-The payload is a 16-byte payload header followed by ``4 * channel_count`` bytes
-of sample data.
-
-.. list-table::
- :header-rows: 1
-
- * - Offset
- - Size
- - Field
- - Description
- * - 0
- - 2
- - sensor_type
- - Sensor type ID
- * - 2
- - 2
- - sensor_index
- - Instance index
- * - 4
- - 2
- - channel_count
- - Number of ``s32`` channels
- * - 6
- - 2
- - sample_format
- - Must be ``1`` (``s32``)
- * - 8
- - 4
- - scale_nano
- - Scale factor in nano-units
- * - 12
- - 4
- - reserved
- - Must be zero for v0
- * - 16
- - 4 * channel_count
- - samples
- - Signed 32-bit channel samples
-
-The current RFC driver accepts only ``sample_format = s32`` and only the fixed
-channel counts used by its supported IIO devices.
-
-``DEVICE_STATUS`` payload
--------------------------
-
-The payload size is 20 bytes. Fields are ``uptime_s``, ``status_flags``,
-``error_flags``, ``dropped_frames``, and a reserved field. Each field is
-32 bits. The reserved field must be zero for v0.
-
-``CAPABILITY_REPORT`` payload
------------------------------
-
-The base payload size is 4 bytes. It contains ``capability_count`` and a
-reserved field. The reserved field must be zero for v0. Each capability entry
-is 20 bytes:
-
-.. list-table::
- :header-rows: 1
-
- * - Offset
- - Size
- - Field
- - Description
- * - 0
- - 2
- - sensor_type
- - Sensor type ID
- * - 2
- - 2
- - sensor_index
- - Instance index
- * - 4
- - 2
- - channel_count
- - Number of channels
- * - 6
- - 2
- - sample_format
- - Must be ``1`` (``s32``)
- * - 8
- - 4
- - scale_nano
- - Scale factor in nano-units
- * - 12
- - 4
- - flags
- - Capability flags
- * - 16
- - 4
- - reserved
- - Must be zero for v0
-
-Capability flag bit 0 means enabled by default. Bit 1 means calibrated data can
-be provided by the device. Other bits are invalid for v0.
-
-Sensor type IDs
----------------
-
-.. list-table::
- :header-rows: 1
-
- * - Value
- - Sensor
- - Current RFC driver mapping
- * - ``0x0001``
- - accelerometer
- - ``IIO_ACCEL``, X/Y/Z
- * - ``0x0002``
- - gyroscope
- - ``IIO_ANGL_VEL``, X/Y/Z
- * - ``0x0003``
- - magnetometer
- - ``IIO_MAGN``, X/Y/Z
- * - ``0x0004``
- - barometer
- - not mapped
- * - ``0x0005``
- - temperature
- - ``IIO_TEMP``
- * - ``0x0006``
- - humidity
- - not mapped
- * - ``0x0007``
- - ambient light
- - not mapped
- * - ``0x0008``
- - proximity
- - not mapped
-
-Scaling
--------
-
-``scale_nano`` is the per-channel scale value in nano-units. The Linux driver
-maps it to ``IIO_CHAN_INFO_SCALE`` as integer plus nano. The exact physical
-unit depends on the IIO channel type.
-
-Timestamps
-----------
-
-The frame header carries ``timestamp_us``, a device-side timestamp in
-microseconds. UART buffering and host scheduling can add delay before a frame
-is processed by the host.
-
-The current RFC driver does not claim production-grade host/device timestamp
-correlation. Buffered IIO timestamps are taken from IIO timestamp clock handling
-when samples are pushed to IIO buffers.
-
-Non-goals for v0 upstream
--------------------------
-
-The v0 upstream driver does not include USB transport, fusion output, Attitude
-and Heading Reference System (AHRS) output, Kalman output, calibration command
-ABI, custom sysfs control surface, production timestamp correlation, or runtime
-capability removal.
diff --git a/Documentation/iio/open-sensor-fusion.rst b/Documentation/iio/open-sensor-fusion.rst
new file mode 100644
index 000000000..244a4fecb
--- /dev/null
+++ b/Documentation/iio/open-sensor-fusion.rst
@@ -0,0 +1,62 @@
+.. 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. Protocol versioning is carried by the
+``protocol_major`` and ``protocol_minor`` fields in the frame header.
+
+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.
diff --git a/MAINTAINERS b/MAINTAINERS
index e227b9aff..2ddefc42d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20015,7 +20015,7 @@ OPEN SENSOR FUSION IIO DRIVER
M: Jinseob Kim <kimjinseob88@gmail.com>
S: Maintained
F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
-F: Documentation/iio/open-sensor-fusion-protocol-v0.rst
+F: Documentation/iio/open-sensor-fusion.rst
F: drivers/iio/opensensorfusion/Kconfig
F: drivers/iio/opensensorfusion/Makefile
F: drivers/iio/opensensorfusion/osf_core.*
@@ -20024,7 +20024,6 @@ F: drivers/iio/opensensorfusion/osf_protocol.*
F: drivers/iio/opensensorfusion/osf_serdev.c
F: drivers/iio/opensensorfusion/osf_stream.*
-
OPENCOMPUTE PTP CLOCK DRIVER
M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
L: netdev@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Describe the OSF sensor aggregation hub.
Use the generic opensensorfusion,osf compatible.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
.../iio/imu/opensensorfusion,osf-green.yaml | 43 -------------------
.../bindings/iio/opensensorfusion,osf.yaml | 43 +++++++++++++++++++
MAINTAINERS | 27 ++++++------
3 files changed, 57 insertions(+), 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
diff --git a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml b/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
deleted file mode 100644
index 626b41fb0..000000000
--- a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
+++ /dev/null
@@ -1,43 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/iio/imu/opensensorfusion,osf-green.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: OSF GREEN sensor aggregation board
-
-maintainers:
- - Jinseob Kim <kimjinseob88@gmail.com>
-
-description: |
- OSF GREEN is an STM32F405-based sensor aggregation board from the Open
- Sensor Fusion open hardware project. It sends OSF0 capability, status, and
- sample frames to a host over a UART link.
-
- Open Sensor Fusion is not a generic industry standard. Public project and
- hardware documentation is available at:
-
- https://github.com/opensensorfusion
- https://github.com/opensensorfusion/opensensorfusion-hardware
-
-allOf:
- - $ref: /schemas/serial/serial-peripheral-props.yaml#
-
-properties:
- compatible:
- const: opensensorfusion,osf-green
-
-required:
- - compatible
-
-unevaluatedProperties: false
-
-examples:
- - |
- serial {
- sensor {
- compatible = "opensensorfusion,osf-green";
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
new file mode 100644
index 000000000..a4049715a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Open Sensor Fusion Sensor Aggregation Hub
+
+maintainers:
+ - Jinseob Kim <kimjinseob88@gmail.com>
+
+description: |
+ Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
+ protocol data stream over its host interface and may report capabilities and
+ samples for multiple sensor classes. The Linux driver discovers the actual
+ sensor channels from OSF capability reports instead of describing those
+ sensors in Device Tree.
+
+ Open Sensor Fusion is not a generic industry standard. Public project
+ documentation is available at:
+
+ https://github.com/opensensorfusion
+
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: opensensorfusion,osf
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial {
+ sensor {
+ compatible = "opensensorfusion,osf";
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 56181470d..e227b9aff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19977,19 +19977,6 @@ F: Documentation/networking/oa-tc6-framework.rst
F: drivers/net/ethernet/oa_tc6.c
F: include/linux/oa_tc6.h
-OPEN SENSOR FUSION IIO DRIVER
-M: Jinseob Kim <kimjinseob88@gmail.com>
-S: Maintained
-F: Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
-F: Documentation/iio/open-sensor-fusion-protocol-v0.rst
-F: drivers/iio/opensensorfusion/Kconfig
-F: drivers/iio/opensensorfusion/Makefile
-F: drivers/iio/opensensorfusion/osf_core.*
-F: drivers/iio/opensensorfusion/osf_iio.*
-F: drivers/iio/opensensorfusion/osf_protocol.*
-F: drivers/iio/opensensorfusion/osf_serdev.c
-F: drivers/iio/opensensorfusion/osf_stream.*
-
OPEN FIRMWARE AND FLATTENED DEVICE TREE
M: Rob Herring <robh@kernel.org>
M: Saravana Kannan <saravanak@kernel.org>
@@ -20024,6 +20011,20 @@ F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+OPEN SENSOR FUSION IIO DRIVER
+M: Jinseob Kim <kimjinseob88@gmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
+F: Documentation/iio/open-sensor-fusion-protocol-v0.rst
+F: drivers/iio/opensensorfusion/Kconfig
+F: drivers/iio/opensensorfusion/Makefile
+F: drivers/iio/opensensorfusion/osf_core.*
+F: drivers/iio/opensensorfusion/osf_iio.*
+F: drivers/iio/opensensorfusion/osf_protocol.*
+F: drivers/iio/opensensorfusion/osf_serdev.c
+F: drivers/iio/opensensorfusion/osf_stream.*
+
+
OPENCOMPUTE PTP CLOCK DRIVER
M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
L: netdev@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
This RFC series adds an Industrial I/O driver for Open Sensor Fusion
sensor aggregation devices.
Open Sensor Fusion is an open hardware project for sensor
aggregation devices. The Linux IIO driver is an initial host-side
implementation for OSF devices. The driver receives OSF frames over
UART, uses device capability reports to discover supported sensor
streams, and exposes supported raw sensor data through IIO devices.
This series is still marked RFC because the DT binding identity, the
supported OSF protocol subset, and protocol extension and backward
compatibility rules are still under review. The v4 series
intentionally models the Linux device as a generic Open Sensor Fusion
device rather than an OSF GREEN board-specific device. OSF GREEN is
the prototype board used for current runtime testing, not the Linux DT
compatible or driver identity.
The current wire format uses the OSF0 magic for protocol major
version 0. That is kept as an internal wire-format detail for
compatibility with existing firmware, tools, and runtime smoke
evidence. The public driver identity remains Open Sensor Fusion / OSF,
with protocol versioning handled by the protocol major/minor fields.
Project links:
https://www.opensensorfusion.org/
https://github.com/opensensorfusion
https://github.com/opensensorfusion/opensensorfusion-hardware
https://github.com/opensensorfusion/opensensorfusion-linux
Runtime testing so far has used an OSF GREEN prototype connected to a
Raspberry Pi over UART. On Raspberry Pi 6.12.75+rpt-rpi-v8, the
driver registered osf-accel, osf-gyro, osf-magn, and osf-temp from a
capability report. Raw reads and software kfifo buffer reads were
tested for all four IIO devices.
Changes since v3:
* Explain why the series is still RFC.
* Move the DT binding out of iio/imu because the device is a sensor
aggregation device rather than an IMU.
* Replace the OSF GREEN board-specific compatible with the generic
opensensorfusion,osf compatible.
* Treat OSF GREEN as tested prototype hardware / board model
information, not as the Linux compatible string.
* Rename the kernel documentation to open-sensor-fusion.rst and
reduce it to a driver-facing overview.
* Add the IIO documentation toctree entry.
* Keep full protocol details and compatibility rules in project
documentation rather than duplicating the full wire specification in
the kernel tree.
* Avoid using OSF0 as the public driver identity; keep it only as the
current wire magic for protocol major version 0.
* Add FourCC-style wire magic handling in the decoder.
* Use GENMASK() for the capability flags mask.
* Clarify signed 32-bit little-endian sample decoding.
* Stop counting normal partial UART receive waits as partial frame
errors.
* Avoid decoding complete frames twice in the stream/core path.
* Remove the local scan[] bounce before
iio_push_to_buffers_with_ts_unaligned() and pass the values buffer
directly.
* Remove the meaningless temperature available_scan_masks entry.
* Update MAINTAINERS paths for the new binding and documentation
names.
Jinseob Kim (6):
dt-bindings: iio: add Open Sensor Fusion device
Documentation: iio: add Open Sensor Fusion driver overview
iio: osf: add protocol decoding
iio: osf: add stream parser
iio: osf: add UART transport
iio: osf: register IIO devices from capabilities
.../iio/imu/opensensorfusion,osf-green.yaml | 43 ---
.../bindings/iio/opensensorfusion,osf.yaml | 43 +++
Documentation/iio/index.rst | 1 +
.../iio/open-sensor-fusion-protocol-v0.rst | 308 ------------------
Documentation/iio/open-sensor-fusion.rst | 62 ++++
MAINTAINERS | 26 +-
drivers/iio/opensensorfusion/Kconfig | 4 +-
drivers/iio/opensensorfusion/osf_core.c | 9 +-
drivers/iio/opensensorfusion/osf_iio.c | 15 +-
drivers/iio/opensensorfusion/osf_protocol.c | 4 +-
drivers/iio/opensensorfusion/osf_protocol.h | 4 +-
drivers/iio/opensensorfusion/osf_serdev.c | 2 +-
drivers/iio/opensensorfusion/osf_stream.c | 38 +--
13 files changed, 145 insertions(+), 414 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
create mode 100644 Documentation/iio/open-sensor-fusion.rst
--
2.43.0
^ permalink raw reply
* Re: [PATCH 13/15] accel/qda: Add DSP process creation and release
From: Dmitry Baryshkov @ 2026-06-07 21:16 UTC (permalink / raw)
To: Ekansh Gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <568987b0-6f54-4b51-b1c0-416435e3f564@oss.qualcomm.com>
On Thu, Jun 04, 2026 at 10:47:13AM +0530, Ekansh Gupta wrote:
> On 20-05-2026 19:30, Dmitry Baryshkov wrote:
> > On Tue, May 19, 2026 at 11:46:03AM +0530, Ekansh Gupta via B4 Relay wrote:
> >>
> >> +/**
> >> + * qda_ioctl_init_create() - Create a DSP process
> >> + * @dev: DRM device structure
> >> + * @data: User-space data (struct drm_qda_init_create)
> >> + * @file_priv: DRM file private data
> >> + *
> >> + * Return: 0 on success, negative error code on failure
> >> + */
> >> +int qda_ioctl_init_create(struct drm_device *dev, void *data, struct drm_file *file_priv)
> >> +{
> >> + return fastrpc_invoke(FASTRPC_RMID_INIT_CREATE, dev, data, file_priv);
> >
> > Where is INIT_CREATE_ATTR, which you described earlier?
> INIT_CREATE_ATTR is used while `sc` creation so the DSP considers the
> request is coming with some attributes, the ioctl functions are going to
> be the same in both the cases, so keeping it unchanged and the decision
> is taken while `sc` is getting created.>
Ack, I missed it earlier.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 12/15] accel/qda: Add FastRPC invocation support
From: Dmitry Baryshkov @ 2026-06-07 21:14 UTC (permalink / raw)
To: Ekansh Gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <ba003d7d-03f5-4572-8321-3d1f666c8c27@oss.qualcomm.com>
On Thu, Jun 04, 2026 at 10:39:14AM +0530, Ekansh Gupta wrote:
> On 20-05-2026 19:26, Dmitry Baryshkov wrote:
> > On Tue, May 19, 2026 at 11:46:02AM +0530, Ekansh Gupta via B4 Relay wrote:
> >> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> >>
> >> Implement the FastRPC remote procedure call path, allowing user-space
> >> to invoke methods on the DSP via DRM_IOCTL_QDA_REMOTE_INVOKE.
> >>
> >> qda_fastrpc.c / qda_fastrpc.h
> >> Implements the FastRPC protocol layer: argument marshalling
> >> (qda_fastrpc_invoke_pack), response unmarshalling
> >> (qda_fastrpc_invoke_unpack), and invocation context lifecycle
> >> management. Each invocation allocates a fastrpc_invoke_context
> >> which tracks buffer descriptors, GEM objects, and the completion
> >> used to synchronise with the DSP response.
> >>
> >> Buffer arguments are handled in three ways:
> >> - DMA-BUF fd: imported via PRIME, IOMMU-mapped dma_addr used
> >> - Direct (inline): copied into the GEM-backed message buffer
> >> - DMA handle: fd forwarded to DSP, physical page descriptor computed
> >
> > No. This needs to go away. The QDA should support only one way to pass
> > data - via the GEM buffers. Everything else should be handled by the
> > shim layer, etc.
> each FD passed here is a GEM buffer. The reason to pass fd is that there
> are some APIs on DSP side which takes fd as an argument and the user
> might use the same on their skel implementation. So in this case the
> remote call will take fd to DSP and the skel implementation will use the
> FD.>
Then handle it all on the userspace side. In the end, bad library API is
not a reason to complicate kernel API and kernel driver.
> >> +#define FASTRPC_SCALARS(method, in, out) \
> >> + FASTRPC_BUILD_SCALARS(0, method, in, out, 0, 0)
> >> +
> >> +/**
> >> + * struct fastrpc_buf_overlap - Buffer overlap tracking structure
> >> + *
> >> + * Tracks overlapping buffer regions to optimise memory mapping and avoid
> >> + * redundant mappings of the same physical memory.
> >
> > WHat for? Even if this is a valid optimization, implement it as a
> > subsequent patch. The first goal should be very simple - get GEM buffers
> > from the app, pass them to the DSP, read the results.
> yes, this implementation is mimicking the existing fastrpc design where
> non-FD buffers are also supported. I am currently evaluating the
> maintainance of such buffers from userspace side and trying to
> understand the impacts of the same. I am planning to bring it as a
> future enhancement if there is no regression.>
Other way around. Drop it for now and bring it back if it has any
positive impact.
> >> + */
> >> +struct fastrpc_buf_overlap {
> >
> > Stop clashing the names with the existing fastrpc driver.
> ack.>
> >> + /** @start: Start address of the buffer in user virtual address space */
> >> + u64 start;
> >> + /** @end: End address of the buffer in user virtual address space */
> >> + u64 end;
> >> + /** @raix: Remote argument index associated with this overlap */
> >> + int raix;
> >> + /** @mstart: Start address of the mapped region */
> >> + u64 mstart;
> >> + /** @mend: End address of the mapped region */
> >> + u64 mend;
> >> + /** @offset: Offset within the mapped region */
> >> + u64 offset;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_remote_dmahandle - Remote DMA handle descriptor
> >> + */
> >> +struct fastrpc_remote_dmahandle {
> >> + /** @fd: DMA-BUF file descriptor */
> >> + s32 fd;
> >> + /** @offset: Byte offset within the DMA-BUF */
> >> + u32 offset;
> >> + /** @len: Length of the region in bytes */
> >> + u32 len;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_remote_buf - Remote buffer descriptor
> >> + */
> >> +struct fastrpc_remote_buf {
> >> + /** @pv: Buffer pointer (user virtual address) */
> >> + u64 pv;
> >> + /** @len: Length of the buffer in bytes */
> >> + u64 len;
> >> +};
> >> +
> >> +/**
> >> + * union fastrpc_remote_arg - Remote argument (buffer or DMA handle)
> >> + */
> >> +union fastrpc_remote_arg {
> >> + /** @buf: Inline buffer descriptor */
> >> + struct fastrpc_remote_buf buf;
> >> + /** @dma: DMA-BUF handle descriptor */
> >> + struct fastrpc_remote_dmahandle dma;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_phy_page - Physical page descriptor
> >> + */
> >> +struct fastrpc_phy_page {
> >> + /** @addr: Physical (IOMMU) address of the page */
> >> + u64 addr;
> >> + /** @size: Size of the contiguous region in bytes */
> >> + u64 size;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_invoke_buf - Invoke buffer descriptor
> >> + */
> >> +struct fastrpc_invoke_buf {
> >> + /** @num: Number of contiguous physical regions */
> >> + u32 num;
> >> + /** @pgidx: Index into the physical page array */
> >> + u32 pgidx;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_msg - FastRPC wire message for remote invocations
> >> + *
> >> + * Sent to the remote processor via RPMsg. This is the exact layout
> >> + * the DSP expects; do not reorder or add fields without DSP firmware
> >> + * coordination.
> >> + */
> >> +struct fastrpc_msg {
> >> + /** @remote_session_id: Session identifier on the remote processor */
> >> + int remote_session_id;
> >> + /** @tid: Thread ID of the invoking thread */
> >> + int tid;
> >> + /** @ctx: Context identifier for matching request/response */
> >> + u64 ctx;
> >> + /** @handle: Handle of the remote method to invoke */
> >> + u32 handle;
> >> + /** @sc: Scalars value encoding in/out buffer counts */
> >> + u32 sc;
> >> + /** @addr: Physical address of the message payload buffer */
> >> + u64 addr;
> >> + /** @size: Size of the message payload in bytes */
> >> + u64 size;
> >> +};
> >> +
> >> +/**
> >> + * struct qda_msg - FastRPC message with kernel-internal bookkeeping
> >> + *
> >> + * The wire-format portion is kept in the embedded @fastrpc member (must
> >> + * be first) so that &qda_msg->fastrpc can be passed directly to
> >> + * rpmsg_send() without a copy.
> >> + */
> >> +struct qda_msg {
> >> + /**
> >> + * @fastrpc: Wire-format message sent to the DSP via RPMsg.
> >> + * Must be the first member.
> >> + */
> >> + struct fastrpc_msg fastrpc;
> >> + /** @buf: Kernel virtual address of the payload buffer */
> >> + void *buf;
> >> + /** @phys: Physical/DMA address of the payload buffer */
> >> + u64 phys;
> >> + /** @ret: Return value from the remote processor */
> >> + int ret;
> >> + /** @fastrpc_ctx: Back-pointer to the owning invocation context */
> >> + struct fastrpc_invoke_context *fastrpc_ctx;
> >> + /** @file_priv: DRM file private data for GEM object lookup */
> >> + struct drm_file *file_priv;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_invoke_context - Remote procedure call invocation context
> >> + *
> >> + * Maintains all state for a single remote procedure call, including buffer
> >> + * management, synchronisation, and result handling.
> >> + */
> >> +struct fastrpc_invoke_context {
> >> + /** @node: List node for linking contexts in a queue */
> >> + struct list_head node;
> >> + /** @ctxid: Unique context identifier (XArray key shifted left by 4) */
> >> + u64 ctxid;
> >> + /** @inbufs: Number of input buffers */
> >> + int inbufs;
> >> + /** @outbufs: Number of output buffers */
> >> + int outbufs;
> >> + /** @handles: Number of DMA-BUF handle arguments */
> >> + int handles;
> >> + /** @nscalars: Total number of scalar arguments */
> >> + int nscalars;
> >> + /** @nbufs: Total number of buffer arguments (inbufs + outbufs) */
> >> + int nbufs;
> >
> > If it is inbufs + outbufs, why do you need it here?
> >
> >> + /** @pid: Process ID of the calling process */
> >> + int pid;
> >> + /** @retval: Return value from the remote invocation */
> >> + int retval;
> >> + /** @metalen: Length of the FastRPC metadata header in bytes */
> >> + int metalen;
> >
> > size_t, also why do you need it?
> >
> >> + /** @remote_session_id: Session identifier on the remote processor */
> >> + int remote_session_id;
> >> + /** @pd: Protection domain identifier encoded into the context ID */
> >> + int pd;
> >> + /** @type: Invocation type (e.g. FASTRPC_RMID_INVOKE_DYNAMIC) */
> >> + int type;
> >> + /** @sc: Scalars value encoding in/out buffer counts */
> >> + u32 sc;
> >
> > How is this different from the counts above?
> sc carries the method id and handle counts. The reason to maintain count
> separately is to avoid calculating it again and again.>
Is it just a sum of several values or something more complicated?
> >> + /** @handle: Handle of the remote method being invoked */
> >> + u32 handle;
> >> + /** @crc: Pointer to CRC values for data integrity checking */
> >> + u32 *crc;
> >
> > Add it later. It's unused. Drop all unused fields.
> ack.>
> >> + /** @fdlist: Pointer to array of DMA-BUF file descriptors */
> >> + u64 *fdlist;
> >
> > Why do you need DMA-BUFs in the invocation context? They all should be
> > GEM buffers.
> the reason is that the users are dependent on FDs as they can import
> buffers allocated from anywhere and there are DSP APIs which takes fd as
> an argument, so they might end up using the same in there skel
> implementation.>
No, DSP API can't take FD, they don't quite cross the OS and IOMMU
boundary. It's the userspace library API. Which might be improved,
rewritten, implemented underneath, etc. For the kernel side please,
pass _only_ GEM handles + offsets.
> >> + /** @pkt_size: Total payload size in bytes */
> >> + u64 pkt_size;
> >> + /** @aligned_pkt_size: Page-aligned payload size for GEM allocation */
> >> + u64 aligned_pkt_size;
> >> + /** @list: Array of invoke buffer descriptors */
> >> + struct fastrpc_invoke_buf *list;
> >> + /** @pages: Array of physical page descriptors for all arguments */
> >> + struct fastrpc_phy_page *pages;
> >> + /** @input_pages: Array of physical page descriptors for input buffers */
> >> + struct fastrpc_phy_page *input_pages;
> >
> > I think you are trying to bring all the complexity from the old driver
> > with no added benefit. Please don't. Use the existing memory manager.
> > Let it handle all the gory details. If someting is not there, we should
> > consider extending GEM instead.
> I'm not changing the metadata format as the DSP might not understand the
> messages if we modify it.
Well, it's up to you to know if DSP will understand the message or not.
The probability ("might not") is not suitable here. Anyway, let's get
rid of the various data formats first, then maybe some of the items will
go away on their own.
> Also, the fd is still being used because of
> the client dependency on it. I'll check if there is any other logic that
> needs alteration here.>
If the client keeps on passing FD to the library calls, you can map
FD to GEM handles in the library code.
> >> +
> >> +static int fastrpc_context_get_id(struct fastrpc_invoke_context *ctx, struct qda_dev *qdev)
> >> +{
> >> + int ret;
> >> + u32 id;
> >> +
> >> + if (!qdev)
> >> + return -EINVAL;
> >> +
> >> + ret = xa_alloc(&qdev->ctx_xa, &id, ctx, xa_limit_32b, GFP_KERNEL);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ctx->ctxid = id << 4;
> >
> > Why is it being shifted?
> this is to accomodate PD type>
Not really an answer.
> >> + return 0;
> >> +}
> >> +
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* RE: [PATCH net-next v4 16/16] Documentation: networking: Add timestamp related APIs to OA TC6 framework
From: Selvamani Rajagopal @ 2026-06-07 21:10 UTC (permalink / raw)
To: Randy Dunlap, Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <cf3d6937-1ffa-4d81-8e19-b3f607a7e1d1@infradead.org>
>
> Hi,
> These needs a few additional blank lines to avoid docs build warnings:
Will do. My bad that I didn't verify with make htmldocs after editing the file.
>
> Documentation/networking/oa-tc6-framework.rst:554: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:561: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:566: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:573: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
>
> See below.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox