* Re: [PATCH v2 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260421-cherubic-urban-beluga-49ee00@quoll>
On 4/21/26 10:02 AM, Krzysztof Kozlowski wrote:
> On Thu, Apr 16, 2026 at 01:31:40AM +0200, Marek Vasut wrote:
>> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>> ---
>> Cc: Conor Dooley <conor+dt@kernel.org>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>> Cc: Magnus Damm <magnus.damm@gmail.com>
>> Cc: Michael Turquette <mturquette@baylibre.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: Stephen Boyd <sboyd@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-clk@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-renesas-soc@vger.kernel.org
>> ---
>> V2: Add ztr/zt clock at the end of the list to match bindings
>> ---
>> arch/arm/boot/dts/renesas/r8a7740.dtsi | 2 +-
>
>> include/dt-bindings/clock/r8a7740-clock.h | 2 ++
>
> This goes to the binding patch.
>
> Didn't you have also a checkpatch warning?
I only got this warning, but the docs 1/4 and includes 3/4 are a
separate patch in this series:
"
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
"
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260421-attentive-cockle-of-finesse-e5bfb1@quoll>
On 4/21/26 10:01 AM, Krzysztof Kozlowski wrote:
> On Thu, Apr 16, 2026 at 01:31:38AM +0200, Marek Vasut wrote:
>> Document ZT trace bus and ZTR trace clock on the R-Mobile A1.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>> ---
>
> This might affect ABI, because you are basically requiring DTS to have
> additional two clocks. Probably it does not affect anyone, but
> technically is an ABI change, so should be explained in commit msg WHY
> you are doing it and what is the impact, instead of saying WHAT you did.
>
> If there is going to be a new version, please fix it and please keep the
> feedback for future commits.
I hope this is addressed in V3.
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Jinjie Ruan @ 2026-04-23 1:48 UTC (permalink / raw)
To: Thomas Gleixner, Mark Rutland
Cc: Mathias Stearn, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Blake Oler
In-Reply-To: <87wlxy22x7.ffs@tglx>
On 4/23/2026 3:47 AM, Thomas Gleixner wrote:
> On Wed, Apr 22 2026 at 19:11, Mark Rutland wrote:
>> On Wed, Apr 22, 2026 at 07:49:30PM +0200, Thomas Gleixner wrote:
>> Conceptually we just need to use syscall_enter_from_user_mode() and
>> irqentry_enter_from_user_mode() appropriately.
>
> Right. I figured that out.
>
>> In practice, I can't use those as-is without introducing the exception
>> masking problems I just fixed up for irqentry_enter_from_kernel_mode(),
>> so I'll need to do some similar refactoring first.
>
> See below.
>
>> I haven't paged everything in yet, so just to cehck, is there anything
>> that would behave incorrectly if current->rseq.event.user_irq were set
>> for syscall entry? IIUC it means we'll effectively do the slow path, and
>> I was wondering if that might be acceptable as a one-line bodge for
>> stable.
>
> It might work, but it's trivial enough to avoid that. See below. That on
> top of 6.19.y makes the selftests pass too.
This aligns with my thoughts when convert arm64 to generic syscall
entry. Currently, the arm64 entry code does not distinguish between IRQ
and syscall entries. It fails to call rseq_note_user_irq_entry() for IRQ
entries as the generic entry framework does, because arm64 uses
enter_from_user_mode() exclusively instead of
irqentry_enter_from_user_mode().
https://lore.kernel.org/all/20260320102620.1336796-10-ruanjinjie@huawei.com/
>
> Thanks,
>
> tglx
> ---
> arch/arm64/kernel/entry-common.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -58,6 +58,12 @@ static void noinstr exit_to_kernel_mode(
> irqentry_exit(regs, state);
> }
>
> +static __always_inline void arm64_enter_from_user_mode_syscall(struct pt_regs *regs)
> +{
> + enter_from_user_mode(regs);
> + mte_disable_tco_entry(current);
> +}
> +
> /*
> * Handle IRQ/context state management when entering from user mode.
> * Before this function is called it is not safe to call regular kernel code,
> @@ -65,8 +71,8 @@ static void noinstr exit_to_kernel_mode(
> */
> static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs)
> {
> - enter_from_user_mode(regs);
> - mte_disable_tco_entry(current);
> + arm64_enter_from_user_mode_syscall(regs);
> + rseq_note_user_irq_entry();
> }
>
> /*
> @@ -717,7 +723,7 @@ static void noinstr el0_brk64(struct pt_
>
> static void noinstr el0_svc(struct pt_regs *regs)
> {
> - arm64_enter_from_user_mode(regs);
> + arm64_enter_from_user_mode_syscall(regs);
> cortex_a76_erratum_1463225_svc_handler();
> fpsimd_syscall_enter();
> local_daif_restore(DAIF_PROCCTX);
> @@ -869,7 +875,7 @@ static void noinstr el0_cp15(struct pt_r
>
> static void noinstr el0_svc_compat(struct pt_regs *regs)
> {
> - arm64_enter_from_user_mode(regs);
> + arm64_enter_from_user_mode_syscall(regs);
> cortex_a76_erratum_1463225_svc_handler();
> local_daif_restore(DAIF_PROCCTX);
> do_el0_svc_compat(regs);
^ permalink raw reply
* Re: [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode
From: Peng Fan @ 2026-04-23 1:17 UTC (permalink / raw)
To: Sudeep Holla
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Cristian Marussi, linux-kernel, linux-clk,
devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <20260422-satisfied-rough-mongrel-aabca1@sudeepholla>
On Wed, Apr 22, 2026 at 07:51:03PM +0100, Sudeep Holla wrote:
>On Wed, Apr 22, 2026 at 10:00:23PM +0800, Peng Fan wrote:
>> Hi Sudeep,
>>
>> Thanks for giving a look.
>>
>> On Wed, Apr 22, 2026 at 02:14:56PM +0100, Sudeep Holla wrote:
>> >On Fri, Mar 06, 2026 at 02:20:13PM +0800, Peng Fan (OSS) wrote:
>> >> From: Peng Fan <peng.fan@nxp.com>
>> >>
>> >> SCMI CLOCK_RATE_SET allows the caller to specify the rounding behaviour
>> >> when setting a clock rate. The previously added dt-bindings header
>> >> defines three modes:
>> >>
>> >> ROUND_DOWN / ROUND_UP / ROUND_AUTO
>> >>
>> >> To enable device tree clients to select a rounding mode, extend the
>> >> SCMI clock provider to support "#clock-cells = <2>", where the second
>> >> cell encodes the desired rounding mode. The default remains
>> >> ROUND_DOWN for backwards compatibility with existing device trees.
>> >>
>> >
>> >Where is the binding update documented ? It's not in 1/2.
>>
>> This was missed in this patchset, I will fix in new version, if this
>> patchset does not have big design flaw.
>>
>> >
>> >Also if it can be static in the device tree, why can't it be
>> >autonomously handled in the platform firmware ? I think I know the
>>
>> Linux passes ROUND_DOWN, SCMI firmware uses round down for clk calculation.
>>
>> >answer for this but I want to make sure it is a valid use-case and
>> >gets documented here as part of binding updates.
>>
>> Per info from our video software team.
>> We have some video modes where the best pixel clock rate is slightly above the
>> nominal rate, and the default round down rule (CLOCK_ROUND_RULE_CEILING in SM
>> firmware) can cause the resulting clock rate to be much lower than expected.
>>
>> disp1pix = 96200000 Hz (desired pixel clock rate)
>>
>> The MIPI DPHY cannot hit the exact frequency of 288600000 Hz needed for this
>> pixel clock rate, so the next best DPHY PLL frequency is 289000000 Hz. This
>> corresponds to a pixel clock frequency of 96333333 Hz, which is slightly higher
>> than the nominal rate of 96200000 Hz the video mode specifies.
>>
>> Setting the VIDEOPLL (disp1pix parent) to 289000000 Hz should divide down to
>> the adjusted disp1pix frequency of 96333333 Hz, but here is what happens in the
>> SM firmware:
>>
>> quotient = 289000000 / (96200000 + 1) = 3.004 => 3 (notice that the SM always
>> receives the nominal clock rate, not the adjusted rate)
>>
>> If the rounding rule is round down (CLOCK_ROUND_RULE_CEILING),
>> quotient = quotient + 1. Therefore, quotient becomes 4.
>>
>> disp1pix = 289000000 / 4 = 72250000, which is nowhere close to the target of
>> 96333333.
>>
>
>I do not think this is the correct interpretation of `CLOCK_ROUND_DOWN/UP`.
>
>`CLOCK_ROUND_DOWN/UP` should apply to the requested `disp1pix` rate itself,
>not to the divider choice in a way that forces selection of the next integer
>divisor and produces a much lower output clock.
>
>Here, the requested `disp1pix` is `96,200,000 Hz`, and the parent rate is
>`289,000,000 Hz`. The achievable child rates nearby are:
>
>`289,000,000 / 3 = 96,333,333 Hz`
>`289,000,000 / 4 = 72,250,000 Hz`
>
>Given those options, the firmware should be able to round the request
>autonomously to the nearest supported `disp1pix` rate, which is `96,333,333
>Hz` (`289,000,000 / 3`).
>
>Under that interpretation:
>
>`CLOCK_ROUND_UP` would permit choosing `96,333,333`
>`CLOCK_ROUND_AUTO` would also likely choose `96,333,333`
>Choosing `/4` and ending up at `72,250,000` does not look like a meaningful
>rounding of `96,200,000`
>
>So the issue appears to be that the firmware is applying the rounding rule to
>divider selection rather than to the resulting `disp1pix` frequency.
User requests 96.2 MHz with ROUND_DOWN semantics, expecting the closest
achievable frequency that does not meaningfully deviate from the request.
Firmware evaluates the parent rate of 289,000,000 Hz and computes:
289,000,000 / 3 = 96,333,333 Hz
Since this resulting frequency is slightly higher than the requested
96.2 MHz, the firmware, applying a strict `output <= requested` rule,
rejects divider 3 and selects divider 4 instead, producing:
289,000,000 / 4 = 72,250,000 Hz
This leads to an output frequency that is much farther from the requested
value.
My question is: if the firmware were to select divider 3 and produce
96,333,333 Hz (only ~0.13% higher than the request), would that be
considered a violation of ROUND_DOWN semantics, or is ROUND_DOWN intended
to select the closest achievable output frequency rather than enforcing
a strict inequality against the requested rate?
Thanks,
Peng
>
>> However, if we can use `ROUND_AUTO` the SM firmware would select a quotient of 3
>> in this case, and `disp1pix` would match our target: `289000000 / 3 = 96333333`.
>
>Given the explanation above, I would not support this approach. `ROUND_AUTO`
>should be sufficient for this case if the firmware is making a sensible
>selection.
>
>--
>Regards,
>Sudeep
>
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: renesas: r8a7740: Describe coresight on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Describe coresight topology on R-Mobile A1. Extend the current PTM node
with connection funnel, TPIU, ETB and replicator. The coresight on this
hardware is clocked from the ZT/ZTR trace clock.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: No change
V3: No change
---
arch/arm/boot/dts/renesas/r8a7740.dtsi | 114 ++++++++++++++++++++++++-
1 file changed, 111 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7740.dtsi b/arch/arm/boot/dts/renesas/r8a7740.dtsi
index f7136db7a2eae..c7056b96ec0b7 100644
--- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
+++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
@@ -18,7 +18,7 @@ / {
cpus {
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0x0>;
@@ -59,9 +59,117 @@ pmu {
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
};
- ptm {
- compatible = "arm,coresight-etm3x";
+ replicator {
+ compatible = "arm,coresight-static-replicator";
+ clocks = <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "atclk";
power-domains = <&pd_d4>;
+
+ out-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* replicator output ports */
+ port@0 {
+ reg = <0>;
+
+ replicator_out_port0: endpoint {
+ remote-endpoint = <&tpiu_in_port>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+
+ replicator_out_port1: endpoint {
+ remote-endpoint = <&etb_in_port>;
+ };
+ };
+ };
+
+ in-ports {
+ /* replicator input port */
+ port {
+ replicator_in_port0: endpoint {
+ remote-endpoint = <&funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ etb@e6fa1000 {
+ compatible = "arm,coresight-etb10", "arm,primecell";
+ reg = <0xe6fa1000 0x1000>;
+ clocks = <&cpg_clocks R8A7740_CLK_ZT>, <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "apb_pclk", "atclk";
+ power-domains = <&pd_d4>;
+
+ in-ports {
+ port {
+ etb_in_port: endpoint {
+ remote-endpoint = <&replicator_out_port1>;
+ };
+ };
+ };
+ };
+
+ tpiu@e6fa3000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0xe6fa3000 0x1000>;
+ clocks = <&cpg_clocks R8A7740_CLK_ZT>, <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "apb_pclk", "atclk";
+ power-domains = <&pd_d4>;
+
+ in-ports {
+ port {
+ tpiu_in_port: endpoint {
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+ };
+
+ funnel {
+ compatible = "arm,coresight-static-funnel";
+
+ /* funnel output ports */
+ out-ports {
+ port {
+ funnel_out_port: endpoint {
+ remote-endpoint =
+ <&replicator_in_port0>;
+ };
+ };
+ };
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* funnel input ports */
+ port@0 {
+ reg = <0>;
+ funnel0_in_port0: endpoint {
+ remote-endpoint = <&ptm0_out_port>;
+ };
+ };
+ };
+ };
+
+ ptm@e6fbc000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xe6fbc000 0x1000>;
+ clocks = <&cpg_clocks R8A7740_CLK_ZT>, <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "apb_pclk", "atclk";
+ cpu = <&cpu0>;
+ power-domains = <&pd_d4>;
+
+ out-ports {
+ port {
+ ptm0_out_port: endpoint {
+ remote-endpoint = <&funnel0_in_port0>;
+ };
+ };
+ };
};
ceu0: ceu@fe910000 {
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
These clock supply the coresight tracing modules, PTM, TPIU,
ETB and replicator. Without these clock, the coresight tracing
can not be operated.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Add ztr/zt clock at the end of the list to match bindings
V3: Keep only the trace clock DT part here, extend the commit message.
---
arch/arm/boot/dts/renesas/r8a7740.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7740.dtsi b/arch/arm/boot/dts/renesas/r8a7740.dtsi
index d13ab86c3ab47..f7136db7a2eae 100644
--- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
+++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
@@ -553,7 +553,7 @@ cpg_clocks: cpg_clocks@e6150000 {
"usb24s",
"i", "zg", "b", "m1", "hp",
"hpp", "usbp", "s", "zb", "m3",
- "cp";
+ "cp", "ztr", "zt";
};
/* Variable factor clocks (DIV6) */
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Document ZT trace bus and ZTR trace clock on the R-Mobile A1.
These clock supply the coresight tracing modules, PTM, TPIU,
ETB and replicator. Without these clock, the coresight tracing
can not be operated. While this does change the ABI, it does so
by extending the existing clock-output-names, therefore if an
old software is used with new DT, the coresight tracing parts
will likely fail to probe, otherwise if new software is used
with an old DT, there is no impact.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Reorder new clock at the end to match bindings
V3: - Clarify why this change has to be done and its impact
- Include include/dt-bindings/clock/r8a7740-clock.h change here
- Add RB from Krzysztof
---
.../devicetree/bindings/clock/renesas,cpg-clocks.yaml | 6 ++++--
include/dt-bindings/clock/r8a7740-clock.h | 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
index a0e09b7002f07..925ed35d6658a 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
@@ -41,7 +41,7 @@ properties:
clock-output-names:
minItems: 3
- maxItems: 17
+ maxItems: 19
renesas,mode:
description: Board-specific settings of the MD_CK* bits on R-Mobile A1
@@ -123,6 +123,8 @@ allOf:
- const: zb
- const: m3
- const: cp
+ - const: ztr
+ - const: zt
required:
- renesas,mode
@@ -240,6 +242,6 @@ examples:
#clock-cells = <1>;
clock-output-names = "system", "pllc0", "pllc1", "pllc2", "r",
"usb24s", "i", "zg", "b", "m1", "hp", "hpp",
- "usbp", "s", "zb", "m3", "cp";
+ "usbp", "s", "zb", "m3", "cp", "ztr", "zt";
renesas,mode = <0x05>;
};
diff --git a/include/dt-bindings/clock/r8a7740-clock.h b/include/dt-bindings/clock/r8a7740-clock.h
index 1b3fdb39cc426..8a8816b2ff6ac 100644
--- a/include/dt-bindings/clock/r8a7740-clock.h
+++ b/include/dt-bindings/clock/r8a7740-clock.h
@@ -24,6 +24,8 @@
#define R8A7740_CLK_ZB 14
#define R8A7740_CLK_M3 15
#define R8A7740_CLK_CP 16
+#define R8A7740_CLK_ZTR 17
+#define R8A7740_CLK_ZT 18
/* MSTP1 */
#define R8A7740_CLK_CEU21 28
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/4] clk: renesas: r8a7740: Implement ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Implement ZT trace bus and ZTR trace clock on the R-Mobile A1.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: No change
V3: No change
---
drivers/clk/renesas/clk-r8a7740.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/renesas/clk-r8a7740.c b/drivers/clk/renesas/clk-r8a7740.c
index 635d59ead499e..31a79674583e8 100644
--- a/drivers/clk/renesas/clk-r8a7740.c
+++ b/drivers/clk/renesas/clk-r8a7740.c
@@ -37,6 +37,8 @@ static struct div4_clk div4_clks[] = {
{ "zg", CPG_FRQCRA, 16 },
{ "b", CPG_FRQCRA, 8 },
{ "m1", CPG_FRQCRA, 4 },
+ { "ztr", CPG_FRQCRB, 20 },
+ { "zt", CPG_FRQCRB, 16 },
{ "hp", CPG_FRQCRB, 4 },
{ "hpp", CPG_FRQCRC, 20 },
{ "usbp", CPG_FRQCRC, 16 },
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/4] Describe coresight on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
Implement support for ZT trace bus and ZTR trace clock on R-Mobile A1.
Describe coresight topology on R-Mobile A1. Extend the current PTM node
with connection funnel, TPIU, ETB and replicator. The coresight on this
hardware is clocked from the ZT/ZTR trace clock.
Please note that this is written according to R-Mobile A1 User's Manual:
Hardware , Rev.2.00 Sep. 2013 . I currently do not have access to this
hardware.
Marek Vasut (4):
dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on
R-Mobile A1
clk: renesas: r8a7740: Implement ZT/ZTR trace clock on R-Mobile A1
ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
ARM: dts: renesas: r8a7740: Describe coresight on R-Mobile A1
.../bindings/clock/renesas,cpg-clocks.yaml | 6 +-
arch/arm/boot/dts/renesas/r8a7740.dtsi | 116 +++++++++++++++++-
drivers/clk/renesas/clk-r8a7740.c | 2 +
include/dt-bindings/clock/r8a7740-clock.h | 2 +
4 files changed, 120 insertions(+), 6 deletions(-)
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
--
2.53.0
^ permalink raw reply
* Re: [PATCH/RFC 00/14] R-Car X5H Ironhide SCMI CPG/MDLC remapping
From: Kevin Hilman @ 2026-04-22 22:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Sudeep Holla, Cristian Marussi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Saravana Kannan,
Michael Turquette, Stephen Boyd, Philipp Zabel, Ulf Hansson,
Rafael J . Wysocki, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Geert Uytterhoeven <geert+renesas@glider.be> writes:
> Hi all,
>
> TL;DR:
>
> Describe hardware in DT, and perform the mapping to SCMI in Linux.
>
> The Renesas R-Car X5H-based Ironhide board is the first Renesas
> SoC/board combination that implements the ARM System Control and
> Management Interface (SCMI).
>
> This means Linux can no longer perform various system operations (e.g.
> clock, power domain, and reset control) by accessing the hardware
> directly. Instead, these operations are abstracted according to various
> SCMI sub-protocols, and Linux has to send messages to an SCMI-compliant
> firmware running on a System Control Processor (SCP).
> More specifically, the R-Car X5H SCP FW SCMI controls access to:
> 1. Core clocks and module clocks,
> 2. Module resets,
> 3. Power domains,
I'm very curious how power domain hierarchy is described on this SoC,
because one more issue to add to your list is that hierarchy cannot be
described for power domains in SCMI.
I know you're aware of it already, but just FYI for anyone else
exploring this space, I have a series[1] in-flight right now to address
this limitation of SCMI so that we can at least describe this hierarchy
in DT and the pmdomain framework.
Kevin
[1] https://lore.kernel.org/linux-pm/20260420-topic-lpm-pmdomain-child-ids-v3-0-c2c40bef238c@baylibre.com/
^ permalink raw reply
* [PATCH v13 4/4] arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
From: Shenwei Wang @ 2026-04-22 21:28 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree, linux-remoteproc, imx, linux-arm-kernel, linux-imx
In-Reply-To: <20260422212849.1240591-1-shenwei.wang@nxp.com>
Add the RPMSG bus node along with its GPIO subnodes to the device
tree.
Enable remote device communication and GPIO control via RPMSG on
the i.MX platform.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 1de3ad60c6aa..f1b984eb1203 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -190,6 +190,31 @@ scmi_sensor: protocol@15 {
cm33: remoteproc-cm33 {
compatible = "fsl,imx8ulp-cm33";
status = "disabled";
+
+ rpmsg {
+ rpmsg-io {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rpmsg_gpioa: gpio@0 {
+ compatible = "rpmsg-gpio";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ rpmsg_gpiob: gpio@1 {
+ compatible = "rpmsg-gpio";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+ };
+ };
};
soc: soc@0 {
--
2.43.0
^ permalink raw reply related
* [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang @ 2026-04-22 21:28 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree, linux-remoteproc, imx, linux-arm-kernel, linux-imx,
Bartosz Golaszewski, Andrew Lunn
In-Reply-To: <20260422212849.1240591-1-shenwei.wang@nxp.com>
On an AMP platform, the system may include two processors:
- An MCU running an RTOS
- An MPU running Linux
These processors communicate via the RPMSG protocol.
The driver implements the standard GPIO interface, allowing
the Linux side to control GPIO controllers which reside in
the remote processor via RPMSG protocol.
Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
drivers/gpio/Kconfig | 17 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rpmsg.c | 573 ++++++++++++++++++++++++++++++++++++++
3 files changed, 591 insertions(+)
create mode 100644 drivers/gpio/gpio-rpmsg.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 020e51e30317..4ad299fe3c6f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1917,6 +1917,23 @@ config GPIO_SODAVILLE
endmenu
+menu "RPMSG GPIO drivers"
+ depends on RPMSG
+
+config GPIO_RPMSG
+ tristate "Generic RPMSG GPIO support"
+ depends on OF && REMOTEPROC
+ select GPIOLIB_IRQCHIP
+ default REMOTEPROC
+ help
+ Say yes here to support the generic GPIO functions over the RPMSG
+ bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
+ i.MX9x.
+
+ If unsure, say N.
+
+endmenu
+
menu "SPI GPIO expanders"
depends on SPI_MASTER
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index b267598b517d..ee75c0e65b8b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
obj-$(CONFIG_GPIO_REG) += gpio-reg.o
obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
+obj-$(CONFIG_GPIO_RPMSG) += gpio-rpmsg.o
obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
diff --git a/drivers/gpio/gpio-rpmsg.c b/drivers/gpio/gpio-rpmsg.c
new file mode 100644
index 000000000000..993cde7af2fa
--- /dev/null
+++ b/drivers/gpio/gpio-rpmsg.c
@@ -0,0 +1,573 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 NXP
+ *
+ * The driver exports a standard gpiochip interface to control
+ * the GPIO controllers via RPMSG on a remote processor.
+ */
+
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/driver.h>
+#include <linux/init.h>
+#include <linux/irqdomain.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/rpmsg.h>
+#include <linux/virtio_gpio.h>
+
+#define MAX_PORT_PER_CHANNEL 10
+#define GPIOS_PER_PORT_DEFAULT 32
+#define RPMSG_TIMEOUT 1000
+
+/* GPIO RPMSG Type */
+#define GPIO_RPMSG_SEND 0
+#define GPIO_RPMSG_REPLY 1
+#define GPIO_RPMSG_NOTIFY 2
+
+struct rpmsg_gpio_packet {
+ u8 type; /* Message type */
+ u8 cmd; /* Command code */
+ u8 port_idx;
+ u8 line;
+ u8 val1;
+ u8 val2;
+};
+
+struct rpmsg_gpio_line {
+ u8 irq_shutdown;
+ u8 irq_unmask;
+ u8 irq_mask;
+ u32 irq_wake_enable;
+ u32 irq_type;
+ struct rpmsg_gpio_packet msg;
+};
+
+struct rpmsg_gpio_info {
+ struct rpmsg_device *rpdev;
+ struct rpmsg_gpio_packet *reply_msg;
+ struct completion cmd_complete;
+ struct mutex lock;
+ void **port_store;
+};
+
+struct rpmsg_gpio_port {
+ struct gpio_chip gc;
+ struct rpmsg_gpio_line lines[GPIOS_PER_PORT_DEFAULT];
+ struct rpmsg_gpio_info info;
+ u32 ngpios;
+ u32 idx;
+};
+
+/**
+ * struct rpmsg_drvdata - driver data per channel.
+ * @rproc_name: the name of the remote proc.
+ * @recv_pkt: a pointer to the received packet for protocol fix up.
+ * @channel_devices: an array of the devices related to the rpdev.
+ */
+struct rpdev_drvdata {
+ const char *rproc_name;
+ void *recv_pkt;
+ void *channel_devices[MAX_PORT_PER_CHANNEL];
+};
+
+static int rpmsg_gpio_send_message(struct rpmsg_gpio_port *port,
+ struct rpmsg_gpio_packet *msg)
+{
+ struct rpmsg_gpio_info *info = &port->info;
+ int ret;
+
+ reinit_completion(&info->cmd_complete);
+
+ ret = rpmsg_send(info->rpdev->ept, msg, sizeof(*msg));
+ if (ret) {
+ dev_err(&info->rpdev->dev, "rpmsg_send failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = wait_for_completion_timeout(&info->cmd_complete,
+ msecs_to_jiffies(RPMSG_TIMEOUT));
+ if (ret == 0) {
+ dev_err(&info->rpdev->dev, "rpmsg_send timeout!\n");
+ return -ETIMEDOUT;
+ }
+
+ if (info->reply_msg->val1) {
+ dev_err(&info->rpdev->dev, "remote core replies an error: %d!\n",
+ info->reply_msg->val1);
+ return -EINVAL;
+ }
+
+ /* copy the reply message */
+ memcpy(&port->lines[info->reply_msg->line].msg,
+ info->reply_msg, sizeof(*info->reply_msg));
+
+ return 0;
+}
+
+static struct rpmsg_gpio_packet *
+rpmsg_gpio_msg_init_common(struct rpmsg_gpio_port *port, unsigned int line, u8 cmd)
+{
+ struct rpmsg_gpio_packet *msg = &port->lines[line].msg;
+
+ memset(msg, 0, sizeof(*msg));
+ msg->type = GPIO_RPMSG_SEND;
+ msg->cmd = cmd;
+ msg->port_idx = port->idx;
+ msg->line = line;
+
+ return msg;
+}
+
+static int rpmsg_gpio_get(struct gpio_chip *gc, unsigned int line)
+{
+ struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+ struct rpmsg_gpio_packet *msg;
+ int ret;
+
+ guard(mutex)(&port->info.lock);
+
+ msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_GET_VALUE);
+
+ ret = rpmsg_gpio_send_message(port, msg);
+ if (!ret)
+ ret = !!port->lines[line].msg.val2;
+
+ return ret;
+}
+
+static int rpmsg_gpio_get_direction(struct gpio_chip *gc, unsigned int line)
+{
+ struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+ struct rpmsg_gpio_packet *msg;
+ int ret;
+
+ guard(mutex)(&port->info.lock);
+
+ msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_GET_DIRECTION);
+
+ ret = rpmsg_gpio_send_message(port, msg);
+ if (ret)
+ return ret;
+
+ switch (port->lines[line].msg.val2) {
+ case VIRTIO_GPIO_DIRECTION_IN:
+ return GPIO_LINE_DIRECTION_IN;
+ case VIRTIO_GPIO_DIRECTION_OUT:
+ return GPIO_LINE_DIRECTION_OUT;
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static int rpmsg_gpio_direction_input(struct gpio_chip *gc, unsigned int line)
+{
+ struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+ struct rpmsg_gpio_packet *msg;
+
+ guard(mutex)(&port->info.lock);
+
+ msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_DIRECTION);
+ msg->val1 = VIRTIO_GPIO_DIRECTION_IN;
+
+ return rpmsg_gpio_send_message(port, msg);
+}
+
+static int rpmsg_gpio_set(struct gpio_chip *gc, unsigned int line, int val)
+{
+ struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+ struct rpmsg_gpio_packet *msg;
+
+ guard(mutex)(&port->info.lock);
+
+ msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_VALUE);
+ msg->val1 = val;
+
+ return rpmsg_gpio_send_message(port, msg);
+}
+
+static int rpmsg_gpio_direction_output(struct gpio_chip *gc, unsigned int line, int val)
+{
+ struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+ struct rpmsg_gpio_packet *msg;
+ int ret;
+
+ guard(mutex)(&port->info.lock);
+
+ msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_DIRECTION);
+ msg->val1 = VIRTIO_GPIO_DIRECTION_OUT;
+
+ ret = rpmsg_gpio_send_message(port, msg);
+ if (ret)
+ return ret;
+
+ msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_VALUE);
+ msg->val1 = val;
+
+ return rpmsg_gpio_send_message(port, msg);
+}
+
+static int gpio_rpmsg_irq_set_type(struct irq_data *d, u32 type)
+{
+ struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+ u32 line = d->hwirq;
+
+ switch (type) {
+ case IRQ_TYPE_EDGE_RISING:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_RISING;
+ irq_set_handler_locked(d, handle_simple_irq);
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_FALLING;
+ irq_set_handler_locked(d, handle_simple_irq);
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ type = VIRTIO_GPIO_IRQ_TYPE_EDGE_BOTH;
+ irq_set_handler_locked(d, handle_simple_irq);
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_LOW;
+ irq_set_handler_locked(d, handle_level_irq);
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_HIGH;
+ irq_set_handler_locked(d, handle_level_irq);
+ break;
+ default:
+ dev_err(&port->info.rpdev->dev, "unsupported irq type: %u\n", type);
+ return -EINVAL;
+ }
+
+ port->lines[line].irq_type = type;
+
+ return 0;
+}
+
+static int gpio_rpmsg_irq_set_wake(struct irq_data *d, u32 enable)
+{
+ struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+ u32 line = d->hwirq;
+
+ port->lines[line].irq_wake_enable = enable;
+
+ return 0;
+}
+
+/*
+ * This unmask/mask function is invoked in two situations:
+ * - when an interrupt is being set up, and
+ * - after an interrupt has occurred.
+ *
+ * The GPIO driver does not access hardware registers directly.
+ * Instead, it caches all relevant information locally, and then sends
+ * the accumulated state to the remote system at this stage.
+ */
+static void gpio_rpmsg_unmask_irq(struct irq_data *d)
+{
+ struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+ u32 line = d->hwirq;
+
+ port->lines[line].irq_unmask = 1;
+}
+
+static void gpio_rpmsg_mask_irq(struct irq_data *d)
+{
+ struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+ u32 line = d->hwirq;
+
+ /*
+ * When an interrupt occurs, the remote system masks the interrupt
+ * and then sends a notification to Linux. After Linux processes
+ * that notification, it sends an RPMsg command back to the remote
+ * system to unmask the interrupt again.
+ */
+ port->lines[line].irq_mask = 1;
+}
+
+static void gpio_rpmsg_irq_shutdown(struct irq_data *d)
+{
+ struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+ u32 line = d->hwirq;
+
+ port->lines[line].irq_shutdown = 1;
+}
+
+static void gpio_rpmsg_irq_bus_lock(struct irq_data *d)
+{
+ struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+
+ mutex_lock(&port->info.lock);
+}
+
+static void gpio_rpmsg_irq_bus_sync_unlock(struct irq_data *d)
+{
+ struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+ struct rpmsg_gpio_packet *msg;
+ u32 line = d->hwirq;
+
+ /*
+ * For mask irq, do nothing here.
+ * The remote system will mask interrupt after an interrupt occurs,
+ * and then send a notification to Linux system. After Linux system
+ * handles the notification, it sends an rpmsg back to the remote
+ * system to unmask this interrupt again.
+ */
+ if (port->lines[line].irq_mask && !port->lines[line].irq_unmask) {
+ port->lines[line].irq_mask = 0;
+ mutex_unlock(&port->info.lock);
+ return;
+ }
+
+ msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_IRQ_TYPE);
+
+ if (port->lines[line].irq_shutdown) {
+ port->lines[line].irq_shutdown = 0;
+ msg->val1 = VIRTIO_GPIO_IRQ_TYPE_NONE;
+ msg->val2 = 0;
+ } else {
+ msg->val1 = port->lines[line].irq_type;
+
+ if (port->lines[line].irq_unmask) {
+ msg->val2 = 0;
+ port->lines[line].irq_unmask = 0;
+ } else /* irq set wake */
+ msg->val2 = port->lines[line].irq_wake_enable;
+ }
+
+ rpmsg_gpio_send_message(port, msg);
+ mutex_unlock(&port->info.lock);
+}
+
+static const struct irq_chip gpio_rpmsg_irq_chip = {
+ .irq_mask = gpio_rpmsg_mask_irq,
+ .irq_unmask = gpio_rpmsg_unmask_irq,
+ .irq_set_wake = gpio_rpmsg_irq_set_wake,
+ .irq_set_type = gpio_rpmsg_irq_set_type,
+ .irq_shutdown = gpio_rpmsg_irq_shutdown,
+ .irq_bus_lock = gpio_rpmsg_irq_bus_lock,
+ .irq_bus_sync_unlock = gpio_rpmsg_irq_bus_sync_unlock,
+ .flags = IRQCHIP_IMMUTABLE,
+};
+
+static void rpmsg_gpio_remove_action(void *data)
+{
+ struct rpmsg_gpio_port *port = data;
+
+ port->info.port_store[port->idx] = NULL;
+}
+
+static int rpmsg_gpiochip_register(struct rpmsg_device *rpdev, struct device_node *np)
+{
+ struct rpdev_drvdata *drvdata = dev_get_drvdata(&rpdev->dev);
+ struct rpmsg_gpio_port *port;
+ struct gpio_irq_chip *girq;
+ struct gpio_chip *gc;
+ int ret;
+
+ port = devm_kzalloc(&rpdev->dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ ret = of_property_read_u32(np, "reg", &port->idx);
+ if (ret)
+ return ret;
+
+ if (port->idx >= MAX_PORT_PER_CHANNEL)
+ return -EINVAL;
+
+ ret = devm_mutex_init(&rpdev->dev, &port->info.lock);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, "ngpios", &port->ngpios);
+ if (ret || port->ngpios > GPIOS_PER_PORT_DEFAULT)
+ port->ngpios = GPIOS_PER_PORT_DEFAULT;
+
+ port->info.reply_msg = devm_kzalloc(&rpdev->dev,
+ sizeof(*port->info.reply_msg),
+ GFP_KERNEL);
+ if (!port->info.reply_msg)
+ return -ENOMEM;
+
+ init_completion(&port->info.cmd_complete);
+ port->info.port_store = drvdata->channel_devices;
+ port->info.port_store[port->idx] = port;
+ port->info.rpdev = rpdev;
+
+ gc = &port->gc;
+ gc->owner = THIS_MODULE;
+ gc->parent = &rpdev->dev;
+ gc->fwnode = of_fwnode_handle(np);
+ gc->ngpio = port->ngpios;
+ gc->base = -1;
+ gc->label = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
+ drvdata->rproc_name, port->idx);
+
+ gc->direction_input = rpmsg_gpio_direction_input;
+ gc->direction_output = rpmsg_gpio_direction_output;
+ gc->get_direction = rpmsg_gpio_get_direction;
+ gc->get = rpmsg_gpio_get;
+ gc->set = rpmsg_gpio_set;
+
+ girq = &gc->irq;
+ gpio_irq_chip_set_chip(girq, &gpio_rpmsg_irq_chip);
+ girq->parent_handler = NULL;
+ girq->num_parents = 0;
+ girq->parents = NULL;
+ girq->chip->name = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
+ drvdata->rproc_name, port->idx);
+
+ ret = devm_add_action_or_reset(&rpdev->dev, rpmsg_gpio_remove_action, port);
+ if (ret)
+ return ret;
+
+ return devm_gpiochip_add_data(&rpdev->dev, gc, port);
+}
+
+static const char *rpmsg_get_rproc_node_name(struct rpmsg_device *rpdev)
+{
+ const char *name = NULL;
+ struct device_node *np;
+ struct rproc *rproc;
+
+ rproc = rproc_get_by_child(&rpdev->dev);
+ if (!rproc)
+ return NULL;
+
+ np = of_node_get(rproc->dev.of_node);
+ if (!np && rproc->dev.parent)
+ np = of_node_get(rproc->dev.parent->of_node);
+
+ if (np) {
+ name = devm_kstrdup(&rpdev->dev, np->name, GFP_KERNEL);
+ of_node_put(np);
+ }
+
+ return name;
+}
+
+static struct device_node *
+rpmsg_get_channel_ofnode(struct rpmsg_device *rpdev, char *chan_name)
+{
+ struct device_node *np_chan = NULL, *np;
+ struct rproc *rproc;
+
+ rproc = rproc_get_by_child(&rpdev->dev);
+ if (!rproc)
+ return NULL;
+
+ np = of_node_get(rproc->dev.of_node);
+ if (!np && rproc->dev.parent)
+ np = of_node_get(rproc->dev.parent->of_node);
+
+ /* The of_node_put() is performed by of_find_node_by_name(). */
+ if (np)
+ np_chan = of_find_node_by_name(np, chan_name);
+
+ return np_chan;
+}
+
+static int rpmsg_gpio_channel_callback(struct rpmsg_device *rpdev, void *data,
+ int len, void *priv, u32 src)
+{
+ struct rpmsg_gpio_packet *msg = data;
+ struct rpmsg_gpio_port *port = NULL;
+ struct rpdev_drvdata *drvdata;
+
+ drvdata = dev_get_drvdata(&rpdev->dev);
+ if (!msg || !drvdata)
+ return -EINVAL;
+
+ if (msg->port_idx < MAX_PORT_PER_CHANNEL)
+ port = drvdata->channel_devices[msg->port_idx];
+
+ if (!port || msg->line >= port->ngpios) {
+ dev_err(&rpdev->dev, "wrong port index or line number. port:%d line:%d\n",
+ msg->port_idx, msg->line);
+ return -EINVAL;
+ }
+
+ if (msg->type == GPIO_RPMSG_REPLY) {
+ *port->info.reply_msg = *msg;
+ complete(&port->info.cmd_complete);
+ } else if (msg->type == GPIO_RPMSG_NOTIFY) {
+ generic_handle_domain_irq_safe(port->gc.irq.domain, msg->line);
+ } else {
+ dev_err(&rpdev->dev, "wrong command type (0x%x)\n", msg->type);
+ }
+
+ return 0;
+}
+
+static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev)
+{
+ struct device *dev = &rpdev->dev;
+ struct rpdev_drvdata *drvdata;
+ struct device_node *np;
+ int ret = -ENODEV;
+
+ if (!dev->of_node) {
+ np = rpmsg_get_channel_ofnode(rpdev, rpdev->id.name);
+ if (np) {
+ dev->of_node = np;
+ set_primary_fwnode(dev, of_fwnode_handle(np));
+ }
+ return -EPROBE_DEFER;
+ }
+
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->rproc_name = rpmsg_get_rproc_node_name(rpdev);
+ dev_set_drvdata(dev, drvdata);
+
+ for_each_child_of_node_scoped(dev->of_node, child) {
+ if (!of_device_is_available(child))
+ continue;
+
+ if (!of_match_node(dev->driver->of_match_table, child))
+ continue;
+
+ ret = rpmsg_gpiochip_register(rpdev, child);
+ if (ret < 0)
+ break;
+ }
+
+ return ret;
+}
+
+static const struct of_device_id rpmsg_gpio_dt_ids[] = {
+ { .compatible = "rpmsg-gpio" },
+ { /* sentinel */ }
+};
+
+static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
+ { .name = "rpmsg-io" },
+ { },
+};
+MODULE_DEVICE_TABLE(rpmsg, rpmsg_gpio_channel_id_table);
+
+static struct rpmsg_driver rpmsg_gpio_channel_client = {
+ .callback = rpmsg_gpio_channel_callback,
+ .id_table = rpmsg_gpio_channel_id_table,
+ .probe = rpmsg_gpio_channel_probe,
+ .drv = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = rpmsg_gpio_dt_ids,
+ },
+};
+module_rpmsg_driver(rpmsg_gpio_channel_client);
+
+MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
+MODULE_DESCRIPTION("generic rpmsg gpio driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
From: Shenwei Wang @ 2026-04-22 21:28 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree, linux-remoteproc, imx, linux-arm-kernel, linux-imx
In-Reply-To: <20260422212849.1240591-1-shenwei.wang@nxp.com>
Remote processors may announce multiple GPIO controllers over an RPMSG
channel. These GPIO controllers may require corresponding device tree
nodes, especially when acting as providers, to supply phandles for their
consumers.
Define an RPMSG node to work as a container for a group of RPMSG channels
under the imx_rproc node. Each subnode within "rpmsg" represents an
individual RPMSG channel. The name of each subnode corresponds to the
channel name as defined by the remote processor.
All remote devices associated with a given channel are defined as child
nodes under the corresponding channel node.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
.../devicetree/bindings/gpio/gpio-rpmsg.yaml | 55 +++++++++++++++++++
.../bindings/remoteproc/fsl,imx-rproc.yaml | 53 ++++++++++++++++++
2 files changed, 108 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
diff --git a/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
new file mode 100644
index 000000000000..6c78b6850321
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-rpmsg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic RPMSG GPIO Controller
+
+maintainers:
+ - Shenwei Wang <shenwei.wang@nxp.com>
+
+description:
+ On an AMP platform, some GPIO controllers are exposed by the remote processor
+ through the RPMSG bus. The RPMSG GPIO transport protocol defines the packet
+ structure and communication flow between Linux and the remote firmware. Those
+ controllers are managed via this transport protocol. For more details of the
+ protocol, check the document below.
+ Documentation/driver-api/gpio/gpio-rpmsg.rst
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,rpmsg-gpio
+ - const: rpmsg-gpio
+ - const: rpmsg-gpio
+
+ reg:
+ description:
+ The reg property represents the index of the GPIO controllers. Since
+ the driver manages controllers on a remote system, this index tells
+ the remote system which controller to operate.
+ maxItems: 1
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - "#interrupt-cells"
+
+allOf:
+ - $ref: /schemas/gpio/gpio.yaml#
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index ce8ec0119469..aea33205a881 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -85,6 +85,34 @@ properties:
This property is to specify the resource id of the remote processor in SoC
which supports SCFW
+ rpmsg:
+ type: object
+ additionalProperties: false
+ description:
+ Represents the RPMSG bus between Linux and the remote system. Contains
+ a group of RPMSG channel devices running on the bus.
+
+ properties:
+ rpmsg-io:
+ type: object
+ additionalProperties: false
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "gpio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/gpio/gpio-rpmsg.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - '#address-cells'
+ - '#size-cells'
+
required:
- compatible
@@ -147,5 +175,30 @@ examples:
&mu 3 1>;
memory-region = <&vdev0buffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
syscon = <&src>;
+
+ rpmsg {
+ rpmsg-io {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@0 {
+ compatible = "rpmsg-gpio";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio@1 {
+ compatible = "rpmsg-gpio";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+ };
+ };
};
...
--
2.43.0
^ permalink raw reply related
* [PATCH v13 1/4] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
From: Shenwei Wang @ 2026-04-22 21:28 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree, linux-remoteproc, imx, linux-arm-kernel, linux-imx
In-Reply-To: <20260422212849.1240591-1-shenwei.wang@nxp.com>
Describes the gpio rpmsg transport protocol over the rpmsg bus between
the remote system and Linux.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
Documentation/driver-api/gpio/gpio-rpmsg.rst | 266 +++++++++++++++++++
Documentation/driver-api/gpio/index.rst | 1 +
2 files changed, 267 insertions(+)
create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
diff --git a/Documentation/driver-api/gpio/gpio-rpmsg.rst b/Documentation/driver-api/gpio/gpio-rpmsg.rst
new file mode 100644
index 000000000000..abfde68c9b0a
--- /dev/null
+++ b/Documentation/driver-api/gpio/gpio-rpmsg.rst
@@ -0,0 +1,266 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+GPIO RPMSG (Remote Processor Messaging) Protocol
+================================================
+
+The GPIO RPMSG transport protocol is used for communication and interaction
+with GPIO controllers on remote processors via the RPMSG bus.
+
+Message Format
+--------------
+
+The RPMSG message consists of a 6-byte packet with the following layout:
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ |type |cmd |port |line | data |
+ +-----+-----+-----+-----+-----+----+
+
+- **type (Message Type)**: The message type can be one of:
+
+ - 0: GPIO_RPMSG_SEND
+ - 1: GPIO_RPMSG_REPLY
+ - 2: GPIO_RPMSG_NOTIFY
+
+- **cmd**: Command code, used for GPIO_RPMSG_SEND messages.
+
+- **port**: The GPIO port (bank) index.
+
+- **line**: The GPIO line (pin) index of the port.
+
+- **data**: See details in the command description below.
+
+- **reply err**: Error code from the remote core.
+
+ - 0: Success
+ - 1: General error (Early remote software only returns this unclassified error)
+ - 2: Not supported (A command is not supported by the remote firmware)
+ - 3: Resource not available (The resource is not allocated to Linux)
+ - 4: Resource busy (The resource is already in use)
+ - 5: Parameter error
+
+
+GPIO Commands
+-------------
+
+Commands are specified in the **Cmd** field for **GPIO_RPMSG_SEND** (Type=0) messages.
+
+The SEND message is always sent from Linux to the remote firmware. Each
+SEND corresponds to a single REPLY message. The GPIO driver should
+serialize messages and determine whether a REPLY message is required. If a
+REPLY message is expected but not received within the specified timeout
+period (currently 1 second in the Linux driver), the driver should return
+-ETIMEOUT.
+
+GET_DIRECTION (Cmd=2)
+~~~~~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 0 | 2 |port |line | 0 | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+**Reply:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 1 | 2 |port |line | err | dir|
+ +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+- **dir**: Direction.
+
+ - 0: None
+ - 1: Output
+ - 2: Input
+
+SET_DIRECTION (Cmd=3)
+~~~~~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 0 | 3 |port |line | dir | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+- **dir**: Direction.
+
+ - 0: None
+ - 1: Output
+ - 2: Input
+
+**Reply:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 1 | 3 |port |line | err | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+
+GET_VALUE (Cmd=4)
+~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 0 | 4 |port |line | 0 | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+**Reply:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 1 | 4 |port |line | err | val|
+ +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+- **val**: Line level.
+
+ - 0: Low
+ - 1: High
+
+SET_VALUE (Cmd=5)
+~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 0 | 5 |port |line | val | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+- **val**: Output level.
+
+ - 0: Low
+ - 1: High
+
+**Reply:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 1 | 5 |port |line | err | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+SET_IRQ_TYPE (Cmd=6)
+~~~~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 0 | 6 |port |line | val | wk |
+ +-----+-----+-----+-----+-----+----+
+
+- **val**: IRQ types.
+
+ - 0: Interrupt disabled
+ - 1: Rising edge trigger
+ - 2: Falling edge trigger
+ - 3: Both edge trigger
+ - 4: High level trigger
+ - 8: Low level trigger
+
+- **wk**: Wakeup enable.
+
+ The remote system should always aim to stay in a power-efficient state by
+ shutting down or clock-gating the GPIO blocks that aren't in use. Since
+ the remoteproc driver is responsible for managing the power states of the
+ remote firmware, the GPIO driver does not require to know the firmware's
+ running states.
+
+ When the wakeup bit is set, the remote firmware should configure the line
+ as a wakeup source. The firmware should send the notification message to
+ Linux after it is woken from the GPIO line.
+
+ - 0: Disable wakeup from GPIO
+ - 1: Enable wakeup from GPIO
+
+**Reply:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 1 | 6 |port |line | err | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+NOTIFY_REPLY (Cmd=10)
+~~~~~~~~~~~~~~~~~~~~~
+The reply message for the notification is optional. The remote firmware can
+implement it to simulate the interrupt acknowledgment behavior.
+
+**Request:**
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 0 | 10 |port |line |level| 0 |
+ +-----+-----+-----+-----+-----+----+
+
+- **port**: The GPIO port (bank) index.
+
+- **line**: The GPIO line (pin) index of the port.
+
+- **level**: GPIO line status.
+
+Notification Message
+--------------------
+
+Notifications are sent by the remote core and they have
+**Type=2 (GPIO_RPMSG_NOTIFY)**:
+
+When a GPIO line asserts an interrupt on the remote processor, the firmware
+should immediately mask the corresponding interrupt source and send a
+notification message to the Linux. Upon completion of the interrupt
+handling on the Linux side, the driver should issue a
+command **SET_IRQ_TYPE** to the firmware to unmask the interrupt.
+
+A Notification message can arrive between a SEND and its REPLY message,
+and the driver is expected to handle this scenario.
+
+.. code-block:: none
+
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 2 | 0 |port |line |type | 0 |
+ +-----+-----+-----+-----+-----+----+
+
+- **port**: The GPIO port (bank) index.
+
+- **line**: The GPIO line (pin) index of the port.
+
+- **type**: Optional parameter to indicate the trigger event type.
+
diff --git a/Documentation/driver-api/gpio/index.rst b/Documentation/driver-api/gpio/index.rst
index bee58f709b9a..e5eb1f82f01f 100644
--- a/Documentation/driver-api/gpio/index.rst
+++ b/Documentation/driver-api/gpio/index.rst
@@ -16,6 +16,7 @@ Contents:
drivers-on-gpio
bt8xxgpio
pca953x
+ gpio-rpmsg
Core
====
--
2.43.0
^ permalink raw reply related
* [PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform
From: Shenwei Wang @ 2026-04-22 21:28 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree, linux-remoteproc, imx, linux-arm-kernel, linux-imx
Support the remote devices on the remote processor via the RPMSG bus on
i.MX platform.
Changes in v13:
- drop the support for legacy NXP firmware.
- remove the fixed_up hooks from the rpmsg gpio driver.
- code cleanup.
Changes in v12:
- Fixed the "underline" warning reported by Randy.
Changes in v11:
- Expand RPMSG for the first time per Shuah's review comment.
Changes in v10:
- Update gpio-rpmsg.rst according to Daniel Baluta's review comments.
- Add a kernel CONFIG for fixed up handlers and only enable it on
i.MX products.
- Fixed bugs reported by kernel test robot.
Changes in v9:
- Reuse the gpio-virtio design for command and IRQ type definitions.
- Remove msg_id, version, and vendor fields from the generic protocol.
- Add fixed-up handlers to support legacy firmware.
Changes in v8:
- Add "depends on REMOTEPROC" in Kconfig to fix the build error reported
by the kernel test robot.
- Move the .rst patch before the .yaml patch.
- Handle the "ngpios" DT property based on Andrew's feedback.
Changes in v7:
- Reworked the driver to use the rpmsg_driver framework instead of
platform_driver, based on feedback from Bjorn and Arnaud.
- Updated gpio-rpmsg.yaml and imx_rproc.yaml according to comments from
Rob and Arnaud.
- Further refinements to gpio-rpmsg.yaml per Arnaud's feedback.
Changes in v6:
- make the driver more generic with the actions below:
rename the driver file to gpio-rpmsg.c
remove the imx related info in the function and variable names
rename the imx_rpmsg.h to rpdev_info.h
create a gpio-rpmsg.yaml and refer it in imx_rproc.yaml
- update the gpio-rpmsg.rst according to the feedback from Andrew and
move the source file to driver-api/gpio
- fix the bug reported by Zhongqiu Han
- remove the I2C related info
Changes in v5:
- move the gpio-rpmsg.rst from admin-guide to staging directory after
discussion with Randy Dunlap.
- add include files with some code improvements per Bartosz's comments.
Changes in v4:
- add a documentation to describe the transport protocol per Andrew's
comments.
- add a new handler to get the gpio direction.
Changes in v3:
- fix various format issue and return value check per Peng 's review
comments.
- add the logic to also populate the subnodes which are not in the
device map per Arnaud's request. (in imx_rproc.c)
- update the yaml per Frank's review comments.
Changes in v2:
- re-implemented the gpio driver per Linus Walleij's feedback by using
GPIOLIB_IRQCHIP helper library.
- fix various format issue per Mathieu/Peng 's review comments.
- update the yaml doc per Rob's feedback
Shenwei Wang (4):
docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
gpio: rpmsg: add generic rpmsg GPIO driver
arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
.../devicetree/bindings/gpio/gpio-rpmsg.yaml | 55 ++
.../bindings/remoteproc/fsl,imx-rproc.yaml | 53 ++
Documentation/driver-api/gpio/gpio-rpmsg.rst | 266 ++++++++
Documentation/driver-api/gpio/index.rst | 1 +
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 25 +
drivers/gpio/Kconfig | 17 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rpmsg.c | 573 ++++++++++++++++++
8 files changed, 991 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
create mode 100644 drivers/gpio/gpio-rpmsg.c
--
2.43.0
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-22 21:20 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aekkVQwueKbFtG7C@e129823.arm.com>
On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > Hi Mimi,
> >
> > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > the TPM driver must be built as built-in and
> > > > must be probed before the IMA subsystem is initialized.
> > > >
> > > > However, when the TPM device operates over the FF-A protocol using
> > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > interface to the tpm_crb driver — has not yet been probed.
> > > >
> > > > To ensure the TPM device operating over the FF-A protocol with
> > > > the CRB interface is probed before IMA initialization,
> > > > the following conditions must be met:
> > > >
> > > > 1. The corresponding ffa_device must be registered,
> > > > which is done via ffa_init().
> > > >
> > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > tpm_crb_ffa_init().
> > > >
> > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > be probed successfully. (See crb_acpi_add() and
> > > > tpm_crb_ffa_init() for reference.)
> > > >
> > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > >
> > > > When this occurs, probing the TPM device is deferred.
> > > > However, the deferred probe can happen after the IMA subsystem
> > > > has already been initialized, since IMA initialization is performed
> > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > at the same level.
> > > >
> > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > log though TPM device presents in the system.
> > > >
> > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > >
> > > A lot of change for just detecting whether ima_init() is being called on
> > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > changes (e.g. ima_init_core).
> > >
> > > Please just limit the change to just calling ima_init() twice.
> >
> > My concern is that ima_update_policy_flags() will be called
> > when ima_init() is deferred -- not initialised anything.
> > though functionally, it might be okay however,
> > I think ima_update_policy_flags() and notifier should work after ima_init()
> > works logically.
> >
> > This change I think not much quite a lot. just wrapper ima_init() with
> > ima_init_core() with some error handling.
> >
> > Am I missing something?
>
> Also, if we handle in ima_init() only, but it failed with other reason,
> we shouldn't call again ima_init() in the late_initcall_sync.
>
> To handle this, It wouldn't do in the ima_init() but we need to handle
> it by caller of ima_init().
Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
instead of going into TPM-bypass mode, return immediately. There are no calls
to anything else. Just call ima_init() a second time.
Mimi
^ permalink raw reply
* [PATCH v3 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
From: Lothar Rubusch @ 2026-04-22 21:09 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260422210936.20095-1-l.rubusch@gmail.com>
The driver allocated memory for work_data in the non-blocking read
path but never free'd it again. After first read-out the memory pointer
seemed to be recycled and never was allocated again, due to some errors
in the logic, so that the leak was not growing.
Add kfree(work_data) in the completion callback on error. then add
kfree(work_data) after the data is consumed in the subsequent read
call. Finally ensure atomic_dec() is called only after the data has
been consumed or an error occurred to prevent race conditions.
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 43 ++++++++++++++++++++--------------
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index dbb39ed0cea1..19720bdd446d 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -25,13 +25,17 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
struct hwrng *rng = areq;
- if (status)
+ if (status) {
dev_warn_ratelimited(&i2c_priv->client->dev,
"i2c transaction failed (%d)\n",
status);
+ kfree(work_data);
+ rng->priv = 0;
+ atomic_dec(&i2c_priv->tfm_count);
+ return;
+ }
rng->priv = (unsigned long)work_data;
- atomic_dec(&i2c_priv->tfm_count);
}
static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
@@ -42,31 +46,36 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
- /* keep maximum 1 asynchronous read in flight at any time */
- if (!atomic_add_unless(&i2c_priv->tfm_count, 1, 1))
- return 0;
-
+ /* Verify if data available from last run */
if (rng->priv) {
work_data = (struct atmel_i2c_work_data *)rng->priv;
max = min(sizeof(work_data->cmd.data), max);
memcpy(data, &work_data->cmd.data, max);
- rng->priv = 0;
- } else {
- work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
- if (!work_data) {
- atomic_dec(&i2c_priv->tfm_count);
- return -ENOMEM;
- }
- work_data->ctx = i2c_priv;
- work_data->client = i2c_priv->client;
- max = 0;
+ /* Now, free memory */
+ kfree(work_data);
+ rng->priv = 0;
+ atomic_dec(&i2c_priv->tfm_count);
+ return max;
}
+ /* When a request is still in-flight but not processed */
+ if (atomic_read(&i2c_priv->tfm_count) > 0)
+ return 0;
+
+ /* Start a new request */
+ work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
+ if (!work_data)
+ return -ENOMEM;
+
+ atomic_inc(&i2c_priv->tfm_count);
+ work_data->ctx = i2c_priv;
+ work_data->client = i2c_priv->client;
+
atmel_i2c_init_random_cmd(&work_data->cmd);
atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
- return max;
+ return 0;
}
static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
--
2.53.0
^ permalink raw reply related
* [PATCH] arm64: dts: imx8mn: Sort ifm VHIP4 EvalBoard Makefile entries
From: Marek Vasut @ 2026-04-22 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Fabio Estevam, Frank Li,
Krzysztof Kozlowski, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, devicetree, imx, linux-kernel
Sort the Makefile entries alphabetically. No functional change.
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm64/boot/dts/freescale/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c990..1a08c5202f0fd 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -206,10 +206,10 @@ imx8mn-vhip4-evalboard-v1-overlay-ksz8794-dtbs := imx8mn-vhip4-evalboard-v1.dtb
imx8mn-vhip4-evalboard-v1-overlay-ksz8794.dtbo
imx8mn-vhip4-evalboard-v1-overlay-ksz9031-dtbs := imx8mn-vhip4-evalboard-v1.dtb \
imx8mn-vhip4-evalboard-v1-overlay-ksz9031.dtbo
-imx8mn-vhip4-evalboard-v2-overlay-ksz8794-dtbs := imx8mn-vhip4-evalboard-v2.dtb \
- imx8mn-vhip4-evalboard-v2-overlay-ksz8794.dtbo
imx8mn-vhip4-evalboard-v2-overlay-adin1300-dtbs := imx8mn-vhip4-evalboard-v2.dtb \
imx8mn-vhip4-evalboard-v2-overlay-adin1300.dtbo
+imx8mn-vhip4-evalboard-v2-overlay-ksz8794-dtbs := imx8mn-vhip4-evalboard-v2.dtb \
+ imx8mn-vhip4-evalboard-v2-overlay-ksz8794.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mn-vhip4-evalboard-v1.dtb \
imx8mn-vhip4-evalboard-v1-overlay-ksz8794.dtb \
imx8mn-vhip4-evalboard-v1-overlay-ksz8794.dtbo \
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Lothar Rubusch @ 2026-04-22 21:09 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260422210936.20095-1-l.rubusch@gmail.com>
The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
32 bytes of entropy, and a 2-byte CRC. The current blocking read
implementation was incorrectly copying data starting from the
count byte, leading to offset data and truncated entropy.
Additionally, the chip requires significant execution time to
generate random numbers, going by the datasheet. Reading the I2C bus
too early results in the chip NACK-ing or returning a partial buffer
followed by zeros.
Verification:
Tests before showed repeadetly reading only 8 bytes of entropy:
$ head -c 32 /dev/hwrng | hexdump -C
00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
After this patch applied, the result will be as follows:
$ head -c 32 /dev/hwrng | hexdump -C
00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
00000020
Fix these issues by:
Increase cmd.msecs to 30ms to provide sufficient execution time. Then
set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
hardware response. Eventually, correct the memcpy() offset to index 1 of
the data buffer to skip the count byte and retrieve exactly 32 bytes of
entropy.
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 19720bdd446d..f7dc00d0f4cd 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -19,6 +19,9 @@
#include <linux/workqueue.h>
#include "atmel-i2c.h"
+#define ATMEL_RNG_BLOCK_SIZE 32
+#define ATMEL_RNG_EXEC_TIME 30
+
static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
void *areq, int status)
{
@@ -91,13 +94,15 @@ static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
atmel_i2c_init_random_cmd(&cmd);
+ cmd.msecs = ATMEL_RNG_EXEC_TIME;
+ cmd.rxsize = RANDOM_RSP_SIZE;
ret = atmel_i2c_send_receive(i2c_priv->client, &cmd);
if (ret)
return ret;
- max = min(sizeof(cmd.data), max);
- memcpy(data, cmd.data, max);
+ max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
+ memcpy(data, &cmd.data[1], max);
return max;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/3] crypto: atmel-sha204a - fix non-blocking read logic
From: Lothar Rubusch @ 2026-04-22 21:09 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
In-Reply-To: <20260422210936.20095-1-l.rubusch@gmail.com>
The non-blocking path was (also) failing to provide valid entropy
due to improper buffer management and a lack of hardware execution
time.
Ensure cmd.msecs (30ms) and cmd.rxsize (35ms) are initialized before
enqueuing the background work. Fix the data offset to skip the
1-byte hardware count header when copying bits to the caller. Correctly
return 0 (busy) to the hwrng core while hardware execution is in
progress, preventing zero-filled buffers, which was the situation
before.
With this fix applied, tests will look similar to this:
$ socat -u OPEN:/dev/hwrng,nonblock - | head -c 32 | hexdump -C
00000000 23 cc 42 3c 90 b1 38 fc 54 37 35 4b 09 c5 e1 0d |#.B<..8.T75K....|
2026/03/23 14:30:18 socat[858] E read(5, 0x55be363000, 8192): Resource temporarily unavailable
00000010 73 3b af d9 02 70 76 bd 2d 59 4b 12 01 ac ae 2b |s;...pv.-YK....+|
00000020
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/crypto/atmel-sha204a.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index f7dc00d0f4cd..04cbf80c1411 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -33,7 +33,6 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
"i2c transaction failed (%d)\n",
status);
kfree(work_data);
- rng->priv = 0;
atomic_dec(&i2c_priv->tfm_count);
return;
}
@@ -49,20 +48,19 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
- /* Verify if data available from last run */
if (rng->priv) {
work_data = (struct atmel_i2c_work_data *)rng->priv;
- max = min(sizeof(work_data->cmd.data), max);
- memcpy(data, &work_data->cmd.data, max);
+ max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
+ memcpy(data, &work_data->cmd.data[1], max);
- /* Now, free memory */
+ /* Free memory and clear the in-flight flag */
kfree(work_data);
rng->priv = 0;
atomic_dec(&i2c_priv->tfm_count);
return max;
}
- /* When a request is still in-flight but not processed */
+ /* If a request is still in-flight, return 0 (busy) */
if (atomic_read(&i2c_priv->tfm_count) > 0)
return 0;
@@ -76,8 +74,14 @@ static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
work_data->client = i2c_priv->client;
atmel_i2c_init_random_cmd(&work_data->cmd);
+
+ /* Set the execution time for the RNG command (from datasheet) */
+ work_data->cmd.msecs = ATMEL_RNG_EXEC_TIME;
+ work_data->cmd.rxsize = RANDOM_RSP_SIZE;
+
atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
+ /* Return 0 to indicate 'busy', data will be ready on next call */
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes
From: Lothar Rubusch @ 2026-04-22 21:09 UTC (permalink / raw)
To: herbert, thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel, l.rubusch
When testing the RNG functionality on the Atmel SHA204a hardware, I
found the following issues: rngtest reported failures and hexdump
reveiled only the first 8 bytes out of 32 provided actually entropy.
Having a closer look into it, I found a (small) memory leak, missing
to free work_data, miss-reading of the count field into the entropy
fields and parts of the 32 random bytes staying 0 due to reading the
slow i2c device.
The series proposes fixes and how fixed functionality can be/was
verified. Executing rngtest afterward showed a decent result, due
to the i2c bus a bit slow.
All setups require selecting the Atmel-sha204a as active RNG.
$ cat /sys/class/misc/hw_random/rng_available
3f104000.rng 1-0064 none
$ echo 1-0064 > /sys/class/misc/hw_random/rng_current
$ cat /sys/class/misc/hw_random/rng_current
1-0064
Testing RNG properties currently shows problematic results:
$ rngtest < /dev/hwrng
rngtest 2.6
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 1040032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 52
rngtest: FIPS 140-2(2001-10-10) Monobit: 52
rngtest: FIPS 140-2(2001-10-10) Poker: 52
rngtest: FIPS 140-2(2001-10-10) Runs: 52
rngtest: FIPS 140-2(2001-10-10) Long run: 52
rngtest: FIPS 140-2(2001-10-10) Continuous run: 52
rngtest: input channel speed: (min=7.631; avg=7.804; max=7.827)Kibits/s
rngtest: FIPS tests speed: (min=32.273; avg=32.701; max=33.056)Mibits/s
rngtest: Program run time: 130177956 microseconds
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
v2 -> v3: Removal blank line, rebased
v1 -> v2: Removal of C++ style comment (I saw it too late, sry for that)
---
Lothar Rubusch (3):
crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
crypto: atmel-sha204a - fix truncated 32-byte blocking read
crypto: atmel-sha204a - fix non-blocking read logic
drivers/crypto/atmel-sha204a.c | 60 ++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 21 deletions(-)
base-commit: 3bfbf5f0a99c991769ec562721285df7ab69240b
--
2.53.0
^ permalink raw reply
* [PATCH 2/2] remoteproc: xlnx: enable auto boot feature
From: Tanmay Shah @ 2026-04-22 20:25 UTC (permalink / raw)
To: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, tanmay.shah
Cc: linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422202558.2362971-1-tanmay.shah@amd.com>
remoteproc framework has capability to start (or attach to) the remote
processor automatically if auto boot flag is set by the driver during
probe. If remote core is not started before the Linux boot, and linux is
expected to start the remote core then it uses "firmware-name" property
to load default firmware during auto boot.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 49 +++++++++++++++++--------
1 file changed, 34 insertions(+), 15 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 50a9974f3202..c6ec8186b160 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
};
/**
- * zynqmp_r5_add_rproc_core() - Add core data to framework.
- * Allocate and add struct rproc object for each r5f core
+ * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
+ * Allocate struct rproc object for each r5f core
* This is called for each individual r5f core
*
* @cdev: Device node of each r5 core
*
* Return: zynqmp_r5_core object for success else error code pointer
*/
-static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
+static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
{
struct zynqmp_r5_core *r5_core;
+ const char *fw_name = NULL;
struct rproc *r5_rproc;
int ret;
@@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
if (ret)
return ERR_PTR(ret);
+ ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
+ if (ret < 0 && ret != -EINVAL)
+ return ERR_PTR(dev_err_probe(cdev, ret,
+ "failed to parse firmware-name\n"));
+
/* Allocate remoteproc instance */
r5_rproc = rproc_alloc(cdev, dev_name(cdev),
&zynqmp_r5_rproc_ops,
- NULL, sizeof(struct zynqmp_r5_core));
+ fw_name, sizeof(struct zynqmp_r5_core));
if (!r5_rproc) {
dev_err(cdev, "failed to allocate memory for rproc instance\n");
return ERR_PTR(-ENOMEM);
@@ -931,7 +937,7 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
r5_rproc->recovery_disabled = true;
r5_rproc->has_iommu = false;
- r5_rproc->auto_boot = false;
+ r5_rproc->auto_boot = of_property_read_bool(dev_of_node(cdev), "auto-boot");
r5_core = r5_rproc->priv;
r5_core->dev = cdev;
r5_core->np = dev_of_node(cdev);
@@ -941,13 +947,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
goto free_rproc;
}
- /* Add R5 remoteproc core */
- ret = rproc_add(r5_rproc);
- if (ret) {
- dev_err(cdev, "failed to add r5 remoteproc\n");
- goto free_rproc;
- }
-
/*
* If firmware is already available in the memory then move rproc state
* to DETACHED. Firmware can be preloaded via debugger or by any other
@@ -958,6 +957,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
if (!zynqmp_r5_get_rsc_table_va(r5_core))
r5_rproc->state = RPROC_DETACHED;
+ dev_dbg(cdev, "auto boot %s, rproc state %s, fw-name = %s\n",
+ r5_rproc->auto_boot ? "enabled" : "disabled",
+ (r5_rproc->state == RPROC_DETACHED) ? "detached" : "offline",
+ !fw_name ? "NULL" : fw_name);
+
r5_core->rproc = r5_rproc;
return r5_core;
@@ -1278,7 +1282,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
enum rpu_oper_mode fw_reg_val;
struct device **child_devs;
enum rpu_tcm_comb tcm_mode;
- int core_count, ret, i;
+ int core_count, ret, i, j;
struct mbox_info *ipi;
ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
@@ -1364,7 +1368,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
child_devs[i] = &child_pdev->dev;
/* create and add remoteproc instance of type struct rproc */
- r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
+ r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
if (IS_ERR(r5_cores[i])) {
ret = PTR_ERR(r5_cores[i]);
r5_cores[i] = NULL;
@@ -1409,6 +1413,22 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
goto release_r5_cores;
}
+ for (j = 0; j < cluster->core_count; j++) {
+ /* Add R5 remoteproc core */
+ ret = rproc_add(r5_cores[j]->rproc);
+ if (ret) {
+ dev_err_probe(r5_cores[j]->dev, ret,
+ "failed to add emoteproc\n");
+ i = core_count - 1;
+
+ /* delete previous added rproc */
+ while (--j >= 0)
+ rproc_del(r5_cores[j]->rproc);
+
+ goto release_r5_cores;
+ }
+ }
+
kfree(child_devs);
return 0;
@@ -1418,7 +1438,6 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
if (r5_cores[i]) {
zynqmp_r5_free_mbox(r5_cores[i]->ipi);
of_reserved_mem_device_release(r5_cores[i]->dev);
- rproc_del(r5_cores[i]->rproc);
rproc_free(r5_cores[i]->rproc);
}
i--;
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] remoteproc: xlnx: add auto-boot support
From: Tanmay Shah @ 2026-04-22 20:25 UTC (permalink / raw)
To: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, tanmay.shah
Cc: linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
The Cortex-R remote processors on AMD-Xilinx platforms can run
before linux boot. Add auto-boot property to notify linux that remote
processor is ready to be used, so linux can load fw and start it or
attach to the running processor.
Tanmay Shah (2):
dt-bindings: remoteproc: xlnx: add auto boot feature
remoteproc: xlnx: enable auto boot feature
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 8 +++
drivers/remoteproc/xlnx_r5_remoteproc.c | 49 +++++++++++++------
2 files changed, 42 insertions(+), 15 deletions(-)
base-commit: 6f860d238b44da8ac57be25289b9f4410691c4e2
--
2.34.1
^ permalink raw reply
* [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature
From: Tanmay Shah @ 2026-04-22 20:25 UTC (permalink / raw)
To: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, tanmay.shah
Cc: linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422202558.2362971-1-tanmay.shah@amd.com>
Add auto-boot property to notify that remote processor is setup and
ready to boot. Linux can attempt to boot or attach to already running
remote processor. "firmware-name" property is used to mention default
firmware to boot when linux starts the remote processor.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
.../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index ee63c03949c9..0d27260e3baa 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -135,6 +135,14 @@ patternProperties:
- description: vring1
additionalItems: true
+ auto-boot:
+ type: boolean
+ description: remote core is either already running or ready to boot
+
+ firmware-name:
+ maxItems: 1
+ description: default firmware to load
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v2] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA Olympus
From: Besar Wicaksono @ 2026-04-22 20:17 UTC (permalink / raw)
To: James Clark, will@kernel.org, mark.rutland@arm.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
Thierry Reding, Jon Hunter, Vikram Sethi, Rich Wiley,
Shanker Donthineni, Matt Ochs, Nirmoy Das, Sean Kelley
In-Reply-To: <b1458bc3-0449-4f0f-b346-d25547dd4c97@linaro.org>
> -----Original Message-----
> From: James Clark <james.clark@linaro.org>
> Sent: Wednesday, April 22, 2026 5:33 AM
> To: Besar Wicaksono <bwicaksono@nvidia.com>; will@kernel.org;
> mark.rutland@arm.com
> Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> tegra@vger.kernel.org; Thierry Reding <treding@nvidia.com>; Jon Hunter
> <jonathanh@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; Rich Wiley
> <rwiley@nvidia.com>; Shanker Donthineni <sdonthineni@nvidia.com>; Matt
> Ochs <mochs@nvidia.com>; Nirmoy Das <nirmoyd@nvidia.com>; Sean Kelley
> <skelley@nvidia.com>
> Subject: Re: [PATCH v2] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA
> Olympus
>
> External email: Use caution opening links or attachments
>
>
> On 21/04/2026 21:38, Besar Wicaksono wrote:
> > The PMCCNTR_EL0 in NVIDIA Olympus CPU may increment while
> > in WFI/WFE, which does not align with counting CPU_CYCLES
> > on a programmable counter. Add a MIDR range entry and
> > refuse PMCCNTR_EL0 for cycle events on affected parts so
> > perf does not mix the two behaviors.
> >
> > Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
> > ---
> >
> > Changes from v1:
> > * add CONFIG_ARM64 check to fix build error found by kernel test robot
> > * add explicit include of <asm/cputype.h>
> > v1: https://lore.kernel.org/linux-arm-kernel/20260406232034.2566133-1-
> bwicaksono@nvidia.com/
> >
> > ---
> > drivers/perf/arm_pmuv3.c | 44
> ++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 44 insertions(+)
> >
> > diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> > index 8014ff766cff..7c39d0804b9f 100644
> > --- a/drivers/perf/arm_pmuv3.c
> > +++ b/drivers/perf/arm_pmuv3.c
> > @@ -8,6 +8,7 @@
> > * This code is based heavily on the ARMv7 perf event code.
> > */
> >
> > +#include <asm/cputype.h>
> > #include <asm/irq_regs.h>
> > #include <asm/perf_event.h>
> > #include <asm/virt.h>
> > @@ -978,6 +979,41 @@ static int armv8pmu_get_chain_idx(struct
> pmu_hw_events *cpuc,
> > return -EAGAIN;
> > }
> >
> > +#ifdef CONFIG_ARM64
> > +/*
> > + * List of CPUs that should avoid using PMCCNTR_EL0.
> > + */
> > +static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
> > + /*
> > + * The PMCCNTR_EL0 in Olympus CPU may still increment while in
> WFI/WFE state.
> > + * This is an implementation specific behavior and not an erratum.
> > + *
> > + * From ARM DDI0487 D14.4:
> > + * It is IMPLEMENTATION SPECIFIC whether CPU_CYCLES and PMCCNTR
> count
> > + * when the PE is in WFI or WFE state, even if the clocks are not stopped.
> > + *
> > + * From ARM DDI0487 D24.5.2:
> > + * All counters are subject to any changes in clock frequency, including
> > + * clock stopping caused by the WFI and WFE instructions.
> > + * This means that it is CONSTRAINED UNPREDICTABLE whether or not
> > + * PMCCNTR_EL0 continues to increment when clocks are stopped by
> WFI and
> > + * WFE instructions.
> > + */
> > + MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
> > + {}
> > +};
> > +
> > +static bool armv8pmu_is_in_avoid_pmccntr_cpus(void)
> > +{
> > + return is_midr_in_range_list(armv8pmu_avoid_pmccntr_cpus);
> > +}
> > +#else
> > +static bool armv8pmu_is_in_avoid_pmccntr_cpus(void)
> > +{
> > + return false;
> > +}
> > +#endif
> > +
> > static bool armv8pmu_can_use_pmccntr(struct pmu_hw_events *cpuc,
> > struct perf_event *event)
> > {
> > @@ -1011,6 +1047,14 @@ static bool armv8pmu_can_use_pmccntr(struct
> pmu_hw_events *cpuc,
> > if (cpu_pmu->has_smt)
> > return false;
> >
> > + /*
> > + * On some CPUs, PMCCNTR_EL0 does not match the behavior of
> CPU_CYCLES
> > + * programmable counter, so avoid routing cycles through PMCCNTR_EL0
> to
> > + * prevent inconsistency in the results.
> > + */
> > + if (armv8pmu_is_in_avoid_pmccntr_cpus())
> > + return false;
> > +
>
> Hi Besar,
>
> This is called from armpmu_event_init() before the event is scheduled on
> the CPU so I don't think reading the MIDR at this point is safe.
>
> When the PMU is probed you probably need to do an SMP call to get the
> MIDR of CPUs in that PMU's mask and then cache the "avoid pmccntr"
> result like has_smt. Or even rename has_smt to avoid_pmccntr and combine
> the two results there.
>
> I don't know what will happen if none of those CPUs are online when the
> PMU is probed though...
>
Hi James,
has_smt, iiuc, is common to all the supported CPUs of the PMU context.
It is configured based on the first CPU in supported cpu list.
pmu->has_smt = topology_core_has_smt(cpumask_first(&pmu->supported_cpus));
Is it okay to use same approach? Can we assume all CPUs in supported_cpus have same midr?
Thanks,
Besar
^ 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