* [PATCH v3] ARM: breakpoint: CFI breakpoints only on demand
From: Linus Walleij @ 2026-07-01 10:42 UTC (permalink / raw)
To: Russell King, Nathan Chancellor, Sami Tolvanen, Kees Cook,
Russell King (Oracle)
Cc: linux-arm-kernel, linux-kernel, stable, slipher, Linus Walleij
This removes the stub hw_breakpoint_cfi_handler() from ARM, making
it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless
CFI is actively used in the kernel.
When not instrumenting with CFI, we fall through to return 1 from
hw_breakpoint_pending() "unhandled fault" so userspace can make use
of this breakpoint.
This of course does not work if userspace want to use CFI and custom
breakpoints at the same time, and CONFIG_CFI does exist as something
users might want to select for their kernel. If this is not good
acceptable we need to think about other ways for CFI to interfer, such
as not using BKPT at all (rather something like BUG()) and back out
the offending patch until the compiler behaviour has changed.
Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints")
Reported-by: slipher <slipher@protonmail.com>
Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Trying to solve the CFI bug. Let's see of this first
approach is acceptable for the reporter.
---
Changes in v3:
- Actually strip the RFC prefix...
- Link to v2: https://patch.msgid.link/20260701-arm32-cfi-bug-v2-1-9bf922593e00@kernel.org
Changes in v2:
- Resending as non-RFC so it can be applied as a band-aid.
- Link to v1: https://patch.msgid.link/20260626-arm32-cfi-bug-v1-1-a467b5050c0b@kernel.org
---
arch/arm/kernel/hw_breakpoint.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index cd4b34c96e35..007023db6a5d 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -929,10 +929,6 @@ static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
break;
}
}
-#else
-static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
-{
-}
#endif
/*
@@ -964,9 +960,11 @@ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr,
case ARM_ENTRY_SYNC_WATCHPOINT:
watchpoint_handler(addr, fsr, regs);
break;
+#ifdef CONFIG_CFI
case ARM_ENTRY_CFI_BREAKPOINT:
hw_breakpoint_cfi_handler(regs);
break;
+#endif
default:
ret = 1; /* Unhandled fault. */
}
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260626-arm32-cfi-bug-10fb960749c4
Best regards,
--
Linus Walleij <linusw@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 06/13] KVM: arm64: dirty_bit: Add base FEAT_HACDBS cleaning routine
From: Leonardo Bras @ 2026-07-01 10:47 UTC (permalink / raw)
To: Oliver Upton
Cc: Leonardo Bras, Catalin Marinas, Will Deacon, Marc Zyngier,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng,
linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <akQTypBfpdqSMhm_@kernel.org>
On Tue, Jun 30, 2026 at 12:06:50PM -0700, Oliver Upton wrote:
> On Tue, Jun 30, 2026 at 03:59:38PM +0100, Leonardo Bras wrote:
> > > > + hcr_el2 = read_sysreg(HCR_EL2);
> > > > + write_sysreg(hcr_el2 | HCR_EL2_VM, HCR_EL2);
> > >
> > > sysreg_clear_set_hcr(). I'm pretty sure all the speculative AT errata
> > > depend on HCR_EL2.VM being set _after_ the stage-2 MMU has been loaded.
> > >
> >
> > So, move this to after __load_stage2()?
> > ok
>
> Yes.
>
> > > > + __load_stage2(&kvm->arch.mmu);
> > >
> > > Pretty sure you need an ISB here to ensure loading the MMU is ordered
> > > with enabling HACDBS.
> > >
> >
> > does not __load_stage2() have an isb() here?
> > In any case, will add an isb() after sysreg_clear_set_hcr(), which should
> > come after __load_stage2() IIUC.
>
> No, __load_stage2() inserts an ISB only for hardware subject to the
> speculative AT errata. If an implementation has broken AT and HACDBS in
> the future then it gets an additional ISB. Oh well.
>
Makes sense.
> > > > + hacdbs_start(hw_entries, size);
> > > > +
> > > > + do {
> > > > + wfi();
> > > > + } while (this_cpu_read(hacdbs_pcp.status) == HACDBS_RUNNING);
> > >
> > > This is exactly why I said you should just poll hardware instead. It is
> > > entirely possible that the IRQ arrives before you WFI.
> >
> > It should be fine with WFIT, though, right?
>
> Sure, but we shouldn't assume a functional WFxT even if we have HACDBS.
> Just rely on pre-existing kernel infrastructure to do the thing you want
> to.
Got it.
>
> > I understand the reason in pooling, and even done some workaround in
> > pooling for getting this to run in the model.
> >
> > Based on the previous reply, do you think I should only use polling for
> > now, and implement the IRQ later?
>
> Yes.
>
Will do, then.
Thanks!
Leo
^ permalink raw reply
* [PATCH V5 0/7]PCI: imx6: Integrate pwrctrl API and update device trees
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
From: Sherry Sun <sherry.sun@nxp.com>
This series integrates the PCI pwrctrl framework into the pci-imx6
driver and updates i.MX EVK board device trees to support it.
Patches 2-8 update device trees for i.MX EVK boards which maintained
by NXP to move power supply properties from the PCIe controller node
to the Root Port child node, which is required for pwrctrl framework.
Affected boards:
- i.MX6Q/DL SABRESD
- i.MX6SX SDB
- i.MX8MM EVK
- i.MX8MP EVK
- i.MX8MQ EVK
- i.MX8DXL/QM/QXP EVK
- i.MX95 15x15/19x19 EVK
The driver maintains legacy regulator handling for device trees that
haven't been updated yet. Both old and new device tree structures are
supported.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
Changes in V5:
1. Legacy power supply property is retained for backward compatibility
in patch 1-6.
Changes in V4:
1. Fix the CHECK_DTBS warnings.
2. Drop pci-imx6 pwrctrl support patch as it got applied.
Changes in V3:
1. Rebased on top of latest 7.1.0-rc4
Changes in V2:
1. After commit 2d8c5098b847 ("PCI/pwrctrl: Do not power off on pwrctrl
device removal"), the pwrctrl drivers no longer power off devices
during removal. Update pci-imx6 driver's shutdown callback in patch#1
to explicitly call pci_pwrctrl_power_off_devices() before
pci_pwrctrl_destroy_devices() to ensure devices are properly powered
off.
---
Sherry Sun (7):
arm: dts: imx6qdl-sabresd: Add power supply property to Root Port node
arm: dts: imx6sx-sdb: Add power supply property to Root Port node
arm64: dts: imx8mm-evk: Add power supply property to Root Port node
arm64: dts: imx8mp-evk: Add power supply properties to Root Port node
arm64: dts: imx8mq-evk: Add power supply properties to Root Port node
arm64: dts: imx8dxl/qm/qxp: Add power supply properties to Root Port
node
arm64: dts: imx95: Move power supply properties to Root Port node
arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 2 ++
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 2 ++
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 3 +++
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 2 ++
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 3 +++
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 3 +++
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 3 +++
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 3 +++
arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts | 8 ++++----
10 files changed, 27 insertions(+), 6 deletions(-)
base-commit: be5c93fa674f0fc3c8f359c2143abce6bbb422e6
--
2.50.1
^ permalink raw reply
* [PATCH V5 1/7] arm: dts: imx6qdl-sabresd: Add power supply property to Root Port node
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
In-Reply-To: <20260701105234.198987-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Add the power supply property to the Root Port child node to support the
new PCI pwrctrl framework.
Legacy power supply property is retained for backward compatibility with
existing kernels. New device trees should specify power supply at the
Root Port level to utilize the pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
index fe9046c03ddd..60fe0f973668 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
@@ -756,12 +756,14 @@ &pcie {
pinctrl-0 = <&pinctrl_pcie>;
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pcie>;
status = "okay";
};
&pcie_port0 {
reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcie>;
};
&pwm1 {
--
2.50.1
^ permalink raw reply related
* [PATCH V5 2/7] arm: dts: imx6sx-sdb: Add power supply property to Root Port node
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
In-Reply-To: <20260701105234.198987-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Add the power supply property to the Root Port child node to support the
new PCI pwrctrl framework.
Legacy power supply property is retained for backward compatibility with
existing kernels. New device trees should specify power supply at the
Root Port level to utilize the pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
index 338de4d144b2..2d3521ea0caa 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
@@ -284,12 +284,14 @@ &pcie {
pinctrl-0 = <&pinctrl_pcie>;
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio2 0 GPIO_ACTIVE_LOW>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pcie_gpio>;
status = "okay";
};
&pcie_port0 {
reset-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcie_gpio>;
};
&lcdif1 {
--
2.50.1
^ permalink raw reply related
* [PATCH V5 3/7] arm64: dts: imx8mm-evk: Add power supply property to Root Port node
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
In-Reply-To: <20260701105234.198987-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Add the power supply property to the Root Port child node to support the
new PCI pwrctrl framework.
Legacy power supply property is retained for backward compatibility with
existing kernels. New device trees should specify power supply at the
Root Port level to utilize the pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
index e03aba825c18..ec49cbbfd9ce 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
@@ -542,6 +542,7 @@ &pcie0 {
assigned-clock-rates = <10000000>, <250000000>;
assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
<&clk IMX8MM_SYS_PLL2_250M>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pcie0>;
supports-clkreq;
status = "okay";
@@ -562,6 +563,7 @@ &pcie0_ep {
&pcie0_port0 {
reset-gpios = <&gpio4 21 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcie0>;
};
&sai2 {
--
2.50.1
^ permalink raw reply related
* [PATCH V5 4/7] arm64: dts: imx8mp-evk: Add power supply properties to Root Port node
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
In-Reply-To: <20260701105234.198987-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Add the power supply properties to the Root Port child nodes to support
the new PCI pwrctrl framework.
Legacy power supply properties are retained for backward compatibility
with existing kernels. New device trees should specify power supplies at
the Root Port level to utilize the pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index a7f3acdc36d1..ca09a929ba0a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -772,6 +772,7 @@ &pcie0 {
pinctrl-0 = <&pinctrl_pcie0>;
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio2 7 GPIO_ACTIVE_LOW>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pcie0>;
vpcie3v3aux-supply = <®_pcie0>;
supports-clkreq;
@@ -786,6 +787,8 @@ &pcie0_ep {
&pcie0_port0 {
reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcie0>;
+ vpcie3v3aux-supply = <®_pcie0>;
};
&pwm1 {
--
2.50.1
^ permalink raw reply related
* [PATCH V5 5/7] arm64: dts: imx8mq-evk: Add power supply properties to Root Port node
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
In-Reply-To: <20260701105234.198987-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Add the power supply properties to the Root Port child nodes to support
the new PCI pwrctrl framework.
Legacy power supply properties are retained for backward compatibility
with existing kernels. New device trees should specify power supplies at
the Root Port level to utilize the pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index b9b03416aa39..1f07f1089026 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -403,6 +403,7 @@ &pcie1 {
<&pcie0_refclk>,
<&clk IMX8MQ_CLK_PCIE2_PHY>,
<&clk IMX8MQ_CLK_PCIE2_AUX>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pcie1>;
vpcie3v3aux-supply = <®_pcie1>;
vph-supply = <&vgen5_reg>;
@@ -422,6 +423,8 @@ &pcie1_ep {
&pcie1_port0 {
reset-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcie1>;
+ vpcie3v3aux-supply = <®_pcie1>;
};
&pgc_gpu {
--
2.50.1
^ permalink raw reply related
* [PATCH V5 6/7] arm64: dts: imx8dxl/qm/qxp: Add power supply properties to Root Port node
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
In-Reply-To: <20260701105234.198987-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Add the power supply properties to the Root Port child nodes to support
the new PCI pwrctrl framework.
Legacy power supply properties are retained for backward compatibility
with existing kernels. New device trees should specify power supplies at
the Root Port level to utilize the pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 3 +++
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 3 +++
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 3 +++
3 files changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
index 78e8d41e6791..0ede0c7ed422 100644
--- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
@@ -677,6 +677,7 @@ &pcie0 {
pinctrl-names = "default";
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pcieb>;
vpcie3v3aux-supply = <®_pcieb>;
status = "okay";
@@ -692,6 +693,8 @@ &pcie0_ep {
&pcieb_port0 {
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcieb>;
+ vpcie3v3aux-supply = <®_pcieb>;
};
&sai0 {
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
index f706c86137c0..9e49ac377162 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
@@ -812,6 +812,7 @@ &pciea {
pinctrl-names = "default";
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pciea>;
vpcie3v3aux-supply = <®_pciea>;
supports-clkreq;
@@ -820,6 +821,8 @@ &pciea {
&pciea_port0 {
reset-gpios = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pciea>;
+ vpcie3v3aux-supply = <®_pciea>;
};
&pcieb {
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 2af32eca612a..857a6e512228 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -732,6 +732,7 @@ &pcie0 {
pinctrl-names = "default";
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+ /* This property is deprecated, use power supply from the Root Port node. */
vpcie-supply = <®_pcieb>;
vpcie3v3aux-supply = <®_pcieb>;
supports-clkreq;
@@ -748,6 +749,8 @@ &pcie0_ep {
&pcieb_port0 {
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcieb>;
+ vpcie3v3aux-supply = <®_pcieb>;
};
&scu_key {
--
2.50.1
^ permalink raw reply related
* [PATCH V5 7/7] arm64: dts: imx95: Move power supply properties to Root Port node
From: Sherry Sun (OSS) @ 2026-07-01 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
sherry.sun
In-Reply-To: <20260701105234.198987-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Move the power supply properties from the PCIe controller nodes to the
Root Port child nodes to support the new PCI pwrctrl framework.
Since i.MX95 is the new platform that under development phase, it should
be fine to simply move the power supply properties.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
index 7d820a0f80b2..6aedcbbe915a 100644
--- a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
@@ -555,8 +555,6 @@ &pcie0 {
pinctrl-names = "default";
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio5 13 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_m2_pwr>;
- vpcie3v3aux-supply = <®_m2_pwr>;
supports-clkreq;
status = "disabled";
};
@@ -570,6 +568,8 @@ &pcie0_ep {
&pcie0_port0 {
reset-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_m2_pwr>;
+ vpcie3v3aux-supply = <®_m2_pwr>;
};
&sai1 {
diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index 2e463bc7c601..340ab0253ec2 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -542,8 +542,6 @@ &pcie0 {
pinctrl-names = "default";
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcie0>;
- vpcie3v3aux-supply = <®_pcie0>;
supports-clkreq;
status = "okay";
};
@@ -557,6 +555,8 @@ &pcie0_ep {
&pcie0_port0 {
reset-gpios = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_pcie0>;
+ vpcie3v3aux-supply = <®_pcie0>;
};
&pcie1 {
@@ -564,8 +564,6 @@ &pcie1 {
pinctrl-names = "default";
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_slot_pwr>;
- vpcie3v3aux-supply = <®_slot_pwr>;
status = "okay";
};
@@ -578,6 +576,8 @@ &pcie1_ep {
&pcie1_port0 {
reset-gpios = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>;
+ vpcie3v3-supply = <®_slot_pwr>;
+ vpcie3v3aux-supply = <®_slot_pwr>;
};
&sai1 {
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v14 00/44] arm64: Support for Arm CCA in KVM
From: Steven Price @ 2026-07-01 10:53 UTC (permalink / raw)
To: Kohei Enju
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Aneesh Kumar K . V,
Emi Kisanuki, Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <akR0eX0nCumIgnlh@FCCLS0092175.localdomain>
On 01/07/2026 03:15, Kohei Enju wrote:
> On 05/13 14:17, Steven Price wrote:
>> This series adds support for running protected VMs using KVM under the
>> Arm Confidential Compute Architecture (CCA).
>>
>> This is rebased on v7.1-rc1, but still targets RMM v2.0-bet1[1].
>>
>> The major updates from v13 remain but have been more fully implemented:
>> the RMM uses the host's page size, range based RMI APIs mean we don't
>> have to break everything down to base page sizes, the GIC state is
>> passed via system registers, and the uAPI has been simplified.
>>
>> The main changes since v13 are:
>>
>> * The RMI definitions and wrappers have been fully updated for RMM
>> v2.0-bet1. In particular the temporary RMM v1.0 SMC compatibility
>> patch has been dropped.
>>
>> * The PSCI completion ioctl has been removed. RMM v2.0-bet1 still
>> requires the host to provide the target REC for PSCI calls which
>> name another vCPU, but KVM now performs the RMI PSCI completion
>> automatically before entering the REC again. Userspace no longer
>> needs to issue KVM_ARM_VCPU_RMI_PSCI_COMPLETE. A future spec should
>> remove the need for the host to provide the MPIDR mapping.
>>
>> * The generic RMI init, RMM configuration, GPT setup,
>> delegate/undelegate helpers and SRO infrastructure have moved out of
>> KVM into arch/arm64/kernel/rmi.c. RMI is expected to be used by
>> features outside KVM, so this code should be available even when KVM
>> is not built.
>>
>> * RMI_GRANULE_TRACKING_GET has been updated to work on a range, this
>> allows it to work when the region is not aligned to the tracking
>> size. Solves the problem reported by Mathieu[2].
>>
>> * SRO support has been moved earlier in the series and improved. It
>> provides a cleaner way for the host to provide the RMM with the extra
>> memory it requires. However support is still incomplete where the
>> TF-RMM code does not yet implement it. This is noted by FIXMEs in the
>> code.
>>
>> * The ARM VM type encoding has been reworked to coexist with the
>> upstream pKVM KVM_VM_TYPE_ARM_PROTECTED bit.
>>
>> * The private-memory documentation now notes that arm64 uses
>> KVM_CAP_MEMORY_ATTRIBUTES.
>>
>> * PMU support is dropped for now. It will be added later in a separate
>> series. Similarly for selecting the hash algorithm and RPV.
>
> Hi Steven,
Hi,
> Is there any plan to add support for selecting the MEC policy (shared or
> private)? We have been working on adding support for this on top of your
> series. If this is not already in the works, we may upstream our
> implementation later.
I've been trying to focus on getting the minimum useful series
upstreamed before looking at additional features (such as hash
algorithm, MEC policy etc). If you've already got support then yes
please do upstream it later when we've got this series landed.
Thanks,
Steve
> Thanks,
> Kohei
>
>>
>> There are also the usual rebase updates and smaller fixes, including
>> changes to the RMM v2.0-bet1 range APIs, removal of REC auxiliary
>> granule handling, fixes to the address range descriptor encoding, and
>> cleanups around realm stage-2 teardown.
>>
>> Stateful RMI Operations
>> -----------------------
>>
>> The RMM v2.0 spec introduces Stateful RMI Operations (SROs), which allow
>> the RMM to complete an operation over several SMC calls while requesting
>> or returning memory to the host. This allows interrupts to be handled in
>> the middle of an operation and lets the RMM dynamically allocate memory
>> for internal tracking purposes. For example, RMI_REC_CREATE no longer
>> needs auxiliary granules to be provided up front, and can instead
>> request memory during the operation.
>>
>> This series includes the generic SRO infrastructure in
>> arch/arm64/kernel/rmi.c and uses it for REC create/destroy. The other
>> cases are not yet used by TF-RMM and a future revision will be needed to
>> finish those paths in Linux.
>>
>> This series is based on v7.1-rc1. It is also available as a git
>> repository:
>>
>> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v14
>>
>> Work in progress changes for kvmtool are available from the git
>> repository below:
>>
>> https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v12
>>
>> The TF-RMM has not yet merged the RMM v2.0 support, so you will need to
>> use a branch with RMM v2.0-bet1 support. At the time of writing the
>> following branch is being used:
>>
>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc_2
>> (tested on commit 3340667a291a)
>>
>> There is a kvm-unit-test branch which has been updated to support the
>> attestation used in RMMv2.0 available here:
>>
>> https://gitlab.arm.com/linux-arm/kvm-unit-tests-cca cca/v4
>>
>> [1] https://developer.arm.com/documentation/den0137/2-0bet1/
>> [2] https://lore.kernel.org/all/acrj-cKphy4hJsEG@p14s/
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Linus Walleij @ 2026-07-01 10:53 UTC (permalink / raw)
To: Michael Walle
Cc: Manikandan Muralidharan, pratyush, mwalle, takahiro.kuwano,
miquel.raynal, richard, vigneshr, robh, krzk+dt, conor+dt, srini,
nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
richardcochran, arnd, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <DJN3HIIAY4LE.3MXU9Q2YFSCJJ@walle.cc>
On Wed, Jul 1, 2026 at 10:34 AM Michael Walle <michael@walle.cc> wrote:
> If I'm correct, this is the old style, see commit bd912c991d2e
> ("dt-bindings: nvmem: layouts: add fixed-layout"). So it should
> eventually look like:
>
> sfdp {
> compatible = "jedec,sfdp";
(...)
> Also I'm not sure if we really need to add the "nvmem-cells" here.
> IIRC in MTD it was there to tell a driver to add an nvmem device to
> an already existing compatible/node.
>
> Apart from the MTD case, I've just found qcom,smem-part,yaml which
> has compatible = "nvmem-cells".
You're right, I was using old information, discard my comments...
Reviewed-by: Linus Walleij <linusw@kernel.org>
I think my comment in the driver to check for the compatible
instead of the node name is still valid though.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-07-01 10:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Michael Walle, Linus Walleij, Bartosz Golaszewski,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <CAHp75VeTp4eYQ4QBoeH2VyVhUivxNn1CaC9jskmeg-1zTAOYLQ@mail.gmail.com>
On Wed, Jul 01, 2026 at 01:01:10PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle@kernel.org> wrote:
> > On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
> > > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
> > >
> > >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> > >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> > >> >>> map() function.
> > >>
> > >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
> > >> only called if the irq handling is set up via gc->irq.chip and not
> > >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
> > >
> > > Not really, the gpiochip_irq_reqres() is called to mark that a
> > > GPIO line is used for IRQ, so the gpiolib cannot turn this
> > > GPIO into an output line, gpiod_direction_out() will fail
> > > on lines used for IRQ. So it's a failsafe.
> > >
> > > You can live without it of course, but then you don't get
> > > this failsafe.
> >
> > Thanks for the explanation! So did I make a mistake years ago by
> > adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
> > ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
> >
> > As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
> > to be a gpio_chip, which isn't the case (in general) for an
> > externally allocated domain, is it?
>
> So the whole issue comes from the fact that the IRQ chip is not marked
> as immutable. For immutable IRQ chips (which all GPIO provides should
> have) there is no such issue to begin with, id est there is no
> gpiochip_irq_reqres() callback assigned (and respective _relres).
Ah, for immutable chips we put either custom ones or
GPIOCHIP_IRQ_RESOURCE_HELPERS which actually refers to those callbacks.
So, if the domain is external, it should also provide irq_request_resources
and release callbacks. In the custom case we can wrap gpiochip_reqres_irq()
and gpiochip_relres_irq() respectively.
But we need to have a struct gpio_chip pointer for them. And note, the
IRQ chip data can be anything in that case, so it's not a requirement.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] arm64: topology: read CPPC FFH feedback counters in one operation
From: Pengjie Zhang @ 2026-07-01 10:56 UTC (permalink / raw)
To: Sumit Gupta, catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12, linux-tegra@vger.kernel.org
In-Reply-To: <56a1e8bf-41b1-40cf-a943-79cce84a774e@nvidia.com>
On 6/29/2026 11:27 PM, Sumit Gupta wrote:
>
> On 10/04/26 15:11, Pengjie Zhang wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> arm64 implements CPPC FFH feedback-counter reads using AMU counters.
>> Because those counters must be sampled on the target CPU, reading the
>> delivered and reference counters separately widens the observation
>> window
>> between them.
>>
>> Implement the paired FFH feedback-counter read hook on arm64 and sample
>> both AMU counters together before decoding the requested CPC register
>> values.
>>
>> Also factor the FFH bitfield extraction logic into a helper and reuse
>> it from the existing single-counter FFH read path.
>>
>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>> ---
>> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
>> 1 file changed, 67 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index b32f13358fbb..b90a767b2a1f 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -50,6 +50,16 @@ struct amu_cntr_sample {
>> unsigned long last_scale_update;
>> };
>>
>> +struct amu_ffh_ctrs {
>> + u64 corecnt;
>> + u64 constcnt;
>> +};
>> +
>> +enum cpc_ffh_ctr_id {
>> + CPC_FFH_CTR_CORE = 0x0,
>> + CPC_FFH_CTR_CONST = 0x1,
>> +};
>> +
>> static DEFINE_PER_CPU_SHARED_ALIGNED(struct amu_cntr_sample,
>> cpu_amu_samples);
>>
>> void update_freq_counters_refs(void)
>> @@ -397,7 +407,7 @@ static void cpu_read_constcnt(void *val)
>> }
>>
>> static inline
>> -int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
>> +int counters_read_on_cpu(int cpu, smp_call_func_t func, void *val)
>> {
>> /*
>> * Abort call on counterless CPU.
>> @@ -447,24 +457,73 @@ bool cpc_ffh_supported(void)
>> return true;
>> }
>>
>> +static void amu_read_core_const_ctrs(void *val)
>> +{
>> + struct amu_ffh_ctrs *ctrs = val;
>> +
>> + cpu_read_constcnt(&ctrs->constcnt);
>> + cpu_read_corecnt(&ctrs->corecnt);
>> +}
>
> Any reason to flip the order?
> Harmless as they are read back to back, but better to add a comment
> if it's intentional.
>
> Thanks,
> Sumit
> ....
>
Hi Sumit，
Thanks for taking the time to review and test.
The cpu_read_constcnt() function includes the conditional check
this_cpu_has_cap(ARM64_WORKAROUND_2457168), which incurs a latency of
6–12 nanoseconds on the our platform.
If cpu_read_corecnt() is called prior to cpu_read_constcnt(), it will
widen the sampling interval between the corecnt and constcnt counter
readings. To address this, we have adjusted the call order:
cpu_read_constcnt() is executed first, followed by cpu_read_corecnt().
I will add comments later.
Thanks,
Pengjie
>
>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: samsung: exynos-pmu: Restrict children with unevaluatedProperties
From: Krzysztof Kozlowski @ 2026-07-01 10:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Peter Griffin,
Alim Akhtar, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Cc: Krzysztof Kozlowski
Each schema for a child node should end with either additionalProperties
or unevaluatedProperties, so add missing one making the schema tighter.
Defining 'type: object' is on the other hand not necessary when other
schema is referenced.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/soc/samsung/exynos-pmu.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 76ce7e98c10f..d124f3ae9fbd 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -94,19 +94,19 @@ properties:
reboot-mode:
$ref: /schemas/power/reset/syscon-reboot-mode.yaml
- type: object
+ unevaluatedProperties: false
description:
Reboot mode to alter bootloader behavior for the next boot
syscon-poweroff:
$ref: /schemas/power/reset/syscon-poweroff.yaml#
- type: object
+ unevaluatedProperties: false
description:
Node for power off method
syscon-reboot:
$ref: /schemas/power/reset/syscon-reboot.yaml#
- type: object
+ unevaluatedProperties: false
description:
Node for reboot method
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: samsung: exynos-pmu: Narrow allowed reboot modes
From: Krzysztof Kozlowski @ 2026-07-01 10:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Peter Griffin,
Alim Akhtar, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260701105731.196618-3-krzysztof.kozlowski@oss.qualcomm.com>
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only
a subset actually makes sense and is valid. Provide negative look-ahead
pattern to disallow any modes not supported by the device, which
tightens the binding.
Most of Android-based Exynos devices share the bootloader or its parts,
thus reboot modes are most likely the same, however only a few upstream
DTS define them, so add restrictions only for these.
Google GS101 has on the other hand quite different bootloader with many
known reboot modes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/soc/samsung/exynos-pmu.yaml | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index d124f3ae9fbd..5bd39876e3b3 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -176,6 +176,20 @@ allOf:
properties:
dp-phy: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos7-pmu
+ then:
+ properties:
+ reboot-mode:
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|download$|fastboot$|recovery$))": false
+
- if:
properties:
compatible:
@@ -183,6 +197,13 @@ allOf:
enum:
- google,gs101-pmu
then:
+ properties:
+ reboot-mode:
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|charge$|dm-verity-device-corrupted$|fastboot$|reboot-ab-update$|recovery$)|rescue$|shutdown-thermal$|shutdown-thermal-battery$)": false
+
required:
- google,pmu-intr-gen-syscon
else:
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: rockchip: grf: Narrow allowed reboot modes
From: Krzysztof Kozlowski @ 2026-07-01 10:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Elaine Zhang, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260701105849.197086-3-krzysztof.kozlowski@oss.qualcomm.com>
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only
a subset actually makes sense and is valid. Provide negative look-ahead
pattern to disallow any modes not supported by the device, which
tightens the binding.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 2cc43742b8e3..7bcb4e2f47ec 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -239,11 +239,14 @@ allOf:
properties:
reboot-mode:
type: object
-
$ref: /schemas/power/reset/syscon-reboot-mode.yaml#
-
unevaluatedProperties: false
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|fastboot$|loader$|normal$|recovery$))": false
+
- if:
properties:
compatible:
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: rockchip: pmu: Narrow definition of reboot-mode
From: Krzysztof Kozlowski @ 2026-07-01 10:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Elaine Zhang, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Cc: Krzysztof Kozlowski
The 'reboot-mode' child of PMU node must be a syscon-reboot-mode one, so
add missing $ref to enforce the validation and disallow other
reboot-mode handlers.
Defining 'type: object' is on the other hand not necessary when other
schema is referenced.
This can be further restricted to match hardware/firmware:
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only
a subset actually makes sense and is valid. Provide negative look-ahead
pattern to disallow any modes not supported by the device, which
tightens the binding.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/rockchip/pmu.yaml | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
index 55b2200d6e75..1cff2328cd01 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -61,7 +61,13 @@ properties:
type: object
reboot-mode:
- type: object
+ $ref: /schemas/power/reset/syscon-reboot-mode.yaml
+ unevaluatedProperties: false
+
+ patternProperties:
+ # Negative look-ahead to disallow unsupported modes. The '$' has to be
+ # part of lookahead group to work, instead of trailing outside of ().
+ "^mode-(?!(bootloader$|loader$|normal$|recovery$))": false
required:
- compatible
--
2.53.0
^ permalink raw reply related
* [PATCH RESEND v3] drm/rockchip: Remove dependency on DRM simple helpers
From: Diogo Silva @ 2026-07-01 10:59 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan
Cc: Thomas Zimmermann, linux-kernel, linux-rockchip, linux-arm-kernel,
dri-devel, Simona Vetter, David Airlie, Maxime Ripard,
Maarten Lankhorst
In-Reply-To: <20260608124018.480365-2-diogompaissilva@gmail.com>
Simple KMS helper are deprecated since they only add an intermediate
layer between drivers and the atomic modesetting.
This patch removes the dependency on drm simple helpers from rockchip
DRM drivers.
Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
---
Resending just in case this was missed. Thanks.
v3:
- rebase on drm-tip tree
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 ++++++---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 ++++++---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 9 +++++++--
drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c | 8 ++++++--
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 1 -
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 1 -
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 ++++++--
drivers/gpu/drm/rockchip/rockchip_lvds.c | 9 +++++++--
drivers/gpu/drm/rockchip/rockchip_rgb.c | 8 ++++++--
10 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 776954c7d052..46c245e35d21 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -30,7 +30,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
@@ -303,6 +302,10 @@ rockchip_dp_drm_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
rockchip_dp_encoder_helper_funcs = {
.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
.mode_set = rockchip_dp_drm_encoder_mode_set,
@@ -361,8 +364,8 @@ static int rockchip_dp_drm_create_encoder(struct
rockchip_dp_device *dp)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_simple_encoder_init(drm_dev, encoder,
- DRM_MODE_ENCODER_TMDS);
+ ret = drm_encoder_init(drm_dev, encoder, &rockchip_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 190cce9530c8..c3f41a4449f5 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -23,7 +23,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "cdn-dp-core.h"
#include "cdn-dp-reg.h"
@@ -671,6 +670,10 @@ static int cdn_dp_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs cdn_dp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs cdn_dp_encoder_helper_funcs = {
.atomic_check = cdn_dp_encoder_atomic_check,
};
@@ -988,8 +991,8 @@ static int cdn_dp_bind(struct device *dev, struct
device *master, void *data)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_simple_encoder_init(drm_dev, encoder,
- DRM_MODE_ENCODER_TMDS);
+ ret = drm_encoder_init(drm_dev, encoder, &cdn_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 3547d91b25d3..a09b382d208e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -25,7 +25,6 @@
#include <drm/drm_mipi_dsi.h>
#include <drm/drm_of.h>
#include <drm/drm_print.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
@@ -825,6 +824,10 @@ static void dw_mipi_dsi_encoder_enable(struct
drm_encoder *encoder)
clk_disable_unprepare(dsi->grf_clk);
}
+static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
@@ -840,7 +843,9 @@ static int rockchip_dsi_drm_create_encoder(struct
dw_mipi_dsi_rockchip *dsi,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dsi->dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
+ ret = drm_encoder_init(drm_dev, encoder,
+ &dw_mipi_dsi_encoder_funcs,
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
DRM_ERROR("Failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
index d2e76d36d724..9dc207c2d20d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
@@ -23,7 +23,6 @@
#include <drm/bridge/dw_mipi_dsi2.h>
#include <drm/drm_mipi_dsi.h>
#include <drm/drm_of.h>
-#include <drm/drm_simple_kms_helper.h>
#include <uapi/linux/videodev2.h>
@@ -275,6 +274,10 @@ dw_mipi_dsi2_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs dw_mipi_dsi2_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs
dw_mipi_dsi2_encoder_helper_funcs = {
.atomic_enable = dw_mipi_dsi2_encoder_atomic_enable,
@@ -290,7 +293,8 @@ static int rockchip_dsi2_drm_create_encoder(struct
dw_mipi_dsi2_rockchip *dsi2,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dsi2->dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
+ ret = drm_encoder_init(drm_dev, encoder, &dw_mipi_dsi2_encoder_funcs,
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
dev_err(dsi2->dev, "Failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
index 0de822360c8d..b23efb153c9e 100644
--- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
@@ -20,7 +20,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index cffc0af5190f..b6e154c35e7c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -18,7 +18,6 @@
#include <drm/drm_managed.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
index f35484715c2d..af34062685cd 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
@@ -24,7 +24,6 @@
#include <drm/drm_managed.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 1996f8656612..b4ba9f894360 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -12,7 +12,6 @@
#include <drm/drm_of.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include <linux/clk.h>
#include <linux/mfd/syscon.h>
@@ -454,6 +453,10 @@ rk3066_hdmi_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rk3066_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rk3066_hdmi_encoder_helper_funcs = {
.atomic_check = rk3066_hdmi_encoder_atomic_check,
@@ -696,7 +699,8 @@ rk3066_hdmi_register(struct drm_device *drm,
struct rk3066_hdmi *hdmi)
return -EPROBE_DEFER;
drm_encoder_helper_add(encoder, &rk3066_hdmi_encoder_helper_funcs);
- drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(drm, encoder, &rk3066_hdmi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = &rk3066_hdmi_bridge_funcs;
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 7a0c4fa29f2f..f3be2c91d147 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -24,7 +24,6 @@
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
#include "rockchip_lvds.h"
@@ -427,6 +426,10 @@ static void px30_lvds_encoder_disable(struct
drm_encoder *encoder)
drm_panel_unprepare(lvds->panel);
}
+static const struct drm_encoder_funcs rockchip_lvds_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rk3288_lvds_encoder_helper_funcs = {
.enable = rk3288_lvds_encoder_enable,
@@ -594,7 +597,9 @@ static int rockchip_lvds_bind(struct device *dev,
struct device *master,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dev->of_node);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_LVDS);
+ ret = drm_encoder_init(drm_dev, encoder,
+ &rockchip_lvds_encoder_funcs,
+ DRM_MODE_ENCODER_LVDS, NULL);
if (ret < 0) {
drm_err(drm_dev,
"failed to initialize encoder: %d\n", ret);
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
index add3123e5ce7..2ad24b914989 100644
--- a/drivers/gpu/drm/rockchip/rockchip_rgb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -17,7 +17,6 @@
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "rockchip_drm_drv.h"
#include "rockchip_rgb.h"
@@ -65,6 +64,10 @@ rockchip_rgb_encoder_atomic_check(struct
drm_encoder *encoder,
return 0;
}
+static const struct drm_encoder_funcs rockchip_rgb_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const
struct drm_encoder_helper_funcs rockchip_rgb_encoder_helper_funcs = {
.atomic_check = rockchip_rgb_encoder_atomic_check,
@@ -127,7 +130,8 @@ struct rockchip_rgb *rockchip_rgb_init(struct device *dev,
encoder = &rgb->encoder.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
- ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_NONE);
+ ret = drm_encoder_init(drm_dev, encoder, &rockchip_rgb_encoder_funcs,
+ DRM_MODE_ENCODER_NONE, NULL);
if (ret < 0) {
DRM_DEV_ERROR(drm_dev->dev,
"failed to initialize encoder: %d\n", ret);
--
2.51.2
^ permalink raw reply related
* Re: [PATCH v5 8/8] futex: Use runtime constants for __futex_hash() hot path
From: Sebastian Andrzej Siewior @ 2026-07-01 11:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: K Prateek Nayak, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Catalin Marinas, Will Deacon,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Darren Hart, Davidlohr Bueso,
André Almeida, linux-arch, linux-kernel, Samuel Holland,
Charlie Jenkins, linux-arm-kernel, linux-riscv, linux-s390,
H. Peter Anvin, Thomas Huth, Sean Christopherson, Jisheng Zhang,
Alexandre Ghiti, Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260701084150.GNOeboLw@linutronix.de>
On 2026-07-01 10:41:55 [+0200], To Peter Zijlstra wrote:
> This makes it go away at no extra price but yeah let me boot a big box
> and see.
as-is:
|$ ./perf bench futex hash -f 1 -t 1 -r 10 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 3588]: 1 threads, each operating on 1 [private] futexes for 10 secs.
|
| [thread 0] futex: 0x5555e5ad4740 [ 6449632 ops/sec ]
|
| Averaged 6449632 operations/sec (+- 0,00%), total secs = 10
| Futex hashing: global hash
roughly that area, repeated runs usually change the last three digits.
Patched:
| $ ./perf bench futex hash -f 1 -t 1 -r 10 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 2375]: 1 threads, each operating on 1 [private] futexes for 10 secs.
|
| [thread 0] futex: 0x5585ddebd740 [ 6532004 ops/sec ]
|
| Averaged 6532004 operations/sec (+- 0,00%), total secs = 10
| Futex hashing: global hash
for private hash there is change within the noise area for -b 8192.
So we have here +1.28% ops/sec. Not ground breaking, not bad either.
With more threads:
| $ ./perf bench futex hash -r 30 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 2424]: 144 threads, each operating on 1024 [private] futexes for 30 secs.
|
| [thread 0] futexes: 0x556f3a3387c0 ... 0x556f3a3397bc [ 2104422 ops/sec ]
…
| [thread 143] futexes: 0x556f3a3d9660 ... 0x556f3a3da65c [ 2105480 ops/sec ]
|
| Averaged 2111486 operations/sec (+- 0,03%), total secs = 30
| Futex hashing: global hash
To:
| $ ./perf bench futex hash -r 30 -b 0
| # Running 'futex/hash' benchmark:
| Run summary [PID 2723]: 144 threads, each operating on 1024 [private] futexes for 30 secs.
|
|[thread 0] futexes: 0x560a09e487c0 ... 0x560a09e497bc [ 2135688 ops/sec ]
…
|[thread 143] futexes: 0x560a09ee9660 ... 0x560a09eea65c [ 2137668 ops/sec ]
|
| Averaged 2139685 operations/sec (+- 0,03%), total secs = 30
| Futex hashing: global hash
+1.34%. Again, not ground breaking but still visible. And the memory
savings.
That is btw, 7.2-rc1 on a Intel(R) Xeon(R) CPU E7-8890 v3 (4 NUMA
nodes).
Sebastian
^ permalink raw reply
* Re: [PATCH v4 0/3] regulator: Rework i2c_device_id initialisation
From: Mark Brown @ 2026-06-30 22:40 UTC (permalink / raw)
To: Liam Girdwood, Woodrow Douglass, Michael Hennerich,
Support Opensource, Laurent Pinchart, Ivaylo Ivanov,
Claudiu Beznea, Andrei Simion, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Jagan Teki, Icenowy Zheng,
Alexis Czezar Torreno, Uwe Kleine-König (The Capable Hub)
Cc: linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1782827697.git.u.kleine-koenig@baylibre.com>
On Tue, 30 Jun 2026 16:01:06 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> regulator: Rework i2c_device_id initialisation
>
> Hello,
>
> changes since v2
> (https://lore.kernel.org/lkml/cover.1781888370.git.u.kleine-koenig@baylibre.com):
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.3
Thanks!
[1/3] regulator: Drop unused i2c driver data
https://git.kernel.org/broonie/regulator/c/3ac69e3cb288
[2/3] regulator: Use named initializers for arrays of i2c_device_data
https://git.kernel.org/broonie/regulator/c/8e74b2db5867
[3/3] regulator: Improve style of i2c_device_id arrays
https://git.kernel.org/broonie/regulator/c/2924fa8381ee
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Konrad Dybcio @ 2026-07-01 11:02 UTC (permalink / raw)
To: Jie Gan, Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, linux-arm-msm,
devicetree, linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <62ac6887-1551-490b-b42b-2661d7152734@oss.qualcomm.com>
On 7/1/26 9:31 AM, Jie Gan wrote:
>
>
> On 7/1/2026 3:26 PM, Krzysztof Kozlowski wrote:
>> On 01/07/2026 09:16, Jie Gan wrote:
>>>
>>>
>>> On 7/1/2026 2:57 PM, Krzysztof Kozlowski wrote:
>>>> On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
>>>>> The TNOC compatible previously only allowed the two-string AMBA form
>>>>> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
>>>>> AMBA bus.
>>>>>
>>>>> Convert the compatible to a oneOf and add a standalone
>>>>> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
>>>>> standalone string carries no "arm,primecell" entry, so the device is
>>>>> created on the platform bus instead of the AMBA bus.
[...]
>>> AMBA primecell identification. The purpose of the new compatible is to
>>> clearly distinguish this platform-specific case from the standard
>>> AMBA-based implementation. Or shall I re-use the existing compatible
>>> "qcom,coresight-tnoc" as platform standalone compatible?
>>>
>>> We already have a similar pattern for the interconnect TraceNoC device,
>>> which uses the platform-specific compatible string qcom,coresight-itnoc.
>> I do not see there a fake, duplicated compatible for the same device.
>> Can you elaborate how is that relevant?
>
> Will fix it by removing AMBA related description.
>
> Shall I update the clock name from apb_pclk to apb as a platform device?
Why?
Konrad
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Linus Walleij @ 2026-07-01 11:04 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君]
Cc: brgl@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, mwalle@kernel.org,
andriy.shevchenko@intel.com, TY_Chang[張子逸],
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], Krzysztof Kozlowski
In-Reply-To: <56be68cba7d9461d9a1ec66ed1a1417a@realtek.com>
On Wed, Jul 1, 2026 at 12:41 PM Yu-Chun Lin [林祐君]
<eleanor.lin@realtek.com> wrote:
> To clarify the hardware design: this SoC does not use a banked GPIO
> architecture.
>
> Each GPIO pin has its own dedicated 32-bit control register that handles
> both GPIO configuration and interrupt settings (e.g., edge/level enable).
> The only exception is the interrupt status register, which is grouped into
> 32-bit words.
Aha, I get it!
> Since physical GPIO banks do not exist, using a 3-cell <bank offset flags>
> format would misrepresent the hardware. Therefore,
> keeping #gpio-cells = <2> and #interrupt-cells = <2> is the most accurate
> reflection of the actual silicon.
Hmmmm I would argue that the way the interrupts are routed into a
single 32-bit register for 32 GPIOs would be an argument for using
#interrupt-cells = <3> but it would be confusing to use a mixture of
2 and 3 cells for GPIOs and interrupts, so I guess 2 is OK for both.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/3] can: rockchip: add RK3588 CAN-FD support
From: Marc Kleine-Budde @ 2026-07-01 11:07 UTC (permalink / raw)
To: Heiko Stübner
Cc: linux-can, 1579567540, Vincent Mailhol, kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <2064877.jZfb76A358@diego>
[-- Attachment #1: Type: text/plain, Size: 3951 bytes --]
On 01.07.2026 11:55:39, Heiko Stübner wrote:
> Hi,
>
> Am Mittwoch, 1. Juli 2026, 09:01:27 Mitteleuropäische Sommerzeit schrieb 1579567540@qq.com:
> > From: luch00 <1579567540@qq.com>
>
> please use a real name, not an alias.
>
>
> > Add support for the RK3588v2 CAN-FD controller by introducing a
> > dedicated model ID and OF match entry.
> >
> > The block is closely related to the existing RK3568 variants, but it
> > cannot reuse their match data unchanged. In particular, RK3588v2
> > encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
> > SoC-specific handling.
> >
> > Validation on RK3588v2 also shows that its observed errata profile does
> > not fully match rk3568v2/rk3568v3, so keep a dedicated devtype for this
> > variant instead of relying on an rk3568 fallback.
>
> Funnily enough, we seem to have worked on the same topic
> at the same time :-)
>
> https://lore.kernel.org/lkml/20260630164336.3444550-1-heiko@sntech.de/
>
> > Signed-off-by: luch00 <1579567540@qq.com>
> > ---
> > drivers/net/can/rockchip/rockchip_canfd-core.c | 14 ++++++++++++++
> > drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++++-
> > drivers/net/can/rockchip/rockchip_canfd.h | 12 +++++++++++-
> > 3 files changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
> > index 29de0c01e..3c2480785 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd-core.c
> > +++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
> > @@ -50,6 +50,15 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
> > RKCANFD_QUIRK_CANFD_BROKEN,
> > };
> >
> > +/* Tests on the rk3588v2 reproduce Erratum 5, but not
> > + * Erratum 6 or the special CAN-FD frames that trigger Error Interrupts
> > + * on rk3568v2/rk3568v3.
> > + */
>
> Here I could reproduce erratum 6 though:
> https://lore.kernel.org/lkml/20260630164336.3444550-4-heiko@sntech.de/
>
>
> [...]
>
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > index 475c0409e..fe64db373 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > +++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > @@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
> > {
> > const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
> >
> > - return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
> > + if (priv->devtype_data.model == RKCANFD_MODEL_RK3588V2)
> > + return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
> > +
> > + return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
> > }
> >
> > int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
> > index 93131c7d7..f6105b904 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd.h
> > +++ b/drivers/net/can/rockchip/rockchip_canfd.h
> > @@ -214,7 +214,8 @@
> > #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
> >
> > #define RKCANFD_REG_RX_FIFO_CTRL 0x118
> > -#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
> > +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
> > +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
>
> Oh, didn't see this when doing my variant of the support, so cool that you
> found this.
The "Rockchip RK3588 TRM V1.0-Part1-20220309.pdf" datasheet says bits
"7:5" are RX_FIFO_FRAME_CNT, while bit "6" is marked as reserved. 🤷
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3] ARM: breakpoint: CFI breakpoints only on demand
From: Russell King @ 2026-07-01 11:10 UTC (permalink / raw)
To: Linus Walleij
Cc: Nathan Chancellor, Sami Tolvanen, Kees Cook, linux-arm-kernel,
linux-kernel, stable, slipher
In-Reply-To: <20260701-arm32-cfi-bug-v3-1-e3c37e2b80a4@kernel.org>
On Wed, Jul 01, 2026 at 12:42:09PM +0200, Linus Walleij wrote:
> This removes the stub hw_breakpoint_cfi_handler() from ARM, making
> it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless
> CFI is actively used in the kernel.
>
> When not instrumenting with CFI, we fall through to return 1 from
> hw_breakpoint_pending() "unhandled fault" so userspace can make use
> of this breakpoint.
>
> This of course does not work if userspace want to use CFI and custom
> breakpoints at the same time, and CONFIG_CFI does exist as something
> users might want to select for their kernel. If this is not good
> acceptable we need to think about other ways for CFI to interfer, such
> as not using BKPT at all (rather something like BUG()) and back out
> the offending patch until the compiler behaviour has changed.
>
> Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints")
> Reported-by: slipher <slipher@protonmail.com>
> Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
> Trying to solve the CFI bug. Let's see of this first
> approach is acceptable for the reporter.
Looks fine to me, but will depend whether the reporter has CONFIG_CFI
enabled in their kernel build.
Have the LLVM compiler people responded to this bug yet? What is their
plan with the silly choice of BKPT usage for CFI failure?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ 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