* RE: [PATCH v2] PCI: imx6: Fix i.MX6Q/DL boot hang by separating PHY power and reference clock control
From: Hongxing Zhu (OSS) @ 2026-07-20 8:32 UTC (permalink / raw)
To: Hongxing Zhu (OSS), Manivannan Sadhasivam, Hongxing Zhu (OSS)
Cc: Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org, Hongxing Zhu
In-Reply-To: <GV2PR04MB1201914A80BB2BF78A10465748CC62@GV2PR04MB12019.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Hongxing Zhu (OSS) <hongxing.zhu@oss.nxp.com>
> Sent: Friday, July 17, 2026 4:57 PM
> To: Manivannan Sadhasivam <mani@kernel.org>; Hongxing Zhu (OSS)
> <hongxing.zhu@oss.nxp.com>
> Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de; lpieralisi@kernel.org;
> kwilczynski@kernel.org; robh@kernel.org; bhelgaas@google.com;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev;
> linux-kernel@vger.kernel.org; Hongxing Zhu <hongxing.zhu@nxp.com>
> Subject: RE: [PATCH v2] PCI: imx6: Fix i.MX6Q/DL boot hang by separating PHY
> power and reference clock control
>
> > -----Original Message-----
> > From: Manivannan Sadhasivam <mani@kernel.org>
> > Sent: Friday, July 17, 2026 12:35 AM
> > To: Hongxing Zhu (OSS) <hongxing.zhu@oss.nxp.com>
> > Cc: Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> > lpieralisi@kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> > bhelgaas@google.com; s.hauer@pengutronix.de; kernel@pengutronix.de;
> > festevam@gmail.com; linux- pci@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev;
> > linux-kernel@vger.kernel.org; Hongxing Zhu <hongxing.zhu@nxp.com>
> > Subject: Re: [PATCH v2] PCI: imx6: Fix i.MX6Q/DL boot hang by
> > separating PHY power and reference clock control
> >
> > On Wed, Jul 08, 2026 at 11:59:27AM +0800, hongxing.zhu@oss.nxp.com wrote:
> > > From: Richard Zhu <hongxing.zhu@nxp.com>
> > >
> > > Commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling
> > > regulators") introduced a boot hang on i.MX6Q/DL variants by
> > > changing the initialization sequence.
> > >
> > > The issue stems from coupling PHY power (TEST_PD) and reference
> > > clock
> > > (REF_CLK_EN) control in imx6q_pcie_enable_ref_clk(). When these are
> > > managed together, the timing between PHY power-up and reference
> > > clock enablement cannot be properly controlled, leading to
> > > initialization failures.
> > >
> >
> > What is the timing requirement here?
> The timing requirement is that TEST_PD must be deasserted (cleared) before link
> training starts.
>
> Before commit 610fa91d9863:
> - imx_pcie_assert_core_reset(): Assert TEST_PD and REF_CLK_EN
> - imx_pcie_clk_enable(): Deassert TEST_PD and assert REF_CLK_EN
> - Link training starts with TEST_PD properly cleared
>
> After commit 610fa91d9863:
> - imx_pcie_clk_enable(): Deassert TEST_PD and assert REF_CLK_EN
> - imx_pcie_assert_core_reset(): Assert TEST_PD and assert REF_CLK_EN again
> - Link training starts with TEST_PD still asserted (never cleared again)
>
> This commit corrects the sequence, and makes sure the TEST_PD is cleared
> before link training starts.
> >
> > > Fix this by separating the two concerns:
> > >
> > > - Move PHY power control (TEST_PD) to imx6q_pcie_core_reset() where it
> > > logically belongs with reset operations. This ensures PHY power state
> > > is managed as part of the core reset sequence.
> > >
> > > - Update imx6qp_pcie_core_reset() to call imx6q_pcie_core_reset() for
> > > shared PHY power management, avoiding code duplication.
> > >
> > > - Make imx6q_pcie_enable_ref_clk() responsible only for reference clock
> > > (REF_CLK_EN) control, simplifying its purpose.
> > >
> > > - Remove the 10us delay workaround from imx6q_pcie_enable_ref_clk() as
> > > proper sequencing is now handled by the core_reset functions.
> > >
> > > This refactoring ensures PHY power is controlled during reset
> > > operations, fixing the boot hang while improving code maintainability.
> > >
> >
> > This patch does too many things at once. Can't you split it and keep
> > the minimal fix in one patch?
> Okay, I'll split this into a patch series in v3.
> Thanks.
Hi Mani:
I've attempted to split the changes as below:
1. Set/Clear TEST_PD in assert_core_reset()/deassert_core_reset()
2. Clean up imx6q_pcie_enable_ref_clk() to only manipulate the REF_CLK_EN bit
However, I found that patch 1 alone doesn't work correctly. Here's what happens:
With only patch 1 applied:
- The board boots successfully, but fails to detect the remote endpoint device
- Problem sequence:
Begin (TEST_PD asserted by default)
→ TEST_PD cleared + REF_CLK_EN asserted in clk_enable()
→ TEST_PD asserted again in assert_core_reset()
→ TEST_PD cleared in deassert_core_reset()
With both patches applied:
- The board boots and detects the remote endpoint device successfully
- Correct sequence:
Begin (TEST_PD asserted by default)
→ REF_CLK_EN asserted in clk_enable() (TEST_PD remains untouched)
→ TEST_PD asserted in assert_core_reset()
→ TEST_PD cleared in deassert_core_reset()
The issue is that patch 1 relies on patch 2 to avoid prematurely clearing TEST_PD
in clk_enable(). Both changes are mandatory for the fix to work.
Given this dependency, would you prefer:
- A two-patch series with the dependency clearly documented, or
- A single combined patch since they cannot function independently.
Thanks.
Best Regards
Richard Zhu
>
> Best Regards
> Richard Zhu
> >
> > - Mani
> >
> > > Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling
> > > regulators")
> > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > > ---
> > > Changes in v2:
> > > Regarding sashiko's reivew, invoke imx_pcie_assert_core_reset()
> > > explicitly in error path of imx_pcie_host_init() and imx_pcie_host_exit().
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 45
> > > ++++++++++++---------------
> > > 1 file changed, 20 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index 9406bba36953f..53f3da6ab30d5 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -680,21 +680,12 @@ static int imx_pcie_attach_pd(struct device
> > > *dev)
> > >
> > > static int imx6q_pcie_enable_ref_clk(struct imx_pcie *imx_pcie,
> > > bool
> > > enable) {
> > > - if (enable) {
> > > - /* power up core phy and enable ref clock */
> > > - regmap_clear_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_TEST_PD);
> > > - /*
> > > - * The async reset input need ref clock to sync internally,
> > > - * when the ref clock comes after reset, internal synced
> > > - * reset time is too short, cannot meet the requirement.
> > > - * Add a ~10us delay here.
> > > - */
> > > - usleep_range(10, 100);
> > > - regmap_set_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_REF_CLK_EN);
> > > - } else {
> > > - regmap_clear_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_REF_CLK_EN);
> > > - regmap_set_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_TEST_PD);
> > > - }
> > > + if (enable)
> > > + regmap_set_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > > + IMX6Q_GPR1_PCIE_REF_CLK_EN);
> > > + else
> > > + regmap_clear_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > > + IMX6Q_GPR1_PCIE_REF_CLK_EN);
> > >
> > > return 0;
> > > }
> > > @@ -823,23 +814,25 @@ static int imx6sx_pcie_core_reset(struct
> > > imx_pcie
> > *imx_pcie, bool assert)
> > > return 0;
> > > }
> > >
> > > -static int imx6qp_pcie_core_reset(struct imx_pcie *imx_pcie, bool
> > > assert)
> > > +static int imx6q_pcie_core_reset(struct imx_pcie *imx_pcie, bool
> > > +assert)
> > > {
> > > - regmap_update_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_SW_RST,
> > > - assert ? IMX6Q_GPR1_PCIE_SW_RST : 0);
> > > - if (!assert)
> > > - usleep_range(200, 500);
> > > + if (assert)
> > > + regmap_set_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > > + IMX6Q_GPR1_PCIE_TEST_PD);
> > > + else
> > > + regmap_clear_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > > + IMX6Q_GPR1_PCIE_TEST_PD);
> > >
> > > return 0;
> > > }
> > >
> > > -static int imx6q_pcie_core_reset(struct imx_pcie *imx_pcie, bool
> > > assert)
> > > +static int imx6qp_pcie_core_reset(struct imx_pcie *imx_pcie, bool
> > > +assert)
> > > {
> > > + imx6q_pcie_core_reset(imx_pcie, assert);
> > > + regmap_update_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_SW_RST,
> > > + assert ? IMX6Q_GPR1_PCIE_SW_RST : 0);
> > > if (!assert)
> > > - return 0;
> > > -
> > > - regmap_set_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_TEST_PD);
> > > - regmap_set_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1,
> > IMX6Q_GPR1_PCIE_REF_CLK_EN);
> > > + usleep_range(200, 500);
> > >
> > > return 0;
> > > }
> > > @@ -1445,6 +1438,7 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > > return 0;
> > >
> > > err_phy_off:
> > > + imx_pcie_assert_core_reset(imx_pcie);
> > > phy_power_off(imx_pcie->phy);
> > > err_phy_exit:
> > > phy_exit(imx_pcie->phy);
> > > @@ -1471,6 +1465,7 @@ static void imx_pcie_host_exit(struct
> > > dw_pcie_rp
> > *pp)
> > > dev_err(pci->dev, "unable to power off PHY\n");
> > > phy_exit(imx_pcie->phy);
> > > }
> > > + imx_pcie_assert_core_reset(imx_pcie);
> > > imx_pcie_clk_disable(imx_pcie);
> > >
> > > pci_pwrctrl_power_off_devices(pci->dev);
> > > --
> > > 2.34.1
> > >
> >
> > --
> > மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] KVM: arm64: ptdump: Flush the last region
From: Mark Rutland @ 2026-07-20 8:35 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,
Dev Jain, Ryan Roberts, Sebastian Ene, Vincent Donnefort
In-Reply-To: <20260717231233.2299068-1-weilin.chang@arm.com>
On Sat, Jul 18, 2026 at 12:12:33AM +0100, Wei-Lin Chang wrote:
> Currently the stage-2 ptdump calls note_page() at each leaf entry visit.
> This simply misses the output of the last region, because note_page()
> only dumps output when it detects a change in level/prot, or when the
> walk enters a next marker section. The last region in the guest IPA
> space with the same level/prot is not dumped since there is no change
> after it.
>
> To dump the final region, manually issue a note_page() call with address
> BIT(ia_bits) (end of guest IPA space) and level == -1 to trigger a level
> change after the last region. Additionally treat level == -1 as a last
> flushing note_page() call and avoid dumping the name of the next marker
> for this case.
I think you can use note_page_flush() rather than doing that manually.
> Fixes: 7c4f73548ed1 ("KVM: arm64: Register ptdump with debugfs on guest creation")
> Reported-by: Sashiko AI <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/kvmarm/20260630122758.891011F00A3A@smtp.kernel.org/
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/kvm/ptdump.c | 8 +++++---
> arch/arm64/mm/ptdump.c | 5 +++--
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> index c9140e22abcf..4096e4a92fae 100644
> --- a/arch/arm64/kvm/ptdump.c
> +++ b/arch/arm64/kvm/ptdump.c
> @@ -155,11 +155,13 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
> .seq = m,
> };
>
> - write_lock(&kvm->mmu_lock);
> + guard(write_lock)(&kvm->mmu_lock);
> ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> - write_unlock(&kvm->mmu_lock);
> + if (ret)
> + return ret;
> + note_page(&st->parser_state.ptdump, BIT(mmu->pgt->ia_bits), -1, 0);
This can be:
note_page_flush(&st->parser_state.ptdump);
The level change alone should trigger the dump, so the address doesn't
need to be at the end of the guest IPA space.
Importantly, note_page_flush() will pass 0 as the address, which won't
trigger the checks you try to suppress below.
Please use note_page_flush() here, and drop the changes to
arch/arm64/mm/ptdump.c.
>
> - return ret;
> + return 0;
> }
>
> static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index ab9899ca1e5f..fed4e4407e0e 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -194,6 +194,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> struct ptdump_pg_state *st = container_of(pt_st, struct ptdump_pg_state, ptdump);
> struct ptdump_pg_level *pg_level = st->pg_level;
> static const char units[] = "KMGTPE";
> + bool flush = level == -1;
> ptdesc_t prot = 0;
>
> /* check if the current level has been folded dynamically */
> @@ -234,7 +235,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> pg_level[st->level].num);
> pt_dump_seq_puts(st->seq, "\n");
>
> - if (addr >= st->marker[1].start_address) {
> + if (addr >= st->marker[1].start_address && !flush) {
> st->marker++;
> pt_dump_seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
> }
If you use note_page_flush(), addr will be 0. As the final marker is at
BIT(pgtable->ia_bits), this condition cannot fire.
> @@ -244,7 +245,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> st->level = level;
> }
>
> - if (addr >= st->marker[1].start_address) {
> + if (addr >= st->marker[1].start_address && !flush) {
> st->marker++;
> pt_dump_seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
> }
Likewise here.
Mark.
^ permalink raw reply
* [PATCH v2 0/2] kselftest/arm64: Add two arm64 kselftests for orig_x0 issue
From: Jinjie Ruan @ 2026-07-20 8:51 UTC (permalink / raw)
To: catalin.marinas, will, shuah, linux-kernel, linux-arm-kernel,
linux-kselftest
Cc: ruanjinjie
Recently, a security issue related to orig_x0 was discovered and fixed
in arm64, but there are still no test cases covering it. Seccomp,
tracepoints, and audit can observe a stale value for x0 after a ptracer
or SECCOMP_RET_TRACE modifies x0.
As Kees suggested, this series adds two kselftests for arm64 that validate
the orig_x0 re-synchronisation fix in ptrace, the first one is for ptrace
update, the second one is for SECCOMP_RET_TRACE update.
Link: https://lore.kernel.org/all/20260717182758.17111-1-will@kernel.org/
Link: https://lore.kernel.org/all/20260716120640.6590-1-will@kernel.org/
Link: https://lore.kernel.org/all/202607152004.DEA95D63@keescook/
Changes in v2:
- Update the 2st testcase to cover the corner case pointed out by Sashiko[1].
[1]: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org
Jinjie Ruan (2):
kselftest/arm64: Add seccomp ptrace x0 bypass test
kselftest/arm64: Add testcase for SECCOMP_RET_TRACE orig_x0 bypass
tools/testing/selftests/arm64/abi/.gitignore | 2 +
tools/testing/selftests/arm64/abi/Makefile | 2 +-
.../arm64/abi/seccomp_ptrace_x0_bypass.c | 181 ++++++++++++++++
.../arm64/abi/seccomp_ret_trace_x0_bypass.c | 196 ++++++++++++++++++
4 files changed, 380 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/arm64/abi/seccomp_ptrace_x0_bypass.c
create mode 100644 tools/testing/selftests/arm64/abi/seccomp_ret_trace_x0_bypass.c
--
2.34.1
^ permalink raw reply
* [PATCH v2 2/2] kselftest/arm64: Add testcase for SECCOMP_RET_TRACE orig_x0 bypass
From: Jinjie Ruan @ 2026-07-20 8:51 UTC (permalink / raw)
To: catalin.marinas, will, shuah, linux-kernel, linux-arm-kernel,
linux-kselftest
Cc: ruanjinjie
In-Reply-To: <20260720085145.247690-1-ruanjinjie@huawei.com>
Add a selftest that verifies the kernel re-evaluates a seccomp filter
with the correct (ptrace-modified) first argument after
a SECCOMP_RET_TRACE stop. On arm64, syscall_get_arguments() reads
the first argument from orig_x0, which may be stale if the tracer modified
regs->regs[0] but orig_x0 was not synced. This can cause the filter to
see an old argument and incorrectly allow a syscall that it should
have rejected.
The child installs a filter that:
- TRACEs write() when fd == 2
- returns ERRNO(EPERM) when fd == 1
The parent catches the SECCOMP event, changes x0 (fd) from 2 to 1,
and resumes the child.
If the seccomp re-evaluation sees the stale orig_x0 (fd=2) the filter
returns TRACE again and the kernel (with recheck_after_trace=true)
allows the syscall to proceed – write succeeds and the child exits 0.
If the seccomp re-evaluation sees the new value (fd=1) the filter
returns ERRNO(EPERM), write fails and the child exits non-zero.
The test passes only when the write fails (child exit != 0).
Before the fix:
# ./seccomp_ret_trace_x0_bypass
TAP version 13
1..1
not ok 1 write succeeded, orig_x0 bypass likely
# Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
After the fix:
# ./seccomp_ret_trace_x0_bypass
TAP version 13
1..1
ok 1 seccomp correctly denied modified syscall
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
Cc: Kees Cook <kees@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/all/20260717182758.17111-1-will@kernel.org/
Link: https://lore.kernel.org/all/20260716120640.6590-1-will@kernel.org/
Link: https://lore.kernel.org/all/202607152004.DEA95D63@keescook/
Suggested-by: Kees Cook <kees@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
tools/testing/selftests/arm64/abi/.gitignore | 1 +
tools/testing/selftests/arm64/abi/Makefile | 2 +-
.../arm64/abi/seccomp_ret_trace_x0_bypass.c | 196 ++++++++++++++++++
3 files changed, 198 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/arm64/abi/seccomp_ret_trace_x0_bypass.c
diff --git a/tools/testing/selftests/arm64/abi/.gitignore b/tools/testing/selftests/arm64/abi/.gitignore
index 39129a9907c7..491a80db9dff 100644
--- a/tools/testing/selftests/arm64/abi/.gitignore
+++ b/tools/testing/selftests/arm64/abi/.gitignore
@@ -1,5 +1,6 @@
hwcap
ptrace
seccomp_ptrace_x0_bypass
+seccomp_ret_trace_x0_bypass
syscall-abi
tpidr2
diff --git a/tools/testing/selftests/arm64/abi/Makefile b/tools/testing/selftests/arm64/abi/Makefile
index 5a16db379bd4..a01d3806eba8 100644
--- a/tools/testing/selftests/arm64/abi/Makefile
+++ b/tools/testing/selftests/arm64/abi/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
# Copyright (C) 2021 ARM Limited
-TEST_GEN_PROGS := hwcap ptrace syscall-abi tpidr2 seccomp_ptrace_x0_bypass
+TEST_GEN_PROGS := hwcap ptrace syscall-abi tpidr2 seccomp_ptrace_x0_bypass seccomp_ret_trace_x0_bypass
include ../../lib.mk
diff --git a/tools/testing/selftests/arm64/abi/seccomp_ret_trace_x0_bypass.c b/tools/testing/selftests/arm64/abi/seccomp_ret_trace_x0_bypass.c
new file mode 100644
index 000000000000..6887ec71aef1
--- /dev/null
+++ b/tools/testing/selftests/arm64/abi/seccomp_ret_trace_x0_bypass.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test for SECCOMP_RET_TRACE argument modification bypass
+ * via stale orig_x0 during filter re-evaluation.
+ *
+ * On arm64, syscall_get_arguments() reads the first argument from
+ * regs->orig_x0. When a seccomp filter returns SECCOMP_RET_TRACE,
+ * ptrace may modify regs->regs[0] while orig_x0 remains unchanged.
+ * The kernel then re-evaluates the filter; if it sees the stale
+ * orig_x0, it may incorrectly allow a syscall that the tracer intended
+ * to block.
+ *
+ * This test installs a filter that:
+ * - TRACEs write() when fd == 2
+ * - returns ERRNO(EPERM) when fd == 1
+ * - allows all other syscalls
+ *
+ * The child calls write(2, ...). The parent catches the SECCOMP stop,
+ * changes x0 (fd) from 2 to 1, and resumes the child.
+ *
+ * If re-evaluation sees the old fd=2 (stale orig_x0), the filter
+ * returns TRACE again; because recheck_after_trace is true, the kernel
+ * allows the syscall to proceed. write(1, ...) succeeds, child exits 0.
+ * -> test FAIL (bypass detected).
+ *
+ * If re-evaluation sees the new fd=1 (synced orig_x0), the filter
+ * returns ERRNO(EPERM), write fails, child exits 1.
+ * -> test PASS (no bypass).
+ *
+ * No special privileges required beyond CAP_SYS_PTRACE.
+ */
+#include <errno.h>
+#include <signal.h>
+#include <stddef.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/prctl.h>
+#include <sys/ptrace.h>
+#include <sys/uio.h>
+#include <sys/wait.h>
+#include <linux/elf.h>
+#include <linux/filter.h>
+#include <linux/seccomp.h>
+#include <linux/ptrace.h>
+
+#include "kselftest.h"
+
+#ifndef __NR_write
+#define __NR_write 64
+#endif
+
+#define PTRACE_EVENT_MASK(status) ((status) >> 16)
+
+static int do_child(void)
+{
+ long ret;
+
+ if (ptrace(PTRACE_TRACEME, 0, NULL, NULL))
+ _exit(2);
+
+ raise(SIGSTOP); /* synchronize with parent */
+
+ /*
+ * Filter:
+ * if syscall == write:
+ * if fd == 2 -> TRACE
+ * if fd == 1 -> ERRNO(EPERM)
+ * else -> ALLOW
+ * else -> ALLOW
+ */
+ struct sock_filter filter[] = {
+ /* Load syscall number */
+ BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
+ offsetof(struct seccomp_data, nr)),
+ /* If not write, allow */
+ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_write, 0, 5),
+ /* Load first argument (fd) */
+ BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
+ offsetof(struct seccomp_data, args[0])),
+ /* fd == 2 ? */
+ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, 2, 0, 2),
+ /* Yes: TRACE */
+ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_TRACE),
+ /* fd == 1 ? */
+ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, 1, 0, 1),
+ /* Yes: ERRNO(EPERM) */
+ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (EPERM & SECCOMP_RET_DATA)),
+ /* Other fd: ALLOW */
+ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),
+ };
+
+ struct sock_fprog prog = {
+ .len = ARRAY_SIZE(filter),
+ .filter = filter,
+ };
+
+ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0))
+ _exit(3);
+ if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog))
+ _exit(4);
+
+ /*
+ * write(2, ...) triggers TRACE, parent changes fd to 1.
+ * If re-eval sees fd=1 -> ERRNO -> write fails, ret = -EPERM.
+ * If re-eval sees fd=2 -> TRACE again -> allowed -> write succeeds.
+ */
+ ret = syscall(__NR_write, 2, "", 0);
+ _exit(ret == 0 ? 0 : 1);
+}
+
+int main(void)
+{
+ struct user_pt_regs regs;
+ struct iovec iov = { .iov_base = ®s, .iov_len = sizeof(regs) };
+ pid_t child;
+ int status;
+
+ ksft_print_header();
+ ksft_set_plan(1);
+
+ child = fork();
+ if (!child)
+ return do_child();
+
+ /* 1. Wait for initial SIGSTOP */
+ if (waitpid(child, &status, 0) != child)
+ ksft_exit_fail_msg("waitpid SIGSTOP");
+ if (!WIFSTOPPED(status) || WSTOPSIG(status) != SIGSTOP)
+ ksft_exit_fail_msg("unexpected initial stop");
+
+ /* 2. Enable SECCOMP ptrace events */
+ if (ptrace(PTRACE_SETOPTIONS, child, 0, PTRACE_O_TRACESECCOMP))
+ ksft_exit_fail_msg("PTRACE_SETOPTIONS");
+
+ /* 3. Continue child to hit SECCOMP stop */
+ if (ptrace(PTRACE_CONT, child, 0, 0))
+ ksft_exit_fail_msg("PTRACE_CONT");
+
+ /* 4. Wait for SECCOMP stop */
+ while (1) {
+ if (waitpid(child, &status, 0) != child)
+ ksft_exit_fail_msg("waitpid SECCOMP");
+ if (WIFEXITED(status)) {
+ ksft_test_result_fail("child exited before SECCOMP stop\n");
+ goto out;
+ }
+ if (WIFSIGNALED(status)) {
+ ksft_test_result_fail("child killed unexpectedly\n");
+ goto out;
+ }
+ if (WIFSTOPPED(status) &&
+ WSTOPSIG(status) == SIGTRAP &&
+ PTRACE_EVENT_MASK(status) == PTRACE_EVENT_SECCOMP)
+ break;
+ ptrace(PTRACE_CONT, child, 0, WSTOPSIG(status));
+ }
+
+ /* 5. Modify x0 (fd) from 2 to 1 */
+ if (ptrace(PTRACE_GETREGSET, child, NT_PRSTATUS, &iov))
+ ksft_exit_fail_perror("GETREGSET");
+ if (regs.regs[8] != __NR_write || regs.regs[0] != 2) {
+ ksft_test_result_fail("unexpected regs: syscall=%llu, x0=%llu\n",
+ regs.regs[8], regs.regs[0]);
+ goto out;
+ }
+ regs.regs[0] = 1;
+ if (ptrace(PTRACE_SETREGSET, child, NT_PRSTATUS, &iov))
+ ksft_exit_fail_perror("SETREGSET");
+
+ /* 6. Resume child */
+ if (ptrace(PTRACE_CONT, child, 0, 0))
+ ksft_exit_fail_perror("PTRACE_CONT");
+
+ /* 7. Reap child – must exit normally */
+ if (waitpid(child, &status, 0) != child)
+ ksft_exit_fail_msg("final waitpid");
+
+ if (!WIFEXITED(status)) {
+ ksft_test_result_fail("child did not exit normally\n");
+ goto out;
+ }
+
+ if (WEXITSTATUS(status) != 0)
+ ksft_test_result_pass("seccomp correctly denied modified syscall\n");
+ else
+ ksft_test_result_fail("write succeeded, orig_x0 bypass likely\n");
+
+out:
+ if (child > 0) {
+ kill(child, SIGKILL);
+ waitpid(child, NULL, 0);
+ }
+ ksft_print_cnts();
+ return ksft_get_fail_cnt() ? EXIT_FAILURE : EXIT_SUCCESS;
+}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: ptdump: Flush the last region
From: Dev Jain @ 2026-07-20 8:53 UTC (permalink / raw)
To: Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Ryan Roberts, Sebastian Ene, Vincent Donnefort
In-Reply-To: <20260717231233.2299068-1-weilin.chang@arm.com>
On 18/07/26 4:42 am, Wei-Lin Chang wrote:
> Currently the stage-2 ptdump calls note_page() at each leaf entry visit.
> This simply misses the output of the last region, because note_page()
> only dumps output when it detects a change in level/prot, or when the
> walk enters a next marker section. The last region in the guest IPA
> space with the same level/prot is not dumped since there is no change
> after it.
>
> To dump the final region, manually issue a note_page() call with address
> BIT(ia_bits) (end of guest IPA space) and level == -1 to trigger a level
> change after the last region. Additionally treat level == -1 as a last
> flushing note_page() call and avoid dumping the name of the next marker
> for this case.
>
> Fixes: 7c4f73548ed1 ("KVM: arm64: Register ptdump with debugfs on guest creation")
> Reported-by: Sashiko AI <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/kvmarm/20260630122758.891011F00A3A@smtp.kernel.org/
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/kvm/ptdump.c | 8 +++++---
> arch/arm64/mm/ptdump.c | 5 +++--
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> index c9140e22abcf..4096e4a92fae 100644
> --- a/arch/arm64/kvm/ptdump.c
> +++ b/arch/arm64/kvm/ptdump.c
> @@ -155,11 +155,13 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
> .seq = m,
> };
>
> - write_lock(&kvm->mmu_lock);
> + guard(write_lock)(&kvm->mmu_lock);
The guard clause change has nothing to do with the fix I think? Although the change
is small and the fix is for a recent commit so maybe we don't care having this
in the same patch - not sure how strict kvm reviewers are about this : )
> ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> - write_unlock(&kvm->mmu_lock);
> + if (ret)
> + return ret;
> + note_page(&st->parser_state.ptdump, BIT(mmu->pgt->ia_bits), -1, 0);
>
> - return ret;
> + return 0;
> }
>
> static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index ab9899ca1e5f..fed4e4407e0e 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -194,6 +194,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> struct ptdump_pg_state *st = container_of(pt_st, struct ptdump_pg_state, ptdump);
> struct ptdump_pg_level *pg_level = st->pg_level;
> static const char units[] = "KMGTPE";
> + bool flush = level == -1;
Can we do something similar to what S1 ptdump does (note_page_flush in ptdump_walk_pgd).
> ptdesc_t prot = 0;
>
> /* check if the current level has been folded dynamically */
> @@ -234,7 +235,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> pg_level[st->level].num);
> pt_dump_seq_puts(st->seq, "\n");
>
> - if (addr >= st->marker[1].start_address) {
> + if (addr >= st->marker[1].start_address && !flush) {
> st->marker++;
> pt_dump_seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
> }
> @@ -244,7 +245,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> st->level = level;
> }
>
> - if (addr >= st->marker[1].start_address) {
> + if (addr >= st->marker[1].start_address && !flush) {
> st->marker++;
> pt_dump_seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
> }
^ permalink raw reply
* [PATCH v2 0/3] media: mediatek: unregister VPU watchdog handlers
From: Guangshuo Li @ 2026-07-20 8:57 UTC (permalink / raw)
To: Minghsiu Tsai, Houlong Wei, Andrew-CT Chen, Mauro Carvalho Chehab,
Matthias Brugger, AngeloGioacchino Del Regno, Tiffany Lin,
Yunfei Dong, Hans Verkuil, Nicolas Dufresne, Chen-Yu Tsai,
Fei Shao, Tomasz Figa, Guangshuo Li, Haoxiang Li, Eizan Miyamoto,
Enric Balletbo i Serra, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
The Mediatek vcodec and MDP drivers register watchdog reset handlers
with the VPU driver and pass driver-owned objects as private data.
These handlers can remain registered after an initialization failure or
device removal. A later VPU watchdog reset can therefore invoke a
handler with stale private data and potentially dereference freed
memory.
This series adds a common helper for unregistering VPU watchdog
handlers, then uses it in the vcodec and MDP cleanup paths before their
VPU device references are released.
The series is organized as follows:
1. Add vpu_wdt_unreg_handler() to the VPU driver.
2. Unregister the vcodec watchdog handler during initialization
failure and firmware release.
3. Unregister the MDP watchdog handler during probe failure and
device removal.
v2:
- Split the changes into three patches as requested by Nicolas.
- Fix the extra blank line reported by checkpatch.
- Carry Nicolas' Reviewed-by tag on the MDP patch.
Guangshuo Li (3):
media: mediatek: vpu: add watchdog handler unregister helper
media: mediatek: vcodec: unregister VPU watchdog handler
media: mtk-mdp: unregister VPU watchdog handler
drivers/media/platform/mediatek/mdp/mtk_mdp_core.c | 2 ++
.../mediatek/vcodec/common/mtk_vcodec_fw_vpu.c | 6 ++++++
drivers/media/platform/mediatek/vpu/mtk_vpu.c | 14 ++++++++++++++
drivers/media/platform/mediatek/vpu/mtk_vpu.h | 2 ++
4 files changed, 24 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/3] media: mediatek: vpu: add watchdog handler unregister helper
From: Guangshuo Li @ 2026-07-20 8:57 UTC (permalink / raw)
To: Minghsiu Tsai, Houlong Wei, Andrew-CT Chen, Mauro Carvalho Chehab,
Matthias Brugger, AngeloGioacchino Del Regno, Tiffany Lin,
Yunfei Dong, Hans Verkuil, Nicolas Dufresne, Chen-Yu Tsai,
Fei Shao, Tomasz Figa, Guangshuo Li, Haoxiang Li, Eizan Miyamoto,
Enric Balletbo i Serra, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260720085756.465667-1-lgs201920130244@gmail.com>
VPU clients register watchdog reset handlers with private data owned by
the client device. The VPU driver currently provides no way to clear a
handler when client initialization fails or when the client device is
removed.
Add vpu_wdt_unreg_handler() to clear the reset callback and its private
data while holding the VPU mutex. This allows clients to remove stale
watchdog entries before releasing their device references.
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/mediatek/vpu/mtk_vpu.c | 14 ++++++++++++++
drivers/media/platform/mediatek/vpu/mtk_vpu.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/media/platform/mediatek/vpu/mtk_vpu.c b/drivers/media/platform/mediatek/vpu/mtk_vpu.c
index 8d8319f0cd22..a2b937095248 100644
--- a/drivers/media/platform/mediatek/vpu/mtk_vpu.c
+++ b/drivers/media/platform/mediatek/vpu/mtk_vpu.c
@@ -437,6 +437,20 @@ int vpu_wdt_reg_handler(struct platform_device *pdev,
}
EXPORT_SYMBOL_GPL(vpu_wdt_reg_handler);
+void vpu_wdt_unreg_handler(struct platform_device *pdev, enum rst_id id)
+{
+ struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+
+ if (!vpu || id >= VPU_RST_MAX)
+ return;
+
+ mutex_lock(&vpu->vpu_mutex);
+ vpu->wdt.handler[id].reset_func = NULL;
+ vpu->wdt.handler[id].priv = NULL;
+ mutex_unlock(&vpu->vpu_mutex);
+}
+EXPORT_SYMBOL_GPL(vpu_wdt_unreg_handler);
+
unsigned int vpu_get_vdec_hw_capa(struct platform_device *pdev)
{
struct mtk_vpu *vpu = platform_get_drvdata(pdev);
diff --git a/drivers/media/platform/mediatek/vpu/mtk_vpu.h b/drivers/media/platform/mediatek/vpu/mtk_vpu.h
index 3951547e9ec5..2ccb481a04cf 100644
--- a/drivers/media/platform/mediatek/vpu/mtk_vpu.h
+++ b/drivers/media/platform/mediatek/vpu/mtk_vpu.h
@@ -141,6 +141,8 @@ int vpu_wdt_reg_handler(struct platform_device *pdev,
void vpu_wdt_reset_func(void *priv),
void *priv, enum rst_id id);
+void vpu_wdt_unreg_handler(struct platform_device *pdev, enum rst_id id);
+
/**
* vpu_get_vdec_hw_capa - get video decoder hardware capability
*
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] media: mediatek: vcodec: unregister VPU watchdog handler
From: Guangshuo Li @ 2026-07-20 8:57 UTC (permalink / raw)
To: Minghsiu Tsai, Houlong Wei, Andrew-CT Chen, Mauro Carvalho Chehab,
Matthias Brugger, AngeloGioacchino Del Regno, Tiffany Lin,
Yunfei Dong, Hans Verkuil, Nicolas Dufresne, Chen-Yu Tsai,
Fei Shao, Tomasz Figa, Guangshuo Li, Haoxiang Li, Eizan Miyamoto,
Enric Balletbo i Serra, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260720085756.465667-1-lgs201920130244@gmail.com>
mtk_vcodec_fw_vpu_init() registers a VPU watchdog reset handler and
passes the vcodec device as the private data.
The handler is stored in the VPU device and can outlive the vcodec
device. If firmware initialization fails after the handler has been
registered, or if the firmware object is later released, the watchdog
table can retain a pointer to a vcodec device that is about to be
released. A later watchdog reset can then call the reset handler with a
stale pointer and dereference freed memory while walking the vcodec
context list.
Unregister the watchdog handler in the firmware initialization failure
path and in the firmware release path before dropping the VPU device
reference.
Fixes: 01abf5fbb081 ("media: mediatek: vcodec: separate struct 'mtk_vcodec_ctx'")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
.../platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c
index 3632037f78f5..ee50a794077f 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c
@@ -40,6 +40,11 @@ static int mtk_vcodec_vpu_ipi_send(struct mtk_vcodec_fw *fw, int id, void *buf,
static void mtk_vcodec_vpu_release(struct mtk_vcodec_fw *fw)
{
+ enum rst_id rst_id;
+
+ rst_id = fw->fw_use == ENCODER ? VPU_RST_ENC : VPU_RST_DEC;
+ vpu_wdt_unreg_handler(fw->pdev, rst_id);
+
put_device(&fw->pdev->dev);
}
@@ -120,6 +125,7 @@ struct mtk_vcodec_fw *mtk_vcodec_fw_vpu_init(void *priv, enum mtk_vcodec_fw_use
fw = devm_kzalloc(&plat_dev->dev, sizeof(*fw), GFP_KERNEL);
if (!fw) {
+ vpu_wdt_unreg_handler(fw_pdev, rst_id);
put_device(&fw_pdev->dev);
return ERR_PTR(-ENOMEM);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/3] media: mtk-mdp: unregister VPU watchdog handler
From: Guangshuo Li @ 2026-07-20 8:57 UTC (permalink / raw)
To: Minghsiu Tsai, Houlong Wei, Andrew-CT Chen, Mauro Carvalho Chehab,
Matthias Brugger, AngeloGioacchino Del Regno, Tiffany Lin,
Yunfei Dong, Hans Verkuil, Nicolas Dufresne, Chen-Yu Tsai,
Fei Shao, Tomasz Figa, Guangshuo Li, Haoxiang Li, Eizan Miyamoto,
Enric Balletbo i Serra, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260720085756.465667-1-lgs201920130244@gmail.com>
mtk_mdp_probe() registers the MDP reset handler with the VPU watchdog
code and passes the MDP device as the private data.
The handler is stored in the VPU device and can outlive the MDP probe or
remove path. If probe fails after the handler has been registered, or if
the MDP device is removed, the watchdog table can retain a pointer to an
MDP object that is about to be released. A later VPU watchdog reset can
then call mtk_mdp_reset_handler() with a stale pointer and dereference
freed memory while queuing the MDP watchdog work.
Unregister the watchdog handler in the probe error path and in the
remove path before dropping the VPU device reference.
Fixes: ee18fc7b0b95 ("media: mtk-mdp: handle vpu_wdt_reg_handler() errors during probe")
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/mediatek/mdp/mtk_mdp_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c b/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c
index 8432833814f3..5ccb7aa925d9 100644
--- a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c
@@ -221,6 +221,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
return 0;
err_reg_handler:
+ vpu_wdt_unreg_handler(mdp->vpu_dev, VPU_RST_MDP);
platform_device_put(mdp->vpu_dev);
err_vpu_get_dev:
@@ -254,6 +255,7 @@ static void mtk_mdp_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
vb2_dma_contig_clear_max_seg_size(&pdev->dev);
+ vpu_wdt_unreg_handler(mdp->vpu_dev, VPU_RST_MDP);
platform_device_put(mdp->vpu_dev);
mtk_mdp_unregister_m2m_device(mdp);
v4l2_device_unregister(&mdp->v4l2_dev);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: ptdump: Flush the last region
From: Marc Zyngier @ 2026-07-20 9:03 UTC (permalink / raw)
To: Dev Jain
Cc: Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Ryan Roberts, Sebastian Ene, Vincent Donnefort
In-Reply-To: <ad52d1ee-04cb-42d7-b50c-dfb3d28db5df@arm.com>
On Mon, 20 Jul 2026 09:53:29 +0100,
Dev Jain <dev.jain@arm.com> wrote:
>
>
>
> On 18/07/26 4:42 am, Wei-Lin Chang wrote:
> > Currently the stage-2 ptdump calls note_page() at each leaf entry visit.
> > This simply misses the output of the last region, because note_page()
> > only dumps output when it detects a change in level/prot, or when the
> > walk enters a next marker section. The last region in the guest IPA
> > space with the same level/prot is not dumped since there is no change
> > after it.
> >
> > To dump the final region, manually issue a note_page() call with address
> > BIT(ia_bits) (end of guest IPA space) and level == -1 to trigger a level
> > change after the last region. Additionally treat level == -1 as a last
> > flushing note_page() call and avoid dumping the name of the next marker
> > for this case.
> >
> > Fixes: 7c4f73548ed1 ("KVM: arm64: Register ptdump with debugfs on guest creation")
> > Reported-by: Sashiko AI <sashiko-bot@kernel.org>
> > Closes: https://lore.kernel.org/kvmarm/20260630122758.891011F00A3A@smtp.kernel.org/
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > arch/arm64/kvm/ptdump.c | 8 +++++---
> > arch/arm64/mm/ptdump.c | 5 +++--
> > 2 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> > index c9140e22abcf..4096e4a92fae 100644
> > --- a/arch/arm64/kvm/ptdump.c
> > +++ b/arch/arm64/kvm/ptdump.c
> > @@ -155,11 +155,13 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
> > .seq = m,
> > };
> >
> > - write_lock(&kvm->mmu_lock);
> > + guard(write_lock)(&kvm->mmu_lock);
>
> The guard clause change has nothing to do with the fix I think? Although the change
> is small and the fix is for a recent commit so maybe we don't care having this
> in the same patch - not sure how strict kvm reviewers are about this : )
>
Look at the quality spaghetti code this would otherwise result in:
write_lock();
ret = kvm_pgtable_walk();
if (ret) {
write_unlock();
return ret;
}
note_page_flush();
write_unlock();
return 0;
How is that better? So it has *everything* to do with the fix.
And FWIW, the policy for KVM is that we don't do lock->guard
conversions as a separate patches. Only when we need to change the
code, and as part of the patch that changes that code. Which is
exactly what is happening here.
>
> > ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> > - write_unlock(&kvm->mmu_lock);
> > + if (ret)
> > + return ret;
> > + note_page(&st->parser_state.ptdump, BIT(mmu->pgt->ia_bits), -1, 0);
> >
> > - return ret;
> > + return 0;
> > }
> >
> > static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
> > diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> > index ab9899ca1e5f..fed4e4407e0e 100644
> > --- a/arch/arm64/mm/ptdump.c
> > +++ b/arch/arm64/mm/ptdump.c
> > @@ -194,6 +194,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> > struct ptdump_pg_state *st = container_of(pt_st, struct ptdump_pg_state, ptdump);
> > struct ptdump_pg_level *pg_level = st->pg_level;
> > static const char units[] = "KMGTPE";
> > + bool flush = level == -1;
>
> Can we do something similar to what S1 ptdump does (note_page_flush in ptdump_walk_pgd).
See Mark's email.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: ptdump: Flush the last region
From: Dev Jain @ 2026-07-20 9:10 UTC (permalink / raw)
To: Marc Zyngier
Cc: Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Ryan Roberts, Sebastian Ene, Vincent Donnefort
In-Reply-To: <868q76f2wy.wl-maz@kernel.org>
On 20/07/26 2:33 pm, Marc Zyngier wrote:
> On Mon, 20 Jul 2026 09:53:29 +0100,
> Dev Jain <dev.jain@arm.com> wrote:
>>
>>
>>
>> On 18/07/26 4:42 am, Wei-Lin Chang wrote:
>>> Currently the stage-2 ptdump calls note_page() at each leaf entry visit.
>>> This simply misses the output of the last region, because note_page()
>>> only dumps output when it detects a change in level/prot, or when the
>>> walk enters a next marker section. The last region in the guest IPA
>>> space with the same level/prot is not dumped since there is no change
>>> after it.
>>>
>>> To dump the final region, manually issue a note_page() call with address
>>> BIT(ia_bits) (end of guest IPA space) and level == -1 to trigger a level
>>> change after the last region. Additionally treat level == -1 as a last
>>> flushing note_page() call and avoid dumping the name of the next marker
>>> for this case.
>>>
>>> Fixes: 7c4f73548ed1 ("KVM: arm64: Register ptdump with debugfs on guest creation")
>>> Reported-by: Sashiko AI <sashiko-bot@kernel.org>
>>> Closes: https://lore.kernel.org/kvmarm/20260630122758.891011F00A3A@smtp.kernel.org/
>>> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
>>> ---
>>> arch/arm64/kvm/ptdump.c | 8 +++++---
>>> arch/arm64/mm/ptdump.c | 5 +++--
>>> 2 files changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
>>> index c9140e22abcf..4096e4a92fae 100644
>>> --- a/arch/arm64/kvm/ptdump.c
>>> +++ b/arch/arm64/kvm/ptdump.c
>>> @@ -155,11 +155,13 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
>>> .seq = m,
>>> };
>>>
>>> - write_lock(&kvm->mmu_lock);
>>> + guard(write_lock)(&kvm->mmu_lock);
>>
>> The guard clause change has nothing to do with the fix I think? Although the change
>> is small and the fix is for a recent commit so maybe we don't care having this
>> in the same patch - not sure how strict kvm reviewers are about this : )
>>
>
> Look at the quality spaghetti code this would otherwise result in:
>
> write_lock();
> ret = kvm_pgtable_walk();
> if (ret) {
> write_unlock();
> return ret;
> }
> note_page_flush();
> write_unlock();
>
> return 0;
>
> How is that better? So it has *everything* to do with the fix.
>
> And FWIW, the policy for KVM is that we don't do lock->guard
> conversions as a separate patches. Only when we need to change the
> code, and as part of the patch that changes that code. Which is
> exactly what is happening here.
I agree, thanks.
>
>>
>>> ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
>>> - write_unlock(&kvm->mmu_lock);
>>> + if (ret)
>>> + return ret;
>>> + note_page(&st->parser_state.ptdump, BIT(mmu->pgt->ia_bits), -1, 0);
>>>
>>> - return ret;
>>> + return 0;
>>> }
>>>
>>> static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
>>> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
>>> index ab9899ca1e5f..fed4e4407e0e 100644
>>> --- a/arch/arm64/mm/ptdump.c
>>> +++ b/arch/arm64/mm/ptdump.c
>>> @@ -194,6 +194,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
>>> struct ptdump_pg_state *st = container_of(pt_st, struct ptdump_pg_state, ptdump);
>>> struct ptdump_pg_level *pg_level = st->pg_level;
>>> static const char units[] = "KMGTPE";
>>> + bool flush = level == -1;
>>
>> Can we do something similar to what S1 ptdump does (note_page_flush in ptdump_walk_pgd).
>
> See Mark's email.
>
> M.
>
^ permalink raw reply
* Re: [PATCH v5 3/4] irqchip/gic-v3-its: Fix leak in its_vpe_irq_domain_alloc()
From: Marc Zyngier @ 2026-07-20 8:50 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, jason, lpieralisi, radu, linux-arm-kernel, linux-kernel
In-Reply-To: <20260720071215.50705-4-shikemeng@huaweicloud.com>
On Mon, 20 Jul 2026 08:12:14 +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. Try its_vpe_teardown() in error handling to 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 | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 3e4edcb64065..5dc91862fc15 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4594,9 +4594,11 @@ static int its_vpe_init(struct its_vpe *vpe)
>
> static void its_vpe_teardown(struct its_vpe *vpe)
> {
> - its_vpe_db_proxy_unmap(vpe);
> - its_vpe_id_free(vpe->vpe_id);
> - its_free_pending_table(vpe->vpt_page);
> + if (vpe->vpt_page != NULL) {
> + its_vpe_db_proxy_unmap(vpe);
> + its_vpe_id_free(vpe->vpe_id);
> + its_free_pending_table(vpe->vpt_page);
> + }
Please keep the diff minimal by doing an early return. This also
deserves a comment, because this is not completely obvious:
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 6f5811aae59c1..38032067135b6 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4592,6 +4592,13 @@ static int its_vpe_init(struct its_vpe *vpe)
static void its_vpe_teardown(struct its_vpe *vpe)
{
+ /*
+ * If vpt_page is NULL, then its_vpe_init() has failed, and
+ * there is nothing to do as no resource has been allocated.
+ */
+ if (!vpe->vpt_page)
+ return;
+
its_vpe_db_proxy_unmap(vpe);
its_vpe_id_free(vpe->vpe_id);
its_free_pending_table(vpe->vpt_page);
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH] pwm: meson: Convert to waveform API
From: Alexandre Mergnat @ 2026-07-20 9:20 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, linux-amlogic, Uwe Kleine-König,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-pwm,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260717192735.3E71E1F000E9@smtp.kernel.org>
On Fri, Jul 17, 2026 at 9:27 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Truncation error in hardware waveform quantization breaks legacy polarity inversion.
> - [Medium] Independent rounding in waveform readback produces an invalid state where duty + offset > period.
> --
...
> > + if (meson->data->has_polarity && duty_cnt) {
> > + u64 offset_cnt = mul_u64_u64_div_u64(fin_freq, wf->duty_offset_ns,
> > + NSEC_PER_SEC);
> > +
> > + /*
> > + * Waveforms with duty_offset_ns + duty_length_ns ==
> > + * period_length_ns are implemented by inverting the output:
> > + * The signal then is low for hi counts (the offset) followed
> > + * by high for lo counts (the duty cycle). Other nonzero
> > + * duty_offset_ns values are rounded down to 0.
> > + */
> > + if (offset_cnt && duty_cnt + offset_cnt >= cnt) {
>
> [Severity: High]
> Could integer division truncation cause this check to fail for inverted
> waveforms?
>
> If duty_cnt and offset_cnt are calculated with independent truncation, their
> sum might end up strictly less than cnt even when the original lengths sum to
> the period.
>
> Would this cause the driver to incorrectly fall back to normal polarity with a
> zero offset?
>
At a sub-count boundary floor(duty) + floor(offset) can be cnt - 1 instead of
cnt, so an inverted request can indeed fall back to a non-inverted setting with
duty_offset rounded down to 0. That is a valid result, not a failure:
.round_waveform_tohw() must round every quantity down and only has to return a
waveform not exceeding the request (see the contract above
pwm_set_waveform_might_sleep() and pwm_check_rounding() in drivers/pwm/core.c).
duty_offset 0 <= requested duty_offset, so the result stays within the contract
and CONFIG_PWM_DEBUG accepts it.
The same count-based test is used by pwm-stm32.c (duty_ticks + offset_ticks >=
arr + 1). So the conservative count-based check is intentional. No change.
> > + /*
> > + * wfhw->hi and wfhw->lo are u16, so their sum doesn't overflow and
> > + * NSEC_PER_SEC * (hi + lo) fits into the u64 dividend in
> > + * meson_pwm_cnt_to_ns().
> > + */
> > + wf->period_length_ns = meson_pwm_cnt_to_ns(wfhw->rate, wfhw->hi + wfhw->lo);
> > +
> > + if (wfhw->inverted && wfhw->lo == 0) {
> > + /*
> > + * The output is constant low. Report a normal constant-low
> > + * waveform instead of duty_offset_ns == period_length_ns
> > + * which wouldn't be a valid waveform description. This
> > + * setting is only reachable when the hardware was programmed
> > + * by the bootloader as .round_waveform_tohw() never produces
> > + * it.
> > + */
> > + wf->duty_length_ns = 0;
> > + wf->duty_offset_ns = 0;
> > + } else if (wfhw->inverted) {
> > + wf->duty_length_ns = meson_pwm_cnt_to_ns(wfhw->rate, wfhw->lo);
> > + wf->duty_offset_ns = meson_pwm_cnt_to_ns(wfhw->rate, wfhw->hi);
>
> [Severity: Medium]
> Since meson_pwm_cnt_to_ns() explicitly rounds up, can rounding duty_length_ns
> and duty_offset_ns independently result in their sum exceeding
> period_length_ns?
>
> For example, if rate is 333333333 Hz and both hi and lo counts are 1,
> period_length_ns rounds up to 7 ns, while duty_length_ns and duty_offset_ns
> would each round up to 4 ns. Their sum (8 ns) would exceed the period length,
> potentially leading to integer underflow in consumers attempting to calculate
> the remaining period time.
duty_offset_ns + duty_length_ns > period_length_ns is not an invalid waveform.
The waveform API requires only duty_length_ns <= period_length_ns and
duty_offset_ns < period_length_ns (pwm_wf_valid() in drivers/pwm/core.c); the
sum is deliberately allowed to exceed the period and represents the high phase
wrapping past the period end, i.e. inverted polarity (see the kerneldoc on
struct pwm_waveform in include/linux/pwm.h). For the example {period 7, duty 4,
offset 4} both invariants hold (4 <= 7, 4 < 7), so it is valid.
The core handles it explicitly: pwm_wf2state() maps
duty_length + duty_offset >= period to PWM_POLARITY_INVERSED with
duty_cycle = period - duty_length = 3 ns, so there is no underflow. Rounding
each reported value up independently is what pwm-stm32.c, pwm_th1520.rs and
pwm-axi-pwmgen.c do as well; it is required so that feeding the reported
waveform back through .round_waveform_tohw() reproduces the same counters.
No change.
Alexandre Mergnat
^ permalink raw reply
* [PATCH RESEND] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Chen-Yu Tsai @ 2026-07-20 9:21 UTC (permalink / raw)
To: Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Chen-Yu Tsai,
linux-pci, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel, Krzysztof Kozlowski, Conor Dooley
On some SoCs without an IOMMU behind the PCIe controller, the PCIe
controller memory access could be limited to a small region by the
firmware configuring a memory protection unit. This memory region
must be assigned to the PCIe controller so that the OS knows to
use that region. Otherwise PCIe devices would not work properly.
Allow the memory-region property with one item pointing to a
restricted DMA buffer.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Can we get this merged for v7.2? A matching device tree change was
already merged in v7.2-rc1.
Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
index fbc0378392d4..b88717dec1fa 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -116,6 +116,10 @@ properties:
power-domains:
maxItems: 1
+ memory-region:
+ maxItems: 1
+ description: phandle to restricted DMA buffer
+
mediatek,pbus-csr:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* [PATCH 0/8] driver core: prefer platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
With the final platform device and software node rework changes having
been queued in the driver core tree, Danilo pointed out that
platform_device_set_fwnode() is no longer used and should be removed. I
argued that instead we should prefer it over the OF-specific
platform_device_set_of_node().
This series converts drivers using platform_device_set_of_node() to
platform_device_set_fwnode() and does not intend any functional change
as the semantics of:
platform_device_set_of_node(pdev, np);
should be equal to those of:
platform_device_set_fwnode(pdev, of_fwnode_handle(np));
The prerequisite changes are currently in the driver core tree so this
entire series should follow them as well with Acks from maintainers. If
it doesn't make v7.3 for some reason, then I will resend these next
cycle separately targetting individual trees.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Bartosz Golaszewski (8):
powerpc/powermac: use platform_device_set_fwnode()
i2c: pxa-pci: use platform_device_set_fwnode()
iommu/fsl: use platform_device_set_fwnode()
net: bcmgenet: use platform_device_set_fwnode()
pmdomain: imx: use platform_device_set_fwnode()
mfd: tps6586: use platform_device_set_fwnode()
net: mv643xx: use platform_device_set_fwnode()
slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode()
arch/powerpc/platforms/powermac/low_i2c.c | 2 +-
drivers/i2c/busses/i2c-pxa-pci.c | 2 +-
drivers/iommu/fsl_pamu.c | 2 +-
drivers/mfd/tps6586x.c | 2 +-
drivers/net/ethernet/broadcom/genet/bcmmii.c | 3 ++-
drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
drivers/pmdomain/imx/gpc.c | 2 +-
drivers/slimbus/qcom-ngd-ctrl.c | 2 +-
8 files changed, 9 insertions(+), 8 deletions(-)
---
base-commit: 27edebd505791748a77703e311d76f0f55a8d7ec
change-id: 20260720-pdev-set-fwnode-instead-of-of-node-e83ece371509
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 2/8] i2c: pxa-pci: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/i2c/busses/i2c-pxa-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-pxa-pci.c b/drivers/i2c/busses/i2c-pxa-pci.c
index 92a0647f08c69f841ca99caca757c1728b3f6fce..58532cf9f06d43a0f2173b962eb498c9e4bb81d0 100644
--- a/drivers/i2c/busses/i2c-pxa-pci.c
+++ b/drivers/i2c/busses/i2c-pxa-pci.c
@@ -77,7 +77,7 @@ static struct platform_device *add_i2c_device(struct pci_dev *dev, int bar)
}
pdev->dev.parent = &dev->dev;
- platform_device_set_of_node(pdev, child);
+ platform_device_set_fwnode(pdev, of_fwnode_handle(child));
ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (ret)
--
2.47.3
^ permalink raw reply related
* [PATCH 1/8] powerpc/powermac: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/powerpc/platforms/powermac/low_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
index a175a32a222bab4cc7400f6ab6071f5630db2cb8..eda35534cfd72e828616f27b5f8319189d68285e 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -1471,7 +1471,7 @@ static int __init pmac_i2c_create_platform_devices(void)
if (bus->platform_dev == NULL)
return -ENOMEM;
bus->platform_dev->dev.platform_data = bus;
- platform_device_set_of_node(bus->platform_dev, bus->busnode);
+ platform_device_set_fwnode(bus->platform_dev, of_fwnode_handle(bus->busnode));
platform_device_add(bus->platform_dev);
}
--
2.47.3
^ permalink raw reply related
* [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 0f0dbabfaabbce3469de79af91d7731b8476709f..6f471723bd53f454e4b0de1716977b4382013429 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -492,7 +492,8 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv)
ppdev->dev.parent = &pdev->dev;
if (dn)
- platform_device_set_of_node(ppdev, bcmgenet_mii_of_find_mdio(priv));
+ platform_device_set_fwnode(ppdev,
+ of_fwnode_handle(bcmgenet_mii_of_find_mdio(priv)));
else
ppd.phy_mask = ~0;
--
2.47.3
^ permalink raw reply related
* [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/iommu/fsl_pamu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index c83bbc3faad56d6ee1c89b0a7f74028af02c81e9..268a1f752fbceab4fd24013aeea5df1b6982fbb1 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -975,7 +975,7 @@ static __init int fsl_pamu_init(void)
goto error_device_alloc;
}
- platform_device_set_of_node(pdev, np);
+ platform_device_set_fwnode(pdev, of_fwnode_handle(np));
ret = pamu_domain_init();
if (ret)
--
2.47.3
^ permalink raw reply related
* [PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/pmdomain/imx/gpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
index abca5f449a226fbae4213926e1395c413160c950..c147eaf048ba2b79a744ec87029420981581e48e 100644
--- a/drivers/pmdomain/imx/gpc.c
+++ b/drivers/pmdomain/imx/gpc.c
@@ -487,7 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
domain->ipg_rate_mhz = ipg_rate_mhz;
pd_pdev->dev.parent = &pdev->dev;
- platform_device_set_of_node(pd_pdev, np);
+ platform_device_set_fwnode(pd_pdev, of_fwnode_handle(np));
ret = platform_device_add(pd_pdev);
if (ret) {
--
2.47.3
^ permalink raw reply related
* [PATCH 6/8] mfd: tps6586: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/mfd/tps6586x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index 3cfd2f02b62f3cc370e0d970ec2643b638fd0fec..fc7c4b55c385416741925904abae4fd240f55b13 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -397,7 +397,7 @@ static int tps6586x_add_subdevs(struct tps6586x *tps6586x,
pdev->dev.parent = tps6586x->dev;
pdev->dev.platform_data = subdev->platform_data;
- platform_device_set_of_node(pdev, subdev->of_node);
+ platform_device_set_fwnode(pdev, of_fwnode_handle(subdev->of_node));
ret = platform_device_add(pdev);
if (ret) {
--
2.47.3
^ permalink raw reply related
* [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
goto put_err;
}
ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
- platform_device_set_of_node(ppdev, pnp);
+ platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
ret = platform_device_add_resources(ppdev, &res, 1);
if (ret)
--
2.47.3
^ permalink raw reply related
* [PATCH 8/8] slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-20 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound, Bartosz Golaszewski
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com>
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/slimbus/qcom-ngd-ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index 934c44c5bc1a92fae98f52bccd12ed849379dca8..bf077f47c9ddd484c11f98b47d2d8d4daf78dcb7 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -1538,7 +1538,7 @@ static int of_qcom_slim_ngd_register(struct device *parent,
kfree(ngd);
return ret;
}
- platform_device_set_of_node(ngd->pdev, node);
+ platform_device_set_fwnode(ngd->pdev, of_fwnode_handle(node));
ctrl->ngd = ngd;
ret = platform_device_add(ngd->pdev);
--
2.47.3
^ permalink raw reply related
* [PATCH] arm64: dts: mediatek: mt8192-asurada: Disable mmc1 on Spherion
From: Chen-Yu Tsai @ 2026-07-20 9:27 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
Spherion does not have an micro SD card slot.
Disable mmc1.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts b/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts
index c02edba73eaf..0b976b09d47f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada-spherion-r0.dts
@@ -64,6 +64,10 @@ &rt5682 {
VBAT-supply = <&pp3300_ldo_z>;
};
+&mmc1 {
+ status = "disabled";
+};
+
&sound {
compatible = "mediatek,mt8192_mt6359_rt1015p_rt5682";
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: ptdump: Flush the last region
From: Dev Jain @ 2026-07-20 9:30 UTC (permalink / raw)
To: Marc Zyngier
Cc: Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Ryan Roberts, Sebastian Ene, Vincent Donnefort
In-Reply-To: <4a598a6c-496f-441c-b268-a725f9ee8090@arm.com>
On 20/07/26 2:40 pm, Dev Jain wrote:
>
>
> On 20/07/26 2:33 pm, Marc Zyngier wrote:
>> On Mon, 20 Jul 2026 09:53:29 +0100,
>> Dev Jain <dev.jain@arm.com> wrote:
>>>
>>>
>>>
>>> On 18/07/26 4:42 am, Wei-Lin Chang wrote:
>>>> Currently the stage-2 ptdump calls note_page() at each leaf entry visit.
>>>> This simply misses the output of the last region, because note_page()
>>>> only dumps output when it detects a change in level/prot, or when the
>>>> walk enters a next marker section. The last region in the guest IPA
>>>> space with the same level/prot is not dumped since there is no change
>>>> after it.
>>>>
>>>> To dump the final region, manually issue a note_page() call with address
>>>> BIT(ia_bits) (end of guest IPA space) and level == -1 to trigger a level
>>>> change after the last region. Additionally treat level == -1 as a last
>>>> flushing note_page() call and avoid dumping the name of the next marker
>>>> for this case.
>>>>
>>>> Fixes: 7c4f73548ed1 ("KVM: arm64: Register ptdump with debugfs on guest creation")
>>>> Reported-by: Sashiko AI <sashiko-bot@kernel.org>
>>>> Closes: https://lore.kernel.org/kvmarm/20260630122758.891011F00A3A@smtp.kernel.org/
>>>> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
>>>> ---
>>>> arch/arm64/kvm/ptdump.c | 8 +++++---
>>>> arch/arm64/mm/ptdump.c | 5 +++--
>>>> 2 files changed, 8 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
>>>> index c9140e22abcf..4096e4a92fae 100644
>>>> --- a/arch/arm64/kvm/ptdump.c
>>>> +++ b/arch/arm64/kvm/ptdump.c
>>>> @@ -155,11 +155,13 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
>>>> .seq = m,
>>>> };
>>>>
>>>> - write_lock(&kvm->mmu_lock);
>>>> + guard(write_lock)(&kvm->mmu_lock);
>>>
>>> The guard clause change has nothing to do with the fix I think? Although the change
>>> is small and the fix is for a recent commit so maybe we don't care having this
>>> in the same patch - not sure how strict kvm reviewers are about this : )
>>>
>>
>> Look at the quality spaghetti code this would otherwise result in:
>>
>> write_lock();
>> ret = kvm_pgtable_walk();
>> if (ret) {
>> write_unlock();
>> return ret;
>> }
>> note_page_flush();
>> write_unlock();
>>
>> return 0;
>>
>> How is that better? So it has *everything* to do with the fix.
>>
>> And FWIW, the policy for KVM is that we don't do lock->guard
>> conversions as a separate patches. Only when we need to change the
>> code, and as part of the patch that changes that code. Which is
>> exactly what is happening here.
>
> I agree, thanks.
Yeah in my head I was thinking that the guard clause is a "functional change"
but it really isn't, the fix implies that without the guard you will get
horrible code, and had the code been correct in the first place, it would
have been written *with* the guard, so yes that was a stupid
observation from my side : )
>
>
>>
>>>
>>>> ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
>>>> - write_unlock(&kvm->mmu_lock);
>>>> + if (ret)
>>>> + return ret;
>>>> + note_page(&st->parser_state.ptdump, BIT(mmu->pgt->ia_bits), -1, 0);
>>>>
>>>> - return ret;
>>>> + return 0;
>>>> }
>>>>
>>>> static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
>>>> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
>>>> index ab9899ca1e5f..fed4e4407e0e 100644
>>>> --- a/arch/arm64/mm/ptdump.c
>>>> +++ b/arch/arm64/mm/ptdump.c
>>>> @@ -194,6 +194,7 @@ void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
>>>> struct ptdump_pg_state *st = container_of(pt_st, struct ptdump_pg_state, ptdump);
>>>> struct ptdump_pg_level *pg_level = st->pg_level;
>>>> static const char units[] = "KMGTPE";
>>>> + bool flush = level == -1;
>>>
>>> Can we do something similar to what S1 ptdump does (note_page_flush in ptdump_walk_pgd).
>>
>> See Mark's email.
>>
>> M.
>>
>
^ 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