* [PATCH 2/4] media: rc: sunxi-cir: add support for the A523
From: Justin Suess @ 2026-07-02 21:47 UTC (permalink / raw)
To: Sean Young, Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard
Cc: linux-media, devicetree, linux-arm-kernel, linux-sunxi, Sashiko,
Justin Suess
In-Reply-To: <20260702214750.3428694-1-utilityemal77@gmail.com>
The A523 (sun55i) has a newer revision of the CIR receiver IP. Two
register fields that do not exist on older SoCs must be programmed
for reception to work:
- CTL bits [7:6] select which pulse polarities are captured into the
RX FIFO. The reset value of 0 captures nothing, so program "both
pulse" mode, which captures regardless of header polarity.
- SPLCFG (the sample configuration register) bits [1:0] select the
sample clock as a division of the module clock, replacing the
fixed module clock / 64 sample rate of the older IP. Select
module clock / 256, which together with the 24 MHz module clock
used on the A523 gives a 10.7 μs sample period, close to the 8 μs
of the previous 8 MHz / 64 configuration, and keeps the default
125 ms idle timeout representable in the 8-bit idle threshold
field.
Parameterize the sample divisor in the resolution/timeout
calculations, which older SoCs keep at the fixed 64, and add the
A523 quirks and compatible.
Signed-off-by: Justin Suess <utilityemal77@gmail.com>
---
drivers/media/rc/sunxi-cir.c | 76 ++++++++++++++++++++++++++++++------
1 file changed, 63 insertions(+), 13 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index cb4c56bf0752..82ada9dc0347 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -31,6 +31,11 @@
/* CIR mode */
#define REG_CTL_MD (BIT(4) | BIT(5))
+/* Pulse mode selector (bits [7:6]) */
+#define REG_CTL_PMD(m) ((m) << 6)
+/* Capture both pulse polarities */
+#define REG_CTL_PMD_BOTH REG_CTL_PMD(1)
+
/* Rx Config */
#define SUNXI_IR_RXCTL_REG 0x10
/* Pulse Polarity Invert flag */
@@ -66,6 +71,13 @@
/* IR Sample Config */
#define SUNXI_IR_CIR_REG 0x34
+/*
+ * Sample clock divider select (bits [1:0]), present on newer IP revisions
+ * (e.g. sun55i). Selects the sample clock as a fraction of the module clock;
+ * must be programmed for the sampler to run. Older SoCs lack the field and
+ * use a fixed module-clock/64 sample rate, so they leave it 0.
+ */
+#define REG_CIR_SDIV(val) ((val) & GENMASK(1, 0))
/* CIR_REG register noise threshold */
#define REG_CIR_NTHR(val) (((val) << 2) & (GENMASK(7, 2)))
/* CIR_REG register idle threshold */
@@ -73,6 +85,8 @@
/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
#define SUNXI_IR_BASE_CLK 8000000
+/* Default sample clock divisor: module clock / 64 (legacy fixed rate) */
+#define SUNXI_IR_SAMPLE_DIV 64
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
@@ -81,10 +95,18 @@
*
* @has_reset: SoC needs reset deasserted.
* @fifo_size: size of the fifo.
+ * @both_pulse: program the CTRL pulse-mode field (newer IP revisions).
+ * @sample_div_sel: value for the SPLCFG sample-clock divider field (0 on
+ * legacy SoCs that lack the field).
+ * @sample_divisor: module-clock divisor that yields the sample clock; matches
+ * @sample_div_sel on newer IP, or the fixed /64 on legacy SoCs.
*/
struct sunxi_ir_quirks {
bool has_reset;
int fifo_size;
+ bool both_pulse;
+ u8 sample_div_sel;
+ u32 sample_divisor;
};
struct sunxi_ir {
@@ -92,6 +114,9 @@ struct sunxi_ir {
void __iomem *base;
int irq;
int fifo_size;
+ bool both_pulse;
+ u8 sample_div_sel;
+ u32 sample_divisor;
struct clk *clk;
struct clk *apb_clk;
struct reset_control *rst;
@@ -140,17 +165,19 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
}
/* Convert idle threshold to usec */
-static unsigned int sunxi_ithr_to_usec(unsigned int base_clk, unsigned int ithr)
+static unsigned int sunxi_ithr_to_usec(unsigned int base_clk, unsigned int div,
+ unsigned int ithr)
{
return DIV_ROUND_CLOSEST(USEC_PER_SEC * (ithr + 1),
- base_clk / (128 * 64));
+ base_clk / (128 * div));
}
/* Convert usec to idle threshold */
-static unsigned int sunxi_usec_to_ithr(unsigned int base_clk, unsigned int usec)
+static unsigned int sunxi_usec_to_ithr(unsigned int base_clk, unsigned int div,
+ unsigned int usec)
{
/* make sure we don't end up with a timeout less than requested */
- return DIV_ROUND_UP((base_clk / (128 * 64)) * usec, USEC_PER_SEC) - 1;
+ return DIV_ROUND_UP((base_clk / (128 * div)) * usec, USEC_PER_SEC) - 1;
}
static int sunxi_ir_set_timeout(struct rc_dev *rc_dev, unsigned int timeout)
@@ -158,15 +185,17 @@ static int sunxi_ir_set_timeout(struct rc_dev *rc_dev, unsigned int timeout)
struct sunxi_ir *ir = rc_dev->priv;
unsigned int base_clk = clk_get_rate(ir->clk);
- unsigned int ithr = sunxi_usec_to_ithr(base_clk, timeout);
+ unsigned int ithr = sunxi_usec_to_ithr(base_clk, ir->sample_divisor,
+ timeout);
dev_dbg(rc_dev->dev.parent, "setting idle threshold to %u\n", ithr);
- /* Set noise threshold and idle threshold */
- writel(REG_CIR_NTHR(SUNXI_IR_RXNOISE) | REG_CIR_ITHR(ithr),
+ /* Set sample clock divider, noise threshold and idle threshold */
+ writel(REG_CIR_SDIV(ir->sample_div_sel) |
+ REG_CIR_NTHR(SUNXI_IR_RXNOISE) | REG_CIR_ITHR(ithr),
ir->base + SUNXI_IR_CIR_REG);
- rc_dev->timeout = sunxi_ithr_to_usec(base_clk, ithr);
+ rc_dev->timeout = sunxi_ithr_to_usec(base_clk, ir->sample_divisor, ithr);
return 0;
}
@@ -193,8 +222,14 @@ static int sunxi_ir_hw_init(struct device *dev)
goto exit_disable_apb_clk;
}
- /* Enable CIR Mode */
- writel(REG_CTL_MD, ir->base + SUNXI_IR_CTL_REG);
+ /*
+ * Enable CIR Mode. On newer IP revisions the pulse-mode field must
+ * also be set, otherwise no pulses are captured into the RX FIFO.
+ */
+ tmp = REG_CTL_MD;
+ if (ir->both_pulse)
+ tmp |= REG_CTL_PMD_BOTH;
+ writel(tmp, ir->base + SUNXI_IR_CTL_REG);
/* Set noise threshold and idle threshold */
sunxi_ir_set_timeout(ir->rc, ir->rc->timeout);
@@ -271,6 +306,9 @@ static int sunxi_ir_probe(struct platform_device *pdev)
}
ir->fifo_size = quirks->fifo_size;
+ ir->both_pulse = quirks->both_pulse;
+ ir->sample_div_sel = quirks->sample_div_sel;
+ ir->sample_divisor = quirks->sample_divisor ?: SUNXI_IR_SAMPLE_DIV;
/* Clock */
ir->apb_clk = devm_clk_get(dev, "apb");
@@ -325,10 +363,10 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
/* Frequency after IR internal divider with sample period in us */
- ir->rc->rx_resolution = (USEC_PER_SEC / (b_clk_freq / 64));
+ ir->rc->rx_resolution = (USEC_PER_SEC / (b_clk_freq / ir->sample_divisor));
ir->rc->timeout = IR_DEFAULT_TIMEOUT;
- ir->rc->min_timeout = sunxi_ithr_to_usec(b_clk_freq, 0);
- ir->rc->max_timeout = sunxi_ithr_to_usec(b_clk_freq, 255);
+ ir->rc->min_timeout = sunxi_ithr_to_usec(b_clk_freq, ir->sample_divisor, 0);
+ ir->rc->max_timeout = sunxi_ithr_to_usec(b_clk_freq, ir->sample_divisor, 255);
ir->rc->s_timeout = sunxi_ir_set_timeout;
ir->rc->driver_name = SUNXI_IR_DEV;
@@ -395,6 +433,14 @@ static const struct sunxi_ir_quirks sun6i_a31_ir_quirks = {
.fifo_size = 64,
};
+static const struct sunxi_ir_quirks sun55i_a523_ir_quirks = {
+ .has_reset = true,
+ .fifo_size = 64,
+ .both_pulse = true,
+ .sample_div_sel = 2, /* sample clock = module clock / 256 */
+ .sample_divisor = 256,
+};
+
static const struct of_device_id sunxi_ir_match[] = {
{
.compatible = "allwinner,sun4i-a10-ir",
@@ -408,6 +454,10 @@ static const struct of_device_id sunxi_ir_match[] = {
.compatible = "allwinner,sun6i-a31-ir",
.data = &sun6i_a31_ir_quirks,
},
+ {
+ .compatible = "allwinner,sun55i-a523-ir",
+ .data = &sun55i_a523_ir_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sunxi_ir_match);
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: allwinner: a523: add IR receiver node
From: Justin Suess @ 2026-07-02 21:47 UTC (permalink / raw)
To: Sean Young, Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard
Cc: linux-media, devicetree, linux-arm-kernel, linux-sunxi, Sashiko,
Justin Suess
In-Reply-To: <20260702214750.3428694-1-utilityemal77@gmail.com>
The A523 has a CIR receiver in the RTC power domain, clocked from the
R-CCU, with its RX signal available on PL11.
Clock the module directly from the 24 MHz host oscillator; the driver
selects a /256 sample divider on this SoC, giving a sample period
close to the legacy 8 MHz / 64 configuration of older SoCs.
Keep the node disabled by default; boards with an IR receiver can
enable it.
Signed-off-by: Justin Suess <utilityemal77@gmail.com>
---
.../arm64/boot/dts/allwinner/sun55i-a523.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
index ca6a16807049..5e46c4b1ee61 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
@@ -927,6 +927,25 @@ r_i2c_pins: r-i2c-pins {
allwinner,pinmux = <2>;
function = "r_i2c0";
};
+
+ r_ir_rx_pin: r-ir-rx-pin {
+ pins = "PL11";
+ allwinner,pinmux = <2>;
+ function = "s_cir";
+ };
+ };
+
+ r_ir: ir@7040000 {
+ compatible = "allwinner,sun55i-a523-ir";
+ reg = <0x07040000 0x400>;
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_BUS_R_IR_RX>, <&r_ccu CLK_R_IR_RX>;
+ clock-names = "apb", "ir";
+ clock-frequency = <24000000>;
+ resets = <&r_ccu RST_BUS_R_IR_RX>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_ir_rx_pin>;
+ status = "disabled";
};
pck600: power-controller@7060000 {
--
2.54.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: allwinner: a523: enable IR receiver on the X96Q Pro+
From: Justin Suess @ 2026-07-02 21:47 UTC (permalink / raw)
To: Sean Young, Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard
Cc: linux-media, devicetree, linux-arm-kernel, linux-sunxi, Sashiko,
Justin Suess
In-Reply-To: <20260702214750.3428694-1-utilityemal77@gmail.com>
The X96Q Pro+ TV box has an IR receiver window on the front panel,
wired to the SoC CIR input on PL11.
Enable the CIR receiver.
Signed-off-by: Justin Suess <utilityemal77@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
index a96927fbdadd..de2bdc21c781 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
@@ -266,6 +266,10 @@ reg_dcdc3_323: dcdc3 {
};
};
+&r_ir {
+ status = "okay";
+};
+
&r_pio {
/*
* Specifying the supply would create a circular dependency.
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 6/6] KVM: arm64: ptdump: Introduce the shadow ptdump file
From: Itaru Kitayama @ 2026-07-02 21:48 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Sebastian Ene
In-Reply-To: <20260630121005.1130996-7-weilin.chang@arm.com>
On Tue, Jun 30, 2026 at 01:10:05PM +0100, Wei-Lin Chang wrote:
> Create a ptdump file for all shadow page tables. It will dump out all
> valid shadow page tables at the time of request, with the mmu's index,
> guest VTCR_EL2, VTTBR_EL2, and whether the guest stage-2 is enabled or
> not.
>
> Also detach the nested mmu array under the mmu_lock in
> kvm_arch_flush_shadow_all() so readers cannot race with the array being
> removed, then free the old array after dropping the lock.
>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/kvm/nested.c | 12 ++++++--
> arch/arm64/kvm/ptdump.c | 61 ++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 69 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 6435efd65cb5..17a180ddf6ca 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1283,6 +1283,7 @@ void kvm_nested_s2_flush(struct kvm *kvm)
>
> void kvm_arch_flush_shadow_all(struct kvm *kvm)
> {
> + struct kvm_s2_mmu *mmus;
> int i;
>
> for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
> @@ -1291,9 +1292,14 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm)
> if (!WARN_ON(atomic_read(&mmu->refcnt)))
> kvm_free_stage2_pgd(mmu);
> }
> - kvfree(kvm->arch.nested_mmus);
> - kvm->arch.nested_mmus = NULL;
> - kvm->arch.nested_mmus_size = 0;
> +
> + scoped_guard(write_lock, &kvm->mmu_lock) {
> + mmus = kvm->arch.nested_mmus;
> + kvm->arch.nested_mmus = NULL;
> + kvm->arch.nested_mmus_size = 0;
> + }
> +
> + kvfree(mmus);
> kvm_uninit_stage2_mmu(kvm);
> }
>
> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> index 40f93b7c7ad9..1649eaa75798 100644
> --- a/arch/arm64/kvm/ptdump.c
> +++ b/arch/arm64/kvm/ptdump.c
> @@ -181,6 +181,50 @@ static int kvm_ptdump_guest_canonical_show(struct seq_file *m, void *unused)
> return 0;
> }
>
> +static int kvm_ptdump_guest_nested_show(struct seq_file *m, void *unused)
> +{
> + int ret = 0, i;
> + struct kvm_ptdump_guest_state *st = m->private;
> + struct kvm *kvm = st->kvm;
> + struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
> + .cb = kvm_ptdump_visitor,
> + .arg = &st->parser_state,
> + .flags = KVM_PGTABLE_WALK_LEAF,
> + };
> +
> + guard(write_lock)(&kvm->mmu_lock);
> +
> + if (!kvm->arch.nested_mmus)
> + return 0;
> +
> + for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
> + struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
> +
> + if (!mmu->pgt)
> + continue;
> +
> + if (kvm_s2_mmu_valid(mmu)) {
> + memset(st, 0, sizeof(*st));
> + ret = kvm_ptdump_parser_init(st, kvm, mmu->pgt);
> + if (ret)
> + return ret;
> + st->parser_state = (struct ptdump_pg_state) {
> + .marker = &st->ipa_marker[0],
> + .level = -1,
> + .pg_level = &st->level[0],
> + .seq = m,
> + };
> + seq_printf(m, "nested mmu %d VTCR: 0x%016llx VTTBR: 0x%016llx s2: %s\n",
> + i, mmu->tlb_vtcr, mmu->tlb_vttbr,
> + mmu->nested_stage2_enabled ? "enabled" : "disabled");
This header information in the debugfs "shadow_page_tables" file, under
the nested directory is showing guest hypervisor's configuration while
the file is designed to show nested guest's shadwo stage 2 translation
tables layouts owned by Host EL2 hypervisor. Is this intentional?
Thanks,
Itaru.
> + ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> + if (ret)
> + return ret;
> + }
> + }
> + return ret;
> +}
> +
> static int kvm_ptdump_guest_open(struct inode *m, struct file *file,
> int (*show)(struct seq_file *, void *))
> {
> @@ -212,6 +256,11 @@ static int kvm_ptdump_guest_canonical_open(struct inode *m, struct file *file)
> return kvm_ptdump_guest_open(m, file, kvm_ptdump_guest_canonical_show);
> }
>
> +static int kvm_ptdump_guest_nested_open(struct inode *m, struct file *file)
> +{
> + return kvm_ptdump_guest_open(m, file, kvm_ptdump_guest_nested_show);
> +}
> +
> static int kvm_ptdump_guest_close(struct inode *m, struct file *file)
> {
> struct kvm *kvm = m->i_private;
> @@ -230,6 +279,13 @@ static const struct file_operations kvm_ptdump_guest_canonical_fops = {
> .release = kvm_ptdump_guest_close,
> };
>
> +static const struct file_operations kvm_ptdump_guest_nested_fops = {
> + .open = kvm_ptdump_guest_nested_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = kvm_ptdump_guest_close,
> +};
> +
> static int kvm_pgtable_range_show(struct seq_file *m, void *unused)
> {
> struct kvm *kvm = m->private;
> @@ -307,6 +363,9 @@ void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
> kvm, &kvm_pgtable_range_fops);
> debugfs_create_file("stage2_levels", 0400, kvm->debugfs_dentry,
> kvm, &kvm_pgtable_levels_fops);
> - if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT))
> + if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT)) {
> kvm->arch.debugfs_nv_dentry = debugfs_create_dir("nested", kvm->debugfs_dentry);
> + debugfs_create_file("shadow_page_tables", 0400, kvm->arch.debugfs_nv_dentry,
> + kvm, &kvm_ptdump_guest_nested_fops);
> + }
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 7/7] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Thomas Gleixner @ 2026-07-02 21:55 UTC (permalink / raw)
To: Lorenzo Pieralisi, Rafael J. Wysocki, Len Brown, Sunil V L,
Marc Zyngier, Huacai Chen, Anup Patel, Hanjun Guo, Sudeep Holla,
Catalin Marinas, Will Deacon
Cc: linux-riscv, linux-kernel, linux-acpi, linux-arm-kernel,
loongarch, Lorenzo Pieralisi, Rafael J. Wysocki
In-Reply-To: <20260701-gic-v5-acpi-iwb-probe-deferral-v3-7-c5562cf0fe29@kernel.org>
On Wed, Jul 01 2026 at 16:38, Lorenzo Pieralisi wrote:
> Register an ACPI hook in the ACPI interrupt management code for GICv5 to
> retrieve the ACPI interrupt controller handle (if any) of the controller
> handling a specific GSI, by updating the acpi_set_irq_model() call with
> the gic_v5_get_gsi_handle() function pointer parameter.
>
> gicv5_get_gsi_handle() allows ACPI core to detect the ACPI handle
> of the controller that manages a specific GSI interrupt.
>
> Update the IWB driver to clear device dependencies in ACPI core once the
> IWB driver has probed.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
Assuming this goes through the ACPI tree:
Acked-by: Thomas Gleixner <tglx@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 7/7] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Thomas Gleixner @ 2026-07-02 21:56 UTC (permalink / raw)
To: Lorenzo Pieralisi, Rafael J. Wysocki, Len Brown, Sunil V L,
Marc Zyngier, Huacai Chen, Anup Patel, Hanjun Guo, Sudeep Holla,
Catalin Marinas, Will Deacon
Cc: linux-riscv, linux-kernel, linux-acpi, linux-arm-kernel,
loongarch, Lorenzo Pieralisi, Rafael J. Wysocki
In-Reply-To: <878q7tnjj2.ffs@fw13>
On Thu, Jul 02 2026 at 23:55, Thomas Gleixner wrote:
> On Wed, Jul 01 2026 at 16:38, Lorenzo Pieralisi wrote:
>> Register an ACPI hook in the ACPI interrupt management code for GICv5 to
>> retrieve the ACPI interrupt controller handle (if any) of the controller
>> handling a specific GSI, by updating the acpi_set_irq_model() call with
>> the gic_v5_get_gsi_handle() function pointer parameter.
>>
>> gicv5_get_gsi_handle() allows ACPI core to detect the ACPI handle
>> of the controller that manages a specific GSI interrupt.
>>
>> Update the IWB driver to clear device dependencies in ACPI core once the
>> IWB driver has probed.
>>
>> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
>> Cc: Thomas Gleixner <tglx@kernel.org>
>
> Assuming this goes through the ACPI tree:
>
> Acked-by: Thomas Gleixner <tglx@kernel.org>
If that's not the plan, let me know and I pick it up.
^ permalink raw reply
* [PATCH 02/12] arm64: dts: rockchip: refactor rk3588s-nanopi* to support M6
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
Refactor FriendlyElec NanoPi R6 boards based on RK3588S SoC in
preparation to add support the NanoPi M6 board.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts | 2 +-
.../boot/dts/rockchip/{rk3588s-nanopi-r6.dtsi => rk3588s-nanopi.dtsi} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
index ccc5e4627517..77fef2662ca5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-nanopi-r6.dtsi"
+#include "rk3588s-nanopi.dtsi"
/ {
model = "FriendlyElec NanoPi R6C";
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
index 9c3e0b0daaac..f8993418a122 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-nanopi-r6.dtsi"
+#include "rk3588s-nanopi.dtsi"
/ {
model = "FriendlyElec NanoPi R6S";
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
rename to arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v4 4/6] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Marc Zyngier @ 2026-07-02 22:10 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, lpieralisi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260702033050.1583-5-shikemeng@huaweicloud.com>
On Thu, 02 Jul 2026 04:30:48 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> Multiple ITS units may exist in a system. When an error occurs, it is
> difficult to identify which ITS triggered it because most error logs
> lack the ITS address. Some logs already include this information and
> is useful for debugging. Add the ITS address to the remaining error
> logs so that all ITS-related errors can be consistently attributed to
> a specific ITS instance.
I already said *no* to this.
If you want to log errors, implement a PMU or RAS driver that reports
errors on a per ITS basis, in a way that is collectable by existing
tooling.
The kernel log is not the place for your sorry debug hacks, which is
in general not readable by normal users. And I'd rather remove the
other instances as a matter of consistency.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH 00/12] arm64: dts: rockchip: Add NanoPi M6 board
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
This patch series add support for the NanoPi M6. This board is very
similar to the NanoPi R6C and R6S boards which are already supported.
Main differences:
* M.2 M-key slot with PCIe (Also present on R6C)
* M.2 E-key slot with PCIe and USB (from hub)
* 1 additional USB 2.0 port from an on-board USB hub
* RT5616 audio CODEC
Patch 2 and 3 moves a bit code around. Please let me know if those two
should be squashed together.
Next few patches adds some missing bits the common nanopi dtsi file.
While the final patch adds support for NanoPi M6.
All changes have been verified using the schematics for M6, R6C and R6S.
Only M6 have been boot and runtime tested. Tester for R6x are welcome.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
Joachim Eastwood (12):
dt-bindings: arm: rockchip: add FriendlyElec NanoPi M6
arm64: dts: rockchip: refactor rk3588s-nanopi* to support M6
arm64: dts: rockchip: move NanoPi R6 code into common dtsi
arm64: dts: rockchip: rk3588s-nanopi: add missing sdmmc cd pinctrl
arm64: dts: rockchip: rk3588s-nanopi: remove pull up on rtc int pin
arm64: dts: rockchip: rk3588s-nanopi: add missing pcie rst pinctrl
arm64: dts: rockchip: rk3588s-nanopi: pcie2x1l2: add clkreq
arm64: dts: rockchip: rk3588s-nanopi: remove always-on from vdd_npu_s0 reg
arm64: dts: rockchip: rk3588s-nanopi: remove useless vcc_3v3_pcie20
arm64: dts: rockchip: rk3588s-nanopi: add gmac1 add phy-supply
arm64: dts: rockchip: rk3588s-nanopi: remove bogus vcc5v0_usb regulator
arm64: dts: rockchip: add support for NanoPi M6 board
.../devicetree/bindings/arm/rockchip.yaml | 3 +-
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-m6.dts | 200 ++++++
.../arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 792 --------------------
.../arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 1 +
.../arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 800 +++++++++++++++++++++
7 files changed, 1005 insertions(+), 793 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260701-nanopi-m6-ffeef7252fd7
Best regards,
--
Joachim Eastwood <joachim.eastwood@gmail.com>
^ permalink raw reply
* [PATCH 05/12] arm64: dts: rockchip: rk3588s-nanopi: remove pull up on rtc int pin
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
All boards in the RK3588S NanoPi familiy has a pull on the PCB for the
RTC interrupt pin. So there is no need to enable the pull-up in the SoC.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index a8f32b994b10..f3a240b48a2a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -331,7 +331,7 @@ hdmi0_tx_on_h: hdmi0-tx-on-h {
hym8563 {
rtc_int: rtc-int {
- rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
--
2.55.0
^ permalink raw reply related
* [PATCH 03/12] arm64: dts: rockchip: move NanoPi R6 code into common dtsi
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
Move NanoPi R6C and R6S specific DT into its own file.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
.../arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 96 ++++++++++++++++++++++
.../arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts | 1 +
.../arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 89 --------------------
4 files changed, 98 insertions(+), 89 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
new file mode 100644
index 000000000000..2f8c580afc2b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/ {
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&key1_pin>;
+
+ button-user {
+ label = "User";
+ linux,code = <BTN_1>;
+ gpios = <&gpio1 RK_PC0 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ sys_led: led-0 {
+ label = "sys_led";
+ gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sys_led_pin>;
+ };
+
+ wan_led: led-1 {
+ label = "wan_led";
+ gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wan_led_pin>;
+ };
+
+ lan1_led: led-2 {
+ label = "lan1_led";
+ gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan1_led_pin>;
+ };
+
+ lan2_led: led-3 {
+ gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan2_led_pin>;
+ };
+ };
+
+ vcc5v0_usb_otg0: regulator-vcc5v0-usb-otg0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&typec5v_pwren>;
+ regulator-name = "vcc5v0_usb_otg0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_usb>;
+ };
+};
+
+&pinctrl {
+ gpio-key {
+ key1_pin: key1-pin {
+ rockchip,pins = <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ gpio-leds {
+ sys_led_pin: sys-led-pin {
+ rockchip,pins =
+ <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wan_led_pin: wan-led-pin {
+ rockchip,pins =
+ <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ lan1_led_pin: lan1-led-pin {
+ rockchip,pins =
+ <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ lan2_led_pin: lan2-led-pin {
+ rockchip,pins =
+ <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ typec5v_pwren: typec5v-pwren {
+ rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
index 77fef2662ca5..90922c55da37 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6c.dts
@@ -3,6 +3,7 @@
/dts-v1/;
#include "rk3588s-nanopi.dtsi"
+#include "rk3588s-nanopi-r6.dtsi"
/ {
model = "FriendlyElec NanoPi R6C";
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
index f8993418a122..8b318561342c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6s.dts
@@ -3,6 +3,7 @@
/dts-v1/;
#include "rk3588s-nanopi.dtsi"
+#include "rk3588s-nanopi-r6.dtsi"
/ {
model = "FriendlyElec NanoPi R6S";
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index 91b6eefd7abf..d41c49716fa2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -33,19 +33,6 @@ button-maskrom {
};
};
- gpio-keys {
- compatible = "gpio-keys";
- pinctrl-names = "default";
- pinctrl-0 = <&key1_pin>;
-
- button-user {
- label = "User";
- linux,code = <BTN_1>;
- gpios = <&gpio1 RK_PC0 GPIO_ACTIVE_LOW>;
- debounce-interval = <50>;
- };
- };
-
hdmi-con {
compatible = "hdmi-connector";
type = "a";
@@ -57,38 +44,6 @@ hdmi_con_in: endpoint {
};
};
- leds {
- compatible = "gpio-leds";
-
- sys_led: led-0 {
- label = "sys_led";
- gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- pinctrl-names = "default";
- pinctrl-0 = <&sys_led_pin>;
- };
-
- wan_led: led-1 {
- label = "wan_led";
- gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&wan_led_pin>;
- };
-
- lan1_led: led-2 {
- label = "lan1_led";
- gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&lan1_led_pin>;
- };
-
- lan2_led: led-3 {
- gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&lan2_led_pin>;
- };
- };
-
vcc5v0_sys: regulator-vcc5v0-sys {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_sys";
@@ -151,18 +106,6 @@ vcc5v0_usb: regulator-vcc5v0-usb {
vin-supply = <&vcc5v0_sys>;
};
- vcc5v0_usb_otg0: regulator-vcc5v0-usb-otg0 {
- compatible = "regulator-fixed";
- enable-active-high;
- gpios = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&typec5v_pwren>;
- regulator-name = "vcc5v0_usb_otg0";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc5v0_usb>;
- };
-
vcc5v0_host_20: regulator-vcc5v0-host-20 {
compatible = "regulator-fixed";
enable-active-high;
@@ -380,34 +323,6 @@ &pd_npu {
};
&pinctrl {
- gpio-key {
- key1_pin: key1-pin {
- rockchip,pins = <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-
- gpio-leds {
- sys_led_pin: sys-led-pin {
- rockchip,pins =
- <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- wan_led_pin: wan-led-pin {
- rockchip,pins =
- <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- lan1_led_pin: lan1-led-pin {
- rockchip,pins =
- <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- lan2_led_pin: lan2-led-pin {
- rockchip,pins =
- <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
hdmi {
hdmi0_tx_on_h: hdmi0-tx-on-h {
rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
@@ -427,10 +342,6 @@ sd_s0_pwr: sd-s0-pwr {
};
usb {
- typec5v_pwren: typec5v-pwren {
- rockchip,pins = <1 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
vcc5v0_host20_en: vcc5v0-host20-en {
rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
};
--
2.55.0
^ permalink raw reply related
* [PATCH 04/12] arm64: dts: rockchip: rk3588s-nanopi: add missing sdmmc cd pinctrl
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
The cd (card detect) pin is used, but not reserved through pinctrl.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index d41c49716fa2..a8f32b994b10 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -336,6 +336,10 @@ rtc_int: rtc-int {
};
sdmmc {
+ sdmmc_det_pin: sdmmc-det-pin {
+ rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
sd_s0_pwr: sd-s0-pwr {
rockchip,pins = <4 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
};
@@ -407,6 +411,8 @@ &sdmmc {
no-mmc;
no-sdio;
sd-uhs-sdr104;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_det_pin>;
vmmc-supply = <&vcc_3v3_sd_s0>;
vqmmc-supply = <&vccio_sd_s0>;
status = "okay";
--
2.55.0
^ permalink raw reply related
* [PATCH 09/12] arm64: dts: rockchip: rk3588s-nanopi: remove useless vcc_3v3_pcie20
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
There is no separate regulator for boards with RTL8125BG MACs.
The power is only separated from VCC_3V3_S3 with a ferrite bead.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index 463cfeddf270..e4900af9822a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -86,16 +86,6 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
vin-supply = <&vcc_3v3_s3>;
};
- vcc_3v3_pcie20: regulator-vcc3v3-pcie20 {
- compatible = "regulator-fixed";
- regulator-name = "vcc_3v3_pcie20";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vcc_3v3_s3>;
- };
-
vcc5v0_usb: regulator-vcc5v0-usb {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_usb";
@@ -305,7 +295,7 @@ &pcie2x1l1 {
pinctrl-names = "default";
pinctrl-0 = <&pcie2_1_rst>;
reset-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
- vpcie3v3-supply = <&vcc_3v3_pcie20>;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
status = "okay";
};
@@ -314,7 +304,7 @@ &pcie2x1l2 {
pinctrl-0 = <&pcie2_2_rst>, <&pcie20x1m0_clkreqn>;
supports-clkreq;
reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
- vpcie3v3-supply = <&vcc_3v3_pcie20>;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
status = "okay";
};
--
2.55.0
^ permalink raw reply related
* [PATCH 11/12] arm64: dts: rockchip: rk3588s-nanopi: remove bogus vcc5v0_usb regulator
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
All USB regulators (power switches) are feed from the main vcc5v0
supply. There is no regulator or switch in between.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 2 +-
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 12 +-----------
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
index 2f8c580afc2b..ff579f75d8d3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi
@@ -55,7 +55,7 @@ vcc5v0_usb_otg0: regulator-vcc5v0-usb-otg0 {
regulator-name = "vcc5v0_usb_otg0";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc5v0_usb>;
+ vin-supply = <&vcc5v0_sys>;
};
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index 596b5a64c191..43b9342bbf14 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -86,16 +86,6 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
vin-supply = <&vcc_3v3_s3>;
};
- vcc5v0_usb: regulator-vcc5v0-usb {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_usb";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc5v0_sys>;
- };
-
vcc5v0_host_20: regulator-vcc5v0-host-20 {
compatible = "regulator-fixed";
enable-active-high;
@@ -105,7 +95,7 @@ vcc5v0_host_20: regulator-vcc5v0-host-20 {
regulator-name = "vcc5v0_host_20";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc5v0_usb>;
+ vin-supply = <&vcc5v0_sys>;
};
};
--
2.55.0
^ permalink raw reply related
* [PATCH 10/12] arm64: dts: rockchip: rk3588s-nanopi: add gmac1 add phy-supply
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
The RTL8211F Ethernet phy is power from the VCC_3V3_S3 rail.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index e4900af9822a..596b5a64c191 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -153,6 +153,7 @@ &gmac1 {
clock_in_out = "output";
phy-handle = <&rgmii_phy1>;
phy-mode = "rgmii-rxid";
+ phy-supply = <&vcc_3v3_s3>;
pinctrl-0 = <&gmac1_miim
&gmac1_tx_bus2
&gmac1_rx_bus2
--
2.55.0
^ permalink raw reply related
* [PATCH 01/12] dt-bindings: arm: rockchip: add FriendlyElec NanoPi M6
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
Add device tree binding documentation for FriendlyElec NanoPi M6,
a single-board computer based on the Rockchip RK3588S SoC. Very
similar to NanoPi R6C and R6S.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde18626d..6ba512964c25 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -344,9 +344,10 @@ properties:
- friendlyarm,nanopi-r5s
- const: rockchip,rk3568
- - description: FriendlyElec NanoPi R6 series boards
+ - description: FriendlyElec NanoPi6 series boards
items:
- enum:
+ - friendlyarm,nanopi-m6
- friendlyarm,nanopi-r6c
- friendlyarm,nanopi-r6s
- const: rockchip,rk3588s
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v4 3/6] irqchip/gic-v3-its: Fix leak in its_vpe_irq_domain_alloc()
From: Marc Zyngier @ 2026-07-02 22:12 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, jason, lpieralisi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260702033050.1583-4-shikemeng@huaweicloud.com>
On Thu, 02 Jul 2026 04:30:47 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> When its_irq_gic_domain_alloc() fails, the following
> its_vpe_irq_domain_free() skips calling its_vep_teardown() for the
> corresponding irq. Call its_vpe_teardown() when its_irq_gic_domain_alloc()
> is failedto avoid the leak issue.
>
> Fixes: 7d75bbb4bc1ad ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown")
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 3e4edcb64065..8968bedefdba 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4666,8 +4666,10 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq
> break;
> err = its_irq_gic_domain_alloc(domain, virq + i,
> vm->vpes[i]->vpe_db_lpi);
> - if (err)
> + if (err) {
> + its_vpe_teardown(vm->vpes[i]);
> break;
> + }
There is already a spot for error handling in this function, we don't
need a second one.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH 07/12] arm64: dts: rockchip: rk3588s-nanopi: pcie2x1l2: add clkreq
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
The clkreq is present on the board, so hook it up in DT.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index 361682c18e69..bcb2f5d63a61 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -312,7 +312,8 @@ &pcie2x1l1 {
&pcie2x1l2 {
pinctrl-names = "default";
- pinctrl-0 = <&pcie2_2_rst>;
+ pinctrl-0 = <&pcie2_2_rst>, <&pcie20x1m0_clkreqn>;
+ supports-clkreq;
reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc_3v3_pcie20>;
status = "okay";
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v3 4/5] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Thomas Gleixner @ 2026-07-02 22:18 UTC (permalink / raw)
To: Marek Vasut, linux-pci
Cc: Marek Vasut, Marc Zyngier, Yoshihiro Shimoda,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260701203918.63189-5-marek.vasut+renesas@mailbox.org>
On Wed, Jul 01 2026 at 22:37, Marek Vasut wrote:
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> The quirk is keyed on the combination of the GIC implementation
> and the platform identification in the device tree.
>
> Acked-by: Marc Zyngier <maz@kernel.org>
> Co-developed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Assuming this goes through the PCI tree:
Acked-by: Thomas Gleixner <tglx@kernel.org>
^ permalink raw reply
* [PATCH 12/12] arm64: dts: rockchip: add support for NanoPi M6 board
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
The NanoPi M6 board shares most of the features of the R6 boards.
Main differences:
* M.2 M-key slot with PCIe (Also present on R6C)
* M.2 E-key slot with PCIe and USB (from hub)
* 1 additional USB 2.0 port from an on-board USB hub
* RT5616 audio CODEC
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-m6.dts | 200 +++++++++++++++++++++
2 files changed, 201 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 761d82b4f4f2..2867830eddf8 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -218,6 +218,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-gameforce-ace.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-indiedroid-nova.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-khadas-edge2.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-m6.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-m6.dts b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-m6.dts
new file mode 100644
index 000000000000..64448bf55cf7
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi-m6.dts
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-nanopi.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi M6";
+ compatible = "friendlyarm,nanopi-m6", "rockchip,rk3588s";
+
+ sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_det>;
+
+ simple-audio-card,name = "realtek,rt5616-codec";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,mclk-fs = <256>;
+
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_LOW>;
+
+ simple-audio-card,widgets =
+ "Headphone", "Headphones",
+ "Microphone", "Microphone Jack";
+ simple-audio-card,routing =
+ "Headphones", "HPOL",
+ "Headphones", "HPOR",
+ "MIC1", "Microphone Jack",
+ "Microphone Jack", "micbias1";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0_8ch>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&rt5616>;
+ };
+ };
+
+ adc-keys-1 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-maskrom {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ press-threshold-microvolt = <1800>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ sys_led: led-0 {
+ label = "sys_led";
+ gpios = <&gpio1 RK_PA4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sys_led_pin>;
+ };
+
+ user_led: led-1 {
+ label = "user_led";
+ gpios = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_led_pin>;
+ };
+ };
+
+ vcc_3v3_pcie: regulator-vcc-3v3-pcie {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2_2_pwren>;
+ regulator-name = "vcc_3v3_pcie";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc5v0_usb_otg0: regulator-vcc5v0-usb-otg0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PD4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&typec5v_pwren>;
+ regulator-name = "vcc5v0_usb_otg0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vdd_mpcie_3v3: regulator-vdd-mpcie-3v3 {
+ compatible = "regulator-fixed";
+ /* Controlled by EXT_EN on RK806 */
+ regulator-name = "vdd_mpcie_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&i2c7 {
+ clock-frequency = <200000>;
+ status = "okay";
+
+ rt5616: codec@1b {
+ compatible = "realtek,rt5616";
+ reg = <0x1b>;
+ clocks = <&cru I2S0_8CH_MCLKOUT>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ assigned-clocks = <&cru I2S0_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+
+ port {
+ rt5616_p0_0: endpoint {
+ remote-endpoint = <&i2s0_8ch_p0_0>;
+ };
+ };
+ };
+};
+
+&i2s0_8ch {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0_lrck
+ &i2s0_mclk
+ &i2s0_sclk
+ &i2s0_sdi0
+ &i2s0_sdo0>;
+ status = "okay";
+
+ i2s0_8ch_p0: port {
+ i2s0_8ch_p0_0: endpoint {
+ dai-format = "i2s";
+ mclk-fs = <256>;
+ remote-endpoint = <&rt5616_p0_0>;
+ };
+ };
+};
+
+&pcie2x1l1 { /* M.2 E-key 2230 */
+ vpcie3v3-supply = <&vdd_mpcie_3v3>;
+};
+
+&pcie2x1l2 { /* M.2 M-key 2280 */
+ pinctrl-0 = <&pcie2_2_rst>, <&pcie20x1m0_clkreqn>, <&pcie20x1m0_waken>;
+ vpcie3v3-supply = <&vcc_3v3_pcie>;
+};
+
+&pinctrl {
+ gpio-leds {
+ sys_led_pin: sys-led-pin {
+ rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ user_led_pin: user-led-pin {
+ rockchip,pins = <1 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ headphone {
+ hp_det: hp-det {
+ rockchip,pins = <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ pcie2_2_pwren: pcie2-2-pwren {
+ rockchip,pins = <3 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ typec5v_pwren: typec5v-pwren {
+ rockchip,pins = <3 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&u2phy3 {
+ status = "okay";
+};
+
+&u2phy3_host {
+ phy-supply = <&vcc5v0_host_20>;
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v2 0/6] KVM: arm64: ptdump: Shadow ptdump fixes
From: Itaru Kitayama @ 2026-07-02 23:02 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Sebastian Ene
In-Reply-To: <vfzn6kbhyemhkum2s72yucbgj4shn7j3g7qd3iima242yph2fr@vdihx2sfibki>
On Thu, Jul 02, 2026 at 08:41:43AM +0100, Wei-Lin Chang wrote:
> On Thu, Jul 02, 2026 at 03:55:48PM +0900, Itaru Kitayama wrote:
> > Hi Wei-Lin,
> > On Tue, Jun 30, 2026 at 01:09:59PM +0100, Wei-Lin Chang wrote:
> > > Hi,
> > >
> > > This is v2 of fixing shadow ptdump debugfs files. Unfortunately I couldn't make
> > > per mmu ptdump files work after all, mainly because there isn't a clean way to
> > > locate the specific nested mmu for each ptdump file as the nested mmus could be
> > > freed when the file gets opened. Therefore in this series a single file
> > > "shadow_page_tables" is created that dumps all valid mmus' page table
> > > information.
> > >
> > > An advantage of this is that this new ptdump file have a lifetime identical to
> > > other ptdump files i.e. stage2_page_tables, ipa_range, etc., hence avoiding the
> > > dentry UAF found last time [1].
> > >
> > > With this all ptdump files are only removed when the last kvm reference gets
> > > dropped and kvm_destroy_vm_debugfs() is called, in their open(), show()
> > > functions the nested mmu array and mmu->pgt are checked with mmu_lock held to
> > > prevent UAF.
> > >
> > > Patch 1-2: Undo previous shadow ptdump implementation.
> > > Patch 3: Fix a mmu->pgt UAF that happens when ptdump files are read after
> > > mmu->pgt is freed.
> > > Patch 4-5: Preparation for the shadow page table dump file.
> > > Patch 6: Implementation of the shadow page table dump file.
> > >
> > > The fixes are tested with CONFIG_PROVE_LOCKING,
> > > CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
> > >
> > > Thanks!
> >
> > Running your shadow stage 2 kselftest with bpftrace shows me that __kvm_pgtable_stage2_init()
> > for shadow stage 2 translation tables are built with ia_bits = 52 and
> > start_level = 0, but the debugfs entry for the active shadow stage 2 tables prints
> > out that's 3 levels. Is this fully expected?
>
> Where is this level information you are seeing from? If it is
> "stage2_level", that only reports the number of levels for the canonical
> stage-2 (non nested). For nested mmus only the page tables are dumped in
> nested/shadow_page_tables.
Yes I know. The initial stage 2 translation table structure information is obtained by
instrumenting the kernel using eBPF fexit to __kvm_pgtable_stage2_init().
Since you're correctly loopin over nested_mmus array, and the output is
correctly shown using the kvm_pgtable information via the kvm_s2_mmu for
them, I am confused at this moment.
Thanks,
Itaru.
>
> Thanks,
> Wei-Lin Chang
>
> >
> > Thanks,
> > Itaru.
> >
> > >
> > > * Changes from v1 ([2]):
> > >
> > > - Move from per mmu ptdump files to one file that will dump all shadow page
> > > tables.
> > >
> > > [1]: https://lore.kernel.org/kvmarm/ajty6I7ZqodP4ous@sm-arm-grace07/
> > > [2]: https://lore.kernel.org/kvmarm/20260623142443.648972-1-weilin.chang@arm.com/
> > >
> > > Wei-Lin Chang (6):
> > > KVM: arm64: ptdump: Remove shadow ptdump files
> > > KVM: arm64: ptdump: Undo making the ptdump code mmu aware
> > > KVM: arm64: ptdump: Fix UAF when mmu->pgt is freed
> > > KVM: arm64: ptdump: Factor out initialization of
> > > kvm_ptdump_guest_state
> > > KVM: arm64: ptdump: Extract kvm_ptdump_guest_open() from canonical
> > > ptdump path
> > > KVM: arm64: ptdump: Introduce the shadow ptdump file
> > >
> > > arch/arm64/include/asm/kvm_host.h | 5 +-
> > > arch/arm64/include/asm/kvm_mmu.h | 4 -
> > > arch/arm64/kvm/nested.c | 18 +--
> > > arch/arm64/kvm/ptdump.c | 185 ++++++++++++++++++++----------
> > > 4 files changed, 135 insertions(+), 77 deletions(-)
> > >
> > > --
> > > 2.43.0
> > >
^ permalink raw reply
* [PATCH v1] arm64: cpuinfo: Fix sysfs cleanup on failure
From: Yuho Choi @ 2026-07-02 23:07 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Brown, Yicong Yang, Oliver Upton, Zhou Wang,
linux-arm-kernel, linux-kernel, Yuho Choi
cpuid_cpu_online() creates the CPU registers kobject and the base
identification attribute group before optionally merging the SME-specific
SMIDR attribute into that group.
If the base group creation fails, return after deleting the kobject. If
the SME merge fails, remove the base group before deleting the kobject.
Fixes: d69d56496487 ("arm64/sme: Expose SMIDR through sysfs")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
arch/arm64/kernel/cpuinfo.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index d50e2a9b066b..141bcfa4d611 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -380,9 +380,19 @@ static int cpuid_cpu_online(unsigned int cpu)
goto out;
rc = sysfs_create_group(&info->kobj, &cpuregs_attr_group);
if (rc)
- kobject_del(&info->kobj);
- if (system_supports_sme())
+ goto out_del_kobj;
+ if (system_supports_sme()) {
rc = sysfs_merge_group(&info->kobj, &sme_cpuregs_attr_group);
+ if (rc)
+ goto out_remove_group;
+ }
+
+ return 0;
+
+out_remove_group:
+ sysfs_remove_group(&info->kobj, &cpuregs_attr_group);
+out_del_kobj:
+ kobject_del(&info->kobj);
out:
return rc;
}
--
2.43.0
^ permalink raw reply related
* [PATCH] arm64: tlbflush: add debug counters for local vs broadcast flushes
From: Sayali Kulkarni @ 2026-07-02 23:17 UTC (permalink / raw)
To: linu.cherian
Cc: anshuman.khandual, catalin.marinas, kevin.brodsky,
linux-arm-kernel, linux-kernel, mark.rutland, ryan.roberts, will,
yang, ying.huang, Sayali Kulkarni
In-Reply-To: <20260523134710.3827956-1-linu.cherian@arm.com>
From: Sayali Kulkarni <sskulkarni@amperecomputing.com>
Add vmstat counters under CONFIG_DEBUG_TLBFLUSH to measure how often
the active_cpu optimization takes the local fast path versus a broadcast.
Tracks local/broadcast for mm and range flushes, plus the count of
broadcasts forced by active_cpu being MULTIPLE
Signed-off-by: Sayali Kulkarni <sskulkarni@amperecomputing.com>
---
Hi all,
To help analyze when this patch takes effect, I measured how
often TLB invalidations take the local fast path versus a broadcast, using
debug vmstat counters added under CONFIG_DEBUG_TLBFLUSH. The counters
record local vs broadcast for whole-mm and range flushes, plus the count of
broadcasts caused by the mm being active on multiple CPUs.
Setup:
- Ampere Altra, 64 cores
- 7.2.0-rc1 base with the active_cpu patch plus the debug counters.
- Hit rate = local flushes / (local + broadcast), read from /proc/vmstat before and
after each run.
- Test: A program that repeatedly flips page’s protection using mprotect(), with a
configurable number of threads sharing one address space
Results:
workload local fraction
----------------------------- --------------
mprotect, 1 thread, pinned ~100%
mprotect, 2 threads ~0.06%
mprotect, 4 threads ~0.06%
mprotect, 8 threads ~0.06%
stress-ng --vm 1, pinned ~100%
For a genuinely single-threaded process, the local fast path is taken essentially
every time. Both are consistent across repeated runs.
For multi-threaded process, active_cpu becomes MULTIPLE and broadcast takes
place for nearly every invalidation.
One caveat worth noting: "stress-ng --vm 1" is not actually a single-CPU
workload. It spawns a parent, a management process and the worker,
and the scheduler places them on different CPUs, so the mm becomes active on
more than one CPU and invalidations broadcast. Unpinned, this gives a highly
variable local fraction (I observed roughly 7%-57% across runs). Pinning it
to a single CPU, or using a genuinely single-threaded test, gives ~100%.
So the local fast path is taken while the mm stays active on a single CPU;
broadcasts return once the mm becomes active on more than one CPU,
whether via task migration or via a workload spreading itself across CPUs.
This is a hit-rate measurement only; it does not measure the performance
delta of the local vs broadcast path, which would need separate kernel-level
timing.
Thanks,
Sayali Kulkarni (Ampere)
sskulkarni@amperecomputing.com
--
Debug counters patch used for these measurements is below / attached.
arch/arm64/Kconfig.debug | 9 +++++++++
arch/arm64/include/asm/tlbflush.h | 21 +++++++++++++++++++--
arch/arm64/mm/context.c | 14 +++++++++++++-
include/linux/vm_event_item.h | 13 +++++++++++--
mm/vmstat.c | 6 +++++-
5 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index 265c4461031f..2229655f9d3d 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -20,4 +20,13 @@ config ARM64_RELOC_TEST
depends on m
tristate "Relocation testing module"
+config DEBUG_TLBFLUSH
+ bool "Add vmstat counters to analyze TLB handling"
+ depends on DEBUG_KERNEL
+ help
+ This option adds vmstat counters that track how arm64 TLB invalidations
+ are handled, specifically how many take the local fast path versus a
+ broadcast. The counts are exposed in /proc/vmstat and are useful for
+ analyzing the active_cpu optimization. If unsure, say N.
+
source "drivers/hwtracing/coresight/Kconfig"
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 90b4e4147590..cbda203aa020 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -16,7 +16,13 @@
#include <linux/mmu_notifier.h>
#include <asm/cputype.h>
#include <asm/mmu.h>
-
+#include <linux/vm_event_item.h>
+#ifdef CONFIG_DEBUG_TLBFLUSH
+extern void _count_vm_tlb_event(enum vm_event_item);
+#define count_tlb_event(x) _count_vm_tlb_event(x)
+#else
+#define count_tlb_event(x) do { } while (0)
+#endif
/*
* Raw TLBI operations.
*
@@ -370,8 +376,12 @@ static inline bool flush_tlb_user_pre(struct mm_struct *mm, tlbf_t flags)
}
local = active == self;
- if (!local)
+ if (!local) {
+ if (active == ACTIVE_CPU_MULTIPLE)
+ /* broadcast because mm is active on multiple CPUs */
+ count_tlb_event(NR_TLB_ARM64_BROADCAST_MULTIPLE);
migrate_enable();
+ }
return local;
}
@@ -490,10 +500,12 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
__tlbi(aside1, asid);
__tlbi_user(aside1, asid);
dsb(nsh);
+ count_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
} else {
__tlbi(aside1is, asid);
__tlbi_user(aside1is, asid);
__tlbi_sync_s1ish(mm);
+ count_tlb_event(NR_TLB_FLUSH_ALL);
}
flush_tlb_user_post(local);
mmu_notifier_arch_invalidate_secondary_tlbs(mm, 0, -1UL);
@@ -712,6 +724,11 @@ static __always_inline void __do_flush_tlb_range(struct vm_area_struct *vma,
dsb(nsh);
}
+ if (local)
+ count_tlb_event(NR_TLB_LOCAL_FLUSH_RANGE);
+ else
+ count_tlb_event(NR_TLB_FLUSH_RANGE);
+
flush_tlb_user_post(local);
}
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index f34ed78393e0..d41c1b517abf 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -11,7 +11,7 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/mm.h>
-
+#include <linux/vmstat.h>
#include <asm/cpufeature.h>
#include <asm/mmu_context.h>
#include <asm/smp.h>
@@ -443,4 +443,16 @@ static int asids_init(void)
set_kpti_asid_bits(asid_map);
return 0;
}
+
+#ifdef CONFIG_DEBUG_TLBFLUSH
+/*
+ * Helper so the TLB flush inlines in tlbflush.h can update the vmstat TLB
+ * counters without pulling vmstat internals into the header.
+ */
+void _count_vm_tlb_event(enum vm_event_item x)
+{
+ count_vm_tlb_event(x);
+}
+#endif
+
early_initcall(asids_init);
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 03fe95f5a020..edd508f3b1fc 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -117,10 +117,19 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
#endif /* CONFIG_BALLOON_MIGRATION */
#endif /* CONFIG_BALLOON */
#ifdef CONFIG_DEBUG_TLBFLUSH
+ /*
+ * arm64 TLB flush accounting for the active_cpu optimization
+ * local_* counters mean the local-only fast path was taken;
+ * the broadcast counters mean a full broadcast was required.
+ */
NR_TLB_REMOTE_FLUSH, /* cpu tried to flush others' tlbs */
NR_TLB_REMOTE_FLUSH_RECEIVED,/* cpu received ipi for flush */
- NR_TLB_LOCAL_FLUSH_ALL,
- NR_TLB_LOCAL_FLUSH_ONE,
+ NR_TLB_LOCAL_FLUSH_ALL, /* local whole-mm flush */
+ NR_TLB_LOCAL_FLUSH_ONE, /* used by x86 */
+ NR_TLB_LOCAL_FLUSH_RANGE, /* local range flush (incl. single page) */
+ NR_TLB_FLUSH_ALL, /* broadcast whole-mm flush */
+ NR_TLB_FLUSH_RANGE, /* broadcast range flush; also single page */
+ NR_TLB_ARM64_BROADCAST_MULTIPLE, /* broadcast; mm active on multiple CPUs */
#endif /* CONFIG_DEBUG_TLBFLUSH */
#ifdef CONFIG_SWAP
SWAP_RA,
diff --git a/mm/vmstat.c b/mm/vmstat.c
index f534972f517d..b5b7a3268cb2 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1433,7 +1433,11 @@ const char * const vmstat_text[] = {
[I(NR_TLB_REMOTE_FLUSH)] = "nr_tlb_remote_flush",
[I(NR_TLB_REMOTE_FLUSH_RECEIVED)] = "nr_tlb_remote_flush_received",
[I(NR_TLB_LOCAL_FLUSH_ALL)] = "nr_tlb_local_flush_all",
- [I(NR_TLB_LOCAL_FLUSH_ONE)] = "nr_tlb_local_flush_one",
+ [I(NR_TLB_LOCAL_FLUSH_ONE)] = "nr_tlb_local_flush_one",
+ [I(NR_TLB_LOCAL_FLUSH_RANGE)] = "nr_tlb_local_flush_range",
+ [I(NR_TLB_FLUSH_ALL)] = "nr_tlb_flush_all",
+ [I(NR_TLB_FLUSH_RANGE)] = "nr_tlb_flush_range",
+ [I(NR_TLB_ARM64_BROADCAST_MULTIPLE)] = "nr_tlb_arm64_broadcast_multiple",
#endif /* CONFIG_DEBUG_TLBFLUSH */
#ifdef CONFIG_SWAP
--
2.47.3
^ permalink raw reply related
* [PATCH 06/12] arm64: dts: rockchip: rk3588s-nanopi: add missing pcie rst pinctrl
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
The pins are used as reset-gpios but not reserved through pinctrl.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index f3a240b48a2a..361682c18e69 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -303,12 +303,16 @@ rgmii_phy1: ethernet-phy@1 {
};
&pcie2x1l1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2_1_rst>;
reset-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc_3v3_pcie20>;
status = "okay";
};
&pcie2x1l2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2_2_rst>;
reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc_3v3_pcie20>;
status = "okay";
@@ -335,6 +339,16 @@ rtc_int: rtc-int {
};
};
+ pcie {
+ pcie2_1_rst: pcie2-1-rst {
+ rockchip,pins = <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ pcie2_2_rst: pcie2-2-rst {
+ rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
sdmmc {
sdmmc_det_pin: sdmmc-det-pin {
rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.55.0
^ permalink raw reply related
* [PATCH 08/12] arm64: dts: rockchip: rk3588s-nanopi: remove always-on from vdd_npu_s0 reg
From: Joachim Eastwood via B4 Relay @ 2026-07-02 22:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, Joachim Eastwood
In-Reply-To: <20260703-nanopi-m6-v1-0-8344a1559519@gmail.com>
From: Joachim Eastwood <joachim.eastwood@gmail.com>
Since the NPU is hooked up on these the always-on isn't needed anymore.
Signed-off-by: Joachim Eastwood <joachim.eastwood@gmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
index bcb2f5d63a61..463cfeddf270 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-nanopi.dtsi
@@ -258,7 +258,6 @@ vdd_npu_s0: regulator@42 {
regulator-max-microvolt = <950000>;
regulator-ramp-delay = <2300>;
regulator-boot-on;
- regulator-always-on;
vin-supply = <&vcc5v0_sys>;
regulator-state-mem {
--
2.55.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox