* [PATCH v3 3/3] iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
Replace multiple open-coded switch statements that map between
scan_index, alarm bits, and register offsets with a centralized
table-driven approach.
Introduce a struct-based alarm_map to describe the relationship
between scan indices and alarm offsets, and add a helper to
translate scan_index to event IDs. This removes duplicated logic
across ams_get_alarm_offset(), ams_event_to_channel(), and
ams_get_alarm_mask().
The new approach improves maintainability, reduces code size,
and makes it easier to extend or modify alarm mappings in the
future, while preserving existing behavior.
Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
---
drivers/iio/adc/xilinx-ams.c | 161 +++++++++++++----------------------
1 file changed, 58 insertions(+), 103 deletions(-)
diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 70a1f97f6dad..2ce78883cead 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -102,6 +102,7 @@
#define AMS_PS_SEQ_MASK GENMASK(21, 0)
#define AMS_PL_SEQ_MASK GENMASK_ULL(59, 22)
+#define AMS_ALARM_NONE 0x000 /* not a real offset */
#define AMS_ALARM_TEMP 0x140
#define AMS_ALARM_SUPPLY1 0x144
#define AMS_ALARM_SUPPLY2 0x148
@@ -763,9 +764,49 @@ static int ams_read_raw(struct iio_dev *indio_dev,
}
}
+struct ams_alarm_map {
+ enum ams_ps_pl_seq scan_index;
+ unsigned int base_offset;
+};
+
+/*
+ * Array index matches enum ams_alarm_bit.
+ * Entries with base_offset == AMS_ALARM_NONE are unused/invalid
+ * (e.g. RESERVED) and must be skipped.
+ */
+static const struct ams_alarm_map alarm_map[] = {
+ [AMS_ALARM_BIT_TEMP] = { AMS_SEQ_TEMP, AMS_ALARM_TEMP },
+ [AMS_ALARM_BIT_SUPPLY1] = { AMS_SEQ_SUPPLY1, AMS_ALARM_SUPPLY1 },
+ [AMS_ALARM_BIT_SUPPLY2] = { AMS_SEQ_SUPPLY2, AMS_ALARM_SUPPLY2 },
+ [AMS_ALARM_BIT_SUPPLY3] = { AMS_SEQ_SUPPLY3, AMS_ALARM_SUPPLY3 },
+ [AMS_ALARM_BIT_SUPPLY4] = { AMS_SEQ_SUPPLY4, AMS_ALARM_SUPPLY4 },
+ [AMS_ALARM_BIT_SUPPLY5] = { AMS_SEQ_SUPPLY5, AMS_ALARM_SUPPLY5 },
+ [AMS_ALARM_BIT_SUPPLY6] = { AMS_SEQ_SUPPLY6, AMS_ALARM_SUPPLY6 },
+ [AMS_ALARM_BIT_RESERVED] = { 0, AMS_ALARM_NONE },
+ [AMS_ALARM_BIT_SUPPLY7] = { AMS_SEQ_SUPPLY7, AMS_ALARM_SUPPLY7 },
+ [AMS_ALARM_BIT_SUPPLY8] = { AMS_SEQ_SUPPLY8, AMS_ALARM_SUPPLY8 },
+ [AMS_ALARM_BIT_SUPPLY9] = { AMS_SEQ_SUPPLY9, AMS_ALARM_SUPPLY9 },
+ [AMS_ALARM_BIT_SUPPLY10] = { AMS_SEQ_SUPPLY10, AMS_ALARM_SUPPLY10 },
+ [AMS_ALARM_BIT_VCCAMS] = { AMS_SEQ_VCCAMS, AMS_ALARM_VCCAMS },
+ [AMS_ALARM_BIT_TEMP_REMOTE] = { AMS_SEQ_TEMP_REMOTE, AMS_ALARM_TEMP_REMOTE },
+};
+
+static int ams_scan_index_to_event(int scan_index)
+{
+ for (unsigned int i = 0; i < ARRAY_SIZE(alarm_map); i++) {
+ if (alarm_map[i].base_offset == AMS_ALARM_NONE)
+ continue;
+
+ if (alarm_map[i].scan_index == scan_index)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
static int ams_get_alarm_offset(int scan_index, enum iio_event_direction dir)
{
- int offset;
+ int offset, event;
if (scan_index >= AMS_PS_SEQ_MAX)
scan_index -= AMS_PS_SEQ_MAX;
@@ -779,36 +820,11 @@ static int ams_get_alarm_offset(int scan_index, enum iio_event_direction dir)
offset = 0;
}
- switch (scan_index) {
- case AMS_SEQ_TEMP:
- return AMS_ALARM_TEMP + offset;
- case AMS_SEQ_SUPPLY1:
- return AMS_ALARM_SUPPLY1 + offset;
- case AMS_SEQ_SUPPLY2:
- return AMS_ALARM_SUPPLY2 + offset;
- case AMS_SEQ_SUPPLY3:
- return AMS_ALARM_SUPPLY3 + offset;
- case AMS_SEQ_SUPPLY4:
- return AMS_ALARM_SUPPLY4 + offset;
- case AMS_SEQ_SUPPLY5:
- return AMS_ALARM_SUPPLY5 + offset;
- case AMS_SEQ_SUPPLY6:
- return AMS_ALARM_SUPPLY6 + offset;
- case AMS_SEQ_SUPPLY7:
- return AMS_ALARM_SUPPLY7 + offset;
- case AMS_SEQ_SUPPLY8:
- return AMS_ALARM_SUPPLY8 + offset;
- case AMS_SEQ_SUPPLY9:
- return AMS_ALARM_SUPPLY9 + offset;
- case AMS_SEQ_SUPPLY10:
- return AMS_ALARM_SUPPLY10 + offset;
- case AMS_SEQ_VCCAMS:
- return AMS_ALARM_VCCAMS + offset;
- case AMS_SEQ_TEMP_REMOTE:
- return AMS_ALARM_TEMP_REMOTE + offset;
- default:
+ event = ams_scan_index_to_event(scan_index);
+ if (event < 0 || alarm_map[event].base_offset == AMS_ALARM_NONE)
return 0;
- }
+
+ return alarm_map[event].base_offset + offset;
}
static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
@@ -821,49 +837,13 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
scan_index = AMS_PS_SEQ_MAX;
}
- switch (event) {
- case AMS_ALARM_BIT_TEMP:
- scan_index += AMS_SEQ_TEMP;
- break;
- case AMS_ALARM_BIT_SUPPLY1:
- scan_index += AMS_SEQ_SUPPLY1;
- break;
- case AMS_ALARM_BIT_SUPPLY2:
- scan_index += AMS_SEQ_SUPPLY2;
- break;
- case AMS_ALARM_BIT_SUPPLY3:
- scan_index += AMS_SEQ_SUPPLY3;
- break;
- case AMS_ALARM_BIT_SUPPLY4:
- scan_index += AMS_SEQ_SUPPLY4;
- break;
- case AMS_ALARM_BIT_SUPPLY5:
- scan_index += AMS_SEQ_SUPPLY5;
- break;
- case AMS_ALARM_BIT_SUPPLY6:
- scan_index += AMS_SEQ_SUPPLY6;
- break;
- case AMS_ALARM_BIT_SUPPLY7:
- scan_index += AMS_SEQ_SUPPLY7;
- break;
- case AMS_ALARM_BIT_SUPPLY8:
- scan_index += AMS_SEQ_SUPPLY8;
- break;
- case AMS_ALARM_BIT_SUPPLY9:
- scan_index += AMS_SEQ_SUPPLY9;
- break;
- case AMS_ALARM_BIT_SUPPLY10:
- scan_index += AMS_SEQ_SUPPLY10;
- break;
- case AMS_ALARM_BIT_VCCAMS:
- scan_index += AMS_SEQ_VCCAMS;
- break;
- case AMS_ALARM_BIT_TEMP_REMOTE:
- scan_index += AMS_SEQ_TEMP_REMOTE;
- break;
- default:
- break;
- }
+ if (event < 0 || event >= ARRAY_SIZE(alarm_map))
+ return NULL;
+
+ if (alarm_map[event].base_offset == AMS_ALARM_NONE)
+ return NULL;
+
+ scan_index += alarm_map[event].scan_index;
for (i = 0; i < dev->num_channels; i++)
if (dev->channels[i].scan_index == scan_index)
@@ -877,43 +857,18 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
static int ams_get_alarm_mask(int scan_index)
{
- int bit = 0;
+ int bit = 0, event;
if (scan_index >= AMS_PS_SEQ_MAX) {
bit = AMS_PL_ALARM_START;
scan_index -= AMS_PS_SEQ_MAX;
}
- switch (scan_index) {
- case AMS_SEQ_TEMP:
- return BIT(AMS_ALARM_BIT_TEMP + bit);
- case AMS_SEQ_SUPPLY1:
- return BIT(AMS_ALARM_BIT_SUPPLY1 + bit);
- case AMS_SEQ_SUPPLY2:
- return BIT(AMS_ALARM_BIT_SUPPLY2 + bit);
- case AMS_SEQ_SUPPLY3:
- return BIT(AMS_ALARM_BIT_SUPPLY3 + bit);
- case AMS_SEQ_SUPPLY4:
- return BIT(AMS_ALARM_BIT_SUPPLY4 + bit);
- case AMS_SEQ_SUPPLY5:
- return BIT(AMS_ALARM_BIT_SUPPLY5 + bit);
- case AMS_SEQ_SUPPLY6:
- return BIT(AMS_ALARM_BIT_SUPPLY6 + bit);
- case AMS_SEQ_SUPPLY7:
- return BIT(AMS_ALARM_BIT_SUPPLY7 + bit);
- case AMS_SEQ_SUPPLY8:
- return BIT(AMS_ALARM_BIT_SUPPLY8 + bit);
- case AMS_SEQ_SUPPLY9:
- return BIT(AMS_ALARM_BIT_SUPPLY9 + bit);
- case AMS_SEQ_SUPPLY10:
- return BIT(AMS_ALARM_BIT_SUPPLY10 + bit);
- case AMS_SEQ_VCCAMS:
- return BIT(AMS_ALARM_BIT_VCCAMS + bit);
- case AMS_SEQ_TEMP_REMOTE:
- return BIT(AMS_ALARM_BIT_TEMP_REMOTE + bit);
- default:
+ event = ams_scan_index_to_event(scan_index);
+ if (event < 0)
return 0;
- }
+
+ return BIT(event + bit);
}
static int ams_read_event_config(struct iio_dev *indio_dev,
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/3] iio: adc: xilinx-ams: use guard(mutex) for automatic locking
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi,
Andy Shevchenko
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
Replace open-coded mutex_lock()/mutex_unlock() pairs with
guard(mutex) to simplify locking and ensure proper unlock on
all control flow paths.
This removes explicit unlock handling, reduces boilerplate,
and avoids potential mistakes in error paths while keeping
the behavior unchanged.
Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
drivers/iio/adc/xilinx-ams.c | 24 ++++++++----------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 6191cd1b29a5..70a1f97f6dad 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -720,22 +720,20 @@ static int ams_read_raw(struct iio_dev *indio_dev,
int ret;
switch (mask) {
- case IIO_CHAN_INFO_RAW:
- mutex_lock(&ams->lock);
+ case IIO_CHAN_INFO_RAW: {
+ guard(mutex)(&ams->lock);
if (chan->scan_index >= AMS_CTRL_SEQ_BASE) {
ret = ams_read_vcc_reg(ams, chan->address, val);
if (ret)
- goto unlock_mutex;
+ return ret;
ams_enable_channel_sequence(indio_dev);
} else if (chan->scan_index >= AMS_PS_SEQ_MAX)
*val = readl(ams->pl_base + chan->address);
else
*val = readl(ams->ps_base + chan->address);
- ret = IIO_VAL_INT;
-unlock_mutex:
- mutex_unlock(&ams->lock);
- return ret;
+ return IIO_VAL_INT;
+ }
case IIO_CHAN_INFO_SCALE:
switch (chan->type) {
case IIO_VOLTAGE:
@@ -939,7 +937,7 @@ static int ams_write_event_config(struct iio_dev *indio_dev,
alarm = ams_get_alarm_mask(chan->scan_index);
- mutex_lock(&ams->lock);
+ guard(mutex)(&ams->lock);
if (state)
ams->alarm_mask |= alarm;
@@ -948,8 +946,6 @@ static int ams_write_event_config(struct iio_dev *indio_dev,
ams_update_alarm(ams, ams->alarm_mask);
- mutex_unlock(&ams->lock);
-
return 0;
}
@@ -962,15 +958,13 @@ static int ams_read_event_value(struct iio_dev *indio_dev,
struct ams *ams = iio_priv(indio_dev);
unsigned int offset = ams_get_alarm_offset(chan->scan_index, dir);
- mutex_lock(&ams->lock);
+ guard(mutex)(&ams->lock);
if (chan->scan_index >= AMS_PS_SEQ_MAX)
*val = readl(ams->pl_base + offset);
else
*val = readl(ams->ps_base + offset);
- mutex_unlock(&ams->lock);
-
return IIO_VAL_INT;
}
@@ -983,7 +977,7 @@ static int ams_write_event_value(struct iio_dev *indio_dev,
struct ams *ams = iio_priv(indio_dev);
unsigned int offset;
- mutex_lock(&ams->lock);
+ guard(mutex)(&ams->lock);
/* Set temperature channel threshold to direct threshold */
if (chan->type == IIO_TEMP) {
@@ -1005,8 +999,6 @@ static int ams_write_event_value(struct iio_dev *indio_dev,
else
writel(val, ams->ps_base + offset);
- mutex_unlock(&ams->lock);
-
return 0;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/3] iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
ams_event_to_channel() may return a pointer past the end of
dev->channels when no matching scan_index is found. This can lead
to invalid memory access in ams_handle_event().
Add a bounds check in ams_event_to_channel() and return NULL when
no channel is found. Also guard the caller to safely handle this
case.
Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
---
drivers/iio/adc/xilinx-ams.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 124470c92529..6191cd1b29a5 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -871,6 +871,9 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
if (dev->channels[i].scan_index == scan_index)
break;
+ if (i == dev->num_channels)
+ return NULL;
+
return &dev->channels[i];
}
@@ -1012,6 +1015,8 @@ static void ams_handle_event(struct iio_dev *indio_dev, u32 event)
const struct iio_chan_spec *chan;
chan = ams_event_to_channel(indio_dev, event);
+ if (!chan)
+ return;
if (chan->type == IIO_TEMP) {
/*
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi
This series addresses significant code duplication in alarm handling
logic across the Xilinx AMS IIO driver.
To address this, the series introduces a centralized table-driven
mapping (alarm_map) that replaces multiple switch statements spread
across the driver.
This improves:
- maintainability (single source of truth for mappings)
- readability (removes repeated switch logic)
- extensibility (new alarms require only table updates)
No functional changes are intended.
Series overview:
- Patch 1: fix out-of-bounds channel lookup
- Patch 2: convert mutex handling to guard(mutex)
- Patch 3: introduce table-driven alarm mapping
v1 -> v2:
- Fixed Fixes tag format
- Replaced AMS_ALARM_INVALID with AMS_ALARM_NONE
- Changed alarm_map base_offset type
v2 -> v3:
- Replace 'i >= num_channels' with 'i == num_channels'
- Add missing trailing comma in alarm_map array initializer
Guilherme Ivo Bozi (3):
iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event
handling
iio: adc: xilinx-ams: use guard(mutex) for automatic locking
iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
drivers/iio/adc/xilinx-ams.c | 190 +++++++++++++----------------------
1 file changed, 71 insertions(+), 119 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH v2 2/4] KVM: arm64: sefltests: Add helpers for guest hypervisors
From: Itaru Kitayama @ 2026-04-14 22:14 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, kvm, linux-kselftest, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Shuah Khan
In-Reply-To: <20260412142216.3806482-3-weilin.chang@arm.com>
On Sun, Apr 12, 2026 at 03:22:14PM +0100, Wei-Lin Chang wrote:
> Add helpers so that guest hypervisors can run nested guests. SP_EL1
> save/restore is added to allow nested guests to use a stack.
>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> .../selftests/kvm/include/arm64/nested.h | 17 +++++++
> tools/testing/selftests/kvm/lib/arm64/entry.S | 5 ++
> .../testing/selftests/kvm/lib/arm64/nested.c | 46 +++++++++++++++++++
> 3 files changed, 68 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
> index 86d931facacb..7928ef89494a 100644
> --- a/tools/testing/selftests/kvm/include/arm64/nested.h
> +++ b/tools/testing/selftests/kvm/include/arm64/nested.h
> @@ -21,8 +21,17 @@
>
> extern char hyp_vectors[];
>
> +enum vcpu_sysreg {
> + __INVALID_SYSREG__, /* 0 is reserved as an invalid value */
> +
> + SP_EL1,
> +
> + NR_SYS_REGS
> +};
> +
> struct cpu_context {
> struct user_pt_regs regs; /* sp = sp_el0 */
> + u64 sys_regs[NR_SYS_REGS];
> };
>
> struct vcpu {
> @@ -37,9 +46,17 @@ struct hyp_data {
> struct cpu_context hyp_context;
> };
I am not sure of these structs you introduced only for nested guest feature
testing, as the KVM arm64 code they are quite complex and involved,
extracring part of those and add members as hello_nested or simliar
tests evolve, then add test cases to me seems fragile.
But if you have strong reason to add these would you mind explaining a bit?
Thanks,
Itaru.
>
> +void prepare_hyp(void);
> +void init_vcpu(struct vcpu *vcpu, vm_paddr_t l2_pc, vm_paddr_t l2_stack_top);
> +int run_l2(struct vcpu *vcpu, struct hyp_data *hyp_data);
> +
> +void do_hvc(void);
> u64 __guest_enter(struct vcpu *vcpu, struct cpu_context *hyp_context);
> void __hyp_exception(u64 type);
>
> +void __sysreg_save_el1_state(struct cpu_context *ctxt);
> +void __sysreg_restore_el1_state(struct cpu_context *ctxt);
> +
> #endif /* !__ASSEMBLER__ */
>
> #endif /* SELFTEST_KVM_NESTED_H */
> diff --git a/tools/testing/selftests/kvm/lib/arm64/entry.S b/tools/testing/selftests/kvm/lib/arm64/entry.S
> index 33bedf5e7fb2..df3af3463c6c 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/entry.S
> +++ b/tools/testing/selftests/kvm/lib/arm64/entry.S
> @@ -3,6 +3,11 @@
> * adapted from arch/arm64/kvm/hyp/entry.S
> */
>
> + .globl do_hvc
> + do_hvc:
> + hvc #0
> + ret
> +
> /*
> * Manually define these for now
> */
> diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
> index 06ddaab2436f..b30d20b101c4 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/nested.c
> +++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
> @@ -4,7 +4,53 @@
> */
>
> #include "nested.h"
> +#include "processor.h"
> #include "test_util.h"
> +#include <asm/sysreg.h>
> +
> +void prepare_hyp(void)
> +{
> + write_sysreg(HCR_EL2_E2H | HCR_EL2_RW, hcr_el2);
> + write_sysreg(hyp_vectors, vbar_el2);
> + isb();
> +}
> +
> +void init_vcpu(struct vcpu *vcpu, vm_paddr_t l2_pc, vm_paddr_t l2_stack_top)
> +{
> + memset(vcpu, 0, sizeof(*vcpu));
> + vcpu->context.regs.pc = l2_pc;
> + vcpu->context.regs.pstate = PSR_MODE_EL1h | PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT;
> + vcpu->context.sys_regs[SP_EL1] = l2_stack_top;
> +}
> +
> +void __sysreg_save_el1_state(struct cpu_context *ctxt)
> +{
> + ctxt->sys_regs[SP_EL1] = read_sysreg(sp_el1);
> +}
> +
> +void __sysreg_restore_el1_state(struct cpu_context *ctxt)
> +{
> + write_sysreg(ctxt->sys_regs[SP_EL1], sp_el1);
> +}
> +
> +int run_l2(struct vcpu *vcpu, struct hyp_data *hyp_data)
> +{
> + u64 ret;
> +
> + __sysreg_restore_el1_state(&vcpu->context);
> +
> + write_sysreg(vcpu->context.regs.pstate, spsr_el2);
> + write_sysreg(vcpu->context.regs.pc, elr_el2);
> +
> + ret = __guest_enter(vcpu, &hyp_data->hyp_context);
> +
> + vcpu->context.regs.pc = read_sysreg(elr_el2);
> + vcpu->context.regs.pstate = read_sysreg(spsr_el2);
> +
> + __sysreg_save_el1_state(&vcpu->context);
> +
> + return ret;
> +}
>
> void __hyp_exception(u64 type)
> {
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 3/4] KVM: arm64: sefltests: Add basic NV selftest
From: Itaru Kitayama @ 2026-04-14 22:05 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, kvm, linux-kselftest, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Shuah Khan
In-Reply-To: <xsdf2k2u4g6n7nmxcgwhiraqodwtteuxqqtnj2dx5sxgu74a7j@yjijkyohkq4i>
On Tue, Apr 14, 2026 at 11:16:47AM +0100, Wei-Lin Chang wrote:
> On Tue, Apr 14, 2026 at 06:31:22AM +0900, Itaru Kitayama wrote:
> > On Mon, Apr 13, 2026 at 10:18:42AM +0100, Wei-Lin Chang wrote:
> > > Hi Itaru,
> > >
> > > On Mon, Apr 13, 2026 at 08:19:25AM +0900, Itaru Kitayama wrote:
> > > > On Sun, Apr 12, 2026 at 03:22:15PM +0100, Wei-Lin Chang wrote:
> > > > > This selftest simply starts an L1, which starts its own guest (L2). L2
> > > > > runs without stage-1 and 2 translations, it calls an HVC to jump back
> > > > > to L1.
> > > >
> > > > How do you disable both the nested guest (L2)'s MMU and stage 2
> > > > translations?
> > >
> > > Guest stage-2 is disabled by not setting HCR_EL2.VM in prepare_hyp(),
> > > and stage-1 is disabled by not writing to SCTLR_EL12 in init_vcpu(),
> > > effectively using the default value set by L0. However since SCTLR_EL1
> > > has many architecturally UNKNOWN bits (including SCTLR_EL1.M), it should
> > > be better to write a value before running L2 I suppose...
> >
> > Thanks. What do you think of using copy_el2_to_el1() macro in at.c, so we
> > can prepare in guest_code() to manipulate the SCTLR_EL12 System register
> > with the sensible programmed values?
>
> Yes, using copy_el2_to_el1() can give us an L2 stage-1 that is identical
> to the L1's stage-1. But what I was considering was if guest stage-2 is
> enabled (which we plan to implement), then those stage-1 page tables
> will have to be mapped for L2, and its base address translated to L2IPA.
> It's doable but seems like extra complexity when stage-1 is not so
> interesting for KVM (except for AT?), it lets the guest do whatever it
> likes and let the hardware do the translation.
>
> Let me know if you have reasons to want stage-1 for L2, there could be
> something I should consider but did not.
By keeping nested guest's MMU enabled, we can exercise the shadow stage
2 on the host. But I am fine with you starting nested guest's IPA and I
hope Marc and Oliver approve this seris and merge upstream.
Thanks,
Itaru.
>
> Thanks,
> Wei-Lin Chang
>
> >
> > Itaru.
> >
> > >
> > > Thanks,
> > > Wei-Lin Chang
> > >
> > > >
> > > > Itaru.
> > > >
> > > > >
> > > > > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > > > > ---
> > > > > tools/testing/selftests/kvm/Makefile.kvm | 1 +
> > > > > .../selftests/kvm/arm64/hello_nested.c | 103 ++++++++++++++++++
> > > > > 2 files changed, 104 insertions(+)
> > > > > create mode 100644 tools/testing/selftests/kvm/arm64/hello_nested.c
> > > > >
> > > > > diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> > > > > index 3dc3e39f7025..e8c108e0c487 100644
> > > > > --- a/tools/testing/selftests/kvm/Makefile.kvm
> > > > > +++ b/tools/testing/selftests/kvm/Makefile.kvm
> > > > > @@ -168,6 +168,7 @@ TEST_GEN_PROGS_arm64 += arm64/arch_timer_edge_cases
> > > > > TEST_GEN_PROGS_arm64 += arm64/at
> > > > > TEST_GEN_PROGS_arm64 += arm64/debug-exceptions
> > > > > TEST_GEN_PROGS_arm64 += arm64/hello_el2
> > > > > +TEST_GEN_PROGS_arm64 += arm64/hello_nested
> > > > > TEST_GEN_PROGS_arm64 += arm64/host_sve
> > > > > TEST_GEN_PROGS_arm64 += arm64/hypercalls
> > > > > TEST_GEN_PROGS_arm64 += arm64/external_aborts
> > > > > diff --git a/tools/testing/selftests/kvm/arm64/hello_nested.c b/tools/testing/selftests/kvm/arm64/hello_nested.c
> > > > > new file mode 100644
> > > > > index 000000000000..97387e4697b3
> > > > > --- /dev/null
> > > > > +++ b/tools/testing/selftests/kvm/arm64/hello_nested.c
> > > > > @@ -0,0 +1,103 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > +/*
> > > > > + * hello_nested - Go from vEL2 to EL1 then back
> > > > > + */
> > > > > +
> > > > > +#include "nested.h"
> > > > > +#include "processor.h"
> > > > > +#include "test_util.h"
> > > > > +#include "ucall.h"
> > > > > +
> > > > > +#define XLATE2GPA (0xABCD)
> > > > > +#define L2STACKSZ (0x100)
> > > > > +
> > > > > +/*
> > > > > + * TPIDR_EL2 is used to store vcpu id, so save and restore it.
> > > > > + */
> > > > > +static vm_paddr_t ucall_translate_to_gpa(void *gva)
> > > > > +{
> > > > > + vm_paddr_t gpa;
> > > > > + u64 vcpu_id = read_sysreg(tpidr_el2);
> > > > > +
> > > > > + GUEST_SYNC2(XLATE2GPA, gva);
> > > > > +
> > > > > + /* get the result from userspace */
> > > > > + gpa = read_sysreg(tpidr_el2);
> > > > > +
> > > > > + write_sysreg(vcpu_id, tpidr_el2);
> > > > > +
> > > > > + return gpa;
> > > > > +}
> > > > > +
> > > > > +static void l2_guest_code(void)
> > > > > +{
> > > > > + do_hvc();
> > > > > +}
> > > > > +
> > > > > +static void guest_code(void)
> > > > > +{
> > > > > + struct vcpu vcpu;
> > > > > + struct hyp_data hyp_data;
> > > > > + int ret;
> > > > > + vm_paddr_t l2_pc, l2_stack_top;
> > > > > + /* force 16-byte alignment for the stack pointer */
> > > > > + u8 l2_stack[L2STACKSZ] __attribute__((aligned(16)));
> > > > > +
> > > > > + GUEST_ASSERT_EQ(get_current_el(), 2);
> > > > > + GUEST_PRINTF("vEL2 entry\n");
> > > > > +
> > > > > + l2_pc = ucall_translate_to_gpa(l2_guest_code);
> > > > > + l2_stack_top = ucall_translate_to_gpa(&l2_stack[L2STACKSZ]);
> > > > > +
> > > > > + init_vcpu(&vcpu, l2_pc, l2_stack_top);
> > > > > + prepare_hyp();
> > > > > +
> > > > > + ret = run_l2(&vcpu, &hyp_data);
> > > > > + GUEST_ASSERT_EQ(ret, ARM_EXCEPTION_TRAP);
> > > > > + GUEST_DONE();
> > > > > +}
> > > > > +
> > > > > +int main(void)
> > > > > +{
> > > > > + struct kvm_vcpu_init init;
> > > > > + struct kvm_vcpu *vcpu;
> > > > > + struct kvm_vm *vm;
> > > > > + struct ucall uc;
> > > > > + vm_paddr_t gpa;
> > > > > +
> > > > > + TEST_REQUIRE(kvm_check_cap(KVM_CAP_ARM_EL2));
> > > > > + vm = vm_create(1);
> > > > > +
> > > > > + kvm_get_default_vcpu_target(vm, &init);
> > > > > + init.features[0] |= BIT(KVM_ARM_VCPU_HAS_EL2);
> > > > > + vcpu = aarch64_vcpu_add(vm, 0, &init, guest_code);
> > > > > + kvm_arch_vm_finalize_vcpus(vm);
> > > > > +
> > > > > + while (true) {
> > > > > + vcpu_run(vcpu);
> > > > > +
> > > > > + switch (get_ucall(vcpu, &uc)) {
> > > > > + case UCALL_SYNC:
> > > > > + if (uc.args[0] == XLATE2GPA) {
> > > > > + gpa = addr_gva2gpa(vm, (vm_vaddr_t)uc.args[1]);
> > > > > + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_TPIDR_EL2), gpa);
> > > > > + }
> > > > > + break;
> > > > > + case UCALL_PRINTF:
> > > > > + pr_info("%s", uc.buffer);
> > > > > + break;
> > > > > + case UCALL_DONE:
> > > > > + pr_info("DONE!\n");
> > > > > + goto end;
> > > > > + case UCALL_ABORT:
> > > > > + REPORT_GUEST_ASSERT(uc);
> > > > > + fallthrough;
> > > > > + default:
> > > > > + TEST_FAIL("Unhandled ucall: %ld\n", uc.cmd);
> > > > > + }
> > > > > + }
> > > > > +
> > > > > +end:
> > > > > + kvm_vm_free(vm);
> > > > > + return 0;
> > > > > +}
> > > > > --
> > > > > 2.43.0
> > > > >
^ permalink raw reply
* [PATCH v7 6/6] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
- eMMC module, you can optionally solder a SPI NOR in place and turn
off the eMMC
- PCIe-attached NIC (pcie2x1l1)
- PCIe NVMe slot (pcie2x1l2)
- AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
- BCM4345C5 Bluetooth
- es8388 audio
- USB 2.0 and USB 3.0
- Two HDMI ports, the second is connected to the SoC's DP controller
driven through a Lontium LT8711UXD bridge.
Vendors schematics are available at:
https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 442 ++++++++++++++++++
2 files changed, 443 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4d384f153c13..c99dca2ae9e7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
new file mode 100644
index 000000000000..61462c66753d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -0,0 +1,442 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5 Pro";
+ compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ mmc2 = &sdio;
+ };
+
+ hdmi1-con {
+ compatible = "hdmi-connector";
+ label = "HDMI1 OUT";
+ type = "a";
+
+ port {
+ hdmi1_con_in: endpoint {
+ remote-endpoint = <<8711uxd_out>;
+ };
+ };
+ };
+
+ lt8711uxd {
+ compatible = "lontium,lt8711uxd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt8711uxd_in: endpoint {
+ remote-endpoint = <&dp0_out_con>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lt8711uxd_out: endpoint {
+ remote-endpoint = <&hdmi1_con_in>;
+ };
+ };
+ };
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s2_2ch>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm15 0 1000000 0>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_ACTIVITY;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm3 0 1000000 0>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ cooling-levels = <0 50 100 150 200 255>;
+ fan-supply = <&vcc5v0_sys>;
+ pwms = <&pwm2 0 20000000 0>;
+ };
+
+ vcc3v3_dp: regulator-vcc3v3-dp {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_bridge_en>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_dp";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc3v3_phy1: regulator-vcc3v3-phy1 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v3_phy1_en>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_phy1";
+ startup-delay-us = <50000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc5v0_otg: regulator-vcc5v0-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_otg_en>;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "vcc5v0_otg";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ post-power-on-delay-ms = <200>;
+ reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
+ };
+
+ typea_con: usb-a-connector {
+ compatible = "usb-a-connector";
+ data-role = "host";
+ label = "USB3 Type-A";
+ power-role = "source";
+ vbus-supply = <&vcc5v0_otg>;
+ };
+};
+
+&dp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp0m0_pins>;
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp1: endpoint {
+ remote-endpoint = <&vp1_out_dp0>;
+ };
+};
+
+&dp0_out {
+ dp0_out_con: endpoint {
+ remote-endpoint = <<8711uxd_in>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m4_xfer>;
+ status = "okay";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+ status = "okay";
+
+ es8388: audio-codec@11 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x11>;
+ #sound-dai-cells = <0>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_1v8_s0>;
+ assigned-clock-rates = <12288000>;
+ assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
+ clocks = <&cru I2S2_2CH_MCLKOUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s2m1_mclk>;
+ };
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4m3_xfer>;
+ status = "okay";
+};
+
+&i2s2_2ch {
+ pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
+ &i2s2m1_sdi &i2s2m1_sdo>;
+ status = "okay";
+};
+
+&package_thermal {
+ polling-delay = <1000>;
+
+ cooling-maps {
+ map0 {
+ trip = <&package_fan0>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map1 {
+ trip = <&package_fan1>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ package_fan0: package-fan0 {
+ hysteresis = <2000>;
+ temperature = <55000>;
+ type = "active";
+ };
+
+ package_fan1: package-fan1 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+};
+
+/* NVMe */
+&pcie2x1l1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2x1l1_rst &pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
+ reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ supports-clkreq;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+};
+
+/* NIC */
+&pcie2x1l2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2x1l2_rst>;
+ reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_phy1>;
+ status = "okay";
+};
+
+&pinctrl {
+ bluetooth {
+ bt_wake_gpio: bt-wake-pin {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host_irq: bt-wake-host-irq {
+ rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ dp {
+ dp_bridge_en: dp-bridge-en {
+ rockchip,pins = <3 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ pcie2x1l1_rst: pcie2x1l1-rst {
+ rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ pcie2x1l2_rst: pcie2x1l2-rst {
+ rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ vcc3v3_phy1_en: vcc3v3-phy1-en {
+ rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ vcc5v0_otg_en: vcc5v0-otg-en {
+ rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wlan {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wifi_host_wake_irq: wifi-host-wake-irq {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
+
+&pwm15 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm15m2_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m1_pins>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm3m2_pins>;
+ status = "okay";
+};
+
+&rk806_single {
+ regulators {
+ vcca_1v8_s0: pldo-reg1 {
+ regulator-name = "vcca_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_1v8_s0: pldo-reg2 {
+ regulator-name = "vcc_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&sdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-mmc;
+ no-sd;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ ap6256: wifi@1 {
+ compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-names = "host-wake";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_irq>;
+ };
+};
+
+&uart9 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wakeup";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1500000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
+ shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
+&usb_host0_xhci {
+ dr_mode = "host";
+};
+
+&usbdp_phy0 {
+ /*
+ * USBDP PHY0 is wired to a USB3 Type-A host connector via lanes 2/3.
+ * Additionally lanes 0/1 and the aux channel are wired to the
+ * Lontium LT8711UXD DP-to-HDMI bridge feeding the HDMI1 connector.
+ */
+ rockchip,dp-lane-mux = <0 1>;
+};
+
+&vp1 {
+ vp1_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp1>;
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v7 5/6] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
Orange Pi 5B but has had sound, USB, and leds wired up differently. The
5 and 5B boards use gmac for ethernet where the Pro has a PCIe attached
NIC.
Move the 5/5B-specific bits (analog-sound/es8388, FUSB302 Type-C,
gmac1, pwm-leds, i2s1_8ch routing, USB role-switch plumbing) out of
rk3588s-orangepi-5.dtsi into a new rk3588s-orangepi-5-5b.dtsi that is
included by both 5 and 5B.
The RK806 PLDO1 and PLDO2 outputs are wired differently between the
5/5B and the Pro (PLDO1/PLDO2 are swapped), so label the PMIC node
rk806_single in the base dtsi, drop pldo-reg1/pldo-reg2 from it, and
define them via a &rk806_single regulators augmentation in
rk3588s-orangepi-5-5b.dtsi. The Pro will supply its own mapping.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 222 +++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 225 +-----------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
4 files changed, 240 insertions(+), 215 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
new file mode 100644
index 000000000000..9e987ffa6241
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
+ * but not the Orange Pi 5 Pro.
+ */
+
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm0 0 25000 0>;
+ };
+ };
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-0 = <&gmac1_miim
+ &gmac1_tx_bus2
+ &gmac1_rx_bus2
+ &gmac1_rgmii_clk
+ &gmac1_rgmii_bus>;
+ pinctrl-names = "default";
+ tx_delay = <0x42>;
+ status = "okay";
+};
+
+&i2c6 {
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru I2S1_8CH_MCLKOUT>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
+ assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ };
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vbus_typec>;
+ status = "okay";
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ op-sink-microwatt = <1000000>;
+ power-role = "dual";
+ sink-pdos =
+ <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_hs: endpoint {
+ remote-endpoint = <&usb_host0_xhci_drd_sw>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_ss: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ usbc0_sbu: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_sbu>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&i2s1_8ch {
+ rockchip,i2s-tx-route = <3 2 1 0>;
+ rockchip,i2s-rx-route = <1 3 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclk
+ &i2s1m0_mclk
+ &i2s1m0_lrck
+ &i2s1m0_sdi1
+ &i2s1m0_sdo3>;
+ status = "okay";
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&rk806_single {
+ regulators {
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+
+&usb_host0_xhci {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <&usbc0_hs>;
+ };
+ };
+};
+
+&usb_host2_xhci {
+ status = "okay";
+};
+
+&usbdp_phy0 {
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy0_typec_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_ss>;
+ };
+
+ usbdp_phy0_typec_sbu: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usbc0_sbu>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 83b9b6645a1e..d76bdf1b5e90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -2,12 +2,16 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5";
compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+ aliases {
+ mmc0 = &sdmmc;
+ };
+
vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
compatible = "regulator-fixed";
enable-active-high;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index fd5c6a025cd1..2b605e5fc35a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -3,19 +3,13 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
#include "rk3588s.dtsi"
/ {
- aliases {
- ethernet0 = &gmac1;
- mmc0 = &sdmmc;
- };
-
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -34,38 +28,6 @@ button-recovery {
};
};
- analog-sound {
- compatible = "simple-audio-card";
- pinctrl-names = "default";
- pinctrl-0 = <&hp_detect>;
- simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
- simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
- "LINPUT1", "Microphone Jack",
- "RINPUT1", "Microphone Jack",
- "LINPUT2", "Onboard Microphone",
- "RINPUT2", "Onboard Microphone";
- simple-audio-card,widgets =
- "Microphone", "Microphone Jack",
- "Microphone", "Onboard Microphone",
- "Headphone", "Headphones";
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
-
- masterdai: simple-audio-card,codec {
- sound-dai = <&es8388>;
- system-clock-frequency = <12288000>;
- };
- };
-
hdmi0-con {
compatible = "hdmi-connector";
type = "a";
@@ -77,18 +39,6 @@ hdmi0_con_in: endpoint {
};
};
- pwm-leds {
- compatible = "pwm-leds";
-
- led {
- color = <LED_COLOR_ID_GREEN>;
- function = LED_FUNCTION_STATUS;
- linux,default-trigger = "heartbeat";
- max-brightness = <255>;
- pwms = <&pwm0 0 25000 0>;
- };
- };
-
vbus_typec: regulator-vbus-typec {
compatible = "regulator-fixed";
enable-active-high;
@@ -101,15 +51,6 @@ vbus_typec: regulator-vbus-typec {
vin-supply = <&vcc5v0_sys>;
};
- vcc5v0_sys: regulator-vcc5v0-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
compatible = "regulator-fixed";
gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
@@ -119,6 +60,15 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_3v3_s3>;
};
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
};
&combphy0_ps {
@@ -161,20 +111,6 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
-&gmac1 {
- clock_in_out = "output";
- phy-handle = <&rgmii_phy1>;
- phy-mode = "rgmii-rxid";
- pinctrl-0 = <&gmac1_miim
- &gmac1_tx_bus2
- &gmac1_rx_bus2
- &gmac1_rgmii_clk
- &gmac1_rgmii_bus>;
- pinctrl-names = "default";
- tx_delay = <0x42>;
- status = "okay";
-};
-
&gpu {
mali-supply = <&vdd_gpu_s0>;
status = "okay";
@@ -270,69 +206,6 @@ &i2c6 {
pinctrl-0 = <&i2c6m3_xfer>;
status = "okay";
- es8388: audio-codec@10 {
- compatible = "everest,es8388", "everest,es8328";
- reg = <0x10>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcca_3v3_s0>;
- DVDD-supply = <&vcca_1v8_s0>;
- HPVDD-supply = <&vcca_3v3_s0>;
- PVDD-supply = <&vcca_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
- assigned-clock-rates = <12288000>;
- #sound-dai-cells = <0>;
- };
-
- usbc0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio0>;
- interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usbc0_int>;
- vbus-supply = <&vbus_typec>;
- status = "okay";
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- op-sink-microwatt = <1000000>;
- power-role = "dual";
- sink-pdos =
- <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
- source-pdos =
- <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- usbc0_hs: endpoint {
- remote-endpoint = <&usb_host0_xhci_drd_sw>;
- };
- };
-
- port@1 {
- reg = <1>;
- usbc0_ss: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_ss>;
- };
- };
-
- port@2 {
- reg = <2>;
- usbc0_sbu: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_sbu>;
- };
- };
- };
- };
- };
-
hym8563: rtc@51 {
compatible = "haoyu,hym8563";
reg = <0x51>;
@@ -346,18 +219,6 @@ hym8563: rtc@51 {
};
};
-&i2s1_8ch {
- rockchip,i2s-tx-route = <3 2 1 0>;
- rockchip,i2s-rx-route = <1 3 2 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2s1m0_sclk
- &i2s1m0_mclk
- &i2s1m0_lrck
- &i2s1m0_sdi1
- &i2s1m0_sdo3>;
- status = "okay";
-};
-
&i2s5_8ch {
status = "okay";
};
@@ -404,12 +265,6 @@ typec5v_pwren: typec5v-pwren {
};
};
-&pwm0 {
- pinctrl-0 = <&pwm0m2_pins>;
- pinctrl-names = "default";
- status = "okay";
-};
-
&rknn_core_0 {
npu-supply = <&vdd_npu_s0>;
sram-supply = <&vdd_npu_s0>;
@@ -491,7 +346,7 @@ &spi2 {
pinctrl-names = "default";
pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
- pmic@0 {
+ rk806_single: pmic@0 {
compatible = "rockchip,rk806";
reg = <0x0>;
interrupt-parent = <&gpio0>;
@@ -666,31 +521,6 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg1 {
- regulator-name = "vcc_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcca_1v8_s0: pldo-reg2 {
- regulator-name = "vcca_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
vdda_1v2_s0: pldo-reg3 {
regulator-name = "vdda_1v2_s0";
regulator-always-on;
@@ -841,26 +671,7 @@ &uart2 {
};
&usbdp_phy0 {
- mode-switch;
- orientation-switch;
- sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
- sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbdp_phy0_typec_ss: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&usbc0_ss>;
- };
-
- usbdp_phy0_typec_sbu: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&usbc0_sbu>;
- };
- };
};
&usb_host0_ehci {
@@ -872,15 +683,7 @@ &usb_host0_ohci {
};
&usb_host0_xhci {
- dr_mode = "otg";
- usb-role-switch;
status = "okay";
-
- port {
- usb_host0_xhci_drd_sw: endpoint {
- remote-endpoint = <&usbc0_hs>;
- };
- };
};
&usb_host1_ehci {
@@ -891,7 +694,7 @@ &usb_host1_ohci {
status = "okay";
};
-&usb_host2_xhci {
+&vop {
status = "okay";
};
@@ -899,10 +702,6 @@ &vop_mmu {
status = "okay";
};
-&vop {
- status = "okay";
-};
-
&vp0 {
vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
index d21ec320d295..8af174777809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5B";
--
2.53.0
^ permalink raw reply related
* [PATCH v7 4/6] arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels to match schematic
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Orange Pi 5, 5B and 5 Pro schematics label the RK806 PLDO outputs
using the pattern VCC_*_S0 / VCCA_*_S0 / VDDA_*_S0. Rename the base
dtsi regulator labels (and the es8388 supply references) to match:
pldo-reg1: avcc_1v8_s0 -> vcc_1v8_s0
pldo-reg2: vcc_1v8_s0 -> vcca_1v8_s0
pldo-reg3: avdd_1v2_s0 -> vdda_1v2_s0
pldo-reg4: vcc_3v3_s0 -> vcca_3v3_s0
Also update the saradc vref-supply reference to track the pldo-reg1
rename. No functional change.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..fd5c6a025cd1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -274,10 +274,10 @@ es8388: audio-codec@10 {
compatible = "everest,es8388", "everest,es8328";
reg = <0x10>;
clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcc_3v3_s0>;
- DVDD-supply = <&vcc_1v8_s0>;
- HPVDD-supply = <&vcc_3v3_s0>;
- PVDD-supply = <&vcc_3v3_s0>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
assigned-clock-rates = <12288000>;
#sound-dai-cells = <0>;
@@ -441,7 +441,7 @@ &rknn_mmu_2 {
};
&saradc {
- vref-supply = <&avcc_1v8_s0>;
+ vref-supply = <&vcc_1v8_s0>;
status = "okay";
};
@@ -666,8 +666,8 @@ regulator-state-mem {
};
};
- avcc_1v8_s0: pldo-reg1 {
- regulator-name = "avcc_1v8_s0";
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -678,8 +678,8 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg2 {
- regulator-name = "vcc_1v8_s0";
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -691,8 +691,8 @@ regulator-state-mem {
};
};
- avdd_1v2_s0: pldo-reg3 {
- regulator-name = "avdd_1v2_s0";
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-name = "vdda_1v2_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1200000>;
@@ -703,8 +703,8 @@ regulator-state-mem {
};
};
- vcc_3v3_s0: pldo-reg4 {
- regulator-name = "vcc_3v3_s0";
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-name = "vcca_3v3_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <3300000>;
--
2.53.0
^ permalink raw reply related
* [PATCH v7 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..42c1f3d5ba0c 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "lontium,lt8711uxd",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.53.0
^ permalink raw reply related
* [PATCH v7 2/6] dt-bindings: display: bridge: simple: document the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..752c736c8f85 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - lontium,lt8711uxd
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.53.0
^ permalink raw reply related
* [PATCH v7 1/6] dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann, Krzysztof Kozlowski
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
Add compatible string for the Orange Pi 5 Pro.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ae77ded9fe47..3c6b83a84463 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1320,6 +1320,7 @@ properties:
items:
- enum:
- xunlong,orangepi-5
+ - xunlong,orangepi-5-pro
- xunlong,orangepi-5b
- const: rockchip,rk3588s
--
2.53.0
^ permalink raw reply related
* [PATCH v7 0/6] Add support for Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
This series adds initial support for Orange Pi 5 Pro. The PCIe attached
network driver(dwmac-motorcomm) was just added.
The series was tested against Linux 7.0-rc7
Please take a look.
Thank you,
Dennis Gilmore
Changes in v7:
- Fix up whitespace issues identified by checkpatch.pl --strict in
rk3588s-orangepi-5-5b.dtsi
- checkpatch gave a warning for WARNING: phy-mode "rgmii-rxid" without
comment, as this was moved over I left it untouched
- Added lontium,lt8711uxd to the compatible enum in the simple-bridge
binding
- Added lontium,lt8711uxd match entry with DRM_MODE_CONNECTOR_HDMIA to
the simple-bridge driver
- New patch to rename the regulator labels for the es8388 supplies to
match the schematics as they all use vcca_*
- RK806 PLDO1 and PLDO2 outputs are swapped between the 5/5B and pro.
move their definition to the shared 5/5B dtsi and 5 Pro dts
- Fixed ES8388 PVDD-supply — vcca_3v3_s0 → vcca_1v8_s0, 5 Pro is
different to 5 and 5b.
- analog-sound: use CPU-as-clock-master on the Pro. The ES8388 is wired to
i2s2_2ch (the only I2S block physically routed to the codec pins on this
board), which uses the legacy rockchip_i2s driver. That driver's
slave-mode trigger path hangs for 200 µs polling I2S_CLR and bails with
-ETIMEDOUT ("lrclk update failed"). The TDM-capable i2s0/i2s1/i2s5
blocks served by rockchip_i2s_tdm don't have this issue, which is why
other mainline ES8388 boards get away with bitclock-master = masterdai.
Drop bitclock-master/frame-master and the masterdai label to let the I2S
block generate BCLK/LRCK itself
- Added pinctrl entries for all GPIO pins (dp_bridge_en, vcc3v3_phy1_en,
wifi_enable_h, pcie2x1l1_rst, pcie2x1l2_rst)
- DP bridge rework — replaced dp-connector node with proper chain:
- lt8711uxd bridge node (compatible lontium,lt8711uxd, with port@0/port@1
endpoints). Bridge power is gated by the vcc3v3_dp regulator, whose
enable GPIO (GPIO3_PC2) is driven via the dp_bridge_en pinctrl group;
no enable-gpios/vdd-supply on the bridge node itself.
- hdmi1-con connector node (compatible hdmi-connector, type a)
- dp0_out endpoint now points to bridge input instead of old connector
- drop accidentally included, unrelated changes to
drivers/gpu/drm/bridge/synopsys/dw-dp.c and
Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
- link to v6 https://lore.kernel.org/linux-devicetree/20260411024743.195385-1-dennis@ausil.us/
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5 https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4 https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3 https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purppose
- actually clean up the delete lines and comments missed in v2
- link to v2 https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- Link to v1 https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (6):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
dt-bindings: display: bridge: simple: document the Lontium LT8711UXD
DP-to-HDMI bridge
drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels
to match schematic
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
.../display/bridge/simple-bridge.yaml | 1 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 222 +++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 442 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 235 +---------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
9 files changed, 695 insertions(+), 220 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.53.0
^ permalink raw reply
* Re: [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Alper Gun @ 2026-04-14 21:40 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <20260318155413.793430-1-steven.price@arm.com>
On Wed, Mar 18, 2026 at 8:54 AM Steven Price <steven.price@arm.com> wrote:
>
> This series adds support for running protected VMs using KVM under the
> Arm Confidential Compute Architecture (CCA).
>
> New major version number! This now targets RMM v2.0-bet0[1]. And unlike
> for Linux this represents a significant change.
>
> RMM v2.0 brings with it the ability to configure the RMM to have the
> same page size as the host (so no more RMM_PAGE_SIZE and dealing with
> granules being different from host pages). It also introduces range
> based APIs for many operations which should be more efficient and
> simplifies the code in places.
>
> The handling of the GIC has changed, so the system registers are used to
> pass the GIC state rather than memory. This means fewer changes to the
> KVM code as it looks much like a normal VM in this respect.
>
> And of course the new uAPI introduced in the previous v12 posting is
> retained so that also remains simplified compared to earlier postings.
>
> The RMM support for v2.0 is still early and so this series includes a
> few hacks to ease the integration. Of note are that there are some RMM
> v1.0 SMCs added to paper over areas where the RMM implementation isn't
> quite ready for v2.0, and "SROs" (see below) are deferred to the final
> patch in the series.
>
> The PMU in RMM v2.0 requires more handling on the RMM-side (and
> therefore simplifies the implementation on Linux), but this isn't quite
> ready yet. The Linux side is implemented (but untested).
>
> PSCI still requires the VMM to provide the "target" REC for operations
> that affect another vCPU. This is likely to change in a future version
> of the specification. There's also a desire to force PSCI to be handled
> in the VMM for realm guests - this isn't implemented yet as I'm waiting
> for the dust to settle on the RMM interface first.
>
> Stateful RMI Operations
> -----------------------
>
> The RMM v2.0 spec brings a new concept of Stateful RMI Operations (SROs)
> which allow the RMM to complete an operation over several SMC calls and
> requesting/returning memory to the host. This has the benefit of
> allowing interrupts to be handled in the middle of an operation (by
> returning to the host to handle the interrupt without completing the
> operation) and enables the RMM to dynamically allocate memory for
> internal tracking purposes. One example of this is RMI_REC_CREATE no
> longer needs "auxiliary granules" provided upfront but can request the
> memory needed during the RMI_REC_CREATE operation.
>
> There are a fairly large number of operations that are defined as SROs
> in the specification, but current both Linux and RMM only have support
> for RMI_REC_CREATE and RMI_REC_DESTROY. There a number of TODOs/FIXMEs
> in the code where support is missing.
>
> Given the early stage support for this, the SRO handling is all confined
> to the final patch. This patch can be dropped to return to a pre-SRO
> state (albeit a mixture of RMM v1.0 and v2.0 APIs) for testing purposes.
>
> A future posting will reorder the series to move the generic SRO support
> to an early patch and will implement the proper support for this in all
> RMI SMCs.
>
> One aspect of SROs which is not yet well captured is that in some
> circumstances the Linux kernel will need to call an SRO call in a
> context where memory allocation is restricted (e.g. because a spinlock
> is held). In this case the intention is that the SRO will be cancelled,
> the spinlock dropped so the memory allocation can be completed, and then
> the SRO restarted (obviously after rechecking the state that the
> spinlock was protecting). For this reason the code stores the memory
> allocations within a struct rmi_sro_state object - see the final patch
> for more details.
>
> This series is based on v7.0-rc1. It is also available as a git
> repository:
>
> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13
>
>
Hi Steven,
I have a question regarding host kexec and kdump scenarios, and
whether there is any plan to make them work in this initial series.
Intel TDX and AMD SEV-SNP both have a firmware shutdown command that
is invoked during the kexec or panic code paths to safely bypass
hardware memory protections and boot into the new kernel. As far as
I know, there is no similar global teardown command available for
the RMM.
What is the roadmap for supporting both general kexec and
more specifically kdump (panic) scenarios with CCA?
Thanks,
Alper
^ permalink raw reply
* [PATCH v3 8/8] ARM: defconfig: Add a zx29 defconfig file
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
This enables existing drivers that already are (UART) or will be (USB,
GPIO) necessary to operate this board even if they aren't declared in
the DTS yet.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
arch/arm/configs/zx29_defconfig | 90 +++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
create mode 100644 arch/arm/configs/zx29_defconfig
diff --git a/arch/arm/configs/zx29_defconfig b/arch/arm/configs/zx29_defconfig
new file mode 100644
index 000000000000..dae2d86c7583
--- /dev/null
+++ b/arch/arm/configs/zx29_defconfig
@@ -0,0 +1,90 @@
+CONFIG_SYSVIPC=y
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EXPERT=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_MMU=y
+CONFIG_ARCH_MULTI_V7=y
+CONFIG_ARCH_ZTE=y
+CONFIG_SOC_ZX297520V3=y
+# FIXME: There is no PSCI on this board, but ARM_GIC_V3 depends on it
+CONFIG_ARM_PSCI=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttyAMA1 earlyprintk root=/dev/ram rw"
+# CONFIG_SUSPEND is not set
+CONFIG_BINFMT_FLAT=y
+# CONFIG_UEVENT_HELPER is not set
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_ALLOW_DEV_COREDUMP is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_CPU_FREQ=y
+CONFIG_CPUFREQ_DT_PLATDEV=y
+CONFIG_PM=y
+CONFIG_PM_CLK=y
+CONFIG_PM_GENERIC_DOMAINS=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_DEVTMPFS=y # FIXME: This is specific to my initrd. Remove before upstream
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_KEYBOARD_GPIO_POLLED=y
+CONFIG_GPIOLIB=y
+CONFIG_OF_GPIO=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_DEV_BUS=y
+CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_MFD_SYSCON=y
+# CONFIG_HID is not set
+CONFIG_PINCTRL=y
+CONFIG_GENERIC_PINCTRL_GROUPS=y
+CONFIG_PINMUX=y
+CONFIG_GENERIC_PINMUX_FUNCTIONS=y
+CONFIG_PINCONF=y
+CONFIG_GENERIC_PINCONF=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_POWER_RESET=y
+CONFIG_RESET_SIMPLE=y
+CONFIG_LEDS_GPIO=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_GADGET=y
+CONFIG_MTD=y
+CONFIG_MTD_OF_PARTS=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_SPI_NAND=y
+CONFIG_SPI_MASTER=y
+CONFIG_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_PLTFM=y
+CONFIG_STMMAC_ETH=y
+CONFIG_STMMAC_PLATFORM=y
+CONFIG_MDIO_BUS=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_SRAM=y
+CONFIG_MISC_FILESYSTEMS=y
+CONFIG_JFFS2_FS=y
+CONFIG_CONFIG_TMPFS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_PRINTK_TIME=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_DEBUG_LL=y
+CONFIG_DEBUG_ZTE_ZX=y
+CONFIG_DEBUG_LL_INCLUDE="debug/pl01x.S"
+CONFIG_DEBUG_UART_PL01X=y
+CONFIG_DEBUG_UART_PHYS=0x01408000
+CONFIG_DEBUG_UART_VIRT=0xf4708000
--
2.52.0
^ permalink raw reply related
* [PATCH v3 6/8] ARM: zte: Bring back zx29 UART support
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform"). I did not bring back the zx29-uart .compatible as the
arm,primecell-periphid does the job.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/tty/serial/amba-pl011.c | 37 +++++++++++++++++++++++++++++++++
include/linux/amba/bus.h | 6 ++++++
2 files changed, 43 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f17d288c807..858a0edd3e3b 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -216,6 +216,38 @@ static struct vendor_data vendor_st = {
.get_fifosize = get_fifosize_st,
};
+static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
+ [REG_DR] = ZX_UART011_DR,
+ [REG_FR] = ZX_UART011_FR,
+ [REG_LCRH_RX] = ZX_UART011_LCRH,
+ [REG_LCRH_TX] = ZX_UART011_LCRH,
+ [REG_IBRD] = ZX_UART011_IBRD,
+ [REG_FBRD] = ZX_UART011_FBRD,
+ [REG_CR] = ZX_UART011_CR,
+ [REG_IFLS] = ZX_UART011_IFLS,
+ [REG_IMSC] = ZX_UART011_IMSC,
+ [REG_RIS] = ZX_UART011_RIS,
+ [REG_MIS] = ZX_UART011_MIS,
+ [REG_ICR] = ZX_UART011_ICR,
+ [REG_DMACR] = ZX_UART011_DMACR,
+};
+
+static unsigned int get_fifosize_zte(struct amba_device *dev)
+{
+ return 16;
+}
+
+static struct vendor_data vendor_zte = {
+ .reg_offset = pl011_zte_offsets,
+ .access_32b = true,
+ .ifls = UART011_IFLS_RX4_8 | UART011_IFLS_TX4_8,
+ .fr_busy = ZX_UART01x_FR_BUSY,
+ .fr_dsr = ZX_UART01x_FR_DSR,
+ .fr_cts = ZX_UART01x_FR_CTS,
+ .fr_ri = ZX_UART011_FR_RI,
+ .get_fifosize = get_fifosize_zte,
+};
+
/* Deals with DMA transactions */
struct pl011_dmabuf {
@@ -3081,6 +3113,11 @@ static const struct amba_id pl011_ids[] = {
.mask = 0x00ffffff,
.data = &vendor_st,
},
+ {
+ .id = AMBA_LINUX_ID(0x00, 0x1, 0xffe),
+ .mask = 0x00ffffff,
+ .data = &vendor_zte,
+ },
{ 0, 0 },
};
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 9946276aff73..854c962d70f5 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -103,8 +103,14 @@ enum amba_vendor {
AMBA_VENDOR_ST = 0x80,
AMBA_VENDOR_QCOM = 0x51,
AMBA_VENDOR_LSI = 0xb6,
+ AMBA_VENDOR_LINUX = 0xfe, /* This value is not official */
};
+/* This is used to generate pseudo-ID for AMBA device */
+#define AMBA_LINUX_ID(conf, rev, part) \
+ (((conf) & 0xff) << 24 | ((rev) & 0xf) << 20 | \
+ AMBA_VENDOR_LINUX << 12 | ((part) & 0xfff))
+
extern const struct bus_type amba_bustype;
#define to_amba_device(d) container_of_const(d, struct amba_device, dev)
--
2.52.0
^ permalink raw reply related
* [PATCH v3 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
This is the UART that sends Uboot messages and is accessible via pins on
the boards I have seen so far. UART0 and UART2 exist as well, but don't
have pins enabled by the bootloader. They will be added later.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
arch/arm/boot/dts/zte/zx297520v3.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index ecd07f3fb8b3..09fbb1d052e3 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -6,6 +6,10 @@ / {
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ serial1 = &uart1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -57,5 +61,23 @@ timer {
*/
arm,cpu-registers-not-fw-configured;
};
+
+ /* The UART clock defaults to 26 mhz. It will be replaced when the zx29 clock
+ * framework is added.
+ */
+ uartclk: uartclk: clock-26000000 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ };
+
+ uart1: serial@1408000 {
+ compatible = "arm,pl011", "arm,primecell";
+ arm,primecell-periphid = <0x001feffe>;
+ reg = <0x01408000 0x1000>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>;
+ clock-names = "apb_pclk";
+ };
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v3 4/8] ARM: zte: Add support for zx29 low level debug
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
This is based on the removed zx29 code. A separate (more complicated)
patch will re-add the register map to the pl011 serial driver.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
I am unsure about the virtual address. It doesn't seem to matter, as
long as it is a valid address. This address is based on the old removed
code. Is there a rule-of-thumb physical to virtual mapping I can use to
give a sensible default value?
---
arch/arm/Kconfig.debug | 12 ++++++++++++
arch/arm/include/debug/pl01x.S | 7 +++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 366f162e147d..98d8a5a60048 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1331,6 +1331,16 @@ choice
This option selects UART0 on VIA/Wondermedia System-on-a-chip
devices, including VT8500, WM8505, WM8650 and WM8850.
+ config DEBUG_ZTE_ZX
+ bool "Kernel low-level debugging via zx29 UART"
+ select DEBUG_UART_PL01X
+ depends on ARCH_ZTE
+ help
+ Say Y here if you are enabling ZTE zx297520v3 SOC and need
+ debug UART support. This UART is a PL011 with different
+ register addresses. The UART for boot messages on zx29 boards
+ is usually UART1 and is operating at 921600 8N1.
+
config DEBUG_ZYNQ_UART0
bool "Kernel low-level debugging on Xilinx Zynq using UART0"
depends on ARCH_ZYNQ
@@ -1545,6 +1555,7 @@ config DEBUG_UART_8250
config DEBUG_UART_PHYS
hex "Physical base address of debug UART"
+ default 0x01408000 if DEBUG_ZTE_ZX
default 0x01c28000 if DEBUG_SUNXI_UART0
default 0x01c28400 if DEBUG_SUNXI_UART1
default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
@@ -1701,6 +1712,7 @@ config DEBUG_UART_VIRT
default 0xf31004c0 if DEBUG_MESON_UARTAO
default 0xf4090000 if DEBUG_LPC32XX
default 0xf4200000 if DEBUG_GEMINI
+ default 0xf4708000 if DEBUG_ZTE_ZX
default 0xf6200000 if DEBUG_PXA_UART1
default 0xf7000000 if DEBUG_SUN9I_UART0
default 0xf7000000 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART0
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
index c7e02d0628bf..0c7bfa4c10db 100644
--- a/arch/arm/include/debug/pl01x.S
+++ b/arch/arm/include/debug/pl01x.S
@@ -8,6 +8,13 @@
*/
#include <linux/amba/serial.h>
+#ifdef CONFIG_DEBUG_ZTE_ZX
+#undef UART01x_DR
+#undef UART01x_FR
+#define UART01x_DR 0x04
+#define UART01x_FR 0x14
+#endif
+
#ifdef CONFIG_DEBUG_UART_PHYS
.macro addruart, rp, rv, tmp
ldr \rp, =CONFIG_DEBUG_UART_PHYS
--
2.52.0
^ permalink raw reply related
* [PATCH v3 5/8] ARM: dts: Add an armv7 timer for zx297520v3
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
The stock kernel does not use this timer, but it seems to work fine. The
board has other board-specific timers that would need a driver and I see
no reason to bother with them since the arm standard timer works.
The caveat is the non-standard GIC setup needed to handle the timer's
level-low PPI. This is the responsibility of the boot loader and
documented in Documentation/arch/arm/zte/zx297520v3.rst.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
arch/arm/boot/dts/zte/zx297520v3.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index d6c71d52b26c..ecd07f3fb8b3 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -24,6 +24,15 @@ soc {
interrupt-parent = <&gic>;
ranges;
+ /* The GIC has a non-standard way of configuring ints between level-low/level
+ * high or rising edge/falling edge at 0xf2202070 and onwards. See AP_INT_MODE_BASE
+ * and AP_PPI_MODE_REG in the ZTE kernel, although the offsets in the kernel source
+ * seem wrong.
+ *
+ * Everything defaults to active-high/rising edge, but the timer is active-low. We
+ * currently rely on the boot loader to change timer IRQs to active-low for us for
+ * now.
+ */
gic: interrupt-controller@f2000000 {
compatible = "arm,gic-v3";
interrupt-controller;
@@ -33,5 +42,20 @@ gic: interrupt-controller@f2000000 {
reg = <0xf2000000 0x10000>,
<0xf2040000 0x20000>;
};
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ clock-frequency = <26000000>;
+ interrupt-parent = <&gic>;
+ /* I don't think uboot sets CNTVOFF and the stock kernel doesn't use the
+ * arm timer at all. Since this is a single CPU system I don't think it
+ * really matters that the offset is random though.
+ */
+ arm,cpu-registers-not-fw-configured;
+ };
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v3 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
Add a compatible for boards based on the ZTE zx297520v3 SoC.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
.../devicetree/bindings/arm/zx29.yaml | 20 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/zx29.yaml
diff --git a/Documentation/devicetree/bindings/arm/zx29.yaml b/Documentation/devicetree/bindings/arm/zx29.yaml
new file mode 100644
index 000000000000..717ca6413993
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/zx29.yaml
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/zx29.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE zx29
+
+maintainers:
+ - Stefan Dösinger <stefandoesinger@gmail.com>
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - items:
+ - const: zte,zx297520v3
+
+additionalProperties: true
diff --git a/MAINTAINERS b/MAINTAINERS
index 974d7a98956a..c29eb2dfb1b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29202,6 +29202,7 @@ F: tools/testing/selftests/cgroup/test_zswap.c
ZX29
M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: Documentation/devicetree/bindings/arm/zx29.yaml
F: arch/arm/mach-zte/
SENARYTECH AUDIO CODEC DRIVER
--
2.52.0
^ permalink raw reply related
* [PATCH v3 3/8] ARM: dts: Add D-Link DWR-932M support
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
This adds DT bindings for zx297520v3 and one board that consumes it.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
MAINTAINERS | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 ++
arch/arm/boot/dts/zte/dlink-dwr-932m.dts | 21 ++++++++++++++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 37 ++++++++++++++++++++++++
5 files changed, 63 insertions(+)
create mode 100644 arch/arm/boot/dts/zte/Makefile
create mode 100644 arch/arm/boot/dts/zte/dlink-dwr-932m.dts
create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index c29eb2dfb1b3..21f87d1e0e9a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29203,6 +29203,7 @@ F: tools/testing/selftests/cgroup/test_zswap.c
ZX29
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zx29.yaml
+F: arch/arm/boot/dts/zte
F: arch/arm/mach-zte/
SENARYTECH AUDIO CODEC DRIVER
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index efe38eb25301..28fba538d552 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,3 +39,4 @@ subdir-y += unisoc
subdir-y += vt8500
subdir-y += xen
subdir-y += xilinx
+subdir-y += zte
diff --git a/arch/arm/boot/dts/zte/Makefile b/arch/arm/boot/dts/zte/Makefile
new file mode 100644
index 000000000000..416c24a489cd
--- /dev/null
+++ b/arch/arm/boot/dts/zte/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_ZX297520V3) += \
+ dlink-dwr-932m.dtb
diff --git a/arch/arm/boot/dts/zte/dlink-dwr-932m.dts b/arch/arm/boot/dts/zte/dlink-dwr-932m.dts
new file mode 100644
index 000000000000..a062c40c467b
--- /dev/null
+++ b/arch/arm/boot/dts/zte/dlink-dwr-932m.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * D-Link DWR-932M Board
+ *
+ * (C) Copyright 2026 Stefan Dösinger
+ *
+ */
+
+/dts-v1/;
+
+#include "zx297520v3.dtsi"
+
+/ {
+ model = "D-Link DWR-932M";
+ compatible = "zte,zx297520v3";
+
+ memory@20000000 {
+ device_type = "memory";
+ reg = <0x20000000 0x04000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
new file mode 100644
index 000000000000..d6c71d52b26c
--- /dev/null
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+ gic: interrupt-controller@f2000000 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xf2000000 0x10000>,
+ <0xf2040000 0x20000>;
+ };
+ };
+};
--
2.52.0
^ permalink raw reply related
* [PATCH v3 1/8] ARM: zte: Add zx297520v3 platform support
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.
This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
platform"). My eventual goal is to enable OpenWRT to run on these
devices.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Documentation/arch/arm/zte/zx297520v3.rst | 158 ++++++++++++++++++++++
MAINTAINERS | 4 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-zte/Kconfig | 24 ++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 +++
7 files changed, 210 insertions(+)
create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
create mode 100644 arch/arm/mach-zte/Kconfig
create mode 100644 arch/arm/mach-zte/Makefile
create mode 100644 arch/arm/mach-zte/zx297520v3.c
diff --git a/Documentation/arch/arm/zte/zx297520v3.rst b/Documentation/arch/arm/zte/zx297520v3.rst
new file mode 100644
index 000000000000..a0f25ade0a3d
--- /dev/null
+++ b/Documentation/arch/arm/zte/zx297520v3.rst
@@ -0,0 +1,158 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================================
+Booting Linux on ZTE zx297520v3 SoCs
+====================================
+
+...............................................................................
+
+Author: Stefan Dösinger
+
+Date : 27 Jan 2026
+
+1. Hardware description
+---------------------------
+Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+run in aarch32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
+it seems to lack VFP and NEON.
+
+The SoC is used in a number of cheap LTE to Wifi routers, both battery powered
+MiFis and stationary CPEs. In addition to the CPU these devices usually have
+64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an
+SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2,
+and buttons. Devices with as low as 32 MB or as high as 128 MB ram exist, as
+do devices with 8 or 16 MB of NOR flash.
+
+Some devices, especially the stationary ones, have 100 mbit Ethernet and an
+Ethernet switch.
+
+Usually the devices have LEDs for status indication, although some have SPI or
+i2c connected displays
+
+Some have an SD card slot. If it exists, it is a better choice for the root
+file system because it easily outperforms the built-in NAND.
+
+The LTE interface runs on a separate DSP called ZSP880. It is probably derived
+from LSI ZSPs and has an undocumented instruction set. The ZSP communicates
+with the main CPU via SRAM and DRAM and a mailbox hardware that can generate
+IRQs on either ends.
+
+There is also a Cortex M0 CPU, which is responsible for early HW initialization
+and starting the Cortex A53 CPU. It does not have any essential purpose once
+U-Boot is started. A SRAM-Based handover protocol exists to run custom code on
+this CPU.
+
+2. Booting via USB
+---------------------------
+
+The Boot ROM has support for booting custom code via USB. This mode can be
+entered by connecting a Boot PIN to GND or by modifying the third byte on NAND
+(set it to anything other than 0x5A aka 'Z'). A free software tool to start
+custom uboot and kernels can be found here:
+
+https://github.com/zx297520v3-mainline/zx297520v3-loader
+
+If USB download mode is entered but no boot commands are sent through USB, the
+device will proceed to boot normally after a few seconds. It is therefore
+possible to enable USB boot permanently and still leave the default boot files
+in place.
+
+3. Building for built-in U-Boot
+---------------------------
+The devices come with an ancient U-Boot that loads legacy uImages from NAND and
+boots them without a chance for the user to interrupt. The images are stored in
+files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
+usually mtd4. A file named "fotaflag" switches between the two modes.
+
+In addition to the uImage header, those files have a 384 byte signature header,
+which is used for authenticating the images on some devices. Most devices have
+this authentication disabled and it is enough to pad the uImage files with 384
+zero bytes.
+
+Builtin U-Boot also poorly sets up the CPU. Read the next section for details
+on this. It has no support for loading DTBs, so CONFIG_ARM_APPENDED_DTB is
+needed.
+
+So to build an image that boots from NAND the following steps are necessary:
+
+1) Patch the assembly code from section 3 into arch/arm/kernel/head.S.
+2) make zx29_defconfig
+3) make [-j x]
+4) cat arch/arm/boot/zImage arch/arm/boot/dts/zte/[device].dtb > kernel+dtb
+5) mkimage -A arm -O linux -T kernel -C none -a 0x20008000 -d kernel+dtb uimg
+6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
+7) cat uimg >> ap_recovery.bin
+8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
+free space is not enough.
+9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
+
+For development, booting ap_recovery.bin is recommended because the normal boot
+mode arms the watchdog before starting the kernel.
+
+4. CPU and GIC Setup
+---------------------------
+
+Generally CPU and GICv3 need to be set up according to the requirements spelled
+out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means:
+
+1. GICD_CTLR.DS=1 to disable GIC security
+2. Enable access to ICC_SRE
+3. Disable trapping IRQs into monitor mode
+4. Configure EL2 and below to run in insecure mode.
+5. Configure timer PPIs to active-low.
+
+The kernel sources provided by ZTE do not boot either (interrupts do not work
+at all). They are incomplete in other aspects too, so it is assumed that there
+is some workaround similar to the one described in this document somewhere in
+the binary blobs.
+
+The assembly code below is given as an example of how to achieve this:
+
+```
+#include <linux/irqchip/arm-gic-v3.h>
+#include <asm/assembler.h>
+#include <asm/cp15.h>
+
+@ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ldr r3, =0xf2000000
+ldr r4, =#(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+str r4, [r3]
+
+cps #MON_MODE
+
+@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+@ seems to respond only to non-secure addresses. I have taken insipiration from
+@ Raspberry pi's armstub7.S here.
+@
+@ ARM docs say modify this bit in monitor mode only...
+mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
+ @ Allow hypervisor call.
+mcr p15, 0, r3, c1, c1, 0
+
+@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ldr r3, =0xF22020a8
+ldr r4, =0x50
+str r4, [r3]
+ldr r3, =0xF22020ac
+ldr r4, =0x14
+str r4, [r3]
+
+@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
+orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
+mcr p15, 6, r3, c12, c12, 5
+mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
+orr r3, #(ICC_SRE_EL1_SRE)
+mcr p15, 0, r3, c12, c12, 5
+
+@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+@ for EL2.
+mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
+orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+mcr p15, 4, r3, c12, c9, 5
+isb
+
+@ Back to SVC mode. TODO: Doesn't safe_svcmode_maskall do this for us anyway?
+cps #SVC_MODE
+```
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..974d7a98956a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29200,6 +29200,10 @@ F: include/linux/zswap.h
F: mm/zswap.c
F: tools/testing/selftests/cgroup/test_zswap.c
+ZX29
+M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: arch/arm/mach-zte/
+
SENARYTECH AUDIO CODEC DRIVER
M: bo liu <bo.liu@senarytech.com>
S: Maintained
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec33376f8e2b..4217ed704e48 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -464,6 +464,8 @@ source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vt8500/Kconfig"
+source "arch/arm/mach-zte/Kconfig"
+
source "arch/arm/mach-zynq/Kconfig"
# ARMv7-M architecture
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b7de4b6b284c..573813ef5e77 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -223,6 +223,7 @@ machine-$(CONFIG_ARCH_SUNXI) += sunxi
machine-$(CONFIG_ARCH_TEGRA) += tegra
machine-$(CONFIG_ARCH_U8500) += ux500
machine-$(CONFIG_ARCH_VT8500) += vt8500
+machine-$(CONFIG_ARCH_ZTE) += zte
machine-$(CONFIG_ARCH_ZYNQ) += zynq
machine-$(CONFIG_PLAT_VERSATILE) += versatile
machine-$(CONFIG_PLAT_SPEAR) += spear
diff --git a/arch/arm/mach-zte/Kconfig b/arch/arm/mach-zte/Kconfig
new file mode 100644
index 000000000000..24699256863b
--- /dev/null
+++ b/arch/arm/mach-zte/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+menuconfig ARCH_ZTE
+ bool "ZTE zx family"
+ depends on ARCH_MULTI_V7
+ help
+ Support for ZTE zx-based family of processors.
+
+if ARCH_ZTE
+
+config SOC_ZX297520V3
+ default y if ARCH_ZTE
+ bool "ZX297520v3"
+ select ARM_GIC_V3
+ select ARM_AMBA
+ select HAVE_ARM_ARCH_TIMER
+ select PM_GENERIC_DOMAINS if PM
+ help
+ Support for ZTE zx297520v3 SoC. It a single core SoC used in cheap LTE to WiFi routers.
+ These devices can be Identified by the occurrence of the string "zx297520v3" in the boot
+ output and /proc/cpuinfo of their stock firmware.
+
+ Please read Documentation/arch/arm/zte/zx297520v3.rst on how to boot the kernel.
+
+endif
diff --git a/arch/arm/mach-zte/Makefile b/arch/arm/mach-zte/Makefile
new file mode 100644
index 000000000000..1bfe4fddd6af
--- /dev/null
+++ b/arch/arm/mach-zte/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SOC_ZX297520V3) += zx297520v3.o
diff --git a/arch/arm/mach-zte/zx297520v3.c b/arch/arm/mach-zte/zx297520v3.c
new file mode 100644
index 000000000000..c11c7e836f91
--- /dev/null
+++ b/arch/arm/mach-zte/zx297520v3.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 Stefan Dösinger
+ */
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+static const char *const zx297520v3_dt_compat[] __initconst = {
+ "zte,zx297520v3",
+ NULL,
+};
+
+DT_MACHINE_START(ZX, "ZTE zx297520v3 (Device Tree)")
+ .dt_compat = zx297520v3_dt_compat,
+MACHINE_END
--
2.52.0
^ permalink raw reply related
* [PATCH v3 0/8] Add support for ZTE zx297520v3
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
Hi,
This is a follow-up on my RFC patches from January [0]. I made more progress in more work on this SoC and it is time to get serious about code review and upstreaming.
Since my version in January I managed to get more hardware running: SPI, I2C, PMIC with real time clock and voltage regulators, Watchdog. LTE is not working yet, but I am able to start the coprocessor that handles it and talk to it via mailbox + shared memory. Wifi is working on a few more devices. Since WiFi, USB and Ethernet are working, the devices can have actual use with OpenWRT even without LTE.
Another hacker created a free software program to talk to the USB loader [1] and boot uboot and Linux without modifying the on disk files. At the moment it needs a proprietary blob, so my documentation is emphasising booting with the on-device U-Boot.
This patchset here is mostly unmodified from the version I sent in January. It is the bare minimum to get an interactive shell working on the UART. Future patches can be found on my git repository [2] for those curious to peek ahead. The first 30 patches are in reasonable shape, but the further you go the more cleanup is necessary. I expect all of the patches go require a few rounds of feedback though.
My plan for upstreaming is largly this:
1) This bare minimum boot patchset
2) Add clock and pinctrl drivers
3) Add hardware to the device tree that already has existing drivers
4) Add zx29 specific drivers one by one: Watchdog, spi, i2c, DMA, PMIC, battery
5) SDIO backend for rtl8xxxu
6) rproc, mailbox and rpmsg
I am willing to maintain support for the SoC within reason. My patches add myself as maintainer. This is a hobby project for me though, keep that in mind if you want to ship a commercial product with these SoCs and upstreaming Linux.
Cheers,
Stefan
0: https://lists.infradead.org/pipermail/linux-arm-kernel/2026-January/1099306.html
1: https://github.com/zx297520v3-mainline/zx297520v3-loader
2: https://gitlab.com/stefandoesinger/zx297520-kernel/
Stefan Dösinger (8):
ARM: zte: Add zx297520v3 platform support
dt-bindings: arm: Add zx297520v3 board binding
ARM: dts: Add D-Link DWR-932M support
ARM: zte: Add support for zx29 low level debug
ARM: dts: Add an armv7 timer for zx297520v3
ARM: zte: Bring back zx29 UART support
ARM: dts: Declare UART1 on zx297520v3 boards
ARM: defconfig: Add a zx29 defconfig file
Documentation/arch/arm/zte/zx297520v3.rst | 158 ++++++++++++++++++
.../devicetree/bindings/arm/zx29.yaml | 20 +++
MAINTAINERS | 6 +
arch/arm/Kconfig | 2 +
arch/arm/Kconfig.debug | 12 ++
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 +
arch/arm/boot/dts/zte/dlink-dwr-932m.dts | 21 +++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 83 +++++++++
arch/arm/configs/zx29_defconfig | 90 ++++++++++
arch/arm/include/debug/pl01x.S | 7 +
arch/arm/mach-zte/Kconfig | 24 +++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 +++
drivers/tty/serial/amba-pl011.c | 37 ++++
include/linux/amba/bus.h | 6 +
17 files changed, 492 insertions(+)
create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
create mode 100644 Documentation/devicetree/bindings/arm/zx29.yaml
create mode 100644 arch/arm/boot/dts/zte/Makefile
create mode 100644 arch/arm/boot/dts/zte/dlink-dwr-932m.dts
create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi
create mode 100644 arch/arm/configs/zx29_defconfig
create mode 100644 arch/arm/mach-zte/Kconfig
create mode 100644 arch/arm/mach-zte/Makefile
create mode 100644 arch/arm/mach-zte/zx297520v3.c
--
2.52.0
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-14 20:44 UTC (permalink / raw)
To: Alexei Starovoitov, Alexis Lothoré
Cc: Andrey Konovalov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQ+c9h_wuNwj8pjx885oNErGY7bxxCwKi+DiJ0XKSpyYfg@mail.gmail.com>
On Tue Apr 14, 2026 at 9:16 PM CEST, Alexei Starovoitov wrote:
> On Tue, Apr 14, 2026 at 11:41 AM Alexis Lothoré
> <alexis.lothore@bootlin.com> wrote:
>>
>> On Tue Apr 14, 2026 at 4:36 PM CEST, Alexei Starovoitov wrote:
>> > On Tue, Apr 14, 2026 at 6:13 AM Alexis Lothoré
>> > <alexis.lothore@bootlin.com> wrote:
>> >>
>> >> Hi Andrey, thanks for the prompt review !
[...]
>> > No. The performance penalty will be too high.
>>
>> Since we are mentioning it, I did not consider yet any performance
>> comparision/benchmarking (and I am not really familiar with usual bpf
>> performance validation practices for new bpf features). Is there any
>> existing test I should take a look at for this ? Maybe some specific
>> benches in tools/testing/selftests/bpf/bench ?
>
> So far everything in bpf/bench/ measures bpf infra like
> maps, kprobes, tracepoints, etc.
> We don't have benchmarks for bpf programs.
> So we don't know how well JITs are generating code
> and how much inlining done by the verifier, JITs actually helps.
>
> Puranjay is working on creating a SPECint like set of benchmarks.
>
> For this kasan work we should make the best decisions from
> performance point of view, like not wasting unnecessary call
> and not saving unnecessary registers. btw in the other patch
> I think you can skip saving of r10 and r11.
Noted, I'll do some checks and tests without those two.
> But we cannot quantify yet that avoiding extra call gives us N%.
>
> You can micro-benchmark, of course, but gotta be careful
> interpreting the results. It might be too easy to get into
> thinking that JIT must inline __asan_load() for the sake of performance.
Ok, interesting, thanks for those details
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [GIT PULL] Apple SoC fixes for v7.0
From: Sven Peter @ 2026-04-14 20:24 UTC (permalink / raw)
To: soc; +Cc: asahi, linux-arm-kernel, linux-kernel
Hi,
Two fixes without any functional changes, they just update Sasha's email
everywhere and fix a typo in a dtsi file comment.
As discussed with Arnd I'm already sending out the PR now so that you guys can
decide when to merge this.
Thanks,
Sven
The following changes since commit 028ef9c96e96197026887c0f092424679298aae8:
Linux 7.0 (2026-04-12 13:48:06 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux.git tags/apple-soc-fixes-7.0
for you to fetch changes up to c7ff53ef45b2f879576f7bbeb163828d04f5f491:
arm64: dts: apple: Fix spelling error (2026-04-14 22:13:19 +0200)
----------------------------------------------------------------
Apple SoC fixes for 7.0
Two commits without any functional changes that arrived just before the
merge window opened:
- Update Sasha's email address in all dt-bindings, MAINTAINERS and add
him to mailmap
- Fix a typo in spi1-nvram.dtsi
----------------------------------------------------------------
Axel Flordal (1):
arm64: dts: apple: Fix spelling error
Sasha Finkelstein (2):
mailmap: Update Sasha Finkelstein's email address
dt-bindings: Update Sasha Finkelstein's email address
.mailmap | 1 +
.../devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml | 2 +-
Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml | 2 +-
Documentation/devicetree/bindings/display/panel/apple,summit.yaml | 2 +-
Documentation/devicetree/bindings/gpu/apple,agx.yaml | 2 +-
.../devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml | 2 +-
Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml | 2 +-
Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 2 +-
Documentation/devicetree/bindings/spmi/apple,spmi.yaml | 2 +-
MAINTAINERS | 2 +-
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
11 files changed, 11 insertions(+), 10 deletions(-)
^ 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