* [PATCH v7 09/22] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Smcdeleg extension allows the M-mode to delegate selected counters
to S-mode so that it can access those counters and correpsonding
hpmevent CSRs without M-mode.
Ssccfg (‘Ss’ for Privileged architecture and Supervisor-level
extension, ‘ccfg’ for Counter Configuration) provides access to
delegated counters and new supervisor-level state.
This patch just enables these definitions and enable parsing.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/hwcap.h | 2 ++
arch/riscv/kernel/cpufeature.c | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 51ad55b9677a..089353b250b0 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -115,6 +115,8 @@
#define RISCV_ISA_EXT_SSCSRIND 106
#define RISCV_ISA_EXT_SMCSRIND 107
#define RISCV_ISA_EXT_SMCNTRPMF 108
+#define RISCV_ISA_EXT_SSCCFG 109
+#define RISCV_ISA_EXT_SMCDELEG 110
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 1452521d740a..1fe647e03515 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -330,6 +330,27 @@ static const unsigned int riscv_a_exts[] = {
RISCV_ISA_EXT_ZKNE, \
RISCV_ISA_EXT_ZKNH
+static int riscv_ext_smcdeleg_validate(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SSCSRIND) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZIHPM) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZICNTR))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
+static int riscv_ext_ssccfg_validate(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (!riscv_ext_smcdeleg_validate(data, isa_bitmap) &&
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SMCDELEG))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
static const unsigned int riscv_zk_bundled_exts[] = {
RISCV_ISA_EXT_ZKN,
RISCV_ISA_EXT_ZKR,
@@ -576,12 +597,15 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_BUNDLE_VALIDATE(zvksg, riscv_zvksg_bundled_exts, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zvkt, RISCV_ISA_EXT_ZVKT, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+ __RISCV_ISA_EXT_DATA_VALIDATE(smcdeleg, RISCV_ISA_EXT_SMCDELEG,
+ riscv_ext_smcdeleg_validate),
__RISCV_ISA_EXT_DATA(smcntrpmf, RISCV_ISA_EXT_SMCNTRPMF),
__RISCV_ISA_EXT_DATA(smcsrind, RISCV_ISA_EXT_SMCSRIND),
__RISCV_ISA_EXT_DATA(smmpm, RISCV_ISA_EXT_SMMPM),
__RISCV_ISA_EXT_SUPERSET(smnpm, RISCV_ISA_EXT_SMNPM, riscv_xlinuxenvcfg_exts),
__RISCV_ISA_EXT_DATA(smstateen, RISCV_ISA_EXT_SMSTATEEN),
__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+ __RISCV_ISA_EXT_DATA_VALIDATE(ssccfg, RISCV_ISA_EXT_SSCCFG, riscv_ext_ssccfg_validate),
__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
__RISCV_ISA_EXT_DATA(sscsrind, RISCV_ISA_EXT_SSCSRIND),
__RISCV_ISA_EXT_SUPERSET(ssnpm, RISCV_ISA_EXT_SSNPM, riscv_xlinuxenvcfg_exts),
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH v7 07/22] dt-bindings: riscv: add Smcntrpmf ISA extension description
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Add the description for Smcntrpmf ISA extension
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
Documentation/devicetree/bindings/riscv/extensions.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 15cf0e2ee3ed..2493766e956d 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -181,6 +181,12 @@ properties:
changes to interrupts as frozen at commit ccbddab ("Merge pull
request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
+ - const: smcntrpmf
+ description: |
+ The standard Smcntrpmf machine-level extension for the machine mode
+ to enable privilege mode filtering for cycle and instret counters as
+ ratified in the 20240326 version of the privileged ISA specification.
+
- const: smcsrind
description: |
The standard Smcsrind machine-level extension extends the
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH v7 06/22] RISC-V: Add Smcntrpmf extension parsing
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Smcntrpmf extension allows M-mode to enable privilege mode filtering
for cycle/instret counters. However, the cyclecfg/instretcfg CSRs are
only available only in Ssccfg only Smcntrpmf is present.
That's why, kernel needs to detect presence of Smcntrpmf extension and
enable privilege mode filtering for cycle/instret counters.
Reviewed-by: Clément Léger <cleger@rivosinc.com>
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index d4a7b90e2d78..51ad55b9677a 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -114,6 +114,7 @@
#define RISCV_ISA_EXT_ZICFISS 105
#define RISCV_ISA_EXT_SSCSRIND 106
#define RISCV_ISA_EXT_SMCSRIND 107
+#define RISCV_ISA_EXT_SMCNTRPMF 108
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 3fa0a563fb21..1452521d740a 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -576,6 +576,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_BUNDLE_VALIDATE(zvksg, riscv_zvksg_bundled_exts, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zvkt, RISCV_ISA_EXT_ZVKT, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+ __RISCV_ISA_EXT_DATA(smcntrpmf, RISCV_ISA_EXT_SMCNTRPMF),
__RISCV_ISA_EXT_DATA(smcsrind, RISCV_ISA_EXT_SMCSRIND),
__RISCV_ISA_EXT_DATA(smmpm, RISCV_ISA_EXT_SMMPM),
__RISCV_ISA_EXT_SUPERSET(smnpm, RISCV_ISA_EXT_SMNPM, riscv_xlinuxenvcfg_exts),
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Christophe Leroy (CS GROUP) @ 2026-06-22 8:05 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260621093430.264983361@kernel.org>
Le 21/06/2026 à 11:34, Steven Rostedt a écrit :
> There's been complaints about trace_printk() being defined in kernel.h as it
> can increase the compilation time. As it is only used by some developers for
> debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> cycles for those that do not ever care about it.
Do we have a measurement of the increased compilation time ?
Christophe
>
> Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
> use it can set and not have to always remember to add #include <linux/trace_printk.h>
> to the files they add trace_printk() while debugging. It also means that
> those that do not have that config set will not have to worry about wasted
> CPU cycles as it is only include in the CFLAGS when the option is set, and
> its completely ignored otherwise.
>
> Steven Rostedt (2):
> tracing: Move non-trace_printk prototypes back to kernel.h
> tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
>
> ----
> .../driver_development_debugging_guide.rst | 2 +-
> Makefile | 5 +++++
> arch/powerpc/kvm/book3s_xics.c | 1 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
> drivers/gpu/drm/i915/i915_gem.h | 1 +
> drivers/hwtracing/stm/dummy_stm.c | 4 ++++
> drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
> drivers/usb/early/xhci-dbc.c | 1 +
> fs/ext4/inline.c | 1 +
> include/linux/kernel.h | 19 ++++++++++++++++++-
> include/linux/sunrpc/debug.h | 1 +
> include/linux/trace_printk.h | 22 +++-------------------
> kernel/trace/Kconfig | 10 ++++++++++
> kernel/trace/ring_buffer_benchmark.c | 1 +
> kernel/trace/trace.h | 1 +
> samples/fprobe/fprobe_example.c | 1 +
> samples/ftrace/ftrace-direct-modify.c | 1 +
> samples/ftrace/ftrace-direct-multi-modify.c | 1 +
> samples/ftrace/ftrace-direct-multi.c | 2 +-
> samples/ftrace/ftrace-direct-too.c | 2 +-
> samples/ftrace/ftrace-direct.c | 2 +-
> 21 files changed, 56 insertions(+), 24 deletions(-)
>
^ permalink raw reply
* [PATCH v7 05/22] RISC-V: Define indirect CSR access helpers
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Atish Patra <atishp@rivosinc.com>
The indriect CSR requires multiple instructions to read/write CSR.
Add a few helper functions for ease of usage.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/csr_ind.h | 44 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/riscv/include/asm/csr_ind.h b/arch/riscv/include/asm/csr_ind.h
new file mode 100644
index 000000000000..6fd7d44dc640
--- /dev/null
+++ b/arch/riscv/include/asm/csr_ind.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 Rivos Inc.
+ */
+
+#ifndef _ASM_RISCV_CSR_IND_H
+#define _ASM_RISCV_CSR_IND_H
+
+#include <linux/irqflags.h>
+
+#include <asm/csr.h>
+
+#define csr_ind_read(iregcsr, iselbase, iseloff) ({ \
+ unsigned long __value = 0; \
+ unsigned long __flags; \
+ local_irq_save(__flags); \
+ csr_write(CSR_ISELECT, (iselbase) + (iseloff)); \
+ __value = csr_read(iregcsr); \
+ local_irq_restore(__flags); \
+ __value; \
+})
+
+#define csr_ind_write(iregcsr, iselbase, iseloff, value) ({ \
+ unsigned long __flags; \
+ local_irq_save(__flags); \
+ csr_write(CSR_ISELECT, (iselbase) + (iseloff)); \
+ csr_write(iregcsr, (value)); \
+ local_irq_restore(__flags); \
+})
+
+#define csr_ind_warl(iregcsr, iselbase, iseloff, warl_val) ({ \
+ unsigned long __old_val = 0, __value = 0; \
+ unsigned long __flags; \
+ local_irq_save(__flags); \
+ csr_write(CSR_ISELECT, (iselbase) + (iseloff)); \
+ __old_val = csr_read(iregcsr); \
+ csr_write(iregcsr, (warl_val)); \
+ __value = csr_read(iregcsr); \
+ csr_write(iregcsr, __old_val); \
+ local_irq_restore(__flags); \
+ __value; \
+})
+
+#endif
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH v7 04/22] dt-bindings: riscv: add Sxcsrind ISA extension description
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Add the S[m|s]csrind ISA extension description.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
Documentation/devicetree/bindings/riscv/extensions.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 2b0a8a93bb21..15cf0e2ee3ed 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -181,6 +181,14 @@ properties:
changes to interrupts as frozen at commit ccbddab ("Merge pull
request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
+ - const: smcsrind
+ description: |
+ The standard Smcsrind machine-level extension extends the
+ indirect CSR access mechanism defined by the Smaia extension. This
+ extension allows other ISA extensions to use indirect CSR access
+ mechanism in M-mode as ratified in the 20240326 version of the
+ privileged ISA specification.
+
- const: smmpm
description: |
The standard Smmpm extension for M-mode pointer masking as
@@ -226,6 +234,14 @@ properties:
Profiles Version 1.0, with commit b1d806605f87 ("Updated to
ratified state.")
+ - const: sscsrind
+ description: |
+ The standard Sscsrind supervisor-level extension extends the
+ indirect CSR access mechanism defined by the Ssaia extension. This
+ extension allows other ISA extensions to use indirect CSR access
+ mechanism in S-mode as ratified in the 20240326 version of the
+ privileged ISA specification.
+
- const: ssnpm
description: |
The standard Ssnpm extension for next-mode pointer masking as
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH v7 03/22] RISC-V: Add Sxcsrind ISA extension definition and parsing
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Atish Patra <atishp@rivosinc.com>
The S[m|s]csrind extension extends the indirect CSR access mechanism
defined in Smaia/Ssaia extensions.
This patch just enables the definition and parsing.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/hwcap.h | 4 ++++
arch/riscv/kernel/cpufeature.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 7ef8e5f55c8d..d4a7b90e2d78 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -112,6 +112,8 @@
#define RISCV_ISA_EXT_ZCLSD 103
#define RISCV_ISA_EXT_ZICFILP 104
#define RISCV_ISA_EXT_ZICFISS 105
+#define RISCV_ISA_EXT_SSCSRIND 106
+#define RISCV_ISA_EXT_SMCSRIND 107
#define RISCV_ISA_EXT_XLINUXENVCFG 127
@@ -121,9 +123,11 @@
#ifdef CONFIG_RISCV_M_MODE
#define RISCV_ISA_EXT_SxAIA RISCV_ISA_EXT_SMAIA
#define RISCV_ISA_EXT_SUPM RISCV_ISA_EXT_SMNPM
+#define RISCV_ISA_EXT_SxCSRIND RISCV_ISA_EXT_SMCSRIND
#else
#define RISCV_ISA_EXT_SxAIA RISCV_ISA_EXT_SSAIA
#define RISCV_ISA_EXT_SUPM RISCV_ISA_EXT_SSNPM
+#define RISCV_ISA_EXT_SxCSRIND RISCV_ISA_EXT_SSCSRIND
#endif
#endif /* _ASM_RISCV_HWCAP_H */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index f46aa5602d74..3fa0a563fb21 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -576,11 +576,13 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_BUNDLE_VALIDATE(zvksg, riscv_zvksg_bundled_exts, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zvkt, RISCV_ISA_EXT_ZVKT, riscv_ext_vector_crypto_validate),
__RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+ __RISCV_ISA_EXT_DATA(smcsrind, RISCV_ISA_EXT_SMCSRIND),
__RISCV_ISA_EXT_DATA(smmpm, RISCV_ISA_EXT_SMMPM),
__RISCV_ISA_EXT_SUPERSET(smnpm, RISCV_ISA_EXT_SMNPM, riscv_xlinuxenvcfg_exts),
__RISCV_ISA_EXT_DATA(smstateen, RISCV_ISA_EXT_SMSTATEEN),
__RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
__RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF),
+ __RISCV_ISA_EXT_DATA(sscsrind, RISCV_ISA_EXT_SSCSRIND),
__RISCV_ISA_EXT_SUPERSET(ssnpm, RISCV_ISA_EXT_SSNPM, riscv_xlinuxenvcfg_exts),
__RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
__RISCV_ISA_EXT_DATA(svade, RISCV_ISA_EXT_SVADE),
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH v7 00/22] Add Counter delegation ISA extension support
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
This series adds the counter delegation extension support. It is based on
very early PoC work done by Kevin Xue and mostly rewritten after that.
The counter delegation ISA extension(Smcdeleg/Ssccfg) actually depends
on multiple ISA extensions.
1. S[m|s]csrind : The indirect CSR extension[1] which defines additional
5 ([M|S|VS]IREG2-[M|S|VS]IREG6) register to address size limitation of
RISC-V CSR address space.
2. Smstateen: The stateen bit[60] controls the access to the registers
indirectly via the above indirect registers.
3. Smcdeleg/Ssccfg: The counter delegation extensions[2]
The counter delegation extension allows Supervisor mode to program the
hpmevent and hpmcounters directly without needing the assistance from the
M-mode via SBI calls. This results in a faster perf profiling and very
few traps. This extension also introduces a scountinhibit CSR which allows
to stop/start any counter directly from the S-mode. As the counter
delegation extension potentially can have more than 100 CSRs, the specification
leverages the indirect CSR extension to save the precious CSR address range.
Due to the dependency of these extensions, the following extensions must be
enabled in qemu to use the counter delegation feature in S-mode.
"smstateen=true,sscofpmf=true,ssccfg=true,smcdeleg=true,smcsrind=true,sscsrind=true"
or Virt machine users can just "max" cpu instead.
When we access the counters directly in S-mode, we also need to solve the
following problems.
1. Event to counter mapping
2. Event encoding discovery
The RISC-V ISA doesn't define any standard either for event encoding or the
event to counter mapping rules. Until now, the SBI PMU implementation relies
on device tree binding[3] to discover the event to counter mapping in RISC-V
platform in the firmware. The SBI PMU specification[4] defines event encoding
for standard perf events as well. Thus, the kernel can query the appropriate
counter for an given event from the firmware.
However, the kernel doesn't need any firmware interaction for hardware
counters if counter delegation is available in the hardware. Thus, the driver
needs to discover the above mappings/encodings by itself without any assistance
from firmware.
Solution to Problem #1:
This patch series solves the above problem #1 by extending the perf tool in a
way so that event json file can specify the counter constraints of each event
and that can be passed to the driver to choose the best counter for a given
event.
This series introduces a RISC-V specific event field in "CounterIDMask" in
event_fields that describes a bitmask of counters supported for a specific eventi.
This is the similar approach for few other existing properties in the event_fields
which were used by single architecture as well. The counter constraint bitmap is
passed to the perf driver via newly introduced "counterid_mask" property set in "config2".
The platform vendor have these three ways to encode/use the platform specific
events.
1. Directly in driver with appropriate constraints (discouraged due to bloating
of the driver)
2. Encode in Json with with CounterIDMask field (preferred as it is contained
within platform specific json file)
3. Directly pass counterid_mask at while invoking perf
cpu/event=<code>,counterid_mask=<mask>/
The last two patches show cases these use cases and not intended for merging.
Solution to problem #2:
The event encoding can come from the json or commandline as well.
The Qemu patches are available in upstream now.
The Linux kernel patches can be found here:
https://github.com/atishp04/linux/tree/b4/counter_delegation_v7
[1] https://github.com/riscv/riscv-indirect-csr-access
[2] https://github.com/riscv/riscv-smcdeleg-ssccfg
[3] https://www.kernel.org/doc/Documentation/devicetree/bindings/perf/riscv%2Cpmu.yaml
[4] https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/src/ext-pmu.adoc
To: Paul Walmsley <pjw@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Will Deacon <will@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
To: Atish Patra <atish.patra@linux.dev>
To: Anup Patel <anup@brainfault.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
To: Jiri Olsa <jolsa@kernel.org>
To: Ian Rogers <irogers@google.com>
To: James Clark <james.clark@linaro.org>
Cc: linux-riscv@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Conor Dooley <conor@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-perf-users@vger.kernel.org
Signed-off-by: Atish Patra <atishp@meta.com>
Changes in v7:
- Fixed various issues pointed by Sashiko.
- Rebased on top of v7.1
- Added a separate patch to fix various memory leak issues in probe error path
- Link to v6: https://lore.kernel.org/r/20260608-counter_delegation-v6-0-285b72ed65a9@meta.com
Changes in v6:
- Reverted the file name changes as suggested by Will. Now pmu-sbi.c will continue
to support both counter delegation and SBI PMU with different function prefixes.
- No longer depends up old upstream patch for reusing the Counter property to
encode event to counter mapping property. It directly uses additional field in
json event fields similar to other architectures.
- Added few test patches (not intended for upstreaming) to show case different
possibilities of providing mapping/event encodings.
- Fixed review comments and miscellenous minor typos/fixes on v5
- Rebased on top of v7.1-rc6
Changes in v5:
- Fixed dt_binding_check errors.
- Added the ISA extension dependancy for counter delegation extensions.
- Replaced the boolean variables with static key conditional check required at boot time.
- Miscellaneous minor code restructuring.
- Link to v4: https://lore.kernel.org/r/20250205-counter_delegation-v4-0-835cfa88e3b1@rivosinc.com
Changes in v4:
- Added ISA dependencies as per dt schema instead of description.
- Fixed few compilation issues due to patch reordering in v3.
- Link to v3: https://lore.kernel.org/r/20250127-counter_delegation-v3-0-64894d7e16d5@rivosinc.com
Changes in v3:
- Fixed the dtb binding check failures.
- Inlcuded the fix reported by Rajnesh Kanwal for guest counter overflow.
- Rearranged the overflow handling more efficiently for better modularity.
- Link to v2: https://lore.kernel.org/r/20250114-counter_delegation-v2-0-8ba74cdb851b@rivosinc.com
Changes in v2:
- Dropped architecture specific overrides for event encoding.
- Dropped hwprobe bits.
- Added a vendor specific event encoding table to support vendor specific event
encoding and counter mapping.
- Fixed few bugs and cleanup.
- Link to v1: https://lore.kernel.org/r/20240217005738.3744121-1-atishp@rivosinc.com
---
Atish Patra (19):
RISC-V: perf: fix resource cleanup on driver probe failure
RISC-V: Add Sxcsrind ISA extension definition and parsing
dt-bindings: riscv: add Sxcsrind ISA extension description
RISC-V: Define indirect CSR access helpers
RISC-V: Add Smcntrpmf extension parsing
dt-bindings: riscv: add Smcntrpmf ISA extension description
RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing
dt-bindings: riscv: add Counter delegation ISA extensions description
RISC-V: perf: Restructure the SBI PMU code
RISC-V: perf: Modify the counter discovery mechanism
RISC-V: perf: Add a mechanism to defined legacy event encoding
RISC-V: perf: Implement supervisor counter delegation support
RISC-V: perf: Use config2/vendor table for event to counter mapping
RISC-V: perf: Add legacy event encodings via sysfs
RISC-V: perf: Add Qemu virt machine events
tools/perf: Support event code for arch standard events
tools/perf: Add RISC-V CounterIDMask event field
TEST(do-not-upstream): fake qemu-virt PMU events for cdeleg counter-mask testing
TEST(do-not-upstream): fake qemu vendor JSON + mapfile entry for CounterIDMask path
Charlie Jenkins (1):
RISC-V: perf: Skip PMU SBI extension when not implemented
Kaiwen Xue (2):
RISC-V: Add Sxcsrind ISA extension CSR definitions
RISC-V: Add Sscfg extension CSR definition
.../devicetree/bindings/riscv/extensions.yaml | 63 ++
arch/riscv/include/asm/csr.h | 57 +
arch/riscv/include/asm/csr_ind.h | 44 +
arch/riscv/include/asm/hwcap.h | 7 +
arch/riscv/include/asm/vendorid_list.h | 4 +
arch/riscv/kernel/cpufeature.c | 27 +
drivers/perf/Kconfig | 14 +-
drivers/perf/riscv_pmu_sbi.c | 1095 ++++++++++++++++----
include/linux/perf/riscv_pmu.h | 5 +
.../perf/pmu-events/arch/riscv/arch-standard.json | 10 +
tools/perf/pmu-events/arch/riscv/mapfile.csv | 1 +
.../pmu-events/arch/riscv/qemu/virt/events.json | 26 +
tools/perf/pmu-events/jevents.py | 7 +-
13 files changed, 1155 insertions(+), 205 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20240715-counter_delegation-628a32f8c9cc
Best regards,
--
Atish Patra <atishp@meta.com>
^ permalink raw reply
* [PATCH v7 02/22] RISC-V: Add Sxcsrind ISA extension CSR definitions
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Kaiwen Xue <kaiwenx@rivosinc.com>
This adds definitions of new CSRs and bits defined in Sxcsrind ISA
extension. These CSR enables indirect accesses mechanism to access
any CSRs in M-, S-, and VS-mode. The range of the select values
and ireg will be define by the ISA extension using Sxcsrind extension.
Signed-off-by: Kaiwen Xue <kaiwenx@rivosinc.com>
Reviewed-by: Clément Léger <cleger@rivosinc.com>
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/csr.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 31b8988f4488..b4551a6cf7cb 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -347,6 +347,12 @@
/* Supervisor-Level Window to Indirectly Accessed Registers (AIA) */
#define CSR_SISELECT 0x150
#define CSR_SIREG 0x151
+/* Supervisor-Level Window to Indirectly Accessed Registers (Sxcsrind) */
+#define CSR_SIREG2 0x152
+#define CSR_SIREG3 0x153
+#define CSR_SIREG4 0x155
+#define CSR_SIREG5 0x156
+#define CSR_SIREG6 0x157
/* Supervisor-Level Interrupts (AIA) */
#define CSR_STOPEI 0x15c
@@ -394,6 +400,14 @@
/* VS-Level Window to Indirectly Accessed Registers (H-extension with AIA) */
#define CSR_VSISELECT 0x250
#define CSR_VSIREG 0x251
+/*
+ * VS-Level Window to Indirectly Accessed Registers (H-extension with Sxcsrind)
+ */
+#define CSR_VSIREG2 0x252
+#define CSR_VSIREG3 0x253
+#define CSR_VSIREG4 0x255
+#define CSR_VSIREG5 0x256
+#define CSR_VSIREG6 0x257
/* VS-Level Interrupts (H-extension with AIA) */
#define CSR_VSTOPEI 0x25c
@@ -436,6 +450,12 @@
/* Machine-Level Window to Indirectly Accessed Registers (AIA) */
#define CSR_MISELECT 0x350
#define CSR_MIREG 0x351
+/* Machine-Level Window to Indirectly Accessed Registers (Sxcsrind) */
+#define CSR_MIREG2 0x352
+#define CSR_MIREG3 0x353
+#define CSR_MIREG4 0x355
+#define CSR_MIREG5 0x356
+#define CSR_MIREG6 0x357
/* Machine-Level Interrupts (AIA) */
#define CSR_MTOPEI 0x35c
@@ -498,6 +518,11 @@
# define CSR_IEH CSR_MIEH
# define CSR_ISELECT CSR_MISELECT
# define CSR_IREG CSR_MIREG
+# define CSR_IREG2 CSR_MIREG2
+# define CSR_IREG3 CSR_MIREG3
+# define CSR_IREG4 CSR_MIREG4
+# define CSR_IREG5 CSR_MIREG5
+# define CSR_IREG6 CSR_MIREG6
# define CSR_IPH CSR_MIPH
# define CSR_TOPEI CSR_MTOPEI
# define CSR_TOPI CSR_MTOPI
@@ -523,6 +548,11 @@
# define CSR_IEH CSR_SIEH
# define CSR_ISELECT CSR_SISELECT
# define CSR_IREG CSR_SIREG
+# define CSR_IREG2 CSR_SIREG2
+# define CSR_IREG3 CSR_SIREG3
+# define CSR_IREG4 CSR_SIREG4
+# define CSR_IREG5 CSR_SIREG5
+# define CSR_IREG6 CSR_SIREG6
# define CSR_IPH CSR_SIPH
# define CSR_TOPEI CSR_STOPEI
# define CSR_TOPI CSR_STOPI
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH v7 01/22] RISC-V: perf: fix resource cleanup on driver probe failure
From: Atish Patra @ 2026-06-22 8:04 UTC (permalink / raw)
To: Jiri Olsa, James Clark, Mark Rutland, Will Deacon,
Arnaldo Carvalho de Melo, Rob Herring, Ian Rogers,
Krzysztof Kozlowski, Anup Patel, Paul Walmsley, Atish Patra,
Namhyung Kim
Cc: devicetree, linux-perf-users, Conor Dooley, linux-arm-kernel,
linux-kernel, linux-riscv
In-Reply-To: <20260622-counter_delegation-v7-0-0ba2fd34614e@meta.com>
From: Atish Patra <atishp@meta.com>
Sashiko pointed out various UAF and memory leak issues around
pmu_sbi_device_probe() error paths.
If the probe fails, here are list of cleanups needed.
a. Already registered pmu must be freed
b. per cpu IRQ must be released
c. pmu_ctr_list data structure must be freed
d. cpu hotplug state must be cleaned up only if added.
Fix the resource cleanup by reorganizing the code around probe failure.
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Signed-off-by: Atish Patra <atishp@meta.com>
---
drivers/perf/riscv_pmu_sbi.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 385af5e6e6d0..8753007cc57e 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -1302,7 +1302,8 @@ static void riscv_pmu_destroy(struct riscv_pmu *pmu)
}
}
riscv_pm_pmu_unregister(pmu);
- cpuhp_state_remove_instance(CPUHP_AP_PERF_RISCV_STARTING, &pmu->node);
+ if (!hlist_unhashed(&pmu->node))
+ cpuhp_state_remove_instance(CPUHP_AP_PERF_RISCV_STARTING, &pmu->node);
}
static void pmu_sbi_event_init(struct perf_event *event)
@@ -1424,6 +1425,7 @@ static int pmu_sbi_device_probe(struct platform_device *pdev)
struct riscv_pmu *pmu = NULL;
int ret = -ENODEV;
int num_counters;
+ bool irq_requested = false;
pr_info("SBI PMU extension is available\n");
pmu = riscv_pmu_alloc();
@@ -1452,6 +1454,7 @@ static int pmu_sbi_device_probe(struct platform_device *pdev)
pmu->pmu.capabilities |= PERF_PMU_CAP_NO_INTERRUPT;
pmu->pmu.capabilities |= PERF_PMU_CAP_NO_EXCLUDE;
}
+ irq_requested = (ret == 0);
pmu->pmu.attr_groups = riscv_pmu_attr_groups;
pmu->pmu.parent = &pdev->dev;
@@ -1470,11 +1473,11 @@ static int pmu_sbi_device_probe(struct platform_device *pdev)
ret = riscv_pm_pmu_register(pmu);
if (ret)
- goto out_unregister;
+ goto out_destroy;
ret = perf_pmu_register(&pmu->pmu, "cpu", PERF_TYPE_RAW);
if (ret)
- goto out_unregister;
+ goto out_destroy;
/* SBI PMU Snapsphot is only available in SBI v2.0 */
if (sbi_v2_available) {
@@ -1515,9 +1518,17 @@ static int pmu_sbi_device_probe(struct platform_device *pdev)
return 0;
out_unregister:
+ perf_pmu_unregister(&pmu->pmu);
+
+out_destroy:
riscv_pmu_destroy(pmu);
+ if (irq_requested)
+ free_percpu_irq(riscv_pmu_irq, pmu->hw_events);
out_free:
+ free_percpu(pmu->hw_events);
+ kfree(pmu_ctr_list);
+ pmu_ctr_list = NULL;
kfree(pmu);
return ret;
}
--
2.53.0-Meta
^ permalink raw reply related
* Re: Re: [PATCH net-next v8 3/6] net: stmmac: eic7700: make RGMII delay properties optional
From: Andrew Lunn @ 2026-06-22 7:52 UTC (permalink / raw)
To: 李志
Cc: Maxime Chevallier, devicetree, andrew+netdev, davem, edumazet,
kuba, robh, krzk+dt, conor+dt, netdev, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, pjw, palmer, aou, alex, linux-riscv,
linux-stm32, linux-arm-kernel, linux-kernel, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, lee
In-Reply-To: <512b77d5.993b.19eed207fc9.Coremail.lizhi2@eswincomputing.com>
> I'm preparing a v9 of the series. The next revision will address the
> issues reported by Sashiko review, mainly DT binding schema and DTS
> warnings.
>
> Before I post v9, I'd like to check whether you have any concerns or
> suggestions regarding the driver changes.
From what i remember, i think the patch was O.K, but i've looked at
100s of other patches since then. The commit message sounds like the
basic design is correct.
Andrew
^ permalink raw reply
* Re: [PATCH RFC 1/3] cpu/hotplug: Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST
From: Jinjie Ruan @ 2026-06-22 7:50 UTC (permalink / raw)
To: Peter Zijlstra, Thomas Gleixner
Cc: catalin.marinas, will, tsbogend, pjw, palmer, aou, alex, mingo,
bp, dave.hansen, hpa, kees, nathan, linusw, ojeda, david.kaplan,
lukas.bulwahn, ryan.roberts, maz, timothy.hayes, lpieralisi,
thuth, oupton, yeoreum.yun, miko.lenczewski, broonie,
kevin.brodsky, james.clark, tabba, mrigendra.chaubey, arnd,
anshuman.khandual, x86, linux-kernel, linux-arm-kernel,
linux-mips, linux-riscv
In-Reply-To: <20260619094130.GU49951@noisy.programming.kicks-ass.net>
On 6/19/2026 5:41 PM, Peter Zijlstra wrote:
> On Thu, Jun 18, 2026 at 05:17:03PM +0200, Thomas Gleixner wrote:
>
>> Something simple like the uncompiled below should just work, no?
>>
>> ---
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -102,6 +102,10 @@ config HOTPLUG_PARALLEL
>> bool
>> select HOTPLUG_SPLIT_STARTUP
>>
>> +config HOTPLUG_PARALLEL_SMT
>> + bool
>> + select HOTPLUG_PARALLEL
>
> depends on ARCH_SUPPORTS_SCHED_SMT ?
Maybe select HOTPLUG_SMT?
^ permalink raw reply
* Re: [PATCH v3] drm/bridge: imx93-mipi-dsi: Fix mode validation
From: Liu Ying @ 2026-06-22 7:52 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dmitry Baryshkov, dri-devel, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <DJD6I8NMLN3W.3LVT4L17HT5TU@bootlin.com>
On Fri, Jun 19, 2026 at 06:49:55PM +0200, Luca Ceresoli wrote:
> Hello Liu,
Hi Luca,
>
> On Fri May 15, 2026 at 8:54 AM CEST, Liu Ying wrote:
> > i.MX93 MIPI DPHY PLL has limitation for matching with some pixel clock
> > rates, e.g., the best DPHY PLL frequency is 445.333333MHz for a typical
> > 1920x1080p@60Hz CEA/DMT display mode with a pixel clock rate running
> > at 148.5MHz with 4 data lanes + RGB888 pixel in MIPI DSI sync pulse mode,
> > while the expected PLL frequency is (148.5 * 24) / 4 / 2 MHz = 445.5MHz.
> > Fortunately, VESA Display Monitor Timing Standard allows +/-0.5% pixel
> > clock rate deviation for timings. So, for those display modes read
> > from EDID through a bridge with DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_EDID
> > operation bit masks set, pixel clock rate could be adjusted to match
> > with the PLL frequency(for the above example, the pixel clock rate is
> > adjusted to be 148.444444MHz with about -0.03% deviation from the 148.5MHz
> > nominal rate so that the adjusted rate matches with the 445.333333MHz PLL
> > frequency).
> >
> > Instead of checking the last bridge's operation bit masks against
> > DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_EDID to determine if allowing
> > +/-0.5% pixel clock rate deviation, check any bridge after this bridge,
> > because the last bridge is usually a display connector bridge without
> > any operation bit mask when the clock rate deviation is allowed.
> >
> > Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93 MIPI DSI support")
> > Fixes: 5849eff7f067 ("drm/bridge: imx93-mipi-dsi: use drm_bridge_chain_get_last_bridge()")
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
>
> I'm perhaps not the most qualified to review this change, but let me try.
Thanks for your review.
>
> > --- a/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
> > +++ b/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
> > @@ -489,25 +489,43 @@ static int imx93_dsi_get_phy_configure_opts(struct imx93_dsi *dsi,
> > return 0;
> > }
> >
> > +static inline struct drm_bridge *
> > +imx93_dsi_get_next_bridge_in_chain(struct drm_bridge *bridge)
> > +{
> > + struct drm_bridge *next = drm_bridge_get_next_bridge(bridge);
> > +
> > + drm_bridge_put(bridge);
> > +
> > + return next;
> > +}
> > +
> > static enum drm_mode_status
> > imx93_dsi_validate_mode(struct imx93_dsi *dsi, const struct drm_display_mode *mode)
> > {
> > struct drm_bridge *dmd_bridge = dw_mipi_dsi_get_bridge(dsi->dmd);
> > - struct drm_bridge *last_bridge __free(drm_bridge_put) =
> > - drm_bridge_chain_get_last_bridge(dmd_bridge->encoder);
> > + struct drm_bridge *bridge;
> >
> > - if ((last_bridge->ops & DRM_BRIDGE_OP_DETECT) &&
> > - (last_bridge->ops & DRM_BRIDGE_OP_EDID)) {
> > - unsigned long pixel_clock_rate = mode->clock * 1000;
> > - unsigned long rounded_rate;
> > + for (bridge = drm_bridge_get_next_bridge(dmd_bridge);
> > + bridge;
> > + bridge = imx93_dsi_get_next_bridge_in_chain(bridge)) {
> > + if ((bridge->ops & DRM_BRIDGE_OP_DETECT) &&
> > + (bridge->ops & DRM_BRIDGE_OP_EDID)) {
> > + unsigned long pixel_clock_rate = mode->clock * 1000;
> > + unsigned long rounded_rate;
> >
> > - /* Allow +/-0.5% pixel clock rate deviation */
> > - rounded_rate = clk_round_rate(dsi->clk_pixel, pixel_clock_rate);
> > - if (rounded_rate < pixel_clock_rate * 995 / 1000 ||
> > - rounded_rate > pixel_clock_rate * 1005 / 1000) {
> > - dev_dbg(dsi->dev, "failed to round clock for mode " DRM_MODE_FMT "\n",
> > - DRM_MODE_ARG(mode));
> > - return MODE_NOCLOCK;
> > + /* Allow +/-0.5% pixel clock rate deviation */
> > + rounded_rate = clk_round_rate(dsi->clk_pixel, pixel_clock_rate);
> > + if (rounded_rate < pixel_clock_rate * 995 / 1000 ||
> > + rounded_rate > pixel_clock_rate * 1005 / 1000) {
> > + dev_dbg(dsi->dev,
> > + "failed to round clock for mode " DRM_MODE_FMT "\n",
> > + DRM_MODE_ARG(mode));
> > + drm_bridge_put(bridge);
> > + return MODE_NOCLOCK;
> > + }
> > +
> > + drm_bridge_put(bridge);
> > + break;
> > }
> > }
>
> Is this logic specific to the imx93 MIPI DSI host only? Or should it be
> made generic for all dw-hdmi users, or even every DSI host?
I think it's kind of specific to the i.MX93 MIPI DSI host only, because
1) the i.MX93 MIPI DPHY PLL(integrated into i.MX93 MIPI DPHY IP) supports
the best DPHY PLL frequency @445.333333MHz for the typical 1920x1080p@60Hz
display mode, which is lower than the expected/nominal frequency @445.5MHz
and 2) the generic DW MIPI DSI driver(dw-mipi-dsi.c) is PHY-agnostic, which
means vendors may attach different MIPI DPHY IPs to the common MIPI DSI host
IP and likely there would be no frequency mismatch between the pixel clock
and the PLL like i.MX93 has.
>
> Also, iterating over the bridge chain is not very clean. I'm working on
> bridge hotplug (not upstream yet) and bad things would happen if a bridge
> were hot-unplugged during this loop.
The iterating is essentially the same to drm_for_each_bridge_in_chain_from()
except that bridge_chain_mutex is not taken(since it's already taken) and
the starting bridge is fixed to be the next bridge. A few bridge core APIs
like drm_bridge_chain_mode_valid() call drm_for_each_bridge_in_chain_from().
So, the iterating looks clean to me and I'm not aware of any bad things which
would happen when bridge hotplug is considered.
> If the core did this sort of algorithm
> it would be able to be more robust.
Is the core dw-mipi-dsi.c?
If yes, do you think it's worth doing that even if the frequency mismatch
between the pixel clock and the PLL is kind of specific to the i.MX93 MIPI
DSI host?
>
> Finally, out of my utter ignorance on the subject, is the VESA +/-0.5%
> margin generic enough that this driver can always rely on it?
I see several upstream drivers rely on it, see "git grep '0.5%' drivers/gpu/"
output. And every display mode allows -/+ 0.5% pixel clock rate deviation
according to VESA Display Monitor Timing Standard [1], though [1] is a found
by a random Google search.
[1] https://glenwing.github.io/docs/VESA-DMT-1.13.pdf
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH RFC 1/3] cpu/hotplug: Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST
From: Jinjie Ruan @ 2026-06-22 7:50 UTC (permalink / raw)
To: Thomas Gleixner, catalin.marinas, will, tsbogend, pjw, palmer,
aou, alex, mingo, bp, dave.hansen, hpa, peterz, kees, nathan,
linusw, ojeda, david.kaplan, lukas.bulwahn, ryan.roberts, maz,
timothy.hayes, lpieralisi, thuth, oupton, yeoreum.yun,
miko.lenczewski, broonie, kevin.brodsky, james.clark, tabba,
mrigendra.chaubey, arnd, anshuman.khandual, x86, linux-kernel,
linux-arm-kernel, linux-mips, linux-riscv
In-Reply-To: <87a4srdgk0.ffs@fw13>
On 6/18/2026 11:17 PM, Thomas Gleixner wrote:
> On Thu, Jun 11 2026 at 21:38, Jinjie Ruan wrote:
>
>> During parallel CPU bringup, x86 requires primary SMT threads to boot
>> first to avoid siblings stopping during microcode updates. This constraint
>> is architecture-specific and unnecessary for other platforms
>> like arm64.
>>
>> Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST to decouple this constraint.
>> Platforms requiring this temporal order (e.g., x86) can select it
>> in Kconfig. Other architectures (e.g., arm64) can leave it unselected
>> to entirely bypass the SMT branch via the preprocessor.
>>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/Kconfig | 4 ++++
>> arch/mips/Kconfig | 1 +
>> arch/riscv/Kconfig | 1 +
>> arch/x86/Kconfig | 1 +
>> kernel/cpu.c | 6 +++++-
>> 5 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index e86880045158..0365d2df2659 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -102,6 +102,10 @@ config HOTPLUG_PARALLEL
>> bool
>> select HOTPLUG_SPLIT_STARTUP
>>
>> +config PARALLEL_SMT_PRIMARY_FIRST
>
> Proper namespaces are overrated, right?
>
> All related options start with HOTPLUG_....
Sure, will update to `HOTPLUG_PARALLEL_SMT`
>
>> + bool
>> + depends on HOTPLUG_PARALLEL
>> +
>> config GENERIC_IRQ_ENTRY
>> bool
>>
>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>> index 4364f3dba688..84e11ac0cf71 100644
>> --- a/arch/mips/Kconfig
>> +++ b/arch/mips/Kconfig
>> @@ -642,6 +642,7 @@ config EYEQ
>> select MIPS_CPU_SCACHE
>> select MIPS_GIC
>> select MIPS_L1_CACHE_SHIFT_7
>> + select PARALLEL_SMT_PRIMARY_FIRST if HOTPLUG_PARALLEL
>> select PCI_DRIVERS_GENERIC
>> select SMP_UP if SMP
>> select SWAP_IO_SPACE
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index d235396c4514..0cc49aecc841 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -210,6 +210,7 @@ config RISCV
>> select OF
>> select OF_EARLY_FLATTREE
>> select OF_IRQ
>> + select PARALLEL_SMT_PRIMARY_FIRST if HOTPLUG_PARALLEL
>
> Why does RISCV need this? It does not select HOTPLUG_SMT to begin with.
You are right, this was initially done to keep in line with the legacy
implementation.
>
>> +#ifdef CONFIG_PARALLEL_SMT_PRIMARY_FIRST
>> #ifdef CONFIG_HOTPLUG_SMT
>
> More #ifdeffery is better, right?
>
>> static inline bool cpuhp_smt_aware(void)
>> {
>> @@ -1811,7 +1812,8 @@ static inline const struct cpumask *cpuhp_get_primary_thread_mask(void)
>> {
>> return cpu_none_mask;
>> }
>> -#endif
>> +#endif /* CONFIG_HOTPLUG_SMT */
>> +#endif /* CONFIG_PARALLEL_SMT_PRIMARY_FIRST */
>>
>> bool __weak arch_cpuhp_init_parallel_bringup(void)
>> {
>> @@ -1837,6 +1839,7 @@ static bool __init cpuhp_bringup_cpus_parallel(unsigned int ncpus)
>> if (!__cpuhp_parallel_bringup)
>> return false;
>>
>> +#ifdef CONFIG_PARALLEL_SMT_PRIMARY_FIRST
>
> Seriously?
>
>> if (cpuhp_smt_aware()) {
>> const struct cpumask *pmask = cpuhp_get_primary_thread_mask();
>> static struct cpumask tmp_mask __initdata;
>> @@ -1857,6 +1860,7 @@ static bool __init cpuhp_bringup_cpus_parallel(unsigned int ncpus)
>> cpumask_andnot(&tmp_mask, mask, pmask);
>> mask = &tmp_mask;
>> }
>> +#endif /* CONFIG_PARALLEL_SMT_PRIMARY_FIRST */
>
> Something simple like the uncompiled below should just work, no?
Yes, everything looks good, except for a minor compilation issue.
>
> ---
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -102,6 +102,10 @@ config HOTPLUG_PARALLEL
> bool
> select HOTPLUG_SPLIT_STARTUP
>
> +config HOTPLUG_PARALLEL_SMT
> + bool
> + select HOTPLUG_PARALLEL
> +
+config HOTPLUG_PARALLEL_SMT
+ bool
+ select HOTPLUG_PARALLEL
+ select HOTPLUG_SMT
We should select HOTPLUG_SMT here to prevent the compilation issue where
HOTPLUG_PARALLEL_SMT is enabled without HOTPLUG_SMT.
> config GENERIC_IRQ_ENTRY
> bool
>
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -657,7 +657,7 @@ config EYEQ
> select USB_UHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
> select USB_UHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
> select USE_OF
> - select HOTPLUG_PARALLEL if HOTPLUG_CPU
> + select HOTPLUG_PARALLEL_SMT if HOTPLUG_CPU
> help
> Select this to build a kernel supporting EyeQ SoC from Mobileye.
>
> @@ -2295,7 +2295,6 @@ config MIPS_CPS
> select MIPS_CM
> select MIPS_CPS_PM if HOTPLUG_CPU
> select SMP
> - select HOTPLUG_SMT if HOTPLUG_PARALLEL
> select HOTPLUG_CORE_SYNC_DEAD if HOTPLUG_CPU
> select SYNC_R4K if (CEVT_R4K || CSRC_R4K)
> select SYS_SUPPORTS_HOTPLUG_CPU
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -304,7 +304,7 @@ config X86
> select HAVE_USER_RETURN_NOTIFIER
> select HAVE_GENERIC_VDSO
> select VDSO_GETRANDOM if X86_64
> - select HOTPLUG_PARALLEL if SMP && X86_64
> + select HOTPLUG_PARALLEL_SMT if SMP && X86_64
> select HOTPLUG_SMT if SMP
> select HOTPLUG_SPLIT_STARTUP if SMP && X86_32
> select IRQ_FORCED_THREADING
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -1792,7 +1792,7 @@ static int __init parallel_bringup_parse
> }
> early_param("cpuhp.parallel", parallel_bringup_parse_param);
>
> -#ifdef CONFIG_HOTPLUG_SMT
> +#ifdef CONFIG_HOTPLUG_PARALLEL_SMT
> static inline bool cpuhp_smt_aware(void)
> {
> return cpu_smt_max_threads > 1;
>
^ permalink raw reply
* [PATCH v3 2/2] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-22 7:47 UTC (permalink / raw)
To: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Petar Stepanovic
In-Reply-To: <20260622-axiado-ax3000-ax3005-saradc-v3-0-e57c7c7ae675@axiado.com>
Add support for the SARADC controller found on Axiado AX3000 and
AX3005 SoCs.
The driver supports single-shot voltage reads through the IIO
subsystem. The number of available input channels is selected from
the SoC match data, allowing AX3000 and AX3005 variants to use the
same driver.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
MAINTAINERS | 1 +
drivers/iio/adc/Kconfig | 10 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axiado_saradc.c | 245 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 257 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 932bba890780..e6dadfa65ee0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4318,6 +4318,7 @@ M: Akhila Kavi <akavi@axiado.com>
M: Prasad Bolisetty <pbolisetty@axiado.com>
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
+F: drivers/iio/adc/axiado_saradc.c
AXIS ARTPEC ARM64 SoC SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a9dedbb8eb46..a9ba600a5f64 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -631,6 +631,16 @@ config AT91_SAMA5D2_ADC
To compile this driver as a module, choose M here: the module will be
called at91-sama5d2_adc.
+config AXIADO_SARADC
+ tristate "Axiado SARADC driver"
+ depends on ARCH_AXIADO || COMPILE_TEST
+ help
+ Say yes here to build support for the SARADC found in Axiado
+ SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called axiado_saradc.
+
config AXP20X_ADC
tristate "X-Powers AXP20X and AXP22X ADC driver"
depends on MFD_AXP20X
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 097357d146ba..96de0ce1d90a 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_ADI_AXI_ADC) += adi-axi-adc.o
obj-$(CONFIG_ASPEED_ADC) += aspeed_adc.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
+obj-$(CONFIG_AXIADO_SARADC) += axiado_saradc.o
obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
diff --git a/drivers/iio/adc/axiado_saradc.c b/drivers/iio/adc/axiado_saradc.c
new file mode 100644
index 000000000000..12efe814318c
--- /dev/null
+++ b/drivers/iio/adc/axiado_saradc.c
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2021-2026 Axiado Corporation
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/units.h>
+
+#include <linux/iio/iio.h>
+
+/* Register offsets */
+#define AX_SARADC_GLOBAL_CTRL_REG 0x0004
+#define AX_SARADC_MANUAL_CTRL_REG 0x0008
+#define AX_SARADC_DOUT_REG 0x001C
+
+/* GLOBAL_CTRL register fields */
+#define AX_SARADC_GLOBAL_CTRL_CH_EN_MASK GENMASK(31, 16)
+#define AX_SARADC_GLOBAL_CTRL_SAMPLE_MASK GENMASK(6, 5)
+#define AX_SARADC_GLOBAL_CTRL_MODE_MASK GENMASK(4, 3)
+#define AX_SARADC_GLOBAL_CTRL_PD BIT(2)
+#define AX_SARADC_GLOBAL_CTRL_ENABLE BIT(0)
+
+/* GLOBAL_CTRL register values */
+#define AX_SARADC_GLOBAL_CTRL_SAMPLE_16 \
+ FIELD_PREP(AX_SARADC_GLOBAL_CTRL_SAMPLE_MASK, 0)
+
+#define AX_SARADC_GLOBAL_CTRL_MODE_MANUAL \
+ FIELD_PREP(AX_SARADC_GLOBAL_CTRL_MODE_MASK, 1)
+
+/* MANUAL_CTRL register fields */
+#define AX_SARADC_MANUAL_CTRL_ENABLE BIT(0)
+#define AX_SARADC_MANUAL_CTRL_CH_SEL_MASK GENMASK(4, 1)
+
+#define AX_SARADC_MANUAL_CTRL_EN(ch) \
+ (AX_SARADC_MANUAL_CTRL_ENABLE | \
+ FIELD_PREP(AX_SARADC_MANUAL_CTRL_CH_SEL_MASK, ch))
+
+#define AX_RESOLUTION_BITS 10
+#define AX_SARADC_CONV_CYCLES 13
+#define AX_SARADC_CONV_DELAY_MARGIN_US 10
+
+struct axiado_saradc {
+ void __iomem *regs;
+ struct clk *clk;
+ struct mutex lock; /* Serializes ADC conversions. */
+ unsigned long clk_rate;
+ int vref_uV;
+};
+
+static int axiado_saradc_conversion(struct axiado_saradc *info,
+ struct iio_chan_spec const *chan, int *val)
+{
+ unsigned long usecs;
+
+ guard(mutex)(&info->lock);
+
+ /* Select the channel to be used and trigger conversion */
+ writel(AX_SARADC_MANUAL_CTRL_EN(chan->channel),
+ info->regs + AX_SARADC_MANUAL_CTRL_REG);
+
+ /* Hardware requires 13 conversion cycles at clk_rate */
+ usecs = DIV_ROUND_UP(AX_SARADC_CONV_CYCLES * USEC_PER_SEC,
+ info->clk_rate);
+ fsleep(usecs + AX_SARADC_CONV_DELAY_MARGIN_US);
+
+ *val = readl(info->regs + AX_SARADC_DOUT_REG) &
+ GENMASK(AX_RESOLUTION_BITS - 1, 0);
+
+ /* Stop manual conversion */
+ writel(0, info->regs + AX_SARADC_MANUAL_CTRL_REG);
+
+ return 0;
+}
+
+static int axiado_saradc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ struct axiado_saradc *info = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = axiado_saradc_conversion(info, chan, val);
+ if (ret)
+ return ret;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = info->vref_uV / (MICRO / MILLI);
+ *val2 = AX_RESOLUTION_BITS;
+ return IIO_VAL_FRACTIONAL_LOG2;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info axiado_saradc_iio_info = {
+ .read_raw = axiado_saradc_read_raw,
+};
+
+struct axiado_saradc_soc_data {
+ const char *name;
+ unsigned int num_channels;
+};
+
+static const struct axiado_saradc_soc_data ax3000_saradc_data = {
+ .name = "ax3000_saradc",
+ .num_channels = 16,
+};
+
+static const struct axiado_saradc_soc_data ax3005_saradc_data = {
+ .name = "ax3005_saradc",
+ .num_channels = 8,
+};
+
+#define AX_SARADC_CH(_index, _id) \
+ { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = (_index), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .datasheet_name = (_id), \
+ }
+
+static const struct iio_chan_spec axiado_saradc_iio_channels[] = {
+ AX_SARADC_CH(0, "adc0"), AX_SARADC_CH(1, "adc1"),
+ AX_SARADC_CH(2, "adc2"), AX_SARADC_CH(3, "adc3"),
+ AX_SARADC_CH(4, "adc4"), AX_SARADC_CH(5, "adc5"),
+ AX_SARADC_CH(6, "adc6"), AX_SARADC_CH(7, "adc7"),
+ AX_SARADC_CH(8, "adc8"), AX_SARADC_CH(9, "adc9"),
+ AX_SARADC_CH(10, "adc10"), AX_SARADC_CH(11, "adc11"),
+ AX_SARADC_CH(12, "adc12"), AX_SARADC_CH(13, "adc13"),
+ AX_SARADC_CH(14, "adc14"), AX_SARADC_CH(15, "adc15"),
+};
+
+static void axiado_saradc_disable(void *data)
+{
+ struct axiado_saradc *info = data;
+
+ writel(AX_SARADC_GLOBAL_CTRL_PD, info->regs + AX_SARADC_GLOBAL_CTRL_REG);
+}
+
+static int axiado_saradc_probe(struct platform_device *pdev)
+{
+ const struct axiado_saradc_soc_data *soc_data;
+ struct device *dev = &pdev->dev;
+ struct axiado_saradc *info;
+ struct iio_dev *indio_dev;
+ u32 regval;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*info));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ info = iio_priv(indio_dev);
+
+ info->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(info->regs))
+ return PTR_ERR(info->regs);
+
+ info->clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(info->clk))
+ return PTR_ERR(info->clk);
+
+ info->clk_rate = clk_get_rate(info->clk);
+ if (!info->clk_rate)
+ return dev_err_probe(dev, -EINVAL, "invalid clock rate\n");
+
+ ret = devm_regulator_get_enable_read_voltage(dev, "vref");
+ if (ret < 0)
+ return dev_err_probe(dev, info->vref_uV,
+ "failed to get vref voltage\n");
+ info->vref_uV = ret;
+
+ soc_data = device_get_match_data(dev);
+ if (!soc_data)
+ return dev_err_probe(dev, -EINVAL, "failed to get match data\n");
+
+ ret = devm_mutex_init(dev, &info->lock);
+ if (ret)
+ return ret;
+
+ regval = FIELD_PREP(AX_SARADC_GLOBAL_CTRL_CH_EN_MASK,
+ GENMASK(soc_data->num_channels - 1, 0)) |
+ AX_SARADC_GLOBAL_CTRL_SAMPLE_16 |
+ AX_SARADC_GLOBAL_CTRL_MODE_MANUAL |
+ AX_SARADC_GLOBAL_CTRL_ENABLE;
+
+ writel(AX_SARADC_GLOBAL_CTRL_PD, info->regs + AX_SARADC_GLOBAL_CTRL_REG);
+ writel(regval, info->regs + AX_SARADC_GLOBAL_CTRL_REG);
+
+ ret = devm_add_action_or_reset(dev, axiado_saradc_disable, info);
+ if (ret)
+ return ret;
+
+ indio_dev->name = soc_data->name;
+ indio_dev->info = &axiado_saradc_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = axiado_saradc_iio_channels;
+ indio_dev->num_channels = soc_data->num_channels;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id axiado_saradc_match[] = {
+ {
+ .compatible = "axiado,ax3000-saradc",
+ .data = &ax3000_saradc_data,
+ },
+ {
+ .compatible = "axiado,ax3005-saradc",
+ .data = &ax3005_saradc_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, axiado_saradc_match);
+
+static struct platform_driver axiado_saradc_driver = {
+ .driver = {
+ .name = "axiado-saradc",
+ .of_match_table = axiado_saradc_match,
+ },
+ .probe = axiado_saradc_probe,
+};
+module_platform_driver(axiado_saradc_driver);
+
+MODULE_AUTHOR("AXIADO CORPORATION");
+MODULE_DESCRIPTION("AXIADO SARADC driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: iio: adc: add Axiado AX3000/AX3005 SARADC
From: Petar Stepanovic @ 2026-06-22 7:47 UTC (permalink / raw)
To: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Petar Stepanovic, Conor Dooley
In-Reply-To: <20260622-axiado-ax3000-ax3005-saradc-v3-0-e57c7c7ae675@axiado.com>
The Axiado AX3000 and AX3005 SoCs include a 10-bit SAR ADC controller.
AX3000 supports 16 input channels, while AX3005 supports 8 input
channels.
Document the compatible strings, register region, clock, reference
voltage supply, and IIO channel cells.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/iio/adc/axiado,ax3000-saradc.yaml | 63 ++++++++++++++++++++++
MAINTAINERS | 7 +++
2 files changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
new file mode 100644
index 000000000000..b910852aa56f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/axiado,ax3000-saradc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axiado AX3000/AX3005 Successive Approximation Register ADC
+
+description:
+ The Axiado AX3000/AX3005 SAR ADC is a 10-bit ADC with sixteen input
+ channels on AX3000 and eight input channels on AX3005.
+
+maintainers:
+ - Petar Stepanovic <pstepanovic@axiado.com>
+ - Akhila Kavi <akavi@axiado.com>
+ - Prasad Bolisetty <pbolisetty@axiado.com>
+
+properties:
+ compatible:
+ enum:
+ - axiado,ax3000-saradc
+ - axiado,ax3005-saradc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: saradc
+
+ '#io-channel-cells':
+ const: 1
+
+ vref-supply:
+ description: Reference voltage regulator supplying the ADC
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#io-channel-cells'
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ adc@806a0000 {
+ compatible = "axiado,ax3000-saradc";
+ reg = <0x0 0x806a0000 0x0 0x400>;
+ clocks = <&pclk>;
+ clock-names = "saradc";
+ vref-supply = <&vref_reg>;
+ #io-channel-cells = <1>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index b2040011a386..932bba890780 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4312,6 +4312,13 @@ S: Orphan
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXIADO SARADC DRIVER
+M: Petar Stepanovic <pstepanovic@axiado.com>
+M: Akhila Kavi <akavi@axiado.com>
+M: Prasad Bolisetty <pbolisetty@axiado.com>
+S: Maintained
+F: Documentation/devicetree/bindings/iio/adc/axiado,ax3000-saradc.yaml
+
AXIS ARTPEC ARM64 SoC SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
M: Lars Persson <lars.persson@axis.com>
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/2] iio: adc: Add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-22 7:47 UTC (permalink / raw)
To: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel,
Petar Stepanovic, Conor Dooley
This series adds support for the SAR ADC controller found on Axiado
AX3000 and AX3005 SoCs.
A new driver is needed because this SAR ADC controller is a SoC-specific
hardware block used on Axiado SoCs. It has its own register layout,
channel enable handling, conversion control, and data readout sequence,
and it does not match any existing upstream IIO ADC driver.
AX3000 provides sixteen input channels, while AX3005 provides eight
input channels. The driver uses SoC match data to select the number of
available channels for each compatible.
The driver supports single-shot voltage reads through the IIO subsystem
and uses the reference voltage regulator for scale calculation.
The datasheet is not publicly available. Public high-level product
information is available at:
https://axiado.com/products/#AX3080
The register definitions and programming sequence used by this driver
are based on Axiado internal SoC documentation.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
---
Changes in v3:
- Fixed vref regulator error handling.
- Added linux/units.h and used MICRO / MILLI in scale calculation.
- Reordered struct axiado_saradc members to improve the structure
layout.
- Fixed indentation/alignment of multi-line FIELD_PREP(), GENMASK(), and
writel() expressions.
- Removed the blank line before module_platform_driver().
- Link to v2: https://lore.kernel.org/r/20260611-axiado-ax3000-ax3005-saradc-v2-0-913c9de7c64c@axiado.com
Changes in v2:
- Fixed the devicetree example node name to use the generic ADC node name.
- Removed the explicit `depends on OF` from Kconfig.
- Cleaned up and reordered header includes.
- Added missing includes for `bits.h`, `clk.h`, `cleanup.h`, and `err.h`.
- Removed unused `linux/kernel.h` include.
- Renamed register offset macros to use the `_REG` suffix.
- Renamed register bitfield macros to include the register name prefix.
- Added separate macros for `GLOBAL_CTRL` and `MANUAL_CTRL` register
fields and values.
- Replaced `iowrite32()` / `ioread32()` with `writel()` / `readl()`.
- Moved ADC conversion locking into `axiado_saradc_conversion()` using
`guard(mutex)`.
- Replaced `usleep_range()` with `fsleep()`.
- Renamed `vref_uv` to `vref_uV`.
- Added SoC-specific device names in `axiado_saradc_soc_data`.
- Used the fixed SoC-specific name for `indio_dev->name`.
- Removed unused buffered scan configuration from IIO channels.
- Added a managed cleanup action to disable the SARADC hardware on driver
unbind or probe failure.
- Switched to a local `struct device *dev` helper in probe.
- Used `devm_mutex_init()` for mutex initialization.
- Simplified error handling by using `dev_err_probe()`.
- Updated probe variable declarations to follow reverse Christmas tree
order.
- Fixed the `of_device_id` terminator style.
- Replaced `KBUILD_MODNAME` with a fixed driver name string.
- Link to v1: https://lore.kernel.org/r/20260528-axiado-ax3000-ax3005-saradc-v1-0-345dd5f6608a@axiado.com
---
Petar Stepanovic (2):
dt-bindings: iio: adc: add Axiado AX3000/AX3005 SARADC
iio: adc: add Axiado SARADC driver
.../bindings/iio/adc/axiado,ax3000-saradc.yaml | 63 ++++++
MAINTAINERS | 8 +
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axiado_saradc.c | 245 +++++++++++++++++++++
5 files changed, 327 insertions(+)
---
base-commit: 51f0c0b8545b23963afd5d43a8f56ee05bfa54da
change-id: 20260508-axiado-ax3000-ax3005-saradc-151aed5d25da
Best regards,
--
Petar Stepanovic <pstepanovic@axiado.com>
^ permalink raw reply
* Re: [PATCH] irqchip/gic-v3-its: Add Altera Agilex5 DMA workaround
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-06-22 7:46 UTC (permalink / raw)
To: Marc Zyngier
Cc: tglx@kernel.org, catalin.marinas@arm.com, will@kernel.org,
heiko@sntech.de, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
NG, ADRIAN HO YIN
In-Reply-To: <861pdzrr1j.wl-maz@kernel.org>
On 22/6/2026 3:08 pm, Marc Zyngier wrote:
> On Mon, 22 Jun 2026 03:49:45 +0100,
> muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>>
>> From: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com>
>>
>> Altera Agilex5 GIC600 integration has DDR addressing limitation where
>> only the first 40 bits of physical address can be accessible. Extend
>> existing dma32 quirk in driver to support Agilex5.
>>
>> Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com>
>> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> I like the fact that you waited another *year*[1] to post a fixed
> version of this change, and couldn't even be bothered to tag this as a
> new version, not to mention the lack of Suggested-by: tag for code
> that was provided for your perusal.
>
> So you're late to the party, and someone else is doing actual work [2].
>
> Please synchronise with them.
>
> M.
>
> [1] https://lore.kernel.org/linux-arm-kernel/6a44509ca0edaabc17e59d2e27fef1c782183456.1751618484.git.adrianhoyin.ng@altera.com/
> [2] https://lore.kernel.org/r/20260618220427.14325-3-marek.vasut+renesas@mailbox.org
>
Hi All,
Apologies for the not including the Suggested-by: tag as we are not
familiar with the upstream etiquette. Will submit the revised patch
after Mareks patch is applied.
Br,
Nazim
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-06-22 7:31 UTC (permalink / raw)
To: YH Chung, Shulzhenko, Oleksandr, Arnd Bergmann, Andrew Jeffery,
Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB427604A7136947D020CF272D90002@KL1PR0601MB4276.apcprd06.prod.outlook.com>
Hi Shulzhenko, Arnd, Andrew
Please allow me to summarize the potential approaches we have discussed so
far for upstreaming the eSPI driver:
(1) Reuse the existing SPI subsystem and treat eSPI packets as pure signals.
(2) Maintain the driver under the SoC subsystem, since there is currently no
eSPI subsystem.
(3) Create a new eSPI subsystem and rewrite the eSPI driver accordingly.
For option 1, we do not think this would be a good fit, because eSPI has
clearly defined semantics for each channel, and our hardware exposes
different sets of registers for each of them.
For option 2, we think this would be a practical short-term solution, and we
can expose the per-channel functionality through the existing GPIO, MCTP, and
MTD subsystems for the VW, OOB, and flash channels, respectively.
However, this may need to be revisited once an eSPI subsystem becomes
available in-tree.
For option 3, our concern is that there is currently no other eSPI hardware
or driver in-tree that could serve as a reference for defining a more generic
interface. Creating a new subsystem at this stage may therefore be somewhat
over-engineered, since it would only have one user.
We understand that Nuvoton may be the next likely vendor to support eSPI in
their BMC SoCs. Since drivers/soc patches for Nuvoton BMCs also go through
the BMC tree, we expect there would be an opportunity to reconsider whether
an independent eSPI subsystem is needed once another user appears.
Based on the above, we would like to prepare and submit the next revision
with the driver located under drivers/soc.
Could you please let us know if there are any concerns or suggestions that we
have not covered, or whether we could send the next revision for review?
^ permalink raw reply
* Re: [PATCH RFC v2 2/4] drm/i915/display/dp: Adopt dp_connector helpers to expose link training state
From: Jani Nikula @ 2026-06-22 7:28 UTC (permalink / raw)
To: Kory Maincent, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Luca Ceresoli, Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Baryshkov, Daniel Stone
Cc: Thomas Petazzoni, Mark Yacoub, Sean Paul, Manasi Navare,
Drew Davenport, Louis Chauvet, Luca Ceresoli, dri-devel,
linux-kernel, intel-gfx, intel-xe, linux-mediatek,
linux-arm-kernel, Kory Maincent
In-Reply-To: <20260619-feat_link_cap-v2-2-a3dec4c02ad9@bootlin.com>
On Fri, 19 Jun 2026, Kory Maincent <kory.maincent@bootlin.com> wrote:
> Switch the i915 DP connector initialization from
> drm_connector_init_with_ddc() to drm_connector_dp_init_with_ddc(),
> providing the source link capabilities (supported lane counts, link rates
> and DSC support).
>
> Add intel_dp_report_link_train() to collect the negotiated link
> parameters (rate, lane count and DSC enable) and report them via
> drm_dp_set_max_link_params() and drm_dp_set_cur_link_params() once
> link training completes successfully.
>
> Reset the link properties via drm_dp_reset_link_params()
> when the connector is reported as disconnected or when the display device
> is disabled, so the exposed state always reflects the current link status.
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
>
> Changes in v2:
> - Remove voltage swing and pre emphasis properties.
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 26 ++++++++++++++++++----
> .../gpu/drm/i915/display/intel_dp_link_training.c | 17 ++++++++++++++
> 2 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index f01a6eed38395..46c06c76952e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6414,8 +6414,10 @@ intel_dp_detect(struct drm_connector *_connector,
> drm_WARN_ON(display->drm,
> !drm_modeset_is_locked(&display->drm->mode_config.connection_mutex));
>
> - if (!intel_display_device_enabled(display))
> + if (!intel_display_device_enabled(display)) {
> + drm_dp_sink_reset_link_caps(_connector);
Gut feeling is that the sprinkling of these around is error prone.
> return connector_status_disconnected;
> + }
>
> if (!intel_display_driver_check_access(display))
> return connector->base.status;
> @@ -6465,6 +6467,8 @@ intel_dp_detect(struct drm_connector *_connector,
>
> intel_dp_tunnel_disconnect(intel_dp);
>
> + drm_dp_sink_reset_link_caps(_connector);
> +
> goto out_unset_edid;
> }
>
> @@ -7240,10 +7244,12 @@ intel_dp_init_connector(struct intel_digital_port *dig_port,
> struct intel_connector *connector)
> {
> struct intel_display *display = to_intel_display(dig_port);
> + struct drm_connector_dp_link_caps link_caps;
> struct intel_dp *intel_dp = &dig_port->dp;
> struct intel_encoder *encoder = &dig_port->base;
> struct drm_device *dev = encoder->base.dev;
> enum port port = encoder->port;
> + u32 *rates;
> int type;
>
> if (drm_WARN(dev, dig_port->max_lanes < 1,
> @@ -7291,8 +7297,21 @@ intel_dp_init_connector(struct intel_digital_port *dig_port,
> type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> encoder->base.base.id, encoder->base.name);
>
> - drm_connector_init_with_ddc(dev, &connector->base, &intel_dp_connector_funcs,
> - type, &intel_dp->aux.ddc);
> + intel_dp_set_source_rates(intel_dp);
> + link_caps.nlanes = 4;
> + link_caps.nlink_rates = intel_dp->num_source_rates;
> + rates = kmemdup_array(intel_dp->source_rates, intel_dp->num_source_rates,
> + sizeof(*rates), GFP_KERNEL);
> + if (!rates)
> + goto fail;
> +
> + link_caps.link_rates = rates;
> + link_caps.dsc = HAS_DSC(display);
> +
> + drm_connector_dp_init_with_ddc(dev, &connector->base, &intel_dp_connector_funcs,
> + &link_caps, type, &intel_dp->aux.ddc);
> + kfree(rates);
> +
All of the above feels a bit clumsy in the middle of an already too long
function.
> drm_connector_helper_add(&connector->base, &intel_dp_connector_helper_funcs);
>
> if (!HAS_GMCH(display) && DISPLAY_VER(display) < 12)
> @@ -7315,7 +7334,6 @@ intel_dp_init_connector(struct intel_digital_port *dig_port,
> goto fail;
> }
>
> - intel_dp_set_source_rates(intel_dp);
> intel_dp_set_common_rates(intel_dp);
> intel_dp_reset_link_params(intel_dp);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index a26094223f780..25e0e957fe36d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -1231,6 +1231,18 @@ intel_dp_128b132b_intra_hop(struct intel_dp *intel_dp,
> return sink_status & DP_INTRA_HOP_AUX_REPLY_INDICATION ? 1 : 0;
> }
>
> +static void intel_dp_report_link_train(struct intel_dp *intel_dp)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> +
> + drm_dp_set_max_link_params(&connector->base, intel_dp->link_rate,
> + intel_dp->lane_count);
> +
> + drm_dp_set_cur_link_params(&connector->base, intel_dp->link_rate,
> + intel_dp->lane_count,
> + connector->dp.dsc_decompression_enabled);
> +}
> +
> /**
> * intel_dp_stop_link_train - stop link training
> * @intel_dp: DP struct
> @@ -1259,6 +1271,9 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp,
> intel_dp_program_link_training_pattern(intel_dp, crtc_state, DP_PHY_DPRX,
> DP_TRAINING_PATTERN_DISABLE);
>
> + if (!intel_dp->is_mst)
> + intel_dp_report_link_train(intel_dp);
> +
> if (intel_dp_is_uhbr(crtc_state)) {
> ret = poll_timeout_us(ret = intel_dp_128b132b_intra_hop(intel_dp, crtc_state),
> ret == 0,
> @@ -1772,6 +1787,8 @@ void intel_dp_start_link_train(struct intel_atomic_state *state,
> */
> int lttpr_count;
>
> + drm_dp_sink_set_link_caps(&intel_dp->attached_connector->base, &intel_dp->aux);
This is not okay.
We've already figured out all the information needed, and this call goes
ahead and reads the same information out again.
Moreover, some sinks are fragile when it comes to reading the info and
starting link training. The CTS might complain about redundant reads as
well.
drm_dp_sink_set_link_caps() as a name implies something about link,
i.e. the thing between the source and the sink. But this only sets sink
capabilities. Which also means it should not happen at link training
time at all. We figure the information out at detect, which means it's
available *before* modeset.
The more I think about the function, the more I question it. Like, if
the source doesn't support UHBR at all, or not on this connector, what's
the point of reading the sink UHBR rates?
> +
> intel_hpd_block(encoder);
>
> lttpr_count = intel_dp_init_lttpr_and_dprx_caps(intel_dp);
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH v9 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-06-22 7:23 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Julien Massot, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260621081634.467858-4-l.scorcia@gmail.com>
On Sun, Jun 21, 2026 at 10:13:28AM +0200, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 112 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 23 ++++
> 2 files changed, 135 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [RESEND PATCH v3] coresight: etm-perf: Fix reference count leak in etm_setup_aux
From: Ma Ke @ 2026-06-22 7:10 UTC (permalink / raw)
To: suzuki.poulose, mike.leach, james.clark, leo.yan,
alexander.shishkin, mathieu.poirier
Cc: coresight, linux-arm-kernel, linux-kernel, akpm, Ma Ke, stable
bus_find_device() returns a device with its reference count
incremented. When a user-selected sink is obtained through
coresight_get_sink_by_id(), etm_setup_aux() keeps using the returned
sink while building the path and allocating the sink buffer.
Therefore the lookup reference must remain valid while etm_setup_aux()
is still using the sink, otherwise the sink could be removed under the
caller. Drop the lookup reference on the common exit path, after
etm_setup_aux() no longer directly uses the user-selected sink.
The CoreSight path code takes the references it needs for built paths,
so the initial lookup reference from coresight_get_sink_by_id() is no
longer needed after setup_aux finishes.
Found by code review.
Signed-off-by: Ma Ke <make_ruc2021@163.com>
Cc: stable@vger.kernel.org
Fixes: 0e6c20517596 ("coresight: etm-perf: Allow an event to use different sinks")
---
Changes in v3:
- do not drop the lookup reference in coresight_get_sink_by_id(), as
that would return a sink pointer without keeping the device reference
while etm_setup_aux() is still using it.
- dropped the lookup reference in etm_setup_aux on the common exit path,
as suggested by Suzuki.
- updated the commit message to describe why the reference is kept
until etm_setup_aux() finishes using the sink.
Changes in v2:
- modified the patch as suggestions.
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f85dedf89a3f..d5116177c1b9 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -456,6 +456,11 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
goto err;
out:
+ if (user_sink) {
+ put_device(&user_sink->dev);
+ user_sink = NULL;
+ }
+
return event_data;
err:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] irqchip/gic-v3-its: Add Altera Agilex5 DMA workaround
From: Marc Zyngier @ 2026-06-22 7:08 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: tglx, catalin.marinas, will, heiko, linux-arm-kernel,
linux-kernel, linux-rockchip, adrian.ho.yin.ng
In-Reply-To: <20260622024945.21354-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Mon, 22 Jun 2026 03:49:45 +0100,
muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>
> From: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com>
>
> Altera Agilex5 GIC600 integration has DDR addressing limitation where
> only the first 40 bits of physical address can be accessible. Extend
> existing dma32 quirk in driver to support Agilex5.
>
> Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
I like the fact that you waited another *year*[1] to post a fixed
version of this change, and couldn't even be bothered to tag this as a
new version, not to mention the lack of Suggested-by: tag for code
that was provided for your perusal.
So you're late to the party, and someone else is doing actual work [2].
Please synchronise with them.
M.
[1] https://lore.kernel.org/linux-arm-kernel/6a44509ca0edaabc17e59d2e27fef1c782183456.1751618484.git.adrianhoyin.ng@altera.com/
[2] https://lore.kernel.org/r/20260618220427.14325-3-marek.vasut+renesas@mailbox.org
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH RFC v2 1/4] drm: Introduce DisplayPort connector helpers with link training state
From: Jani Nikula @ 2026-06-22 7:05 UTC (permalink / raw)
To: Kory Maincent, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Luca Ceresoli, Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Baryshkov, Daniel Stone
Cc: Thomas Petazzoni, Mark Yacoub, Sean Paul, Manasi Navare,
Drew Davenport, Louis Chauvet, Luca Ceresoli, dri-devel,
linux-kernel, intel-gfx, intel-xe, linux-mediatek,
linux-arm-kernel, Kory Maincent
In-Reply-To: <20260619-feat_link_cap-v2-1-a3dec4c02ad9@bootlin.com>
On Fri, 19 Jun 2026, Kory Maincent <kory.maincent@bootlin.com> wrote:
> Add managed and unmanaged DisplayPort connector initialization helpers,
> drmm_connector_dp_init() and drm_connector_dp_init_with_ddc(), modeled
> after the existing HDMI counterpart drmm_connector_hdmi_init().
>
> These helpers initialize DP-specific connector state and expose link
> training capabilities and state to userspace via sysfs attributes under
> dp_link:
>
> - source_link_rates_caps: Array of source-supported link rates
> - source_max_lane_count_caps: Source maximum lane count capability
> - source_dsc_caps: Source Display Stream Compression support
> - sink_max_link_rate_caps: Sink maximum link rate capability
> - sink_max_lane_count_caps: Sink maximum lane count capability
> - sink_dsc_caps: Sink DSC support
> - cur_link_rate: Current negotiated link rate
> - cur_lane_count: Current negotiated lane count
> - dsc_en: DSC enabled in current link training
> - max_link_rate: Maximum achievable link rate (limited by source/sink)
> - max_lane_count: Maximum achievable lane count (limited by source/sink)
>
> Link rates are passed by the driver in deca-kbps, following the DRM
> convention, but exposed to userspace in kbps for clarity.
>
> Additional helpers are provided to manage link capabilities and parameters
> at runtime:
> - drm_dp_sink_set_link_caps(): Set sink capabilities after DPCD read
> - drm_dp_sink_reset_link_caps(): Reset sink capabilities on disconnect
> - drm_dp_set_cur_link_params(): Update current link training parameters
> - drm_dp_set_max_link_params(): Update maximum achievable parameters
>
> The aim of such development is to guide users to select the most suitable
> DisplayPort connector for their needs. For example, if you have a USB-C
> hub with lesser capabilities than your computer’s native DisplayPort
> connector (such as HBR2 versus HBR3 support), the system could recommend
> connecting high-resolution displays directly to the computer’s port
> instead of through the hub to ensure optimal performance.
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
>
> Changes in v2:
> - Remove voltage swing and pre-emphasis properties
> - Expose link training state via sysfs dp_link/ group instead of
> connector properties
> - Rename variables from link_train to link as they relate directly to
> the link capabilities
> - Add comprehensive sysfs attributes for both source and sink capabilities
> - Add separate helpers for managing sink capabilities and for current and
> maximum link parameters
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 144 ++++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_connector.c | 122 +++++++++++++++++++++++++++
> drivers/gpu/drm/drm_sysfs.c | 100 ++++++++++++++++++++++
> include/drm/display/drm_dp_helper.h | 7 ++
> include/drm/drm_connector.h | 105 +++++++++++++++++++++++
> 5 files changed, 478 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
> index 9c31e14cc413b..bd0e1eb657412 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -4900,3 +4900,147 @@ int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes)
> 1000000 * 8);
> }
> EXPORT_SYMBOL(drm_dp_max_dprx_data_rate);
> +
> +static int drm_dp_dpcd_read_link_rate_caps(struct drm_dp_aux *aux)
> +{
> + u8 data;
> + int ret;
> +
> + ret = drm_dp_dpcd_read_byte(aux, DP_DP13_DPCD_REV + DP_MAIN_LINK_CHANNEL_CODING, &data);
> + if (ret < 0)
> + return ret;
> +
> + if (data & DP_CAP_ANSI_128B132B) {
> + ret = drm_dp_dpcd_read_byte(aux, DP_128B132B_SUPPORTED_LINK_RATES, &data);
> + if (ret < 0)
> + return ret;
> +
> + if (data & DP_UHBR20)
> + return 20000000;
> + if (data & DP_UHBR13_5)
> + return 13500000;
> + if (data & DP_UHBR10)
> + return 10000000;
> + }
> +
> + ret = drm_dp_dpcd_read_byte(aux, DP_MAX_LINK_RATE, &data);
> + if (ret < 0)
> + return ret;
> +
> + return data * 270000;
> +}
There are three ways of reporting the sink link rates. DP_MAX_LINK_RATE
is the only one that reports the maximum. The other two can report any
rates. The above doesn't handle DP_SUPPORTED_LINK_RATES.
The drivers need to figure out *all* supported rates. What is the point
of adding a "helper" that reads these DPCD registers but only reports
the max rate? Using this will only mean duplicated reads of the
registers. This may confuse the sinks, as well as the CTS.
This is not a good design.
> +
> +/**
> + * drm_dp_sink_set_link_caps - Set DisplayPort sink link capabilities
> + * @connector: DisplayPort connector
> + * @aux: The DP AUX channel to use
> + *
> + * This function sets the DisplayPort sink (monitor) link training capabilities
> + * for the given connector. These capabilities are typically read from the
> + * sink's DPCD registers during HPD processing.
> + */
> +void drm_dp_sink_set_link_caps(struct drm_connector *connector,
> + struct drm_dp_aux *aux)
> +{
> + u32 lane_count, link_rate;
> + u8 data;
> + int ret;
> +
> + if (!connector)
> + return;
> +
> + WARN_ON(!drm_modeset_is_locked(&connector->dev->mode_config.connection_mutex));
> +
> + ret = drm_dp_dpcd_read_byte(aux, DP_MAX_LANE_COUNT, &data);
> + if (ret < 0)
> + return;
> +
> + lane_count = data & DP_MAX_LANE_COUNT_MASK;
> +
> + ret = drm_dp_dpcd_read_link_rate_caps(aux);
> + if (ret < 0)
> + return;
> +
> + link_rate = ret;
> +
> + ret = drm_dp_dpcd_read_byte(aux, DP_DSC_SUPPORT, &data);
> + if (ret < 0)
> + return;
> +
> + connector->dp.sink_max_lane_count_caps = lane_count;
> + connector->dp.sink_max_link_rate_caps = link_rate;
> + connector->dp.sink_dsc_caps = ret & DP_DSC_DECOMPRESSION_IS_SUPPORTED;
> +}
> +EXPORT_SYMBOL_GPL(drm_dp_sink_set_link_caps);
> +
> +/**
> + * drm_dp_set_cur_link_params - Set current DisplayPort link parameters
> + * @connector: DisplayPort connector
> + * @link_rate: Current link rate in deca-kbps
> + * @lane_count: Current lane count
> + * @dsc_en: Display Stream Compression enabled
> + *
> + * This function sets the current active DisplayPort link parameters after
> + * link training has completed. These parameters represent the actual link
> + * configuration being used for display output.
> + */
> +void drm_dp_set_cur_link_params(struct drm_connector *connector,
> + u32 link_rate, u32 lane_count, bool dsc_en)
> +{
> + if (!connector)
> + return;
> +
> + WARN_ON(!drm_modeset_is_locked(&connector->dev->mode_config.connection_mutex));
> +
> + /* Convert deca-kbps in kbps */
> + connector->dp.cur_link_rate = link_rate * 10;
> + connector->dp.cur_lane_count = lane_count;
> + connector->dp.dsc_en = dsc_en;
> +}
> +EXPORT_SYMBOL_GPL(drm_dp_set_cur_link_params);
> +
> +/**
> + * drm_dp_set_max_link_params - Set maximum DisplayPort link parameters
> + * @connector: DisplayPort connector
> + * @link_rate: Maximum link rate in kbps
> + * @lane_count: Maximum lane count
> + *
> + * This function sets the maximum achievable DisplayPort link parameters,
> + * which represent the intersection of source and sink capabilities. These
> + * values are the upper bounds for link training attempts.
> + */
> +void drm_dp_set_max_link_params(struct drm_connector *connector, u32 link_rate,
> + u32 lane_count)
> +{
> + if (!connector)
> + return;
> +
> + WARN_ON(!drm_modeset_is_locked(&connector->dev->mode_config.connection_mutex));
> +
> + connector->dp.max_link_rate = link_rate;
> + connector->dp.max_lane_count = lane_count;
> +}
> +EXPORT_SYMBOL_GPL(drm_dp_set_max_link_params);
> +
> +/**
> + * drm_dp_sink_reset_link_caps - Reset DisplayPort sink capabilities
> + * @connector: DisplayPort connector
> + *
> + * This function resets all DisplayPort sink link capabilities and parameters
> + * to their default state. This should be called when a sink is disconnected
> + * to clear stale capability information.
> + */
> +void drm_dp_sink_reset_link_caps(struct drm_connector *connector)
> +{
> + if (!connector)
> + return;
> +
> + WARN_ON(!drm_modeset_is_locked(&connector->dev->mode_config.connection_mutex));
> +
> + drm_dp_set_cur_link_params(connector, 0, 0, false);
> + drm_dp_set_max_link_params(connector, 0, 0);
> + connector->dp.sink_max_link_rate_caps = 0;
> + connector->dp.sink_max_lane_count_caps = 0;
> + connector->dp.sink_dsc_caps = false;
> +}
> +EXPORT_SYMBOL_GPL(drm_dp_sink_reset_link_caps);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a5d13b92b665c..259af3240c057 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -489,6 +489,128 @@ int drm_connector_init_with_ddc(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_connector_init_with_ddc);
>
> +static int drm_dp_source_set_link_caps(struct drm_connector *connector,
> + const struct drm_connector_dp_link_caps *link_caps)
> +{
> + u32 *_link_rates;
> +
> + _link_rates = devm_kmemdup_array(connector->dev->dev,
> + link_caps->link_rates,
> + link_caps->nlink_rates,
> + sizeof(*link_caps->link_rates),
> + GFP_KERNEL);
> + if (!_link_rates)
> + return -ENOMEM;
> +
> + for (int i = 0; i < link_caps->nlink_rates; i++)
> + /* Convert deca-kbps in kbps */
> + _link_rates[i] *= 10;
Why do you have different rates in different places? Ditch the
conversions?
> +
> + connector->dp.source_link_rates_caps = _link_rates;
> + connector->dp.source_num_link_rates_caps = link_caps->nlink_rates;
> + connector->dp.source_max_lane_count_caps = link_caps->nlanes;
> + connector->dp.source_dsc_caps = link_caps->dsc;
Why do you define a struct, and then not use it as a sub-struct in
connector->dp?
> +
> + return 0;
> +}
> +
> +/**
> + * drmm_connector_dp_init - Init a preallocated DisplayPort connector
> + * @dev: DRM device
> + * @connector: A pointer to the DisplayPort connector to init
> + * @funcs: callbacks for this connector
> + * @dp_link_caps: DisplayPort link training capabilities. The pointer
> + * is not kept by the DRM core
> + * @connector_type: user visible type of the connector
> + * @ddc: optional pointer to the associated ddc adapter
> + *
> + * Initialises a preallocated DisplayPort connector. Connectors can be
> + * subclassed as part of driver connector objects.
> + *
> + * Cleanup is automatically handled with a call to
> + * drm_connector_cleanup() in a DRM-managed action.
> + *
> + * The connector structure should be allocated with drmm_kzalloc().
> + *
> + * The @drm_connector_funcs.destroy hook must be NULL.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drmm_connector_dp_init(struct drm_device *dev,
> + struct drm_connector *connector,
> + const struct drm_connector_funcs *funcs,
> + const struct drm_connector_dp_link_caps *dp_link_caps,
> + int connector_type,
> + struct i2c_adapter *ddc)
> +{
> + int ret;
> +
> + if (!(connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP))
> + return -EINVAL;
> +
> + if (!dp_link_caps)
> + return -EINVAL;
> +
> + ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
> + if (ret)
> + return ret;
> +
> + return drm_dp_source_set_link_caps(connector, dp_link_caps);
> +}
> +EXPORT_SYMBOL(drmm_connector_dp_init);
> +
> +/**
> + * drm_connector_dp_init_with_ddc - Init a preallocated DisplayPort connector
> + * @dev: DRM device
> + * @connector: A pointer to the DisplayPort connector to init
> + * @funcs: callbacks for this connector
> + * @dp_link_caps: DisplayPort link training capabilities. The pointer
> + * is not kept by the DRM core
> + * @connector_type: user visible type of the connector
> + * @ddc: optional pointer to the associated ddc adapter
> + *
> + * Initialises a preallocated connector. Connectors should be
> + * subclassed as part of driver connector objects.
> + *
> + * At driver unload time the driver's &drm_connector_funcs.destroy hook
> + * should call drm_connector_cleanup() and free the connector structure.
> + * The connector structure should not be allocated with devm_kzalloc().
> + *
> + * Ensures that the ddc field of the connector is correctly set.
> + *
> + * Note: consider using drmm_connector_dp_init() instead of
> + * drm_connector_dp_init_with_ddc() to let the DRM managed resource
> + * infrastructure take care of cleanup and deallocation.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_connector_dp_init_with_ddc(struct drm_device *dev,
> + struct drm_connector *connector,
> + const struct drm_connector_funcs *funcs,
> + const struct drm_connector_dp_link_caps *dp_link_caps,
> + int connector_type,
> + struct i2c_adapter *ddc)
> +{
> + int ret;
> +
> + if (!(connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP))
> + return -EINVAL;
> +
> + if (!dp_link_caps)
> + return -EINVAL;
> +
> + ret = drm_connector_init_with_ddc(dev, connector, funcs, connector_type, ddc);
> + if (ret)
> + return ret;
> +
> + return drm_dp_source_set_link_caps(connector, dp_link_caps);
> +}
> +EXPORT_SYMBOL(drm_connector_dp_init_with_ddc);
> +
> static void drm_connector_cleanup_action(struct drm_device *dev,
> void *ptr)
> {
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ef4e923a87284..653fecf23d717 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -340,6 +340,95 @@ static const struct attribute_group *connector_dev_groups[] = {
> NULL
> };
>
> +static ssize_t drm_link_rates_show(u32 num_link_rates, const u32 *link_rates, char *buf)
> +{
> + int size = 0;
> +
> + if (!num_link_rates)
> + return 0;
> +
> + size += sysfs_emit_at(buf, size, "%d", link_rates[0]);
> + for (int i = 1; i < num_link_rates; i++)
> + size += sysfs_emit_at(buf, size, " %d", link_rates[i]);
> +
> + size += sysfs_emit_at(buf, size, "\n");
> + return size;
> +}
> +
> +static ssize_t source_link_rates_caps_show(struct device *device,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct drm_connector *connector = to_drm_connector(device);
> + ssize_t size;
> +
> + drm_modeset_lock(&connector->dev->mode_config.connection_mutex, NULL);
> + size = drm_link_rates_show(connector->dp.source_num_link_rates_caps,
> + connector->dp.source_link_rates_caps, buf);
> + drm_modeset_unlock(&connector->dev->mode_config.connection_mutex);
> + return size;
> +}
> +
> +#define DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(_name) \
> +static ssize_t _name##_show(struct device *device, \
> + struct device_attribute *attr, \
> + char *buf) \
> +{ \
> + struct drm_connector *connector = to_drm_connector(device); \
> + int ret; \
> + drm_modeset_lock(&connector->dev->mode_config.connection_mutex, NULL); \
> + if (!connector->dp._name) { \
> + drm_modeset_unlock(&connector->dev->mode_config.connection_mutex); \
> + return 0; \
> + } \
> + ret = sysfs_emit(buf, "%d\n", connector->dp._name); \
> + drm_modeset_unlock(&connector->dev->mode_config.connection_mutex); \
> + return ret; \
> +}
> +
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(source_max_lane_count_caps);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(source_dsc_caps);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(sink_dsc_caps);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(sink_max_link_rate_caps);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(sink_max_lane_count_caps);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(cur_link_rate);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(cur_lane_count);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(dsc_en);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(max_link_rate);
> +DRM_CONNECTOR_DP_ATTR_SHOW_SIMPLE(max_lane_count);
> +
> +static DEVICE_ATTR_RO(source_link_rates_caps);
> +static DEVICE_ATTR_RO(source_max_lane_count_caps);
> +static DEVICE_ATTR_RO(source_dsc_caps);
> +static DEVICE_ATTR_RO(sink_max_link_rate_caps);
> +static DEVICE_ATTR_RO(sink_max_lane_count_caps);
> +static DEVICE_ATTR_RO(sink_dsc_caps);
> +static DEVICE_ATTR_RO(cur_link_rate);
> +static DEVICE_ATTR_RO(cur_lane_count);
> +static DEVICE_ATTR_RO(dsc_en);
> +static DEVICE_ATTR_RO(max_link_rate);
> +static DEVICE_ATTR_RO(max_lane_count);
> +
> +static struct attribute *connector_dp_link_attrs[] = {
> + &dev_attr_source_link_rates_caps.attr,
> + &dev_attr_source_max_lane_count_caps.attr,
> + &dev_attr_source_dsc_caps.attr,
> + &dev_attr_sink_max_link_rate_caps.attr,
> + &dev_attr_sink_max_lane_count_caps.attr,
> + &dev_attr_sink_dsc_caps.attr,
> + &dev_attr_cur_link_rate.attr,
> + &dev_attr_cur_lane_count.attr,
> + &dev_attr_dsc_en.attr,
> + &dev_attr_max_link_rate.attr,
> + &dev_attr_max_lane_count.attr,
> + NULL
> +};
> +
> +static const struct attribute_group connector_dp_link_group = {
> + .name = "dp_link",
> + .attrs = connector_dp_link_attrs,
> +};
> +
> int drm_sysfs_connector_add(struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> @@ -376,6 +465,15 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
>
> connector->kdev = kdev;
>
> + if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + r = sysfs_create_group(&connector->kdev->kobj, &connector_dp_link_group);
> + if (r) {
> + drm_err(dev, "failed to create DP connector sysfs: %d\n", r);
> + goto err_dp_sysfs;
> + }
> + }
> +
> if (dev_fwnode(kdev)) {
> r = component_add(kdev, &typec_connector_ops);
> if (r)
> @@ -384,6 +482,8 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
>
> return 0;
>
> +err_dp_sysfs:
> + device_del(kdev);
> err_free:
> put_device(kdev);
> return r;
> diff --git a/include/drm/display/drm_dp_helper.h b/include/drm/display/drm_dp_helper.h
> index 8c2d77a032f06..e7620ecb2380a 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -1031,4 +1031,11 @@ ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, struct dp_sdp *sdp
> int drm_dp_link_symbol_cycles(int lane_count, int pixels, int dsc_slice_count,
> int bpp_x16, int symbol_size, bool is_mst);
>
> +void drm_dp_sink_set_link_caps(struct drm_connector *connector, struct drm_dp_aux *aux);
> +void drm_dp_sink_reset_link_caps(struct drm_connector *connector);
> +void drm_dp_set_cur_link_params(struct drm_connector *connector, u32 link_rate,
> + u32 lane_count, bool dsc_en);
> +void drm_dp_set_max_link_params(struct drm_connector *connector, u32 link_rate,
> + u32 lane_count);
> +
> #endif /* _DRM_DP_HELPER_H_ */
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 529755c2e8620..a08b8e9766abe 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -2003,6 +2003,93 @@ struct drm_connector_cec {
> void *data;
> };
>
> +/**
> + * struct drm_connector_dp_link_caps - DRM DisplayPort link capabilities
> + */
> +struct drm_connector_dp_link_caps {
> + /**
> + * @nlanes: Maximum number of lanes number supported
> + */
> + u8 nlanes;
> +
> + /**
> + * @nlink_rates: Number of link rates supported
> + */
> + u32 nlink_rates;
> +
> + /**
> + * @link_rates: Array listing the supported link rates in deca-kbps
> + */
> + const u32 *link_rates;
Just make all of the above ints? There's nothing specifically u32 or u8
about any of them. They're just integers.
> +
> + /**
> + * @dsc: Display Stream Compression supported
> + */
> + bool dsc;
> +};
> +
> +/**
> + * struct drm_connector_dp - DRM Connector DisplayPort-related structure
> + */
> +struct drm_connector_dp {
> + /**
> + * @source_link_rates_caps: Array of supported link rates by the
> + * source in kbps
> + */
> + const u32 *source_link_rates_caps;
> + /**
> + * @source_num_link_rates_caps: Number of link rates in
> + * @source_link_rates_caps array
> + */
> + u32 source_num_link_rates_caps;
> + /**
> + * @source_max_lane_count_caps: Maximum number of lanes supported by
> + * the source
> + */
> + u32 source_max_lane_count_caps;
> + /**
> + * @source_dsc_caps: Display Stream Compression capability of the
> + * source
> + */
> + bool source_dsc_caps;
Why doesn't the above use a struct?
> + /**
> + * @sink_max_link_rate_caps: Maximum link rate supported by the sink
> + * in kbps
> + */
> + u32 sink_max_link_rate_caps;
Why all rates for source, but just one rate for sink? Why is it called
_caps?
> + /**
> + * @sink_max_lane_count_caps: Maximum number of lanes supported by the
> + * sink
> + */
> + u32 sink_max_lane_count_caps;
> + /**
> + * @sink_dsc_caps: Display Stream Compression capability of the sink
> + */
> + bool sink_dsc_caps;
Could use the same struct here.
> + /**
> + * @cur_link_rate: Current negotiated link rate in kbps
> + */
> + u32 cur_link_rate;
> + /**
> + * @cur_lane_count: Current negotiated number of lanes
> + */
> + u32 cur_lane_count;
> + /**
> + * @dsc_en: Display Stream Compression enabled status
> + */
These should be ints.
> + bool dsc_en;
> + /**
> + * @max_link_rate: Maximum achievable link rate considering both
> + * source and sink capabilities in deca-kbps
> + */
> + u32 max_link_rate;
IMO this should be an intersection of source and sink rates.
> + /**
> + * @max_lane_count: Maximum achievable lane count considering both
> + * source and sink capabilities
> + */
> + u32 max_lane_count;
These should be ints.
> +};
> +
> /**
> * struct drm_connector - central DRM connector control structure
> *
> @@ -2426,6 +2513,11 @@ struct drm_connector {
> * @cec: CEC-related data.
> */
> struct drm_connector_cec cec;
> +
> + /**
> + * @dp: DisplayPort-related variable and properties.
> + */
> + struct drm_connector_dp dp;
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> @@ -2458,6 +2550,19 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
> struct i2c_adapter *ddc,
> unsigned long supported_formats,
> unsigned int max_bpc);
> +int drm_connector_dp_init_with_ddc(struct drm_device *dev,
> + struct drm_connector *connector,
> + const struct drm_connector_funcs *funcs,
> + const struct drm_connector_dp_link_caps *dp_link_caps,
> + int connector_type,
> + struct i2c_adapter *ddc);
> +
> +int drmm_connector_dp_init(struct drm_device *dev,
> + struct drm_connector *connector,
> + const struct drm_connector_funcs *funcs,
> + const struct drm_connector_dp_link_caps *dp_link_caps,
> + int connector_type,
> + struct i2c_adapter *ddc);
> void drm_connector_attach_edid_property(struct drm_connector *connector);
> int drm_connector_register(struct drm_connector *connector);
> int drm_connector_dynamic_register(struct drm_connector *connector);
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-22 6:55 UTC (permalink / raw)
To: Marek Vasut
Cc: Thomas Gleixner, linux-pci, Yoshihiro Shimoda,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <d6fce333-4353-4e49-873f-eb3187a631e4@mailbox.org>
On Sun, 21 Jun 2026 23:46:25 +0100,
Marek Vasut <marek.vasut@mailbox.org> wrote:
>
> On 6/21/26 12:59 PM, Thomas Gleixner wrote:
> > On Fri, Jun 19 2026 at 00:02, Marek Vasut wrote:
> >> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> >> or APB interface configured to 32 bit, it can therefore access only
> >> the first 4 GiB of physical address space. This information comes from
> >> R-Car V4H Interface Specification sheet, there is currently no technical
> >> update number assigned to this limitation. Further input from hardware
> >> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> >> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> >> limitation.
> >>
> >> The quirk is keyed on the combination of the GIC implementation
> >> and the platform identification in the device tree.
> >>
> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >
> > This SOB chain is broken.
>
> Broken ? I don't understand , could you please elaborate ?
Either Shimoda-san is the sole author of the change and you are
posting their work, then the first line of the patch should say:
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
with your own SoB immediately following their SoB (see [1]).
Or this has been co-developed, and both of you should be credited as
authors. then Shimoda-san's SoB should be preceded by their
Co-developed-by: tag (see [2]).
Co-developed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This shows exactly who did what, who forwarded whose patch, and forms
the base of the DCO which is documented at [3].
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n449
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n503
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n396
--
Without deviation from the norm, progress is not possible.
^ 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