* [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
The Raspberry Pi 5 has two OTP registers (private and customer), add these
to the devicetree.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
index b7a6bc34ae1a..676081198213 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
@@ -60,6 +60,14 @@ reset: reset {
#reset-cells = <1>;
};
+ otp_customer: otp-customer {
+ compatible = "raspberrypi,firmware-otp-customer";
+ };
+
+ otp_private: otp-private {
+ compatible = "raspberrypi,firmware-otp-private";
+ };
+
power: power {
compatible = "raspberrypi,bcm2835-power";
firmware = <&firmware>;
--
2.47.3
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
The firmware running on the Raspberry Pi VideoCore can be used to access
OTP registers. There are two OTP regions (private and customer). Add a
binding for these.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec9..975c8927d75b 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -137,6 +137,20 @@ required:
- compatible
- mboxes
+patternProperties:
+ "^otp-(customer|private)$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - raspberrypi,firmware-otp-customer
+ - raspberrypi,firmware-otp-private
+
+ required:
+ - compatible
+
additionalProperties: false
examples:
@@ -156,6 +170,10 @@ examples:
#gpio-cells = <2>;
};
+ otp: otp-private {
+ compatible = "raspberrypi,firmware-otp-private";
+ };
+
reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
--
2.47.3
^ permalink raw reply related
* [PATCH 0/3] nvmem: Add Raspberry Pi OTP nvmem driver
From: Gregor Herburger @ 2026-04-08 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Gregor Herburger
Hi,
This series adds support for the Raspberry Pis OTP registers. The
Raspberry Pi has one or more OTP regions. These registers are accessible
through the firmware. Add a driver for it and add the corresponding
devicetree scheme.
I also added the devicetree nodes for the Raspberry Pi as I tested the
series on it.
---
Gregor Herburger (3):
dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
nvmem: Add the Raspberry Pi OTP driver
arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 +++
.../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 8 ++
drivers/nvmem/Kconfig | 12 ++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 2 +
6 files changed, 200 insertions(+)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-rpi-otp-driver-75fce1dcff7d
Best regards,
--
Gregor Herburger <gregor.herburger@linutronix.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank Li @ 2026-04-08 7:58 UTC (permalink / raw)
To: Liu Ying
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <a31e926e-9e7e-4ba4-aafd-0f76f53fa176@nxp.com>
On Wed, Apr 08, 2026 at 02:02:54PM +0800, Liu Ying wrote:
> Hi Frank,
>
> On Tue, Apr 07, 2026 at 05:55:29AM -0400, Frank Li wrote:
> > On Tue, Apr 07, 2026 at 05:15:31PM +0800, Liu Ying wrote:
> >> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
> >>
> >> The panel connects with the QSB board through an adapter board[1]
> >> designed by NXP.
> >>
> >> Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
> >> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >> ---
> >> arch/arm64/boot/dts/freescale/Makefile | 2 +
> >> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
> >> .../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
> >
> > Can you add some description about raname in commit message?
>
> I'll add some description about the file copy in commit message.
>
> > Use -C option to create patch.
>
> Will do.
>
> >
> > ...
> >> diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> >> new file mode 100644
> >> index 000000000000..c233797ec28c
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
> >> @@ -0,0 +1,14 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +/*
> >> + * Copyright 2026 NXP
> >> + */
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
> >> +
> >> +&{/} {
> >> + panel {
> >> + compatible = "tianma,tm050rdh03";
> >> + enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
> >> + };
> >> +};
> >
> > Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
> >
> > to imx93-9x9-qsb.dtb, so needn't create dtsi.
>
> I'm sorry, I don't get your question here.
> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
> file just aims to avoid duplicated code.
My means apply two overlay files to dtb
imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
&{/} {
panel {
compatible = "tianma,tm050rdh03";
enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
};
};
Frank
>
> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
>
> >
> > Frank
> >>
> >> ---
> >> base-commit: 816f193dd0d95246f208590924dd962b192def78
> >> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
> >>
> >> Best regards,
> >> --
> >> Liu Ying <victor.liu@nxp.com>
> >>
>
> --
> Regards,
> Liu Ying
^ permalink raw reply
* Re: [PATCH 2/3] KVM: arm64: vgic: Allow userspace to set IIDR revision 1
From: Marc Zyngier @ 2026-04-08 7:54 UTC (permalink / raw)
To: David Woodhouse
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Paolo Bonzini, Shuah Khan,
David Woodhouse, Raghavendra Rao Ananta, Eric Auger, Kees Cook,
Arnd Bergmann, Nathan Chancellor, linux-arm-kernel, kvmarm,
linux-kernel, kvm, linux-kselftest
In-Reply-To: <20260407210949.2076251-3-dwmw2@infradead.org>
On Tue, 07 Apr 2026 21:27:03 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
>
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Allow userspace to select GICD_IIDR revision 1, which restores the
> original pre-d53c2c29ae0d ("KVM: arm/arm64: vgic: Allow configuration
> of interrupt groups") behaviour where interrupt groups are not
> guest-configurable.
I'm a bit surprised by this.
Either your guest knows that the group registers are not writable and
already deals with the buggy behaviour by not configuring the groups
(or configuring them in a way that matches what the implementation
does). Or it configures them differently and totally fails to handle
the interrupts as they are delivered using the wrong exception type,
if at all.
I'd expect that your guests fall in the former category and not the
latter, as we'd be discussing a very different problem. And my vague
recollection of this issue is that we had established that as long as
the reset values were unchanged, there was no harm in letting things
rip.
So what is this *really* fixing?
>
> When revision 1 is selected:
> - GICv2: IGROUPR reads as zero (group 0), writes are ignored
> - GICv3: IGROUPR reads as all-ones (group 1), writes are ignored
> - v2_groups_user_writable is not set
>
> This is implemented by checking the implementation revision in
> vgic_mmio_read_group() and vgic_mmio_write_group() and returning
> the fixed values when the revision is below 2.
>
> Fixes: d53c2c29ae0d ("KVM: arm/arm64: vgic: Allow configuration of interrupt groups")
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> arch/arm64/kvm/vgic/vgic-mmio-v2.c | 5 +++++
> arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4 ++++
> arch/arm64/kvm/vgic/vgic-mmio.c | 15 +++++++++++++++
> include/kvm/arm_vgic.h | 1 +
> 4 files changed, 25 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v2.c b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> index 0643e333db35..14aa49f86f60 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
> @@ -20,6 +20,8 @@
> * Revision 1: Report GICv2 interrupts as group 0 instead of group 1
> * Revision 2: Interrupt groups are guest-configurable and signaled using
> * their configured groups.
> + * Revision 3: GICv2 behaviour is unchanged from revision 2.
> + * (GICv3 gains GICR_CTLR.{IR,CES}; see vgic-mmio-v3.c)
nit: I don't think we need cross-version documentation, so just drop
the second line.
> */
>
> static unsigned long vgic_mmio_read_v2_misc(struct kvm_vcpu *vcpu,
> @@ -93,6 +95,9 @@ static int vgic_mmio_uaccess_write_v2_misc(struct kvm_vcpu *vcpu,
> */
> reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val);
> switch (reg) {
> + case KVM_VGIC_IMP_REV_1:
> + dist->implementation_rev = reg;
> + return 0;
> case KVM_VGIC_IMP_REV_2:
> case KVM_VGIC_IMP_REV_3:
> vcpu->kvm->arch.vgic.v2_groups_user_writable = true;
nit: move the v1 handling down with a fallthrough in v2/v3 so that we
don't duplicate the basic handling:
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v2.c b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
index 406845b3117cf..34f8b2b615fc5 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v2.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
@@ -96,6 +96,8 @@ static int vgic_mmio_uaccess_write_v2_misc(struct kvm_vcpu *vcpu,
case KVM_VGIC_IMP_REV_2:
case KVM_VGIC_IMP_REV_3:
vcpu->kvm->arch.vgic.v2_groups_user_writable = true;
+ fallthrough;
+ case KVM_VGIC_IMP_REV_1:
dist->implementation_rev = reg;
return 0;
default:
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> index 5913a20d8301..0130db71cfc9 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
> @@ -74,8 +74,11 @@ bool vgic_supports_direct_sgis(struct kvm *kvm)
> /*
> * The Revision field in the IIDR have the following meanings:
> *
> + * Revision 1: Interrupt groups are not guest-configurable.
> + * IGROUPR reads as all-ones (group 1), writes ignored.
> * Revision 2: Interrupt groups are guest-configurable and signaled using
> * their configured groups.
> + * Revision 3: GICR_CTLR.{IR,CES} are advertised.
> */
>
> static unsigned long vgic_mmio_read_v3_misc(struct kvm_vcpu *vcpu,
> @@ -196,6 +199,7 @@ static int vgic_mmio_uaccess_write_v3_misc(struct kvm_vcpu *vcpu,
>
> reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val);
> switch (reg) {
> + case KVM_VGIC_IMP_REV_1:
> case KVM_VGIC_IMP_REV_2:
> case KVM_VGIC_IMP_REV_3:
> dist->implementation_rev = reg;
> diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
> index a573b1f0c6cb..9eb95f13b9b6 100644
> --- a/arch/arm64/kvm/vgic/vgic-mmio.c
> +++ b/arch/arm64/kvm/vgic/vgic-mmio.c
> @@ -48,6 +48,17 @@ unsigned long vgic_mmio_read_group(struct kvm_vcpu *vcpu,
> u32 value = 0;
> int i;
>
> + /*
> + * Revision 1 and below: groups are not guest-configurable.
> + * GICv2 reports all interrupts as group 0 (RAZ).
> + * GICv3 reports all interrupts as group 1 (RAO).
> + */
> + if (vgic_get_implementation_rev(vcpu) < KVM_VGIC_IMP_REV_2) {
> + if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
> + return -1UL;
Hmmm... This can only be a 32bit access, so returning non-zero bits in
the top half is weird. It will be narrowed down before hitting the
guest, but still. Anyway, see below.
> + return 0;
> + }
> +
Why is this needed at all? The group reset values are already the
expected ones for v1, and as long as we prevent writes, the reported
group configuration will be as expected.
> /* Loop over all IRQs affected by this read */
> for (i = 0; i < len * 8; i++) {
> struct vgic_irq *irq = vgic_get_vcpu_irq(vcpu, intid + i);
> @@ -73,6 +84,10 @@ void vgic_mmio_write_group(struct kvm_vcpu *vcpu, gpa_t addr,
> int i;
> unsigned long flags;
>
> + /* Revision 1 and below: groups are not guest-configurable. */
> + if (vgic_get_implementation_rev(vcpu) < KVM_VGIC_IMP_REV_2)
> + return;
> +
> for (i = 0; i < len * 8; i++) {
> struct vgic_irq *irq = vgic_get_vcpu_irq(vcpu, intid + i);
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index f2eafc65bbf4..90fb6cd3c91c 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -248,6 +248,7 @@ struct vgic_dist {
>
> /* Implementation revision as reported in the GICD_IIDR */
> u32 implementation_rev;
> +#define KVM_VGIC_IMP_REV_1 1 /* GICv2 interrupts as group 0 */
> #define KVM_VGIC_IMP_REV_2 2 /* GICv2 restorable groups */
> #define KVM_VGIC_IMP_REV_3 3 /* GICv3 GICR_CTLR.{IW,CES,RWP} */
> #define KVM_VGIC_IMP_REV_LATEST KVM_VGIC_IMP_REV_3
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply related
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Krzysztof Kozlowski @ 2026-04-08 7:52 UTC (permalink / raw)
To: Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <20260407-anacapa-devlop-phase-devicetree-v1-2-97b96367cac3@gmail.com>
On Tue, Apr 07, 2026 at 09:54:33PM +0800, Colin Huang wrote:
> This change introduces a development-phase devicetree for the
> Facebook Anacapa BMC EVT1 hardware revision and updates the Anacapa
> wrapper DTS to reference it.
>
> A dedicated EVT1 DTS is added for revision-specific hardware while
> keeping a single, Anacapa entrypoint used by the build and deployment
> flow. The top-level aspeed-bmc-facebook-anacapa.dts
>
> Signed-off-by: Colin Huang <u8813345@gmail.com>
> ---
> .../aspeed/aspeed-bmc-facebook-anacapa-evt1.dts | 1069 ++++++++++++++++++++
> .../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 1064 +------------------
> 2 files changed, 1070 insertions(+), 1063 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> new file mode 100644
> index 000000000000..a29b7fa1155b
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> @@ -0,0 +1,1069 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +/dts-v1/;
> +#include "aspeed-g6.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/i2c/i2c.h>
> +
> +/ {
> + model = "Facebook Anacapa BMC";
> + compatible = "facebook,anacapa-bmc-evt1",
> + "facebook,anacapa-bmc",
> + "aspeed,ast2600";
Test your DTS before you send, not after. Your binding clearly said
something else.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/3] perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-0-d75dac96e828@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The PMCG is described as a child device of the SMMU in Devicetree and
its register space occupies a sub-region of the parent SMMU MMIO window.
That MMIO region is already requested by the arm-smmu-v3 driver during
SMMU probe.
Using devm_platform_get_and_ioremap_resource() or
devm_platform_ioremap_resource() for the PMCG would attempt to request
the same memory region again and fail with -EBUSY.
Switch to explicitly retrieving the PMCG memory resources and mapping
them with devm_ioremap(), avoiding double-requesting already owned SMMU
MMIO while preserving correct register offsets for both page 0 and the
optional relocated counter page.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 621f02a7f43be364e5c260fd97aa375f5e8e3404..1c9585ef2618397b59158aa18c21054ef672dc83 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -847,7 +847,7 @@ static void smmu_pmu_get_iidr(struct smmu_pmu *smmu_pmu)
static int smmu_pmu_probe(struct platform_device *pdev)
{
struct smmu_pmu *smmu_pmu;
- struct resource *res_0;
+ struct resource *res_0, *res_1;
u32 cfgr, reg_size;
u64 ceid_64[2];
int irq, err;
@@ -877,7 +877,16 @@ static int smmu_pmu_probe(struct platform_device *pdev)
.capabilities = PERF_PMU_CAP_NO_EXCLUDE,
};
- smmu_pmu->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res_0);
+ res_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res_0)
+ return dev_err_probe(dev, -ENOENT, "missing PMCG page 0 MMIO resource\n");
+
+ /*
+ * PMCG registers might be a sub-region of the parent SMMU MMIO window,
+ * which is already requested by the SMMU driver. Do not call
+ * devm_ioremap_resource() here to avoid double-requesting the region.
+ */
+ smmu_pmu->reg_base = devm_ioremap(dev, res_0->start, resource_size(res_0));
if (IS_ERR(smmu_pmu->reg_base))
return PTR_ERR(smmu_pmu->reg_base);
@@ -885,7 +894,11 @@ static int smmu_pmu_probe(struct platform_device *pdev)
/* Determine if page 1 is present */
if (cfgr & SMMU_PMCG_CFGR_RELOC_CTRS) {
- smmu_pmu->reloc_base = devm_platform_ioremap_resource(pdev, 1);
+ res_1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res_1)
+ return dev_err_probe(dev, -ENOENT, "missing PMCG page 1 MMIO resource\n");
+
+ smmu_pmu->reloc_base = devm_ioremap(dev, res_1->start, resource_size(res_1));
if (IS_ERR(smmu_pmu->reloc_base))
return PTR_ERR(smmu_pmu->reloc_base);
} else {
--
2.37.1
^ permalink raw reply related
* [PATCH 2/3] iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-0-d75dac96e828@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The Arm SMMU v3 can expose optional child devices such as the PMCG-based
PMU, which are described as child nodes in Devicetree. While the binding
allows these nodes, the driver did not populate them, preventing the
corresponding platform devices from being created.
Call devm_of_platform_populate() after a successful SMMU DT probe to
instantiate any child nodes associated with the SMMU device.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e8d7dbe495f0302191c3c7ec4c6d7564062f6236..0ce1d41c5ba6864ccad8291551f7f5c91c27b3db 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -5363,6 +5363,9 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
tegra_cmdqv_dt_probe(dev->of_node, smmu);
+ if (!ret)
+ return devm_of_platform_populate(dev);
+
return ret;
}
--
2.37.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-0-d75dac96e828@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The Arm SMMU v3 specification defines an optional PMCG (Performance
Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
with TCU Performance Monitor Counter Group (PMCG) registers starting at
offset 0x02000 in page 0. So PMCG could be described as a child node of the
SMMU in Devicetree.
Add a patternProperties entry to the arm,smmu-v3 binding to allow child
nodes matching "pmu@<addr>" and reference the existing
arm,smmu-v3-pmcg.yaml schema.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
@@ -50,6 +50,10 @@ properties:
- cmdq-sync # CMD_SYNC complete
- priq # PRI Queue not empty
+ '#address-cells': true
+ '#size-cells': true
+ ranges: true
+
'#iommu-cells':
const: 1
@@ -83,6 +87,12 @@ properties:
register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
doesn't support SMMU page1 register space.
+patternProperties:
+ '^pmu@[0-9a-f]+$':
+ type: object
+ $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
+ unevaluatedProperties: false
+
allOf:
- if:
not:
--
2.37.1
^ permalink raw reply related
* [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Peng Fan (OSS) @ 2026-04-08 7:51 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
This patch series adds proper support for describing and probing the
Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
the SMMU in Devicetree, and updates the relevant drivers accordingly.
The SMMU v3 architecture allows an optional PMCG block, typically
associated with TCUs, to be implemented within the SMMU register
address space. For example, mmu700 PMCG is at the offset 0x2000 of the
TCU page 0.
Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
referencing the existing arm,smmu-v3-pmcg binding.
Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
child nodes described in DT once the SMMU probe succeeds.
Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
PMCG is described as a child node. The PMCG registers occupy a sub-region
of the parent SMMU MMIO window, which is already requested by the SMMU
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
.../devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
3 files changed, 29 insertions(+), 3 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-smmu-perf-754367fe66c8
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH] dmaengine: lpc18xx-dmamux: simplify allocation
From: Frank Li @ 2026-04-08 7:48 UTC (permalink / raw)
To: Rosen Penev
Cc: dmaengine, Vinod Koul, Frank Li, Vladimir Zapolskiy, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/LPC18XX ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260407035132.99037-1-rosenp@gmail.com>
On Mon, Apr 06, 2026 at 08:51:32PM -0700, Rosen Penev wrote:
Subject need descript summary.
dmaengine: lpc18xx-dmamux: use flexible array to simplify allocation
Frank
^ permalink raw reply
* Re: [PATCH] arm64: clear_page[s] using memset
From: Linus Walleij @ 2026-04-08 7:47 UTC (permalink / raw)
To: Catalin Marinas, Ryan Roberts
Cc: Will Deacon, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, linux-arm-kernel, kvmarm
In-Reply-To: <adULAT2xus5z3HdQ@arm.com>
On Tue, Apr 7, 2026 at 3:47 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Apr 07, 2026 at 11:25:55AM +0200, Linus Walleij wrote:
> > Quoting my own commit message hehe:
> >
> > > No performance regressions can be seen, the fastpath
> > > benchmarks differences are in the noise.
> >
> > This was tested on hardware with Ryan Robert's fastpath tool.
>
> BTW, have you tried the perf bench mmap test again with the new
> clear_page? Both with single page and multiple pages scenarios. And
> ideally on more than one platform.
>
> Will pointed out (in a private chat) that current clear_page() uses
> non-temporal stores while memset() doesn't. It may not make any
> difference in practice but it would be good to have some numbers.
Hm interesting point, the perf bench mmap test isn't specifically
in fastpath but since it tends to come up I guess we can add it?
Ryan: is it easy to add this test to fastpath? Or easy for me to do
myself? I looked at the instructions but they were a bit intimidating...
The test is the following:
We boot the kernel with cmdline like this:
"default_hugepagesz=1G hugepagesz=1G hugepages=32" to make sure
we have ample hugepages. This was then tested with the same
cmdline as the original series:
perf bench mem mmap -p 1GB -f demand -s 32GB -l 5
The first run was discarded as the memory hierarchy is cold on
the first run. Then I ran the above command 5 times and averaged
the throughput
The x86 commit cb431accb36e51b64ce34b5cc4d5ed292895fd84
also mentions this test:
perf bench mem memset -k 1GB -f default -s 16GB
I tried it on QEMU, no real benefits with either the previous or this
patch, and no regressions either. (x86 passes -f x86-64-stosq
which are some optimized memset instructions)
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH v4 net-next 07/14] net: enetc: add support for "Add" and "Delete" operations to IPFT
From: Wei Fang @ 2026-04-08 7:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011734.1795551-1-kuba@kernel.org>
> > +int ntmp_ipft_add_entry(struct ntmp_user *user,
> > + struct ipft_entry_data *entry)
> > +{
> [ ... ]
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd(&req->crd, user->tbl.ipft_ver, NTMP_QA_ENTRY_ID,
> > + NTMP_GEN_UA_CFGEU | NTMP_GEN_UA_STSEU);
> > + req->ak.keye = entry->keye;
> > + req->cfge = entry->cfge;
>
> The request sets NTMP_GEN_UA_STSEU to indicate statistics data is present,
> but struct ipft_req_ua does not appear to contain a match_count or STSE data
> field before cfge.
>
> Since the hardware expects STSE data before CFGE data (as seen in
> struct ipft_resp_query), will this cause the hardware to misinterpret the
> first 8 bytes of cfge as the match_count, and then read the actual filter
> configuration from out-of-bounds or uninitialized memory?
Based on NETC manual, the STSE_DATA is present only for the commands
which perform a query. So for the 'add' command, we do not need to
provide the STSE_DATA buffer. And STSE_DATA is the statistics of the
entry, which is stored in the internal buffer of IPF table. Performing
NTMP_GEN_UA_STSEU is to reset the statistic counter when adding
an entry.
[...]
> > +struct ipft_pld_byte {
> > + u8 data;
> > + u8 mask;
> > +};
> > +
> > +struct ipft_keye_data {
> > + __le16 precedence;
> > + __le16 resv0[3];
> > + __le16 frm_attr_flags;
> > +#define IPFT_FAF_OVLAN BIT(2)
> > +#define IPFT_FAF_IVLAN BIT(3)
> > +#define IPFT_FAF_IP_HDR BIT(7)
> > +#define IPFT_FAF_IP_VER6 BIT(8)
> > +#define IPFT_FAF_L4_CODE GENMASK(11, 10)
> > +#define IPFT_FAF_TCP_HDR 1
> > +#define IPFT_FAF_UDP_HDR 2
> > +#define IPFT_FAF_SCTP_HDR 3
> > +#define IPFT_FAF_WOL_MAGIC BIT(12)
> > + __le16 frm_attr_flags_mask;
> > + __le16 dscp;
> > +#define IPFT_DSCP GENMASK(5, 0)
> > +#define IPFT_DSCP_MASK GENMASK(11, 0)
>
> Does IPFT_DSCP_MASK completely overlap with IPFT_DSCP?
>
> If it is defined as GENMASK(11, 0) instead of GENMASK(11, 6), using
> FIELD_PREP with this mask will not shift the value into the upper bits,
> which might overwrite the actual DSCP value in bits 0-5.
Thanks, this is a bug, I will fix it.
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: clock: qcom: Add video clock controller on Eliza SoC
From: Taniya Das @ 2026-04-08 7:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Vladimir Zapolskiy
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <4c4e80be-4aeb-4275-977f-b3f8c6ab26b0@oss.qualcomm.com>
On 4/7/2026 7:10 PM, Krzysztof Kozlowski wrote:
> On 17/03/2026 18:14, Taniya Das wrote:
>> Add compatible string for Eliza video clock controller and the bindings
>> for Eliza Qualcomm SoC.
>>
>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> ---
>> .../bindings/clock/qcom,sm8450-videocc.yaml | 16 ++++++++++
>> include/dt-bindings/clock/qcom,eliza-videocc.h | 37 ++++++++++++++++++++++
>> 2 files changed, 53 insertions(+)
>>
>
> Although I already suggested that this was not tested (and you never
> replied where did you test it), but I also checked and this fails checks
> - constraints are mismatched now.
I will update the bindings for videocc.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Bartosz Golaszewski @ 2026-04-08 7:31 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-4-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:42 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> From: Tzuyi Chang <tychang@realtek.com>
>
> Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
>
> Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> which manages pins via shared bank registers, the RTD1625 introduces
> a per-pin register architecture. Each GPIO line now has its own
> dedicated 32-bit control register to manage configuration independently,
> including direction, output value, input value, interrupt enable, and
> debounce. Therefore, this distinct hardware design requires a separate
> driver.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> Changes in v2:
> - Remove "default y".
> - Add base_offset member to struct rtd1625_gpio_info to handle merged regions.
> ---
> drivers/gpio/Kconfig | 11 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-rtd1625.c | 584 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 596 insertions(+)
> create mode 100644 drivers/gpio/gpio-rtd1625.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 5ee11a889867..281549ad72ac 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -638,6 +638,17 @@ config GPIO_RTD
> Say yes here to support GPIO functionality and GPIO interrupt on
> Realtek DHC SoCs.
>
> +config GPIO_RTD1625
> + tristate "Realtek DHC RTD1625 GPIO support"
> + depends on ARCH_REALTEK || COMPILE_TEST
> + select GPIOLIB_IRQCHIP
> + help
> + This option enables support for the GPIO controller on Realtek
> + DHC (Digital Home Center) RTD1625 SoC.
> +
> + Say yes here to support both basic GPIO line functionality
> + and GPIO interrupt handling capabilities for this platform.
> +
> config GPIO_SAMA5D2_PIOBU
> tristate "SAMA5D2 PIOBU GPIO support"
> depends on MFD_SYSCON
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index c05f7d795c43..c95ba218d53a 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -159,6 +159,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
> obj-$(CONFIG_GPIO_REG) += gpio-reg.o
> obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
> +obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
> obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
> obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
> obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
> diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> new file mode 100644
> index 000000000000..bcc1bbb115fa
> --- /dev/null
> +++ b/drivers/gpio/gpio-rtd1625.c
> @@ -0,0 +1,584 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Realtek DHC RTD1625 gpio driver
> + *
> + * Copyright (c) 2023 Realtek Semiconductor Corp.
No modifications since 2023?
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +
> +#define RTD1625_GPIO_DIR BIT(0)
> +#define RTD1625_GPIO_OUT BIT(2)
> +#define RTD1625_GPIO_IN BIT(4)
> +#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
> +#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
> +#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
> +#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
> +#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
> +#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
> +
> +#define RTD1625_GPIO_WREN(x) ((x) << 1)
> +
> +/* Write-enable masks for all GPIO configs and reserved hardware bits */
> +#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
> +#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
> +
> +#define RTD1625_GPIO_DEBOUNCE_1US 0
> +#define RTD1625_GPIO_DEBOUNCE_10US 1
> +#define RTD1625_GPIO_DEBOUNCE_100US 2
> +#define RTD1625_GPIO_DEBOUNCE_1MS 3
> +#define RTD1625_GPIO_DEBOUNCE_10MS 4
> +#define RTD1625_GPIO_DEBOUNCE_20MS 5
> +#define RTD1625_GPIO_DEBOUNCE_30MS 6
> +#define RTD1625_GPIO_DEBOUNCE_50MS 7
> +
> +#define GPIO_CONTROL(gpio) ((gpio) * 4)
> +
> +/**
> + * struct rtd1625_gpio_info - Specific GPIO register information
> + * @num_gpios: The number of GPIOs
> + * @irq_type_support: Supported IRQ types
> + * @gpa_offset: Offset for GPIO assert interrupt status registers
> + * @gpda_offset: Offset for GPIO deassert interrupt status registers
> + * @level_offset: Offset of level interrupt status register
> + * @write_en_all: Write-enable mask for all configurable bits
> + */
> +struct rtd1625_gpio_info {
> + unsigned int num_gpios;
> + unsigned int irq_type_support;
> + unsigned int base_offset;
> + unsigned int gpa_offset;
> + unsigned int gpda_offset;
> + unsigned int level_offset;
> + unsigned int write_en_all;
> +};
Please remove the tabs in the above struct.
> +
> +struct rtd1625_gpio {
> + struct gpio_chip gpio_chip;
> + const struct rtd1625_gpio_info *info;
> + void __iomem *base;
> + void __iomem *irq_base;
> + unsigned int irqs[3];
> + raw_spinlock_t lock;
> + unsigned int *save_regs;
> +};
I'd also personally remove these tabs here but won't die on that hill.
> +
> +static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpa_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpda_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->level_offset + ((offset / 32) * 4);
> +}
Looking at these, I'm under the impression that this driver could quite easily
be converted to using gpio-mmio or even gpio-regmap with an MMIO regmap, have
you looked into it by any chance?
Bart
^ permalink raw reply
* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Markus Elfring @ 2026-04-08 7:28 UTC (permalink / raw)
To: vulab, imx, linux-pm, linux-arm-kernel, Georgi Djakov,
Sascha Hauer, Shawn Guo
Cc: kernel, stable, LKML, Fabio Estevam
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
How do you think about to increase the application of scope-based resource management?
https://elixir.bootlin.com/linux/v7.0-rc7/source/include/linux/of.h#L138
https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/interconnect/imx/imx.c#L117-L160
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Bartosz Golaszewski @ 2026-04-08 7:28 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-5-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:43 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> Add the GPIO node for the Realtek RTD1625 SoC.
>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* RE: [PATCH v4 net-next 06/14] net: enetc: add support for the "Update" operation to buffer pool table
From: Wei Fang @ 2026-04-08 7:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011731.1795517-1-kuba@kernel.org>
> > @@ -702,5 +708,38 @@ int ntmp_vft_add_entry(struct ntmp_user *user,
> u16 vid,
> > }
> > EXPORT_SYMBOL_GPL(ntmp_vft_add_entry);
> >
> > +int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
> > + const struct bpt_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct bpt_req_update),
> > + };
> > + struct bpt_req_update *req;
> > + union netc_cbd cbd;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd_eid(&req->rbe, user->tbl.bpt_ver, 0,
> > + NTMP_GEN_UA_CFGEU | BPT_UA_BPSEU, entry_id);
>
> Does this update action mask match the size of the request buffer?
>
> The mask includes both NTMP_GEN_UA_CFGEU and BPT_UA_BPSEU, which
> instructs
> the hardware to update both the configuration entry and the status entry.
> However, struct bpt_req_update only contains the configuration data,
> omitting the status data.
>
> If the hardware attempts to read the missing BPSE data, could it reject
> the command due to an undersized request length, or read beyond the
> intended payload into zero-initialized DMA padding? This might overwrite
> critical buffer pool tracking variables like amount_used_hwm.
>
> If only the configuration is being updated, should the BPT_UA_BPSEU flag
> be removed?
The BPSE_DATA is a set of statistics and status records kept by the hardware
(internal buffer), and does not require the user to provide additional data to
the hardware for updates. Therefore, for the 'update' operation, the request
buffer does not need to provide BPSE_DATA data.
^ permalink raw reply
* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Frank Li @ 2026-04-08 7:24 UTC (permalink / raw)
To: Wentao Liang
Cc: Georgi Djakov, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-pm, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
On Wed, Apr 08, 2026 at 03:10:04AM +0000, Wentao Liang wrote:
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
>
> Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/interconnect/imx/imx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> index 9511f80cf041..75431b5ccef8 100644
> --- a/drivers/interconnect/imx/imx.c
> +++ b/drivers/interconnect/imx/imx.c
> @@ -143,15 +143,16 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
> }
>
Please use auto cleanup to fix this problem
struct device_node * __free(device_nod) dn = of_parse_phandle(dev->of_node, adj->phandle_name, 0);
Frank
> pdev = of_find_device_by_node(dn);
> - of_node_put(dn);
> if (!pdev) {
> dev_warn(dev, "node %s[%d] missing device for %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> return -EPROBE_DEFER;
> }
> node_data->qos_dev = &pdev->dev;
> dev_dbg(dev, "node %s[%d] has device node %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> }
>
> return dev_pm_qos_add_request(node_data->qos_dev,
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Axel Flordal @ 2026-04-08 7:21 UTC (permalink / raw)
To: asahi, linux-arm-kernel, devicetree, linux-kernel
Cc: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Change "configiguration" to "configuration".
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Axel Flordal <axel@flordal.net>
---
Original patch: https://lore.kernel.org/asahi/CAEg-Je-KwNNGoi3mpPeNq3Jmtzj_5seuj1Qeh2_1dt994iCJSA@mail.gmail.com/T/#t
If this is unwanted I of course won't send again.
---
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
index 9740fbf200f0..d2720b307774 100644
--- a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
+++ b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
@@ -2,7 +2,7 @@
//
// Devicetree include for common spi-nor nvram flash.
//
-// Apple uses a consistent configiguration for the nvram on all known M1* and
+// Apple uses a consistent configuration for the nvram on all known M1* and
// M2* devices.
//
// Copyright The Asahi Linux Contributors
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-04-08 7:18 UTC (permalink / raw)
To: Rob Herring
Cc: Jeremy Kerr, Krzysztof Kozlowski,
andriy.shevchenko@linux.intel.com, Andi Shyti,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20260407204402.GA3641251-robh@kernel.org>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> On Tue, Mar 31, 2026 at 07:30:58AM +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> > > global-regs and enable-dma properties
> > >
> > > Hi Ryan,
> > >
> > > > > Sounds reasonable, but before you do so, how are you planning to
> > > > > manage the allocation of DMA channels across multiple i2c
> peripherals?
> > > > >
> > > > The AST2600 I2C hardware has only one can use DMA at a time.
> > > > To avoid the complexity of managing DMA channel contention, I plan
> > > > to use buffer mode by default for all controllers, which still
> > > > provides better performance than byte mode without requiring DMA
> > > > channel
> > > allocation.
> > >
> > > OK, but your wording there ("by default") implies that DMA is still
> > > selectable for one controller peripheral. In which case: you still
> > > have the problem of managing DMA channel contention, but now it's at
> runtime instead.
> > >
> > > So my question still stands: how are you planning to enforce that
> > > DMA is only enabled for one controller?
> > >
> > > Or are you planning to disable I2C DMA entirely on AST2600?
> > Yes, This is my intent to do.
> > Disable I2C DMA entirely on AST2600.
> > If I remove DMA, should can I keep byte and buffer for sysfs?
>
> 28 versions and it's still not clear when you need what mode. Sigh. The only
> thing better about sysfs then it's not my problem, but that really doesn't sound
> much better.
>
> DMA is only going to be useful for transfers above a certain size. If you are
> doing the typical SMBus style register accesses, then DMA is completely
> useless. The setup DMA overhead is going to be greater than just directly
> reading/writing the I2C controller FIFOs.
Sorry, why you think DMA overhead is greater than read/write FIFO?
When enable DMA, all dma allocate will be initial in probe.
And the DMA mode data is going to dram, that will be read/write data from
dram. Compare with buffer mode, data is from FIFO register to read/write.
So DMA will not have overhead.
> What's the size that makes DMA
> useful? 16, 32, 64 bytes?
The i2c ast2600 can be 4096 byte for each tx/rx dma,
buffer mode is 32byte (16 byte for TX, 16 byte for RX).
>Something greater than the max size in buffer mode
> probably. Really, provide some data that DMA gives better performance
> and/or less CPU usage.
In general i2c transfer len < buffer size. dma did not gain.
But if large than buffer size (16 byte), it will reduce the cpu interrupt latency.
For example, mctp transfer :
https://github.com/torvalds/linux/blob/master/drivers/net/mctp/mctp-i2c.c#L29
mctp max len is 256, that will 1 interrupt for each package transfer.
But in fifo mode will be 256/16 = 16 interrupts.
Compare the smbus I2C_SMBUS_BLOCK_MAX is 32 byte + 2
https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c.h#L145
That is only (32 + 2)/16 = 2~3 interrupts. It may not gain more.
>If you set some minimum size and request DMA only
> above that size, is there really that much contention?
Sorry, I don't know your point here, could you give more your statement?
> If there's some specific
> device that really needs DMA, then make that device's driver request it and
> reserve it.
>
> For byte mode, there's not a clear need nor description of why. Someone once
> long ago asked for it... Who cares, if they really want it, then the issue needs to
> be described. If a certain device requires certain timing that byte mode
> provides, then that should be some property the driver for the device
> communicates to the controller. No need for DT nor sysfs in that case.
>
I agree with your point.
My proposal will remove byte mode. And keep dma/buffer. And remove sysfs for
transfer mode selection, default will be buffer mode. And keep properties
aspeed,enable-dma, which indicate the channel have DMA capability to use.
And if dts add aspeed,enable-dma, the i2c will use DMA otherwise will keep buffer
transfer, is it ok?
^ permalink raw reply
* RE: [PATCH v4 net-next 05/14] net: enetc: add support for the "Add" operation to VLAN filter table
From: Wei Fang @ 2026-04-08 7:12 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011729.1795413-1-kuba@kernel.org>
> > diff --git a/drivers/net/ethernet/freescale/enetc/ntmp.c
> b/drivers/net/ethernet/freescale/enetc/ntmp.c
> > --- a/drivers/net/ethernet/freescale/enetc/ntmp.c
> > +++ b/drivers/net/ethernet/freescale/enetc/ntmp.c
>
> [ ... ]
>
> > @@ -652,5 +655,52 @@ int ntmp_fdbt_search_port_entry(struct ntmp_user
> *user, int port,
> > +int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
> > + const struct vft_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct vft_req_ua),
> > + };
> > + struct vft_req_ua *req;
> > + union netc_cbd cbd;
> > + u32 len;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + /* Request data */
> > + ntmp_fill_crd(&req->crd, user->tbl.vft_ver, 0,
> > + NTMP_GEN_UA_CFGEU);
> > + req->ak.exact.vid = cpu_to_le16(vid);
> > + req->cfge = *cfge;
> > +
> > + /* Request header */
> > + len = NTMP_LEN(data.size, NTMP_STATUS_RESP_LEN);
> > + ntmp_fill_request_hdr(&cbd, data.dma, len, NTMP_VFT_ID,
> > + NTMP_CMD_ADD, NTMP_AM_EXACT_KEY);
> > +
> > + err = netc_xmit_ntmp_cmd(user, &cbd);
> > + if (err)
> > + dev_err(user->dev,
> > + "Failed to add %s entry, vid: %u, err: %pe\n",
> > + ntmp_table_name(NTMP_VFT_ID), vid, ERR_PTR(err));
> > +
> > + ntmp_free_data_mem(&data);
>
> Does this code safely handle hardware timeouts?
>
> If netc_xmit_ntmp_cmd() times out and returns an error, the pending
> transaction is not explicitly aborted before ntmp_free_data_mem()
> unconditionally frees the DMA buffer.
>
> Could the hardware eventually process the pending command and perform a
> DMA write of the response to the physical address of the freed buffer?
>
> This might lead to silent memory corruption if that memory has already
> been reallocated to another subsystem. Would it be safer to explicitly
> abort the pending DMA transaction, reset the device on timeout, or
> intentionally delay freeing the buffer until it is proven safe?
This is indeed a potential issue, I will add a patch to fix it.
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: perf: marvell: Add CN20K DDR PMU binding
From: Krzysztof Kozlowski @ 2026-04-08 7:09 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260407153511.4250-2-gakula@marvell.com>
On Tue, Apr 07, 2026 at 09:05:10PM +0530, Geetha sowjanya wrote:
> Marvell CN20K SoCs integrate a DDR Performance Monitoring Unit (PMU)
> associated with the DDR controller. The block provides hardware counters
> to monitor DDR traffic and performance events and is accessed via a
> dedicated MMIO region.
>
> The CN20K DDR PMU is functionally equivalent to the CN10K DDR PMU, with
> minor register offset differences. This binding documents the CN20K
> variant and introduces a specific compatible string to allow software
> to distinguish between the two implementations.
Drop last sentence, I already asked for that.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39 +++++++++++++++++++
Still wrong filename.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:07 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <1ef8adf850f2fd41b6c4e3c89e4f4e6e0f469a0e.1775559102.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 01:42:33PM +0200, Nora Schiffer wrote:
> The J722S WIZ is mostly identical to the AM64's, but additionally supports
> SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-j721e-wiz.yaml | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:06 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <b67c8b0bc9cc918667e9329d79f617d033d025d5.1775559102.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 01:42:34PM +0200, Nora Schiffer wrote:
> The J722S gmii-sel is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++--------
> 1 file changed, 14 insertions(+), 9 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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