* [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
* [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 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 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
* 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
* 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] 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
* [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
* [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 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 2/3] nvmem: Add the Raspberry Pi OTP 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
In-Reply-To: <20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de>
Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/Kconfig | 12 +++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 2 +
4 files changed, 174 insertions(+)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..892d05fe67be 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
This driver can also be built as a module. If so, the module
will be called nvmem_qoriq_efuse.
+config NVMEM_RASPBERRYPI_OTP
+ tristate "Raspberry Pi OTP support"
+ # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+ # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+ depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
+ help
+ This driver provides access to the Raspberry Pi OTP memory via the
+ nvmem subsystem. The driver supports the customer otp as well as the
+ device specific private key OTP.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-otp.
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..8ca2095e068f 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
obj-$(CONFIG_NVMEM_QORIQ_EFUSE) += nvmem-qoriq-efuse.o
nvmem-qoriq-efuse-y := qoriq-efuse.o
+obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP) += raspberrypi-otp.o
diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
new file mode 100644
index 000000000000..13ee3784b137
--- /dev/null
+++ b/drivers/nvmem/raspberrypi-otp.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_otp_priv {
+ struct rpi_firmware *fw;
+ struct device *dev;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_driver_data {
+ const char *name;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_header {
+ u32 start;
+ u32 count;
+ u32 data[];
+};
+
+static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ int ret;
+
+ fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = offset / 4;
+ fwbuf->count = bytes / 4;
+
+ ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+ if (ret)
+ goto out;
+
+ memcpy(buf, fwbuf->data, bytes);
+
+out:
+ kfree(fwbuf);
+ return ret;
+}
+
+static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ int ret;
+
+ fwbuf = kmalloc(sizeof(struct rpi_otp_header) + bytes, GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = offset / 4;
+ fwbuf->count = bytes / 4;
+ memcpy(fwbuf->data, val, bytes);
+
+ ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+
+ kfree(fwbuf);
+ return ret;
+}
+
+static const struct rpi_otp_driver_data rpi_otp_customer = {
+ .name = "rpi-otp-customer",
+ .read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
+ .write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
+};
+
+static const struct rpi_otp_driver_data rpi_otp_private = {
+ .name = "rpi-otp-private",
+ .read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
+ .write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
+};
+
+static int rpi_otp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_device *nvmem;
+ struct rpi_otp_priv *priv;
+ struct device_node *np;
+ const struct rpi_otp_driver_data *data;
+ struct nvmem_config config = {
+ .read_only = false,
+ .word_size = 4,
+ .stride = 4,
+ .reg_read = rpi_otp_read,
+ .reg_write = rpi_otp_write,
+ .size = 32,
+ };
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ data = device_get_match_data(dev);
+ if (!data)
+ return -ENODEV;
+
+ np = of_get_parent(dev->of_node);
+ if (!np) {
+ dev_err(dev, "Missing firmware node\n");
+ return -ENOENT;
+ }
+
+ priv->fw = devm_rpi_firmware_get(&pdev->dev, np);
+ of_node_put(np);
+ if (!priv->fw)
+ return -EPROBE_DEFER;
+
+ priv->dev = dev;
+ priv->read_tag = data->read_tag;
+ priv->write_tag = data->write_tag;
+ config.dev = dev;
+ config.priv = priv;
+ config.name = data->name;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem))
+ return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
+
+ return 0;
+}
+
+static const struct of_device_id rpi_otp_of_match[] = {
+ {
+ .compatible = "raspberrypi,firmware-otp-customer",
+ .data = &rpi_otp_customer
+ },
+ {
+ .compatible = "raspberrypi,firmware-otp-private",
+ .data = &rpi_otp_private,
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rpi_otp_of_match);
+
+static struct platform_driver raspberry_otp_driver = {
+ .probe = rpi_otp_probe,
+ .driver = {
+ .name = "rpi-otp",
+ .of_match_table = rpi_otp_of_match,
+ },
+};
+module_platform_driver(raspberry_otp_driver);
+
+MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
+MODULE_DESCRIPTION("Raspberry OTP driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe554..6e94ccf34f47 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
+ RPI_FIRMWARE_GET_PRIVATE_OTP = 0x00030081,
+ RPI_FIRMWARE_SET_PRIVATE_OTP = 0x00038081,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Sakari Ailus @ 2026-04-08 8:05 UTC (permalink / raw)
To: michael.riesch
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Collabora Kernel Team, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260305-rk3588-csi2rx-v4-1-81c6bcfefa63@collabora.com>
Hi Michael,
On Fri, Mar 27, 2026 at 12:10:00AM +0100, Michael Riesch via B4 Relay wrote:
> From: Michael Riesch <michael.riesch@collabora.com>
>
> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
> the RK3568.
> Introduce a list of compatible variants and add the RK3588 variant to
> it.
Please use your editor to wrap the commit messages in the future as needed.
It became:
The RK3588 MIPI CSI-2 receivers are compatible to the ones found in the
RK3568. Introduce a list of compatible variants and add the RK3588 variant
to it.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-08 8:08 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <adYKtjPvIgoK2oou@lizhi-Precision-Tower-5810>
On Wed, Apr 08, 2026 at 03:58:59AM -0400, Frank Li wrote:
> 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>;
> };
> };
If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
DPI panel, then it won't work unless the user also apply
imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>
> 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
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH] crypto: tstmgr - guard xxhash tests
From: Herbert Xu @ 2026-04-08 8:08 UTC (permalink / raw)
To: Hamza Mahfooz
Cc: linux-crypto, David S. Miller, Maxime Coquelin, Alexandre Torgue,
linux-stm32, linux-arm-kernel, linux-kernel, Jeff Barnes,
Paul Monson
In-Reply-To: <20260407192859.270745-1-hamzamahfooz@linux.microsoft.com>
On Tue, Apr 07, 2026 at 12:28:59PM -0700, Hamza Mahfooz wrote:
> If the kernel isn't built with CONFIG_CRYPTO_XXHASH and booted with FIPS
> mode enabled it will currently panic. So, only benchmark xxhash64 if
> CRYPTO_XXHASH is enabled.
>
> Cc: Jeff Barnes <jeffbarnes@linux.microsoft.com>
> Cc: Paul Monson <paul.monson@capgemini.com>
> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
> ---
> crypto/testmgr.c | 2 ++
> 1 file changed, 2 insertions(+)
Please show me the panic. Normally it's not an issue if an algorithm
is not present while the test vectors are.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] firmware: raspberrypi: Change dependency to ARCH_BCM2835 and COMPILE_TEST
From: Chen-Yu Tsai @ 2026-04-08 8:11 UTC (permalink / raw)
To: Florian Fainelli, Broadcom internal kernel review list
Cc: Chen-Yu Tsai, linux-rpi-kernel, linux-arm-kernel, linux-kernel
The Raspberry Pi firmware driver has no compile dependencies on the
BCM2835 mailbox driver. It's just a indirect runtime dependency: the
driver only works on a Raspberry Pi.
Change the dependency from BCM2835_MBOX to ARCH_BCM2835. Also allow
compile tests. This allows drivers that have build time dependencies
on this firmware driver to be compile tested as well.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/firmware/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index bbd2155d8483..f99d27c1f6a4 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -114,7 +114,7 @@ config ISCSI_IBFT
config RASPBERRYPI_FIRMWARE
tristate "Raspberry Pi Firmware Driver"
- depends on BCM2835_MBOX
+ depends on ARCH_BCM2835 || COMPILE_TEST
help
This option enables support for communicating with the firmware on the
Raspberry Pi.
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* Re: (subset) [PATCH v3 0/3] Add the missing mpll3 clock and clock controller nodes
From: Jerome Brunet @ 2026-04-08 8:20 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Stephen Boyd,
Michael Turquette, robh+dt, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jian Hu
Cc: devicetree, linux-clk, linux-amlogic, linux-kernel,
linux-arm-kernel, Ronald Claveau, Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-1-jian.hu@amlogic.com>
Applied to clk-meson (clk-meson-next), thanks!
[1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
https://github.com/BayLibre/clk-meson/commit/6d6be1cca2c9
[2/3] dt-bindings: clock: amlogic: t7: Add missing mpll3 parent clock
https://github.com/BayLibre/clk-meson/commit/87edca62c4f5
Best regards,
--
Jerome
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank Li @ 2026-04-08 8:28 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: <f5cd5da8-566d-4dff-b712-3d48927f97eb@nxp.com>
On Wed, Apr 08, 2026 at 04:08:24PM +0800, Liu Ying wrote:
> On Wed, Apr 08, 2026 at 03:58:59AM -0400, Frank Li wrote:
> > 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>;
> > };
> > };
>
> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
> DPI panel, then it won't work unless the user also apply
> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>
> >
Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
applied both overlay file.
can the same board be use for imx91 or other evk boards?
Frank
> > 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
>
> --
> Regards,
> Liu Ying
^ permalink raw reply
* RE: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-08 8:34 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <7ewnbwdo5qtasbxj4uel6a6uthczq2l6udbvoqqkwm776lvseb@v54ri2gknwxn>
> On Tue, Apr 07, 2026 at 06:41:46PM +0800, Sherry Sun wrote:
> > The current DT binding for pci-imx6 specifies the 'reset-gpios'
> > property in the host bridge node. However, the PERST# signal logically
> > belongs to individual Root Ports rather than the host bridge itself.
> > This becomes important when supporting PCIe KeyE connector and PCI
> > power control framework for pci-imx6 driver, which requires properties
> > to be specified in Root Port nodes.
> >
> > Add support for parsing 'reset-gpios' from Root Port child nodes using
> > the common helper pci_host_common_parse_ports(), and update the reset
> > GPIO handling to use the parsed port list from bridge->ports. To
> > maintain DT backwards compatibility, fallback to the legacy method of
> > parsing the host bridge node if the reset property is not present in
> > the Root Port node.
> >
> > Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be
> > in input mode, using gpiod_direction_output() instead of
> > gpiod_set_value_cansleep() to ensure the reset GPIO is properly
> > configured as output before setting its value.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 75
> > +++++++++++++++++++++------
> > 1 file changed, 60 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index d99da7e42590..dd8f9c0fcec4 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -34,6 +34,7 @@
> > #include <linux/pm_runtime.h>
> >
> > #include "../../pci.h"
> > +#include "../pci-host-common.h"
> > #include "pcie-designware.h"
> >
> > #define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > @@ -152,7 +153,6 @@ struct imx_lut_data {
> >
> > struct imx_pcie {
> > struct dw_pcie *pci;
> > - struct gpio_desc *reset_gpiod;
> > struct clk_bulk_data *clks;
> > int num_clks;
> > bool supports_clkreq;
> > @@ -1224,6 +1224,32 @@ static void imx_pcie_disable_device(struct
> pci_host_bridge *bridge,
> > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> >
> > +static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie) {
> > + struct device *dev = pcie->pci->dev;
> > + struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
> > + struct pci_host_port *port;
> > + struct gpio_desc *reset;
> > +
> > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > + if (IS_ERR(reset))
> > + return PTR_ERR(reset);
> > +
> > + if (!reset)
> > + return 0;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + port->reset = reset;
> > + INIT_LIST_HEAD(&port->list);
> > + list_add_tail(&port->list, &bridge->ports);
> > +
> > + return devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> > + &bridge->ports);
> > +}
> > +
> > static void imx_pcie_vpcie_aux_disable(void *data) {
> > struct regulator *vpcie_aux = data;
> > @@ -1233,13 +1259,22 @@ static void imx_pcie_vpcie_aux_disable(void
> > *data)
> >
> > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > assert) {
> > - if (assert) {
> > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
> > - } else {
> > - if (imx_pcie->reset_gpiod) {
> > - msleep(PCIE_T_PVPERL_MS);
> > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
> > - msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > + struct dw_pcie *pci = imx_pcie->pci;
> > + struct pci_host_bridge *bridge = pci->pp.bridge;
> > + struct pci_host_port *port;
> > +
> > + if (!bridge)
> > + return;
> > +
> > + list_for_each_entry(port, &bridge->ports, list) {
> > + if (assert) {
> > + gpiod_direction_output(port->reset, 1);
> > + } else {
> > + if (port->reset) {
> > + msleep(PCIE_T_PVPERL_MS);
> > + gpiod_direction_output(port->reset, 0);
> > + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > + }
>
> Sashiko flagged this loop:
>
> ```
> Does this loop multiply the initialization delays?
> If a controller has multiple Root Ports, the msleep calls will run sequentially
> for each port, linearly increasing the delay. Could we optimize this by
> asserting all reset GPIOs, waiting the pre-delay once, de-asserting all GPIOs,
> and waiting the post-delay once for the entire bus?
> ```
>
> Maybe you should do:
>
> if (!list_empty(&bridge->ports) && !assert)
> msleep(PCIE_T_PVPERL_MS);
>
> list_for_each_entry(port, &bridge->ports, list) {
> ...
> gpiod_direction_output(port->reset, 0);
> ...
> }
>
> if (!list_empty(&bridge->ports) && !assert)
> msleep(PCIE_RESET_CONFIG_WAIT_MS);
>
Hi Mani, I think the code below looks clearer, is that ok for you?
if (assert) {
list_for_each_entry(port, &bridge->ports, list)
gpiod_direction_output(port->reset, 1);
} else {
if (list_empty(&bridge->ports))
return;
msleep(PCIE_T_PVPERL_MS);
list_for_each_entry(port, &bridge->ports, list)
gpiod_direction_output(port->reset, 0);
msleep(PCIE_RESET_CONFIG_WAIT_MS);
}
> And then this:
>
> ```
> Also, since this function is called from imx_pcie_resume_noirq, which
> executes with hardware interrupts disabled, does the use of msleep here
> trigger a 'sleeping while atomic' bug?
> ```
>
> This is a valid concern. You should use mdelay(). But I'd recommend switching
> to IRQ enabled callback, resume() instead. There is no complelling reason to
> use resume_noirq() in this driver and adding delays in noirq() callbacks is not
> recommended as it may increase the overall system resume time.
>
> I will submit a separate series to convert dw_pcie_resume_noirq() and its
> callers to IRQ enabled callbacks since this dw_pcie_resume_noirq() could
> potentially cause delay up to 1sec.
Yes, this is not a new bug introduced by this patch. I agree we should covert the
convert dw_pcie_resume_noirq() and the caller to IRQ enabled callbacks to fix
this in a separate patch series.
For now, should I leave it as is, or switch to mdelay in this patch?
>
> > }
> > }
> > }
> > @@ -1249,8 +1284,25 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > struct device *dev = pci->dev;
> > struct imx_pcie *imx_pcie = to_imx_pcie(pci);
> > + struct pci_host_bridge *bridge = pp->bridge;
> > int ret;
> >
> > + if (bridge && list_empty(&bridge->ports)) {
> > + /* Parse Root Port nodes if present */
> > + ret = pci_host_common_parse_ports(dev, bridge);
> > + if (ret) {
> > + if (ret != -ENOENT) {
> > + dev_err(dev, "Failed to parse Root Port
> nodes: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Fallback to legacy binding for DT backwards
> compatibility */
> > + ret = imx_pcie_parse_legacy_binding(imx_pcie);
>
> This is also flagged by Sashiko:
>
> ```
> Could this error handling corrupt the port state and trigger an invalid legacy
> fallback?
>
> If a device tree defines multiple Root Ports and one lacks the optional reset
> GPIO, pci_host_common_parse_ports returns -ENOENT. This causes the code
> to fall back to imx_pcie_parse_legacy_binding.
>
> Since the already-parsed child ports remain in bridge->ports without rollback,
> the legacy host bridge GPIO will be appended alongside them.
> Valid child nodes are skipped, and both child and legacy GPIOs will be toggled
> simultaneously.
> ```
>
> You should try to cleanup Root Port resources if
> pci_host_common_parse_ports() fails with -ENOENT.
Sure, I will call pci_host_common_delete_ports() to clean up any partially parsed
Root Port resources before falling back to legacy binding.
Best Regards
Sherry
^ permalink raw reply
* RE: [PATCH v4 net-next 09/14] net: dsa: add NETC switch tag support
From: Wei Fang @ 2026-04-08 8:35 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: <20260403011736.1795610-1-kuba@kernel.org>
> > diff --git a/net/dsa/tag_netc.c b/net/dsa/tag_netc.c
> > new file mode 100644
> > index 000000000000..addd41f7f1b6
> > --- /dev/null
> > +++ b/net/dsa/tag_netc.c
> [ ... ]
> > +static void *netc_fill_common_tp_tag(struct sk_buff *skb,
> > + struct net_device *ndev,
> > + u8 subtype, int tag_len)
> > +{
> > + struct dsa_port *dp = dsa_user_to_port(ndev);
> > + u16 queue = skb_get_queue_mapping(skb);
> > + u8 ipv = netdev_txq_to_tc(ndev, queue);
>
> What happens here if the interface doesn't have traffic classes configured?
netdev_txq_to_tc() will return 0 if not TC configured, I mean ndev->num_tc is
0.
>
> By default, netdev_txq_to_tc() returns -1. Because ipv is an unsigned 8-bit
> integer, this casts to 255.
Okay, this is a potential bug when we add TC_SETUP_QDISC_MQPRIO
support. I will fix it.
>
> When this is later passed to FIELD_PREP(NETC_TAG_IPV, ipv) in
> netc_fill_common_tag(), the macro blindly masks the variable, silently
> forcing the IPV field to 7 (the maximum priority) for all default,
> unconfigured traffic. Valid TC values greater than 7 would also be silently
> truncated.
>
> Does this code bypass the intended QoS mechanisms?
No, configure IPV to send packets according to the expected TC.
>
> > + void *tag;
> > +
> > + skb_push(skb, tag_len);
> > + dsa_alloc_etype_header(skb, tag_len);
> > +
> > + tag = dsa_etype_header_pos_tx(skb);
> > + memset(tag + NETC_TAG_CMN_LEN, 0, tag_len - NETC_TAG_CMN_LEN);
> > + netc_fill_common_tag(tag, NETC_TAG_TO_PORT, subtype,
> > + dp->ds->index, dp->index, ipv);
>
> Will this break communication for standard single-switch setups?
>
> The driver passes dp->ds->index as the hardware switch ID here, which
> defaults to 0 for the first switch in a DSA tree. However, on the receive
> path, frames stamped with switch ID 0 are rejected.
>
> If the physical switch hardware uses an ID greater than 0, frames will fail
> the lookup in dsa_conduit_find_user() on receive because the software index
> is 0.
We added the 'dsa,member' property to the netc switch DT-binding doc, specifying
that the 'member' (switch index) value cannot be 0. Furthermore, the netc switch
driver also checks the switch index to ensure it is not 0. Therefore, the software index
and hardware index are equal.
>
> > +
> > + return tag;
> > +}
> [ ... ]
> > +static struct sk_buff *netc_rcv(struct sk_buff *skb,
> > + struct net_device *ndev)
> > +{
> > + struct netc_tag_cmn *tag_cmn;
> > + int tag_len, sw_id, port;
> [ ... ]
> > + if (tag_cmn->qos & NETC_TAG_QV)
> > + skb->priority = FIELD_GET(NETC_TAG_IPV, tag_cmn->qos);
> > +
> > + sw_id = NETC_TAG_SWITCH & tag_cmn->switch_port;
>
> This isn't a bug, but is there a reason to use a raw bitwise AND for sw_id
> instead of using FIELD_GET(NETC_TAG_SWITCH, ...) to match how the port
> field is extracted just below this?
I think either is fine, the final result is the same. I just wrote it this way for
convenience during implementation.
^ permalink raw reply
* Re: [PATCH v3] tpm: i2c: atmel: fix block comment formatting
From: Jarkko Sakkinen @ 2026-04-08 8:38 UTC (permalink / raw)
To: Ethan Luna
Cc: peterhuewe, jgg, nicolas.ferre, claudiu.beznea, linux-integrity,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260324154354.6268-1-trunixcodes@zohomail.com>
On Tue, Mar 24, 2026 at 08:39:49AM -0700, Ethan Luna wrote:
> Multiple block comments in tpm_i2c_atmel.c placed the closing '*/' on the
> same line as the comment text. This violates the kernel's preferred
> comment style, which requires the closing delimiter to appear on its
> line.
>
> Fix the formatting to improve readability and resolve checkpatch
> warnings.
>
> Signed-off-by: Ethan Luna <trunixcodes@zohomail.com>
> ---
>
> V1 -> V2: Fixed block comment formatting consistently across all multi-line comments
> V2 -> V3: Fixed trailing whitespaces consistently across all multi-line comments
>
> v1: https://lore.kernel.org/all/20260322193112.27010-1-trunixcodes@zohomail.com/
> v2: https://lore.kernel.org/all/20260323134200.7766-1-trunixcodes@zohomail.com/
>
> drivers/char/tpm/tpm_i2c_atmel.c | 34 +++++++++++++++++++++-----------
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
> index 4f229656a8e2..9fd73049821f 100644
> --- a/drivers/char/tpm/tpm_i2c_atmel.c
> +++ b/drivers/char/tpm/tpm_i2c_atmel.c
> @@ -31,9 +31,11 @@
>
> struct priv_data {
> size_t len;
> - /* This is the amount we read on the first try. 25 was chosen to fit a
> + /*
> + * This is the amount we read on the first try. 25 was chosen to fit a
> * fair number of read responses in the buffer so a 2nd retry can be
> - * avoided in small message cases. */
> + * avoided in small message cases.
> + */
> u8 buffer[sizeof(struct tpm_header) + 25];
> };
>
> @@ -58,7 +60,9 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
> if (status < 0)
> return status;
>
> - /* The upper layer does not support incomplete sends. */
> + /*
> + * The upper layer does not support incomplete sends.
> + */
> if (status != len)
> return -E2BIG;
>
> @@ -76,9 +80,11 @@ static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> if (priv->len == 0)
> return -EIO;
>
> - /* Get the message size from the message header, if we didn't get the
> + /*
> + * Get the message size from the message header, if we didn't get the
> * whole message in read_status then we need to re-read the
> - * message. */
> + * message.
> + */
> expected_len = be32_to_cpu(hdr->length);
> if (expected_len > count)
> return -ENOMEM;
> @@ -111,15 +117,19 @@ static u8 i2c_atmel_read_status(struct tpm_chip *chip)
> struct i2c_client *client = to_i2c_client(chip->dev.parent);
> int rc;
>
> - /* The TPM fails the I2C read until it is ready, so we do the entire
> + /*
> + * The TPM fails the I2C read until it is ready, so we do the entire
> * transfer here and buffer it locally. This way the common code can
> - * properly handle the timeouts. */
> + * properly handle the timeouts.
> + */
> priv->len = 0;
> memset(priv->buffer, 0, sizeof(priv->buffer));
>
>
> - /* Once the TPM has completed the command the command remains readable
> - * until another command is issued. */
> + /*
> + * Once the TPM has completed the command the command remains readable
> + * until another command is issued.
> + */
> rc = i2c_master_recv(client, priv->buffer, sizeof(priv->buffer));
> dev_dbg(&chip->dev,
> "%s: sts=%d", __func__, rc);
> @@ -172,9 +182,11 @@ static int i2c_atmel_probe(struct i2c_client *client)
>
> dev_set_drvdata(&chip->dev, priv);
>
> - /* There is no known way to probe for this device, and all version
> + /*
> + * There is no known way to probe for this device, and all version
> * information seems to be read via TPM commands. Thus we rely on the
> - * TPM startup process in the common code to detect the device. */
> + * TPM startup process in the common code to detect the device.
> + */
>
> return tpm_chip_register(chip);
> }
> --
> 2.53.0
>
Thank you.
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Applied.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-08 8:40 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <adYRuAU5ueEKHK5l@lizhi-Precision-Tower-5810>
On Wed, Apr 08, 2026 at 04:28:40AM -0400, Frank Li wrote:
> On Wed, Apr 08, 2026 at 04:08:24PM +0800, Liu Ying wrote:
>> On Wed, Apr 08, 2026 at 03:58:59AM -0400, Frank Li wrote:
>>> 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
This ...
>>>
>>> In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
>>> &{/} {
>>> panel {
>>> compatible = "tianma,tm050rdh03";
>>> enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>> };
>>> };
>>
>> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
>> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
>> DPI panel, then it won't work unless the user also apply
>> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>>
>>>
>
> Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
> applied both overlay file.
.... indicates that imx93-9x9-qsb-tianma-tm050rdh03.dtb is generated by
applying both imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo and
imx93-9x9-qsb-tianma-tm050rdh03.dtbo to imx93-9x9-qsb.dtb.
While, imx93-9x9-qsb-tianma-tm050rdh03.dtbo(a DT overlay blob) just contains
the panel node, which means that an user __cannot_ enable the tianma,tm050rdh03
DPI panel by only applying it to imx93-9x9-qsb.dtb, unless the user also
applies imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo. That's why the .dtsi
file is needed.
>
> can the same board be use for imx91 or other evk boards?
Yes, both tianma,tm050rdh03 and ontat,kd50g21-40nt-a1 DPI panels can be
connected to i.MX91/93 11x11 EVK and 9x9 QSB boards.
>
> Frank
>
>>> 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
>>
>> --
>> Regards,
>> Liu Ying
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 2/3] KVM: arm64: vgic: Allow userspace to set IIDR revision 1
From: Woodhouse, David @ 2026-04-08 8:39 UTC (permalink / raw)
To: maz@kernel.org
Cc: kvm@vger.kernel.org, shuah@kernel.org, yuzenghui@huawei.com,
joey.gouly@arm.com, linux-kernel@vger.kernel.org,
catalin.marinas@arm.com, nathan@kernel.org, pbonzini@redhat.com,
kvmarm@lists.linux.dev, arnd@arndb.de, kees@kernel.org,
will@kernel.org, suzuki.poulose@arm.com, oupton@kernel.org,
rananta@google.com, linux-arm-kernel@lists.infradead.org,
linux-kselftest@vger.kernel.org, eric.auger@redhat.com
In-Reply-To: <87wlyhc2g4.wl-maz@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2128 bytes --]
On Wed, 2026-04-08 at 08:54 +0100, Marc Zyngier wrote:
> 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.
What if the guest boots under a new host kernel and finds the group
registers are writable, and then is live migrated to an old host kernel
on which they are not?
What about hibernation, if the *boot* kernel in the guest configures
the groups, but then transfers control back to the resumed guest kernel
which had not?
> So what is this *really* fixing?
I look at that question the other way round.
KVM has an established procedure for allowing userspace to control
guest-visible changes, using the IIDR. First the host kernel which
*supports* the change is rolled out, and only then does the VMM start
to enable it for new launches.
Even if we can address the questions above, and even if we can convince
ourselves that those are the *only* questions to ask... why not follow
the normal, safe, procedure? Especially given that there is already an
IIDR value which corresponds to it.
We don't *have* to YOLO it... and I don't want to :)
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5964 bytes --]
[-- Attachment #2.1: Type: text/plain, Size: 215 bytes --]
Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
[-- Attachment #2.2: Type: text/html, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Jon Hunter @ 2026-04-08 8:42 UTC (permalink / raw)
To: Jason Gunthorpe, Robin Murphy
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
patches, Samiullah Khawaja, stable, Vasant Hegde,
linux-tegra@vger.kernel.org
In-Reply-To: <20260402225121.GI310919@nvidia.com>
Hi Robin, Jason,
On 02/04/2026 23:51, Jason Gunthorpe wrote:
> On Thu, Apr 02, 2026 at 07:11:13PM +0100, Robin Murphy wrote:
>>>> @@ -2714,6 +2714,10 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
>>>> pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
>>>> iova, unmapped_page);
>>>> + /* If the driver itself isn't using the gather, mark it used */
>>>> + if (iotlb_gather->end <= iotlb_gather->start)
>>>> + iommu_iotlb_gather_add_range(&iotlb_gather, iova, unmapped_page);
>>>
>>> The gathers can be joined across unmaps and now we are inviting subtly
>>> ill-formed gathers as only the first unmap will get included.
>
>>> We do have error cases where the gather is legitimately empty, and
>>> this would squash that, it probably needs to check unmapped_page for 0
>>> too, at least.
>>
>> Maybe try looking at the rest of the code around these lines...
>
> Okay, well lets do this one, do you want to send it since it is your
> idea?
Any update on this? Boot is still broken on a couple of our boards.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] Subject: ASoC stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J
From: Tomasz Merta @ 2026-04-08 8:40 UTC (permalink / raw)
To: alsa-devel
Cc: olivier.moysan, arnaud.pouliquen, lgirdwood, broonie, perex,
tiwai, mcoquelin.stm32, alexandre.torgue, linux-stm32,
linux-arm-kernel, linux-kernel, Tomasz Merta, Tomasz Merta
From: Tomasz Merta <tomasz.merta@arrow.com>
The STM32 SAI driver do not set the clock strobing bit (CKSTR) for DSP_A,
DSP_B and LEFT_J formats, causing data to be sampled on the wrong BCLK
edge when SND_SOC_DAIFMT_NB_NF is used.
Per ALSA convention, NB_NF requires sampling on the rising BCLK edge.
The STM32MP25 SAI reference manual states that CKSTR=1 is required for
signals received by the SAI to be sampled on the SCK rising edge.
Without setting CKSTR=1, the SAI samples on the falling edge, violating
the NB_NF convention. For comparison, the NXP FSL SAI driver correctly
sets FSL_SAI_CR2_BCP for DSP_A, DSP_B and LEFT_J, consistent with its
I2S handling.
This patch adds SAI_XCR1_CKSTR for DSP_A, DSP_B and LEFT_J in
stm32_sai_set_dai_fmt which was verified empirically with a cs47l35 codec.
RIGHT_J (LSB) is not investigated and addressed by this patch.
Note: the STM32 I2S driver (stm32_i2s_set_dai_fmt) may have the same issue
for DSP_A mode, as I2S_CGFR_CKPOL is not set. This has not been verified
and is left for a separate investigation.
Signed-off-by: Tomasz Merta <tommerta@gmail.com>
---
sound/soc/stm/stm32_sai_sub.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
index 450e1585edee..3e82fa90e719 100644
--- a/sound/soc/stm/stm32_sai_sub.c
+++ b/sound/soc/stm/stm32_sai_sub.c
@@ -802,6 +802,7 @@ static int stm32_sai_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
break;
/* Left justified */
case SND_SOC_DAIFMT_MSB:
+ cr1 |= SAI_XCR1_CKSTR;
frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSDEF;
break;
/* Right justified */
@@ -809,9 +810,11 @@ static int stm32_sai_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSDEF;
break;
case SND_SOC_DAIFMT_DSP_A:
+ cr1 |= SAI_XCR1_CKSTR;
frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSOFF;
break;
case SND_SOC_DAIFMT_DSP_B:
+ cr1 |= SAI_XCR1_CKSTR;
frcr |= SAI_XFRCR_FSPOL;
break;
default:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: James Clark @ 2026-04-08 8:47 UTC (permalink / raw)
To: Ian Rogers
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, Al Grant,
linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <CAP-5=fXNb50wXT3YH0i=-U8bXwizzH4bv8EL8mC9BMQE0Anp9Q@mail.gmail.com>
On 07/04/2026 7:26 pm, Ian Rogers wrote:
> On Tue, Apr 7, 2026 at 5:35 AM James Clark <james.clark@linaro.org> wrote:
>>
>>
>>
>> On 02/04/2026 4:26 pm, Ian Rogers wrote:
>>> On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
>>>>
>>>> From the TRM [1], N1 has one IMPDEF event which isn't covered by the
>>>> common list. Add a framework so that more cores can be added in the
>>>> future and that the N1 IMPDEF event can be decoded. Also increase the
>>>> size of the buffer because we're adding more strings and if it gets
>>>> truncated it falls back to a hex dump only.
>>>>
>>>> [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
>>>> Suggested-by: Al Grant <al.grant@arm.com>
>>>> Signed-off-by: James Clark <james.clark@linaro.org>
>>>> ---
>>>> tools/perf/util/arm-spe-decoder/Build | 2 +
>>>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
>>>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
>>>> tools/perf/util/arm-spe.c | 13 ++++---
>>>> 4 files changed, 54 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
>>>> index ab500e0efe24..97a298d1e279 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/Build
>>>> +++ b/tools/perf/util/arm-spe-decoder/Build
>>>> @@ -1 +1,3 @@
>>>> perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
>>>> +
>>>> +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
>>>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> index c880b0dec3a1..42a7501d4dfe 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> @@ -15,6 +15,8 @@
>>>>
>>>> #include "arm-spe-pkt-decoder.h"
>>>>
>>>> +#include "../../arm64/include/asm/cputype.h"
>>>
>>> Sashiko spotted:
>>> https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
>>> """
>>> This isn't a bug, but does this include directive rely on accidental
>>> path normalization?
>>>
>>> The relative path ../../arm64/include/asm/cputype.h does not exist relative
>>> to arm-spe-pkt-decoder.c. It only compiles because the Build file adds
>>> -I$(srctree)/tools/arch/arm64/include/ to CFLAGS.
>>>
>>> Would it be cleaner to use #include <asm/cputype.h> to explicitly rely on
>>> the include path?
>>> [ ... ]
>>> """
>>> I wouldn't use <asm/cputype.h> due to cross-compilation and the like,
>>> instead just add the extra "../" into the include path.
>>>
>>
>> Do you mean change the #include to this?
>>
>> #include "../../../arm64/include/asm/cputype.h"
>>
>> I still need to add:
>>
>> CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/
>>
>> To make the this include in cputype.h work:
>>
>> #include <asm/sysreg.h>
>>
>> Which probably only works because there isn't a sysreg.h on other
>> architectures. But I'm not sure what the significance of ../../ vs
>> ../../../ is if either compile? arm-spe.c already does it with ../../
>> which is what I copied.
>
> Hmm.. maybe the path should be
> "../../../arch/arm64/include/asm/cputype.h". The include preference is
> for a path relative to the source file and
> ../../arm64/include/asm/cputype.h doesn't exist. It is kind of horrid
Up 3 dirs from arm-spe-pkt-decoder.c would be
"tools/arm64/include/asm/cputype.h" which doesn't exist either unless
I'm missing something?
If get the compiler to print the path it uses with 3 then it would use
the x86 uapi include path which doesn't seem any less weird to me:
...
In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.c:19:
linux/tools/arch/x86/include/uapi/../../../arm64/include/asm/cputype.h:254:10:
> to add an include path and then use a relative path to escape into a
> higher-level directory. arm-spe.c is a little different as it is one
> directory higher in the directory layout.
>
It is one folder higher, but arm-spe.c still relies on adding a special
include path to CFLAGS_arm-spe.o to make it work. It's not including a
real path relative to the source either.
Yeah it's a bit horrible but I don't think the asm/ thing combined with
copying headers from the kernel to tools expected to handle the case
where we would want to use asm/ stuff for a different arch than the
compile one. It might not be normal to use relative include paths to
escape to higher directories, but it's not a normal situation either. I
think it's a special case for a special scenario. I'm not sure of a
better way, but this is working for now.
> Thanks,
> Ian
>
>>>> +
>>>> static const char * const arm_spe_packet_name[] = {
>>>> [ARM_SPE_PAD] = "PAD",
>>>> [ARM_SPE_END] = "END",
>>>> @@ -307,6 +309,11 @@ static const struct ev_string common_ev_strings[] = {
>>>> { .event = 0, .desc = NULL },
>>>> };
>>>>
>>>> +static const struct ev_string n1_event_strings[] = {
>>>> + { .event = 12, .desc = "LATE-PREFETCH" },
>>>> + { .event = 0, .desc = NULL },
>>>> +};
>>>> +
>>>> static u64 print_event_list(int *err, char **buf, size_t *buf_len,
>>>> const struct ev_string *ev_strings, u64 payload)
>>>> {
>>>> @@ -318,14 +325,44 @@ static u64 print_event_list(int *err, char **buf, size_t *buf_len,
>>>> return payload;
>>>> }
>>>>
>>>> +struct event_print_handle {
>>>> + const struct midr_range *midr_ranges;
>>>> + const struct ev_string *ev_strings;
>>>> +};
>>>> +
>>>> +#define EV_PRINT(range, strings) \
>>>> + { \
>>>> + .midr_ranges = range, \
>>>> + .ev_strings = strings, \
>>>> + }
>>>> +
>>>> +static const struct midr_range n1_event_encoding_cpus[] = {
>>>> + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
>>>> + {},
>>>> +};
>>>> +
>>>> +static const struct event_print_handle event_print_handles[] = {
>>>> + EV_PRINT(n1_event_encoding_cpus, n1_event_strings),
>>>> +};
>>>> +
>>>> static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
>>>> - char *buf, size_t buf_len)
>>>> + char *buf, size_t buf_len, u64 midr)
>>>> {
>>>> u64 payload = packet->payload;
>>>> int err = 0;
>>>>
>>>> arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
>>>> - print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
>>>> + payload = print_event_list(&err, &buf, &buf_len, common_ev_strings,
>>>> + payload);
>>>> +
>>>> + /* Try to decode IMPDEF bits for known CPUs */
>>>> + for (unsigned int i = 0; i < ARRAY_SIZE(event_print_handles); i++) {
>>>> + if (is_midr_in_range_list(midr,
>>>> + event_print_handles[i].midr_ranges))
>>>> + payload = print_event_list(&err, &buf, &buf_len,
>>>> + event_print_handles[i].ev_strings,
>>>> + payload);
>>>> + }
>>>>
>>>> return err;
>>>> }
>>>> @@ -506,7 +543,7 @@ static int arm_spe_pkt_desc_counter(const struct arm_spe_pkt *packet,
>>>> }
>>>>
>>>> int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
>>>> - size_t buf_len)
>>>> + size_t buf_len, u64 midr)
>>>> {
>>>> int idx = packet->index;
>>>> unsigned long long payload = packet->payload;
>>>> @@ -522,7 +559,7 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
>>>> arm_spe_pkt_out_string(&err, &buf, &blen, "%s", name);
>>>> break;
>>>> case ARM_SPE_EVENTS:
>>>> - err = arm_spe_pkt_desc_event(packet, buf, buf_len);
>>>> + err = arm_spe_pkt_desc_event(packet, buf, buf_len, midr);
>>>> break;
>>>> case ARM_SPE_OP_TYPE:
>>>> err = arm_spe_pkt_desc_op_type(packet, buf, buf_len);
>>>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> index adf4cde320aa..17b067fe3c87 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> @@ -11,7 +11,7 @@
>>>> #include <stddef.h>
>>>> #include <stdint.h>
>>>>
>>>> -#define ARM_SPE_PKT_DESC_MAX 256
>>>> +#define ARM_SPE_PKT_DESC_MAX 512
>>>>
>>>> #define ARM_SPE_NEED_MORE_BYTES -1
>>>> #define ARM_SPE_BAD_PACKET -2
>>>> @@ -186,5 +186,6 @@ const char *arm_spe_pkt_name(enum arm_spe_pkt_type);
>>>> int arm_spe_get_packet(const unsigned char *buf, size_t len,
>>>> struct arm_spe_pkt *packet);
>>>>
>>>> -int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len);
>>>> +int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len,
>>>> + u64 midr);
>>>> #endif
>>>> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
>>>> index 7447b000f9cd..46f0309c092b 100644
>>>> --- a/tools/perf/util/arm-spe.c
>>>> +++ b/tools/perf/util/arm-spe.c
>>>> @@ -135,7 +135,7 @@ struct data_source_handle {
>>>> }
>>>>
>>>> static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> - unsigned char *buf, size_t len)
>>>> + unsigned char *buf, size_t len, u64 midr)
>>>> {
>>>> struct arm_spe_pkt packet;
>>>> size_t pos = 0;
>>>> @@ -161,7 +161,7 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> color_fprintf(stdout, color, " ");
>>>> if (ret > 0) {
>>>> ret = arm_spe_pkt_desc(&packet, desc,
>>>> - ARM_SPE_PKT_DESC_MAX);
>>>> + ARM_SPE_PKT_DESC_MAX, midr);
>>>> if (!ret)
>>>> color_fprintf(stdout, color, " %s\n", desc);
>>>> } else {
>>>> @@ -174,10 +174,10 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> }
>>>>
>>>> static void arm_spe_dump_event(struct arm_spe *spe, unsigned char *buf,
>>>> - size_t len)
>>>> + size_t len, u64 midr)
>>>> {
>>>> printf(".\n");
>>>> - arm_spe_dump(spe, buf, len);
>>>> + arm_spe_dump(spe, buf, len, midr);
>>>> }
>>>>
>>>> static int arm_spe_get_trace(struct arm_spe_buffer *b, void *data)
>>>> @@ -1469,8 +1469,11 @@ static int arm_spe_process_auxtrace_event(struct perf_session *session,
>>>> /* Dump here now we have copied a piped trace out of the pipe */
>>>> if (dump_trace) {
>>>> if (auxtrace_buffer__get_data(buffer, fd)) {
>>>> + u64 midr = 0;
>>>> +
>>>> + arm_spe__get_midr(spe, buffer->cpu.cpu, &midr);
>>>
>>> Sashiko claims to have spotted an issue here:
>>> """
>>> Is it possible for arm_spe__get_midr() to cause a segmentation fault here?
>>>
>>> If the trace is from an older recording (metadata version 1) and the
>>> environment lacks a CPUID string (such as during cross-architecture
>>> analysis), perf_env__cpuid() returns NULL.
>>>
>>> It appears arm_spe__get_midr() then passes this NULL pointer to
>>> strtol(cpuid, NULL, 16), which leads to undefined behavior.
>>> """
>>>
>>> But this feels like, if this happens you're already having a bad time
>>> and these changes aren't necessarily making things worse.
>>>
>>> Thanks,
>>> Ian
>>>
>>
>> Yeah I think it might be possible so I can add an error instead of a
>> segfault. I'll check the rest of the Sashiko comments too.
>>
>>>> arm_spe_dump_event(spe, buffer->data,
>>>> - buffer->size);
>>>> + buffer->size, midr);
>>>> auxtrace_buffer__put_data(buffer);
>>>> }
>>>> }
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>
^ 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