* RE: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to flattened model
From: Peng Fan @ 2026-04-23 12:07 UTC (permalink / raw)
To: Xu Yang, Frank Li
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Jun Li
In-Reply-To: <cfyvip6atz6hh57iga5gvkzrdxeorv4tuxontvzixflqn36h7h@2awtzkxkn45c>
> Subject: Re: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to
> flattened model
>
> On Tue, Apr 21, 2026 at 11:53:12PM -0400, Frank Li wrote:
> > On Tue, Apr 21, 2026 at 06:55:01PM +0800, Xu Yang wrote:
> > > Switch to use flattened model for USB3 controller. To enable USB
> > > controller with restricted DMA access range to work correctly, add
> a
> > > pseudo simple-bus to constrain the dma address.
> >
> > i.mx95 should fix >4G dma space's problem. Does it impact other no-
> nxp
> > boards?
>
> Yes, i.MX95 has fixed >3G address DMA access problem.
>
> It's another issue. HSIO domain only support 36 bit bus access. If not
> use smmu, no any issue. If use smmu, it will allocate memory space of
> 36 bit < iova < 48bit.
> HSIO can't handle this case.
If using smmu, iova will be in range {36bit, 48bit}? How?
Thanks
Peng
>
> >
> > Need do break compatible judgement such as
> >
> > i.MX95 is new SoC and still is heave development. The break
> compatible
> > is accepable at development early phase.
> >
> > You can rephrase it.
>
> OK.
>
> Thanks,
> Xu Yang
^ permalink raw reply
* Re: [PATCH] arm64: smp: Limit nr_cpu_ids under nosmp
From: zhangpengjie (A) @ 2026-04-23 12:05 UTC (permalink / raw)
To: Catalin Marinas
Cc: will, maz, timothy.hayes, lpieralisi, mrigendra.chaubey, arnd,
linux-arm-kernel, linux-kernel, zhanjie9, zhenglifeng1, lihuisong,
yubowen8, linhongye, linuxarm, wangzhi12
In-Reply-To: <aekCUnZAE8bSfNfO@arm.com>
Hi Catalin,
On 4/23/2026 1:16 AM, Catalin Marinas wrote:
> On Wed, Apr 22, 2026 at 05:58:31PM +0800, Pengjie Zhang wrote:
>> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>>
>> However, arm64 still enumerates firmware-described CPUs during SMP
>> initialization, so secondary CPUs can remain visible to
>> for_each_possible_cpu() users even though they never reach the
>> bringup path in this configuration.
>>
>> This is not just a cosmetic mask mismatch: code iterating over
>> possible CPUs may observe secondary CPU per-CPU state that is never
>> fully initialized under nosmp.
>>
>> Limit nr_cpu_ids to 1 in arch_disable_smp_support() so that
>> secondary CPUs are not set up on arm64 when nosmp/maxcpus=0 is in
>> effect.
>>
>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>> ---
>> arch/arm64/kernel/smp.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 1aa324104afb..cc34c68871e9 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -435,6 +435,15 @@ static void __init hyp_mode_check(void)
>> }
>> }
>>
>> +void __init arch_disable_smp_support(void)
>> +{
>> + /*
>> + * Under nosmp/maxcpus=0, only the boot CPU can ever be brought up.
>> + * Limit nr_cpu_ids so that secondary CPUs are never set up.
>> + */
>> + set_nr_cpu_ids(1);
>> +}
> I don't think that's the right fix. We don't have anything like the x86
> ioapic to disable in this function, so no need to implement it. If
> nr_cpu_ids must be 1 with nosmp/maxcpus=0, I'd rather do this in the
> generic code. It need some alignment with other architectures if we are
> to do this early. IOW, is nosmp equivalent to nr_cpus=1?
>
> In the meantime, for arm64, we can do something like below and let the
> generic code set nr_cpu_ids() via start_kernel() -> setup_nr_cpu_ids().
Thanks for the review. I completely agree with your assessment.
My initial thought was to consolidate the nosmp logic in one place,
but you are right—using `arch_disable_smp_support()` here is indeed
an abuse of the callback, as arm64 doesn't have SMP-specific hardware
to tear down like the x86 IOAPIC.
My main concern was specifically that under nosmp/maxcpus=0, secondary
CPUs can still remain visible to `for_each_possible_cpu()` users on
arm64, even though they will never reach the bringup path.
Regarding your question on whether `nosmp` is equivalent to `nr_cpus=1`:
practically, they both result in a uniprocessor system, but historically
they take different paths (`setup_max_cpus=0` vs early `nr_cpu_ids=1`).
Unifying this globally in generic code would indeed require a broader
cross-arch discussion, so your arm64-specific mitigation is the best
way forward right now.
Your proposed alternative in `smp_init_cpus()` is elegant and solves
the mask mismatch perfectly.
I will spin up a v2 incorporating your snippet and will add a
`Suggested-by` tag for you.
Thanks,
Pengjie
> -------------8<-------------------
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 1aa324104afb..7364481cc03a 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -754,6 +754,13 @@ void __init smp_init_cpus(void)
> return;
> }
>
> + /*
> + * For the nosmp/maxcpus=0 case, do not mark the secondary CPUs
> + * possible.
> + */
> + if (!setup_max_cpus)
> + return;
> +
> /*
> * We need to set the cpu_logical_map entries before enabling
> * the cpus so that cpu processor description entries (DT cpu nodes
>
>
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-23 10:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <161eb29f-2d07-455a-bd74-4f22061b5dfb@kernel.org>
On 4/23/26 11:26 AM, Krzysztof Kozlowski wrote:
> On 23/04/2026 01:33, Marek Vasut wrote:
>> On 4/21/26 10:02 AM, Krzysztof Kozlowski wrote:
>>> On Thu, Apr 16, 2026 at 01:31:40AM +0200, Marek Vasut wrote:
>>>> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
>>>>
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>>>> ---
>>>> Cc: Conor Dooley <conor+dt@kernel.org>
>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>>>> Cc: Magnus Damm <magnus.damm@gmail.com>
>>>> Cc: Michael Turquette <mturquette@baylibre.com>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: Stephen Boyd <sboyd@kernel.org>
>>>> Cc: devicetree@vger.kernel.org
>>>> Cc: linux-clk@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>> ---
>>>> V2: Add ztr/zt clock at the end of the list to match bindings
>>>> ---
>>>> arch/arm/boot/dts/renesas/r8a7740.dtsi | 2 +-
>>>
>>>> include/dt-bindings/clock/r8a7740-clock.h | 2 ++
>>>
>>> This goes to the binding patch.
>>>
>>> Didn't you have also a checkpatch warning?
>> I only got this warning, but the docs 1/4 and includes 3/4 are a
>> separate patch in this series:
>>
>> "
>> WARNING: DT binding docs and includes should be a separate patch. See:
>> Documentation/devicetree/bindings/submitting-patches.rst
>
> So you did not implement it... Include goes with the binding. Always.
> Look at other commits.
The warning says the exact opposite thing , does it not ?
Maybe the warning text needs to be updated ?
^ permalink raw reply
* [GIT PULL] soc: late changes for 7.1
From: Arnd Bergmann @ 2026-04-23 12:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: soc, linux-kernel, linux-arm-kernel
The following changes since commit 8242c709d4ba858c483ef7ef3cc2dc1280f5383c:
Merge tag 'soc-arm-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc (2026-04-16 20:45:14 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc-late-7.1
for you to fetch changes up to dd5dc1917473f398949b95f6b77c60d4d8eb1d97:
Merge tag 'amlogic-fixes-v7.1-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/late2 (2026-04-23 10:02:27 +0200)
----------------------------------------------------------------
soc: late changes for 7.1
These are the contents that arrived during the easter vacation and didn't
make it into the last 7.0 bugfixes or the first set of branches for the
merge window. Aside from a reset controller bugfix and an update to the
MAINTAINERS entry, this is all devicetree changes.
The Marvell devicetree updates contain the usual minor updates and bugfixes,
along with a two larger but trivial patches to drop unused dtsi files,
the single broadcom fix addresses a build time warning introduced during
the merge window.
The freescale, amlogic, and apple changes missed the last fixes branch
for 7.0.
----------------------------------------------------------------
Anand Moon (1):
arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0
Arnd Bergmann (5):
Merge branch 'arm/fixes' into soc/late2
Merge tag 'mvebu-dt64-7.1-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/late2
ARM: dts: bcm4709: fix bus range assignment
Merge tag 'apple-soc-fixes-7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into soc/late2
Merge tag 'amlogic-fixes-v7.1-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/late2
Axel Flordal (1):
arm64: dts: apple: Fix spelling error
Elad Nachman (3):
arm64: dts: a7k: use phy handle
dt-bindings: arm64: add Marvell 7k COMe boards
dt-bindings: arm64: add Marvell 7k COMe boards
Gabor Juhos (6):
arm64: dts: marvell: armada-3720: drop 'marvell,xenon-emmc' properties
arm64: dts: marvell: armada-37xx: align 'phy-names' of EHCI node with DT schema
arm64: dts: marvell: armada-37xx: drop redundant status property
arm64: dts: marvell: armada-37xx: drop 'marvell,usb-misc-reg' from USB host nodes
arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
Geert Uytterhoeven (1):
arm64: dts: amlogic: s6: Drop CPU masks from GICv3 PPI interrupts
Jun Yan (1):
arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
Krzysztof Kozlowski (5):
Merge tag 'imx-fixes-7.0-2nd' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes
Merge tag 'reset-fixes-for-v7.0-3' of https://git.pengutronix.de/git/pza/linux into arm/fixes
Merge tag 'mvebu-fixes-7.0-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes
Documentation/process: maintainer-soc: Trim from trivial ask-DT
Documentation/process: maintainer-soc: Document purpose of defconfigs
Nick Xie (2):
arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
arm64: dts: amlogic: t7: khadas-vim4: fix board model name
Peng Fan (14):
arm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-navqp: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-edm-g: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-aristainetos3a-som-v1: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-nitrogen-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-ultra-mach-sbc: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
Rob Herring (Arm) (1):
arm/arm64: dts: marvell: Drop unused .dtsi
Robert Marko (1):
arm64: dts: marvell: uDPU: add ethernet aliases
Ronald Claveau (2):
reset: amlogic: t7: Fix null reset ops
arm64: dts: amlogic: Fix GIC register ranges for Amlogic T7
Sasha Finkelstein (2):
mailmap: Update Sasha Finkelstein's email address
dt-bindings: Update Sasha Finkelstein's email address
.mailmap | 1 +
.../bindings/arm/marvell/armada-7k-8k.yaml | 11 ++
.../display/apple,h7-display-pipe-mipi.yaml | 2 +-
.../bindings/display/apple,h7-display-pipe.yaml | 2 +-
.../bindings/display/panel/apple,summit.yaml | 2 +-
.../devicetree/bindings/gpu/apple,agx.yaml | 2 +-
.../input/touchscreen/apple,z2-multitouch.yaml | 2 +-
.../bindings/nvmem/apple,spmi-nvmem.yaml | 2 +-
.../devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 2 +-
.../devicetree/bindings/spmi/apple,spmi.yaml | 2 +-
Documentation/process/maintainer-soc.rst | 12 +-
MAINTAINERS | 2 +-
.../boot/dts/broadcom/bcm4709-netgear-r8000.dts | 1 -
arch/arm/boot/dts/marvell/armada-380.dtsi | 148 ---------------------
arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi | 10 +-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 6 +-
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 4 +-
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 +
.../boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 +-
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
.../arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 +-
.../arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
.../arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
.../freescale/imx8mp-aristainetos3a-som-v1.dtsi | 2 +-
.../dts/freescale/imx8mp-data-modul-edm-sbc.dts | 2 +-
.../boot/dts/freescale/imx8mp-debix-model-a.dts | 2 +-
.../dts/freescale/imx8mp-debix-som-a-bmb-08.dts | 2 +-
.../boot/dts/freescale/imx8mp-debix-som-a.dtsi | 2 +-
.../arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi | 2 +-
.../boot/dts/freescale/imx8mp-icore-mx8mp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-navqp.dts | 2 +-
.../boot/dts/freescale/imx8mp-nitrogen-som.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi | 4 +-
.../boot/dts/freescale/imx8mp-ultra-mach-sbc.dts | 4 +-
.../boot/dts/marvell/armada-3720-atlas-v5.dts | 1 -
.../boot/dts/marvell/armada-3720-espressobin.dtsi | 1 -
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 7 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 9 +-
.../boot/dts/marvell/armada-7020-comexpress.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-8020.dtsi | 20 ---
.../boot/dts/marvell/cn9130-db-comexpress.dtsi | 96 -------------
drivers/reset/amlogic/reset-meson.c | 1 +
43 files changed, 81 insertions(+), 314 deletions(-)
delete mode 100644 arch/arm/boot/dts/marvell/armada-380.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi
diff --git a/.mailmap b/.mailmap
index 7d6fb567ba5e..74cc837befef 100644
--- a/.mailmap
+++ b/.mailmap
@@ -741,6 +741,7 @@ Sarangdhar Joshi <spjoshi@codeaurora.org>
Saravana Kannan <saravanak@kernel.org> <skannan@codeaurora.org>
Saravana Kannan <saravanak@kernel.org> <saravanak@google.com>
Sascha Hauer <s.hauer@pengutronix.de>
+Sasha Finkelstein <k@chaosmail.tech> <fnkl.kernel@gmail.com>
Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
Satya Priya <quic_skakitap@quicinc.com> <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index 4bc7454a5d3a..7e77310da626 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -21,6 +21,17 @@ properties:
- const: marvell,armada-ap806-dual
- const: marvell,armada-ap806
+ - description:
+ Falcon (DB-98CX85x0) Development board COM Express Carrier plus
+ Armada 7020 SoC COM Express CPU module
+ items:
+ - const: marvell,armada7020-falcon-carrier
+ - const: marvell,db-falcon-carrier
+ - const: marvell,armada7020-cpu-module
+ - const: marvell,armada7020
+ - const: marvell,armada-ap806-dual
+ - const: marvell,armada-ap806
+
- description: Armada 7040 SoC
items:
- enum:
diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
index 5e6da66499a5..d7c822df8a94 100644
--- a/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
+++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple pre-DCP display controller MIPI interface
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description:
The MIPI controller part of the pre-DCP Apple display controller
diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
index 102fb1804c0c..571fa32db2cf 100644
--- a/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
+++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple pre-DCP display controller
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description:
A secondary display controller used to drive the "touchbar" on
diff --git a/Documentation/devicetree/bindings/display/panel/apple,summit.yaml b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
index f081755325e9..1c1ba59467f3 100644
--- a/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
+++ b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple "Summit" display panel
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description:
An OLED panel used as a touchbar on certain Apple laptops.
diff --git a/Documentation/devicetree/bindings/gpu/apple,agx.yaml b/Documentation/devicetree/bindings/gpu/apple,agx.yaml
index 05af942ad174..59989d8bd1cb 100644
--- a/Documentation/devicetree/bindings/gpu/apple,agx.yaml
+++ b/Documentation/devicetree/bindings/gpu/apple,agx.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple SoC GPU
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
index 402ca6bffd34..44158e89e818 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple touchscreens attached using the Z2 protocol
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description: A series of touschscreen controllers used in Apple products
diff --git a/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
index 80b5a6cdcec9..4ca75ed07a54 100644
--- a/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
@@ -9,7 +9,7 @@ title: Apple SPMI NVMEM
description: Exports a series of SPMI registers as NVMEM cells
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
allOf:
- $ref: nvmem.yaml#
diff --git a/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
index 04519b0c581d..d8f4f9ffe884 100644
--- a/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
@@ -8,7 +8,7 @@ title: Apple FPWM controller
maintainers:
- asahi@lists.linux.dev
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description: PWM controller used for keyboard backlight on ARM Macs
diff --git a/Documentation/devicetree/bindings/spmi/apple,spmi.yaml b/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
index ba524f1eb704..3e5b14bc8c31 100644
--- a/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
+++ b/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple SPMI controller
maintainers:
- - Sasha Finkelstein <fnkl.kernel@gmail.com>
+ - Sasha Finkelstein <k@chaosmail.tech>
description: A SPMI controller present on most Apple SoCs
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 7d6bad989ad8..a3a90a7d4c68 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -169,8 +169,6 @@ more information on the validation of devicetrees.
For new platforms, or additions to existing ones, ``make dtbs_check`` should not
add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
required to not add any new warnings.
-If in any doubt about a devicetree change, reach out to the devicetree
-maintainers.
Branches and Pull Requests
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -209,3 +207,13 @@ The subject line of a pull request should begin with "[GIT PULL]" and made using
a signed tag, rather than a branch. This tag should contain a short description
summarising the changes in the pull request. For more detail on sending pull
requests, please see Documentation/maintainer/pull-requests.rst.
+
+Defconfigs purpose
+~~~~~~~~~~~~~~~~~~
+
+Defconfigs are primarily used by the kernel developers, because distros have
+their own configs. A change adding new CONFIG options to a defconfig should
+explain why the kernel developers in general would want such option, e.g. by
+providing a name of an upstream-supported machine/board using that new option.
+This implies that enabling options in defconfig for non-upstream machines shall
+not be accepted.
diff --git a/MAINTAINERS b/MAINTAINERS
index d41dc26280b1..71f6968fa695 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8691,7 +8691,7 @@ F: include/linux/host1x.h
F: include/uapi/drm/tegra_drm.h
DRM DRIVERS FOR PRE-DCP APPLE DISPLAY OUTPUT
-M: Sasha Finkelstein <fnkl.kernel@gmail.com>
+M: Sasha Finkelstein <k@chaosmail.tech>
R: Janne Grunau <j@jannau.net>
L: dri-devel@lists.freedesktop.org
L: asahi@lists.linux.dev
diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
index d170c71cbd76..e85693fba16a 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
@@ -139,7 +139,6 @@ &pcie_bridge1 {
pcie@0,0 {
device_type = "pci";
reg = <0x0000 0 0 0 0>;
- bus-range = <0x01 0xff>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/arch/arm/boot/dts/marvell/armada-380.dtsi b/arch/arm/boot/dts/marvell/armada-380.dtsi
deleted file mode 100644
index e94f22b0e9b5..000000000000
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
index 8ef631939033..ab3acef2b147 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
@@ -53,10 +53,10 @@ pwrc: power-controller {
timer {
compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
};
psci {
@@ -84,7 +84,7 @@ gic: interrupt-controller@ff200000 {
interrupt-controller;
reg = <0x0 0xff200000 0 0x10000>,
<0x0 0xff240000 0 0x80000>;
- interrupts = <GIC_PPI 9 0xf04>;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
apb: bus@fe000000 {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index fffdab96b12e..f4c953034be3 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -8,7 +8,7 @@
#include "amlogic-t7.dtsi"
/ {
- model = "Khadas vim4";
+ model = "Khadas VIM4";
compatible = "khadas,vim4", "amlogic,a311d2", "amlogic,t7";
aliases {
@@ -17,7 +17,9 @@ aliases {
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x2 0x0>; /* 8 GB */
+ reg = <0x0 0x0 0x0 0xE0000000
+ 0x1 0x0 0x0 0xE0000000
+ 0x2 0x0 0x0 0x40000000>; /* 8 GB */
};
reserved-memory {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 6510068bcff9..d523cbc0ed22 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -213,7 +213,9 @@ gic: interrupt-controller@fff01000 {
#address-cells = <0>;
interrupt-controller;
reg = <0x0 0xfff01000 0 0x1000>,
- <0x0 0xfff02000 0 0x0100>;
+ <0x0 0xfff02000 0 0x2000>,
+ <0x0 0xfff04000 0 0x2000>,
+ <0x0 0xfff06000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index cc72491eaf6f..f1f53fd98ae2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -72,6 +72,12 @@ cpu0: cpu@0 {
compatible = "arm,cortex-a53";
reg = <0x0 0x0>;
enable-method = "psci";
+ d-cache-line-size = <32>;
+ d-cache-size = <0x8000>;
+ d-cache-sets = <32>;
+ i-cache-line-size = <32>;
+ i-cache-size = <0x8000>;
+ i-cache-sets = <32>;
next-level-cache = <&l2>;
clocks = <&scpi_dvfs 0>;
dynamic-power-coefficient = <140>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index 7dffeb5931c9..701de57ff0f3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -84,7 +84,8 @@ external_phy: ethernet-phy@0 {
reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
interrupt-parent = <&gpio_intc>;
- interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ /* MAC_INTR on GPIOZ_15 */
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
eee-broken-1000t;
};
};
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
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
index 67d22d3768aa..507d1824d99d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
@@ -60,7 +60,7 @@ pmic@25 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
regulators {
buck1: BUCK1 {
@@ -194,7 +194,7 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
pinctrl_pmic: emtop-pmic-grp {
fsl,pins = <
- MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x141
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
index 29b298af0d73..1b5ba3c47164 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
@@ -292,7 +292,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x94>;
+ fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1d4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
index 31a3ca137e63..48a687926aa1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
@@ -283,7 +283,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x84>;
+ fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1c4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi
index f654d866e58c..e7666e54310b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi
@@ -903,7 +903,7 @@ MX8MP_IOMUXC_SAI1_MCLK__GPIO4_IO20 0x41
pinctrl_pmic: aristainetos3-pmic-grp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
index 7e46537a22a0..cb28cf1cdd23 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts
@@ -1001,7 +1001,7 @@ MX8MP_IOMUXC_SAI3_RXFS__AUDIOMIX_PDM_BIT_STREAM00 0x0
pinctrl_pmic: pmic-grp {
fsl,pins = <
/* PMIC_nINT */
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x40000090
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
index 9422beee30b2..201cf7f5eb0e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
@@ -440,7 +440,7 @@ MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c3
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
index 04619a722906..1471ff361b54 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts
@@ -499,7 +499,7 @@ MX8MP_IOMUXC_SAI1_RXD1__GPIO4_IO03 0x140
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi
index 91094c227744..b31e8fe95ca7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi
@@ -241,7 +241,7 @@ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
index f8303b7e2bd2..0a6a60670f76 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
@@ -989,7 +989,7 @@ MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20 0x22
pinctrl_pmic: dhcom-pmic-grp {
fsl,pins = <
/* PMIC_nINT */
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x40000090
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi
index 3f1e0837f349..91b87a7248dd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi
@@ -563,7 +563,7 @@ MX8MP_IOMUXC_GPIO1_IO01__GPIO1_IO01 0x41 /* PCIE RST */
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi
index a6319824ea2e..69558ffefa9a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi
@@ -132,7 +132,7 @@ MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c3
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x41
+ MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
index 4a4f7c1adc23..9dedb9f11145 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
@@ -356,7 +356,7 @@ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi
index f658309612ef..8465b36d440a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi
@@ -296,7 +296,7 @@ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
- MX8MP_IOMUXC_NAND_ALE__GPIO3_IO00 0x41
+ MX8MP_IOMUXC_NAND_ALE__GPIO3_IO00 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
index 3cdb0bc0ab72..c3f7daa773ea 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi
@@ -174,7 +174,7 @@ pmic: pmic@25 {
pinctrl-0 = <&pmic_pins>;
pinctrl-names = "default";
interrupt-parent = <&gpio1>;
- interrupts = <3 GPIO_ACTIVE_LOW>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
nxp,i2c-lt-enable;
regulators {
@@ -417,7 +417,7 @@ MX8MP_IOMUXC_SAI1_RXD1__GPIO4_IO03 0x160
pmic_pins: pinctrl-pmic-grp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0
>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts b/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts
index 9ecec1a41878..3e6f9c88cc20 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts
@@ -275,7 +275,7 @@ pmic@25 {
reg = <0x25>;
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 GPIO_ACTIVE_LOW>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
/*
* i.MX 8M Plus Data Sheet for Consumer Products
@@ -739,7 +739,7 @@ MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07 0x40 /* NFC_INT */
pinctrl_pmic: pmic-grp {
fsl,pins = <
- MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x40 /* #PMIC_INT */
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x1c0 /* #PMIC_INT */
>;
};
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts b/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts
index 070d10a705bb..a313d5687789 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts
@@ -82,7 +82,6 @@ &sdhci0 {
mmc-ddr-1_8v;
mmc-hs400-1_8v;
sd-uhs-sdr104;
- marvell,xenon-emmc;
marvell,xenon-tun-count = <9>;
marvell,pad-type = "fixed-1-8v";
vqmmc-supply = <&vsdc_reg>;
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
index fed2dcecb323..37e16fb3a383 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
@@ -78,7 +78,6 @@ &sdhci0 {
bus-width = <8>;
mmc-ddr-1_8v;
mmc-hs400-1_8v;
- marvell,xenon-emmc;
marvell,xenon-tun-count = <9>;
marvell,pad-type = "fixed-1-8v";
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
index 242820845707..12deacb741cc 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
@@ -15,6 +15,11 @@
#include "armada-372x.dtsi"
/ {
+ aliases {
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -156,7 +161,7 @@ ð1 {
&usb3 {
status = "okay";
phys = <&usb2_utmi_otg_phy>;
- phy-names = "usb2-utmi-otg-phy";
+ phy-names = "usb2-phy";
};
&uart0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 87f9367aec12..360fc24fdde2 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -369,11 +369,10 @@ usb3: usb@58000 {
compatible = "marvell,armada3700-xhci",
"generic-xhci";
reg = <0x58000 0x4000>;
- marvell,usb-misc-reg = <&usb32_syscon>;
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&sb_periph_clk 12>;
- phys = <&comphy0 0>, <&usb2_utmi_otg_phy>;
- phy-names = "usb3-phy", "usb2-utmi-otg-phy";
+ phys = <&usb2_utmi_otg_phy>, <&comphy0 0>;
+ phy-names = "usb2-phy", "usb3-phy";
status = "disabled";
};
@@ -393,10 +392,9 @@ usb32_syscon: system-controller@5d800 {
usb2: usb@5e000 {
compatible = "marvell,armada-3700-ehci";
reg = <0x5e000 0x1000>;
- marvell,usb-misc-reg = <&usb2_syscon>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usb2_utmi_host_phy>;
- phy-names = "usb2-utmi-host-phy";
+ phy-names = "usb";
status = "disabled";
};
@@ -534,7 +532,6 @@ firmware {
armada-3700-rwtm {
compatible = "marvell,armada-3700-rwtm-firmware";
mboxes = <&rwtm 0>;
- status = "okay";
};
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi b/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi
index 2b5ec4a451e3..0cfcf5f6bde1 100644
--- a/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-7020-comexpress.dtsi
@@ -70,7 +70,7 @@ &cp0_eth0 {
&cp0_eth1 {
status = "okay";
- phy = <&phy0>;
+ phy-handle = <&phy0>;
phy-mode = "rgmii-id";
};
diff --git a/arch/arm64/boot/dts/marvell/armada-8020.dtsi b/arch/arm64/boot/dts/marvell/armada-8020.dtsi
deleted file mode 100644
index b6fc18876093..000000000000
diff --git a/arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi b/arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi
deleted file mode 100644
index 028496ebc473..000000000000
diff --git a/drivers/reset/amlogic/reset-meson.c b/drivers/reset/amlogic/reset-meson.c
index 84610365a823..c303e8590dd6 100644
--- a/drivers/reset/amlogic/reset-meson.c
+++ b/drivers/reset/amlogic/reset-meson.c
@@ -42,6 +42,7 @@ static const struct meson_reset_param meson_s4_param = {
};
static const struct meson_reset_param t7_param = {
+ .reset_ops = &meson_reset_ops,
.reset_num = 224,
.reset_offset = 0x0,
.level_offset = 0x40,
^ permalink raw reply related
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-23 11:48 UTC (permalink / raw)
To: Mathias Stearn, Peter Zijlstra
Cc: Mathieu Desnoyers, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, Dmitry Vyukov, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Mark Rutland,
Jinjie Ruan, Blake Oler
In-Reply-To: <CAHnCjA2fa+dP1+yCYNQrTXQaW-JdtfMj7wMikwMeeCRg-3NhiA@mail.gmail.com>
On Thu, Apr 23 2026 at 11:24, Mathias Stearn wrote:
> On Wed, Apr 22, 2026 at 3:13 PM Peter Zijlstra <peterz@infradead.org> wrote:
> To make this more concrete, I am proposing adding
>
> unsafe_put_user((u32)task_cpu(t), &t->rseq.usrptr->cpu_id_start, efault);
>
> after each place where you currently do
>
> unsafe_put_user(0ULL, &t->rseq.usrptr->rseq_cs, efault);
>
> in rseq_update_user_cs. Is that something that you would expect to cause a
> performance issue?
That would work and not bring the performance issues back, but:
1) Did you validate that adding the reset into rseq_update_user_cs() is
actually sufficient?
If adding it to rseq_update_user_cs() is not sufficient, then we
have a really serious problem. Because we'd need to go back and do
it unconditionally, which then makes the 15% performance
regression, which happened when glibc enabled rseq, come back
instantaneously. And in that case the damage for tcmalloc() is the
lesser of two evils.
2) The tcmalloc abuse breaks the documented and guaranteed user space
ABI and therefore it makes it impossible for any other library in
an application which uses tcmalloc to rely on the documented and
guaranteed rseq::cpu_id_start/rseq::cpu_id semantics.
Which means, that tcmalloc is holding everybody else hostage.
That's just not acceptable. Not even under the no regression rule.
3) The fact that tcmalloc prevents a user from enabling rseq debugging
is equally unacceptable as it does not allow me to validate my own
rseq magic code in my mongodb client because enabling it will make
the DB I want to test against go away.
Again tcmalloc holds everybody else hostage for no reason at all.
The most amazing part is that tcmalloc uses this to spare two
instruction cycles, but nobody noticed in 8 years how much performance
the unconditional rseq nonsense in the kernel left on the table.
Thanks,
tglx
^ permalink raw reply
* Re: (subset) [PATCH v3 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Lee Jones @ 2026-04-23 11:45 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy,
Akashdeep Kaur
Cc: vishalm, sebin.francis, d-gole, k-willis
In-Reply-To: <20260401112257.1248437-3-a-kaur@ti.com>
On Wed, 01 Apr 2026 16:52:57 +0530, Akashdeep Kaur wrote:
> Currently, the TPS65219 driver unconditionally registers a poweroff
> handler. This causes issues on systems where a different component
> (such as TF-A firmware) should handle system poweroff instead.
>
> Make the poweroff handler registration conditional based on the
> "system-power-controller" device tree property. This follows the
> standard kernel pattern where only the designated power controller
> registers for system poweroff operations.
>
> [...]
Applied, thanks!
[2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
commit: 0af600b8e3bced37afa267ac9a7f68e15764f502
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 2/2] firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface
From: Michal Simek @ 2026-04-23 11:34 UTC (permalink / raw)
To: Ronak Jain, senthilnathan.thangaraj; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20260408114244.2852015-3-ronak.jain@amd.com>
On 4/8/26 13:42, Ronak Jain wrote:
> Add support for dynamically discovering and exposing Configuration
> Security Unit (CSU) registers through sysfs. Leverage the existing
> PM_QUERY_DATA API to discover available registers at runtime, making
> the interface flexible and maintainable.
>
> Key features:
> - Dynamic register discovery using PM_QUERY_DATA API
> * PM_QID_GET_NODE_COUNT: Query number of available registers
> * PM_QID_GET_NODE_NAME: Query register names by index
> - Automatic sysfs attribute creation under csu_registers/ group
> - Read operations via existing IOCTL_READ_REG API
> - Write operations via existing IOCTL_MASK_WRITE_REG API
> - Firmware-enforced access control (read-only registers reject writes)
>
> The sysfs interface is created at:
> /sys/devices/platform/firmware:zynqmp-firmware/csu_registers/
>
> Currently supported registers include:
> - multiboot (CSU_MULTI_BOOT)
> - idcode (CSU_IDCODE, read-only)
> - pcap-status (CSU_PCAP_STATUS, read-only)
>
> The dynamic discovery approach allows firmware to control which
> registers are exposed without requiring kernel changes, improving
> maintainability and security.
>
> Signed-off-by: Ronak Jain <ronak.jain@amd.com>
> ---
> MAINTAINERS | 10 +
> drivers/firmware/xilinx/Makefile | 2 +-
> drivers/firmware/xilinx/zynqmp-csu-reg.c | 249 +++++++++++++++++++++++
> drivers/firmware/xilinx/zynqmp-csu-reg.h | 18 ++
> drivers/firmware/xilinx/zynqmp.c | 6 +
> include/linux/firmware/xlnx-zynqmp.h | 4 +-
> 6 files changed, 287 insertions(+), 2 deletions(-)
> create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.c
> create mode 100644 drivers/firmware/xilinx/zynqmp-csu-reg.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 10d12b51b1f6..37fe2b7e0ccf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -29212,6 +29212,16 @@ F: drivers/dma/xilinx/xdma.c
> F: include/linux/dma/amd_xdma.h
> F: include/linux/platform_data/amd_xdma.h
>
> +XILINX ZYNQMP CSU REGISTER DRIVER
> +M: Senthil Nathan Thangaraj <senthilnathan.thangaraj@amd.com>
> +R: Michal Simek <michal.simek@amd.com>
> +R: Ronak Jain <ronak.jain@amd.com>
> +L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> +S: Maintained
> +F: Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
> +F: drivers/firmware/xilinx/zynqmp-csu-reg.c
> +F: drivers/firmware/xilinx/zynqmp-csu-reg.h
> +
> XILINX ZYNQMP DPDMA DRIVER
> M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> L: dmaengine@vger.kernel.org
> diff --git a/drivers/firmware/xilinx/Makefile b/drivers/firmware/xilinx/Makefile
> index 8db0e66b6b7e..6203f41daaa6 100644
> --- a/drivers/firmware/xilinx/Makefile
> +++ b/drivers/firmware/xilinx/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> # Makefile for Xilinx firmwares
>
> -obj-$(CONFIG_ZYNQMP_FIRMWARE) += zynqmp.o zynqmp-ufs.o zynqmp-crypto.o
> +obj-$(CONFIG_ZYNQMP_FIRMWARE) += zynqmp.o zynqmp-ufs.o zynqmp-crypto.o zynqmp-csu-reg.o
> obj-$(CONFIG_ZYNQMP_FIRMWARE_DEBUG) += zynqmp-debug.o
> diff --git a/drivers/firmware/xilinx/zynqmp-csu-reg.c b/drivers/firmware/xilinx/zynqmp-csu-reg.c
> new file mode 100644
> index 000000000000..1f304ce858b1
> --- /dev/null
> +++ b/drivers/firmware/xilinx/zynqmp-csu-reg.c
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Zynq MPSoC CSU Register Access
> + *
> + * Copyright (C) 2026 Advanced Micro Devices, Inc.
> + *
> + * Michal Simek <michal.simek@amd.com>
> + * Ronak Jain <ronak.jain@amd.com>
> + */
> +
> +#include <linux/firmware/xlnx-zynqmp.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +
> +#include "zynqmp-csu-reg.h"
> +
> +/* Node ID for CSU module in firmware */
> +#define CSU_NODE_ID 0
> +
> +/* Maximum number of CSU registers supported */
> +#define MAX_CSU_REGS 50
> +
> +/* Size of register name returned by firmware (3 u32 words = 12 bytes) */
> +#define CSU_REG_NAME_LEN 12
> +
> +/**
> + * struct zynqmp_csu_reg - CSU register information
> + * @id: Register index from firmware
> + * @name: Register name
> + * @attr: Device attribute for sysfs
> + */
> +struct zynqmp_csu_reg {
> + u32 id;
> + char name[CSU_REG_NAME_LEN];
> + struct device_attribute attr;
> +};
> +
> +/**
> + * struct zynqmp_csu_data - Per-device CSU data
> + * @csu_regs: Array of CSU registers
> + * @csu_reg_count: Number of CSU registers
> + * @csu_attr_group: Attribute group for sysfs
> + */
> +struct zynqmp_csu_data {
> + struct zynqmp_csu_reg *csu_regs;
> + int csu_reg_count;
> + struct attribute_group csu_attr_group;
> +};
> +
> +/**
> + * zynqmp_pm_get_node_count() - Get number of supported nodes via QUERY_DATA
> + *
> + * Return: Number of nodes on success, or negative error code
> + */
> +static int zynqmp_pm_get_node_count(void)
> +{
> + struct zynqmp_pm_query_data qdata = {0};
> + u32 ret_payload[PAYLOAD_ARG_CNT];
> + int ret;
> +
> + qdata.qid = PM_QID_GET_NODE_COUNT;
> +
> + ret = zynqmp_pm_query_data(qdata, ret_payload);
> + if (ret)
> + return ret;
> +
> + return ret_payload[1];
> +}
> +
> +/**
> + * zynqmp_pm_get_node_name() - Get node name via QUERY_DATA
> + * @index: Register index
> + * @name: Buffer to store register name
> + *
> + * Return: 0 on success, error code otherwise
> + */
> +static int zynqmp_pm_get_node_name(u32 index, char *name)
> +{
> + struct zynqmp_pm_query_data qdata = {0};
> + u32 ret_payload[PAYLOAD_ARG_CNT];
> + int ret;
> +
> + qdata.qid = PM_QID_GET_NODE_NAME;
> + qdata.arg1 = index;
> +
> + ret = zynqmp_pm_query_data(qdata, ret_payload);
> + if (ret)
> + return ret;
> +
> + memcpy(name, &ret_payload[1], CSU_REG_NAME_LEN);
> + name[CSU_REG_NAME_LEN - 1] = '\0';
> +
> + return 0;
> +}
> +
> +/**
> + * zynqmp_csu_reg_show() - Generic show function for all registers
> + * @dev: Device pointer
> + * @attr: Device attribute
> + * @buf: Output buffer
> + *
> + * Return: Number of bytes written to buffer, or error code
> + */
> +static ssize_t zynqmp_csu_reg_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct zynqmp_csu_reg *reg;
> + u32 value;
> + int ret;
> +
> + /* Use container_of to get register directly */
> + reg = container_of(attr, struct zynqmp_csu_reg, attr);
> +
> + ret = zynqmp_pm_sec_read_reg(CSU_NODE_ID, reg->id, &value);
> + if (ret)
> + return ret;
> +
> + return sysfs_emit(buf, "0x%08x\n", value);
> +}
> +
> +/**
> + * zynqmp_csu_reg_store() - Generic store function for writable registers
> + * @dev: Device pointer
> + * @attr: Device attribute
> + * @buf: Input buffer
> + * @count: Buffer size
> + *
> + * Format: "mask value" - both mask and value required
> + * Example: echo "0xFFFFFFFF 0x12345678" > register
> + *
> + * Return: count on success, error code otherwise
> + */
> +static ssize_t zynqmp_csu_reg_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct zynqmp_csu_reg *reg;
> + u32 mask, value;
> + int ret;
> +
> + reg = container_of(attr, struct zynqmp_csu_reg, attr);
> +
> + if (sscanf(buf, "%x %x", &mask, &value) != 2)
> + return -EINVAL;
> +
> + ret = zynqmp_pm_sec_mask_write_reg(CSU_NODE_ID, reg->id, mask, value);
> + if (ret)
> + return ret;
> +
> + return count;
> +}
> +
> +/**
> + * zynqmp_csu_discover_registers() - Discover CSU registers from firmware
> + * @pdev: Platform device pointer
> + *
> + * This function uses PM_QUERY_DATA to discover all available CSU registers
> + * and creates sysfs group under /sys/devices/platform/firmware:zynqmp-firmware/
> + *
> + * Return: 0 on success, error code otherwise
> + */
> +int zynqmp_csu_discover_registers(struct platform_device *pdev)
> +{
> + struct zynqmp_csu_data *csu_data;
> + struct attribute **attrs;
> + int count, ret, i;
> +
> + ret = zynqmp_pm_is_function_supported(PM_QUERY_DATA, PM_QID_GET_NODE_COUNT);
> + if (ret) {
> + dev_dbg(&pdev->dev, "CSU register discovery not supported by current firmware\n");
> + return 0;
> + }
> +
> + count = zynqmp_pm_get_node_count();
> + if (count < 0)
> + return count;
> + if (count == 0) {
> + dev_dbg(&pdev->dev, "No nodes available from firmware\n");
> + return 0;
> + }
> +
> + /* Validate count to prevent excessive memory allocation */
> + if (count > MAX_CSU_REGS) {
> + dev_err(&pdev->dev, "Register count %d exceeds maximum %d\n",
> + count, MAX_CSU_REGS);
> + return -EINVAL;
> + }
> +
> + dev_dbg(&pdev->dev, "Discovered %d nodes from firmware\n", count);
> +
> + csu_data = devm_kzalloc(&pdev->dev, sizeof(*csu_data), GFP_KERNEL);
> + if (!csu_data)
> + return -ENOMEM;
> +
> + csu_data->csu_reg_count = count;
Where is this used?
> +
> + csu_data->csu_regs = devm_kcalloc(&pdev->dev, count, sizeof(*csu_data->csu_regs),
> + GFP_KERNEL);
> + if (!csu_data->csu_regs) {
> + devm_kfree(&pdev->dev, csu_data);
My bet is that you are freeing this memory because csu is optional and you don't
want to waste memory. Is this correct assumption?
If yes, I think it will be good if you can express this intention in commit
message.
> + return -ENOMEM;
> + }
> +
> + attrs = devm_kcalloc(&pdev->dev, count + 1, sizeof(*attrs), GFP_KERNEL);
> + if (!attrs) {
> + devm_kfree(&pdev->dev, csu_data->csu_regs);
> + devm_kfree(&pdev->dev, csu_data);
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < count; i++) {
> + struct zynqmp_csu_reg *reg = &csu_data->csu_regs[i];
> + struct device_attribute *dev_attr = ®->attr;
> +
> + reg->id = i;
> +
> + ret = zynqmp_pm_get_node_name(i, reg->name);
> + if (ret) {
> + dev_warn(&pdev->dev, "Failed to get name for register %d\n", i);
> + snprintf(reg->name, sizeof(reg->name), "csu_reg_%d", i);
> + }
> +
> + /* Create sysfs attribute - firmware enforces actual access control */
> + sysfs_attr_init(&dev_attr->attr);
> + dev_attr->attr.name = reg->name;
> + dev_attr->attr.mode = 0644;
You should comment this a little bit. In commit message you are saying that some
of that registers are read only but here you are exposing all of them as rw.
Do you have any interface/attribute/flag where you can find out if this is read
only?
I expect if you try to write to read only firmware driver will just reject it
anyway. If you don't have any flag for it, it would be good to describe this
limiation in commit message.
> + dev_attr->show = zynqmp_csu_reg_show;
> + dev_attr->store = zynqmp_csu_reg_store;
> +
> + attrs[i] = &dev_attr->attr;
> +
> + dev_dbg(&pdev->dev, "Register %d: id=%d name=%s\n", i, reg->id, reg->name);
> + }
> +
> + csu_data->csu_attr_group.name = "csu_registers";
> + csu_data->csu_attr_group.attrs = attrs;
> +
> + ret = devm_device_add_group(&pdev->dev, &csu_data->csu_attr_group);
> + if (ret) {
> + devm_kfree(&pdev->dev, attrs);
> + devm_kfree(&pdev->dev, csu_data->csu_regs);
> + devm_kfree(&pdev->dev, csu_data);
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_csu_discover_registers);
> diff --git a/drivers/firmware/xilinx/zynqmp-csu-reg.h b/drivers/firmware/xilinx/zynqmp-csu-reg.h
> new file mode 100644
> index 000000000000..b12415db3496
> --- /dev/null
> +++ b/drivers/firmware/xilinx/zynqmp-csu-reg.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Xilinx Zynq MPSoC CSU Register Access
> + *
> + * Copyright (C) 2026 Advanced Micro Devices, Inc.
> + *
> + * Michal Simek <michal.simek@amd.com>
> + * Ronak Jain <ronak.jain@amd.com>
> + */
> +
> +#ifndef __ZYNQMP_CSU_REG_H__
> +#define __ZYNQMP_CSU_REG_H__
> +
> +#include <linux/platform_device.h>
> +
> +int zynqmp_csu_discover_registers(struct platform_device *pdev);
> +
> +#endif /* __ZYNQMP_CSU_REG_H__ */
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index fbe8510f4927..b549d07f7497 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -27,6 +27,7 @@
>
> #include <linux/firmware/xlnx-zynqmp.h>
> #include <linux/firmware/xlnx-event-manager.h>
> +#include "zynqmp-csu-reg.h"
> #include "zynqmp-debug.h"
>
> /* Max HashMap Order for PM API feature check (1<<7 = 128) */
> @@ -2120,6 +2121,11 @@ static int zynqmp_firmware_probe(struct platform_device *pdev)
> dev_err_probe(&pdev->dev, PTR_ERR(em_dev), "EM register fail with error\n");
> }
>
> + /* Discover CSU registers dynamically */
> + ret = zynqmp_csu_discover_registers(pdev);
> + if (ret)
> + dev_warn(&pdev->dev, "CSU register discovery failed: %d\n", ret);
> +
> return of_platform_populate(dev->of_node, NULL, NULL, dev);
> }
>
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index d70dcd462b44..a4b293eb96ce 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -3,7 +3,7 @@
> * Xilinx Zynq MPSoC Firmware layer
> *
> * Copyright (C) 2014-2021 Xilinx
> - * Copyright (C) 2022 - 2025 Advanced Micro Devices, Inc.
> + * Copyright (C) 2022 - 2026 Advanced Micro Devices, Inc.
> *
> * Michal Simek <michal.simek@amd.com>
> * Davorin Mista <davorin.mista@aggios.com>
> @@ -262,6 +262,8 @@ enum pm_query_id {
> PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
> PM_QID_CLOCK_GET_MAX_DIVISOR = 13,
> PM_QID_PINCTRL_GET_ATTRIBUTES = 15,
> + PM_QID_GET_NODE_NAME = 16,
> + PM_QID_GET_NODE_COUNT = 17,
> };
>
> enum rpu_oper_mode {
Thanks,
Michal
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-23 11:20 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <56a8aab50a3b5ce0a345fc2079fb2abc7d0f1b23.camel@linux.ibm.com>
Hi Mimi,
> On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > > Hi Mimi,
> > > > >
> > > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > > the TPM driver must be built as built-in and
> > > > > > > must be probed before the IMA subsystem is initialized.
> > > > > > >
> > > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > > >
> > > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > > the CRB interface is probed before IMA initialization,
> > > > > > > the following conditions must be met:
> > > > > > >
> > > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > > which is done via ffa_init().
> > > > > > >
> > > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > > tpm_crb_ffa_init().
> > > > > > >
> > > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > > tpm_crb_ffa_init() for reference.)
> > > > > > >
> > > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > > >
> > > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > > has already been initialized, since IMA initialization is performed
> > > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > > at the same level.
> > > > > > >
> > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > > log though TPM device presents in the system.
> > > > > > >
> > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > >
> > > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > > changes (e.g. ima_init_core).
> > > > > >
> > > > > > Please just limit the change to just calling ima_init() twice.
> > > > >
> > > > > My concern is that ima_update_policy_flags() will be called
> > > > > when ima_init() is deferred -- not initialised anything.
> > > > > though functionally, it might be okay however,
> > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > > works logically.
> > > > >
> > > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > > ima_init_core() with some error handling.
> > > > >
> > > > > Am I missing something?
> > > >
> > > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > > we shouldn't call again ima_init() in the late_initcall_sync.
> > > >
> > > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > > it by caller of ima_init().
> > >
> > > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > > instead of going into TPM-bypass mode, return immediately. There are no calls
> > > to anything else. Just call ima_init() a second time.
> >
> > I’m not fully convinced this is sufficient.
> >
> > What I meant is the case where ima_init() fails due to other
> > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
>
> The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> available at late_initcall. This would be classified as a bug fix and would be
> backported. No other changes should be included in this patch.
Okay.
> >
> > I’d also like to ask again whether it is fine to call
> > ima_update_policy_flags() and keep the notifier registered in the
> > deferred TPM case. While this may be functionally acceptable, it seems
> > logically questionable to do so when ima_init() has not completed.
>
> Other than extending the TPM, IMA should behave exactly the same whether there
> is a TPM or goes into TPM-bypass mode.
>
> >
> > There is also a possibility that a deferred case ultimately fails (e.g.
> > deferred at late_initcall, but then failing at late_initcall_sync
> > for another reason, even while entering TPM bypass mode). In that case,
> > it seems more appropriate to handle this state in the caller of
> > ima_init(), rather than inside ima_init() itself.
>
> If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> bypass mode. Please don't make any other changes to the existing IMA behavior
> and hide it here behind the late_initcall_sync change.
Okay. you're talking called ima_update_policy_flags() at late_initcall
wouldn't be not a problem even in case of late_initcall_sync's ima_init()
get failed with "TPM-bypass mode".
I see then, I'll make a patch simpler then.
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH v2] crypto: ixp4xx - fix buffer chain unwind on allocation failure
From: Ruoyu Wang @ 2026-04-23 11:19 UTC (permalink / raw)
To: Herbert Xu, Corentin Labbe, linux-crypto
Cc: Linus Walleij, Imre Kaloz, David S . Miller, linux-arm-kernel,
linux-kernel, Ruoyu Wang
chainup_buffers() builds a linked list of buffer descriptors for a
scatterlist. If dma_pool_alloc() fails while constructing the list, the
current code sets buf to NULL and later dereferences it unconditionally
at the end of the function:
buf->next = NULL;
buf->phys_next = 0;
This can lead to a null-pointer dereference on allocation failure.
If the failure happens after part of the descriptor chain has already
been allocated and DMA-mapped, the partially constructed chain also
needs to be released.
Fix this by terminating the partially constructed chain on allocation
failure and letting the callers unwind it via their existing cleanup
paths. Also fix ablk_perform() to preserve the hook pointers before
checking for failure, so partially built chains can be freed correctly.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
v2:
- Keep the unwind path in the callers, per Herbert Xu's feedback.
- Terminate the partial chain before returning NULL on allocation failure.
- Save the hook pointers in ablk_perform() before checking the return value.
- Thanks to Herbert Xu for the review.
drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c | 25 ++++++++++++---------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
index fcc0cf4df..5b90cf0fb 100644
--- a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
+++ b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
@@ -884,8 +884,9 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
ptr = sg_virt(sg);
next_buf = dma_pool_alloc(buffer_pool, flags, &next_buf_phys);
if (!next_buf) {
- buf = NULL;
- break;
+ buf->next = NULL;
+ buf->phys_next = 0;
+ return NULL;
}
sg_dma_address(sg) = dma_map_single(dev, ptr, len, dir);
buf->next = next_buf;
@@ -983,7 +984,7 @@ static int ablk_perform(struct skcipher_request *req, int encrypt)
unsigned int nbytes = req->cryptlen;
enum dma_data_direction src_direction = DMA_BIDIRECTIONAL;
struct ablk_ctx *req_ctx = skcipher_request_ctx(req);
- struct buffer_desc src_hook;
+ struct buffer_desc *buf, src_hook;
struct device *dev = &pdev->dev;
unsigned int offset;
gfp_t flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ?
@@ -1025,22 +1026,24 @@ static int ablk_perform(struct skcipher_request *req, int encrypt)
/* This was never tested by Intel
* for more than one dst buffer, I think. */
req_ctx->dst = NULL;
- if (!chainup_buffers(dev, req->dst, nbytes, &dst_hook,
- flags, DMA_FROM_DEVICE))
- goto free_buf_dest;
- src_direction = DMA_TO_DEVICE;
+ buf = chainup_buffers(dev, req->dst, nbytes, &dst_hook,
+ flags, DMA_FROM_DEVICE);
req_ctx->dst = dst_hook.next;
crypt->dst_buf = dst_hook.phys_next;
+ if (!buf)
+ goto free_buf_dest;
+ src_direction = DMA_TO_DEVICE;
} else {
req_ctx->dst = NULL;
}
req_ctx->src = NULL;
- if (!chainup_buffers(dev, req->src, nbytes, &src_hook, flags,
- src_direction))
- goto free_buf_src;
-
+ buf = chainup_buffers(dev, req->src, nbytes, &src_hook, flags,
+ src_direction);
req_ctx->src = src_hook.next;
crypt->src_buf = src_hook.phys_next;
+ if (!buf)
+ goto free_buf_src;
+
crypt->ctl_flags |= CTL_FLAG_PERFORM_ABLK;
qmgr_put_entry(send_qid, crypt_virt2phys(crypt));
BUG_ON(qmgr_stat_overflow(send_qid));
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-23 11:01 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aem0SSQuE1e3pGOS@e129823.arm.com>
On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > Hi Mimi,
> > > >
> > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > the TPM driver must be built as built-in and
> > > > > > must be probed before the IMA subsystem is initialized.
> > > > > >
> > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > >
> > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > the CRB interface is probed before IMA initialization,
> > > > > > the following conditions must be met:
> > > > > >
> > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > which is done via ffa_init().
> > > > > >
> > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > tpm_crb_ffa_init().
> > > > > >
> > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > tpm_crb_ffa_init() for reference.)
> > > > > >
> > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > >
> > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > has already been initialized, since IMA initialization is performed
> > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > at the same level.
> > > > > >
> > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > log though TPM device presents in the system.
> > > > > >
> > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > >
> > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > changes (e.g. ima_init_core).
> > > > >
> > > > > Please just limit the change to just calling ima_init() twice.
> > > >
> > > > My concern is that ima_update_policy_flags() will be called
> > > > when ima_init() is deferred -- not initialised anything.
> > > > though functionally, it might be okay however,
> > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > works logically.
> > > >
> > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > ima_init_core() with some error handling.
> > > >
> > > > Am I missing something?
> > >
> > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > we shouldn't call again ima_init() in the late_initcall_sync.
> > >
> > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > it by caller of ima_init().
> >
> > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > instead of going into TPM-bypass mode, return immediately. There are no calls
> > to anything else. Just call ima_init() a second time.
>
> I’m not fully convinced this is sufficient.
>
> What I meant is the case where ima_init() fails due to other
> initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
available at late_initcall. This would be classified as a bug fix and would be
backported. No other changes should be included in this patch.
>
> If it fails at the late_initcall stage for such reasons, then we
> should not call ima_init() again at late_initcall_sync.
>
> For this reason, instead of adding a static variable inside
> ima_init(), I think it would be better to manage the state in the
> caller and introduce something like an ima_initialised flag. Also, if
> initialisation fails for other reasons, the notifier block should be
> unregistered.
Defining a global file static variable, in lieu of a local static variable, is
fine. Defining two functions, one for late_initcall and another for
late_initcall_sync, that do nothing other than call ima_init() is also fine.
Please keep this patch as simple as possible.
>
> I’d also like to ask again whether it is fine to call
> ima_update_policy_flags() and keep the notifier registered in the
> deferred TPM case. While this may be functionally acceptable, it seems
> logically questionable to do so when ima_init() has not completed.
Other than extending the TPM, IMA should behave exactly the same whether there
is a TPM or goes into TPM-bypass mode.
>
> There is also a possibility that a deferred case ultimately fails (e.g.
> deferred at late_initcall, but then failing at late_initcall_sync
> for another reason, even while entering TPM bypass mode). In that case,
> it seems more appropriate to handle this state in the caller of
> ima_init(), rather than inside ima_init() itself.
If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
bypass mode. Please don't make any other changes to the existing IMA behavior
and hide it here behind the late_initcall_sync change.
>
> Am I still missing something?
When your original patch moved the initialization from late_initcall to
late_initcall_sync, you didn't question anything. There's absolutely no
difference between that and calling ima_init twice, as long as on late_initcall
ima_init() returns immediately if the TPM chip isn't defined.
Any other changes are superfluous. Keep the patch simple!
Mimi
^ permalink raw reply
* Re: [PATCH] crypto: sun8i-ss - avoid hash and rng references
From: Herbert Xu @ 2026-04-23 11:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Corentin Labbe, David S . Miller, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Eric Biggers, Ovidiu Panait,
linux-crypto, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <3948e39f-dd20-44e2-b264-dc2a0a88f5b5@app.fastmail.com>
On Thu, Apr 23, 2026 at 12:26:23PM +0200, Arnd Bergmann wrote:
>
> Sure, but I'm not adding new code here, I only reported a regression
> from Eric's (otherwise very nice) cleanup and tried to come up
> with a better workaround than adding another 'select'.
>
> I've tried to rework one driver to use IS_ENABLED() checks now
> instead of the #ifdef, and also replace the for()/switch()
> loop with three separate loops for simplicity. See below for
> what I ended up with compared with my first patch.
>
> I'm still not entirely happy with that version either, especially
> since this is getting beyond a purely mechanical cleanup.
> If you think this is better, I can do it for all three drivers,
> otherwise I'd just send the oneline change to work around the
> third driver link failure the same way that Eric did for the
> other two, and let the sunxi maintainters worry about cleaning
> it up.
Sorry, I made my comment based on your original patch only which
simply added ifdefs.
Now that I see the wider context in the driver, I'm happy to take
your original patch as is.
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
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-23 10:56 UTC (permalink / raw)
To: Will Deacon
Cc: Sudeep Holla, Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
sebastianene
In-Reply-To: <aene4KFD5kbSbFRm@willie-the-truck>
Hi Will,
> On Wed, Apr 22, 2026 at 02:32:23PM +0100, Yeoreum Yun wrote:
> > Hi All,
> >
> > > > On Tue, Apr 21, 2026 at 07:57:43AM +0100, Yeoreum Yun wrote:
> > > >
> > > > [...]
> > > >
> > > > >
> > > > > Also, the FF-A initialization is not driven by a device probe, but rather
> > > > > happens as part of the bus registration itself,
> > > > > so it does not fit well with a device_link or probe deferral based approach.
> > > > >
> > > > > Instead, perhaps we could go with the idea I mentioned previously:
> > > > > either introduce a notifier, or create a pseudo ffa_device
> > > > > once pKVM initialization has completed, and
> > > > > then let the ffa driver perform the additional initialization from there.
> > > > >
> > > > > Am I missing something?
> > > > >
> > > >
> > > > In order to handle/cleanup some ugliness in interrupt management in the
> > > > FF-A driver, we may introduce DT node eventually. But it will take sometime.
> > >
> > > Unfortunately, I think this DT node wouldn't be helpful to solve
> > > this situation for dependency with the kvm misc device...
> > >
> > > IMHO, current situation, the notifier seems to good option. unless
> > > we make the initcall to recongise this dependency.
> > >
> >
> > I think the best approach for now is to introduce a notifier to handle this situation.
> > If there are no further suggestions, I’ll send a v2 based on:
> > - https://lore.kernel.org/all/aeS4rAeVQ0yJIPYw@e129823.arm.com/
>
> I can't say that I'm a huge fan of that :/
>
> The notifier will literally fire once, for a single listener. That's
> called a function call.
I revisited Marc’s suggestion about using device links
(https://lore.kernel.org/all/87pl3vb5bm.wl-maz@kernel.org/)
but unless I’m misunderstanding something, I don’t think it would be a viable solution:
- https://lore.kernel.org/all/aen0j3qM2k06OdXC@e129823.arm.com/#t
Also, calling functions defined by FF-A from KVM would introduce
an unnecessary module dependency between the KVM and FF-A drivers.
I’ve been trying to find an alternative approach,
but I’m not confident about what would be appropriate.
If you don’t mind, could you share your thoughts on this?
Thanks!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v2 08/20] drm/plane: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-04-23 10:54 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maarten Lankhorst, David Airlie, Simona Vetter, Jonathan Corbet,
Shuah Khan, Dmitry Baryshkov, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <55c24dca-e354-49d1-8eaa-edf66f679428@suse.de>
[-- Attachment #1: Type: text/plain, Size: 3377 bytes --]
On Tue, Apr 21, 2026 at 03:22:22PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> > to drm_private_obj") introduced a new pattern for allocating drm object
> > states.
> >
> > Instead of relying on the reset() callback, it created a new
> > atomic_create_state hook. This is helpful because reset is a bit
> > overloaded: it's used to create the initial software state, reset it,
> > but also reset the hardware.
> >
> > It can also be used either at probe time, to create the initial state
> > and possibly reset the hardware to an expected default, but also during
> > suspend/resume.
> >
> > Both these cases come with different expectations too: during the
> > initialization, we want to initialize all states, but during
> > suspend/resume, drm_private_states for example are expected to be kept
> > around.
> >
> > And reset() isn't fallible, which makes it harder to handle
> > initialization errors properly.
> >
> > And this is only really relevant for some drivers, since all the helpers
> > for reset only create a new state, and don't touch the hardware at all.
> >
> > It was thus decided to create a new hook that would allocate and
> > initialize a pristine state without any side effect:
> > atomic_create_state to untangle a bit some of it, and to separate the
> > initialization with the actual reset one might need during a
> > suspend/resume.
> >
> > Let's continue the transition to the new pattern with planes.
> >
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 44 +++++++++++++++++++++++++++++++
> > drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++-
> > include/drm/drm_atomic_state_helper.h | 4 +++
> > include/drm/drm_plane.h | 13 +++++++++
> > 4 files changed, 81 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 2548d6da13675f63304dc92423c5d225de0447a8..f4ce9d3573cbecf216904db54335e0cf84a01c39 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -319,10 +319,29 @@ void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> > plane->state = plane_state;
> > }
> > EXPORT_SYMBOL(__drm_atomic_helper_plane_reset);
> > +/**
> > + * __drm_atomic_helper_plane_create_state - initializes plane state
> > + * @plane: plane object
> > + * @state: new state to initialize
> > + *
> > + * Initializes the newly allocated @state, usually required when
> > + * initializing the drivers.
> > + *
> > + * @state is assumed to be zeroed.
> > + *
> > + * This is useful for drivers that subclass @drm_plane_state.
> > + */
> > +void __drm_atomic_helper_plane_create_state(struct drm_plane *plane,
> > + struct drm_plane_state *state)
> > +{
> > + __drm_atomic_helper_plane_state_init(state, plane);
> > +}
> > +EXPORT_SYMBOL(__drm_atomic_helper_plane_create_state);
>
> Will this function have another purpuse? Could we just call
> _plane_state_init() directly from anywhere?
Yeah, I guess that makes sense. I'll drop that patch and the similar ones.
Thanks!
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathias Stearn @ 2026-04-23 10:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Dmitry Vyukov, Jinjie Ruan, linux-man, Mark Rutland,
Mathieu Desnoyers, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, regressions, linux-kernel,
linux-arm-kernel, Peter Zijlstra, Ingo Molnar, Blake Oler
In-Reply-To: <87ik9i0xlj.ffs@tglx>
On Thu, Apr 23, 2026 at 12:39 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> The kernel clears rseq_cs reliably when user space was interrupted and:
>
> the task was preempted
> or
> the return from interrupt delivers a signal
>
> If the task invoked a syscall then there is absolutely no reason to do
> either of this because syscalls from within a critical section are a
> bug and catched when enabling rseq debugging.
>
> The original code did this along with unconditionally updating CPU/MMCID
> which resulted in ~15% performance regression on a syscall heavy
> database benchmark once glibc started to register rseq.
Just to be clear TCMalloc does not need either rseq_cs to be cleared
or cpu_id_start to be written to on syscalls because it doesn't do
syscalls from critical sections. It will actually benefit (slightly)
from not updating cpu_id_start on syscalls.
It is specifically in the cases where an rseq would need to be aborted
(preemption, signals, migration, and membarrier IPI with the rseq
flag) that TCMalloc relies on cpu_id_start being written. It does rely
on that write even when not inside the critical section, because it
effectively uses that to detect if there were any would-cause-abort
events in between two critical sections. But since it leaves the
rseq_cs pointer non-null between critical sections, so you dont need
to add _any_ overhead for programs that never make use of rseq after
registration, or add any overhead to syscalls even for those who do.
^ permalink raw reply
* Re: [PATCH net v2 0/2] net: airoha: Fix NULL pointer derefrences in airoha_qdma_cleanup()
From: patchwork-bot+netdevbpf @ 2026-04-23 10:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260420-airoha_qdma_init_rx_queue-fix-v2-0-d99347e5c18d@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 20 Apr 2026 10:07:46 +0200 you wrote:
> Fix two possible NULL pointer derefrences in airoha_qdma_cleanup routine
> if airoha_qdma_init() fails.
>
> ---
> Changes in v2:
> - Move page_pool allocation after desc list allocation in
> airoha_qdma_init_rx_queue()
> - Move netif_napi_add_tx() after irq desc queue allocation in
> airoha_qdma_tx_irq_init()
> - Link to v1: https://lore.kernel.org/r/20260417-airoha_qdma_init_rx_queue-fix-v1-0-db9fa5e468e5@kernel.org
>
> [...]
Here is the summary with links:
- [net,v2,1/2] net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()
https://git.kernel.org/netdev/net/c/379050947a18
- [net,v2,2/2] net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()
https://git.kernel.org/netdev/net/c/4b91cb65789b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-23 10:39 UTC (permalink / raw)
To: Dmitry Vyukov, Jinjie Ruan, linux-man
Cc: Mark Rutland, Mathias Stearn, Mathieu Desnoyers, Catalin Marinas,
Will Deacon, Boqun Feng, Paul E. McKenney, Chris Kennelly,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Blake Oler
In-Reply-To: <CACT4Y+bxnQyHGdVNE1BYTx+Z2-cscLb38HYS9jBM5gPAz8=4bw@mail.gmail.com>
On Thu, Apr 23 2026 at 07:53, Dmitry Vyukov wrote:
> On Thu, 23 Apr 2026 at 03:48, Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> This part of the rseq man page needs to be fixed as well I think. The
> kernel no longer reliably provides clearing of rseq_cs on preemption,
> right?
>
> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
>
> "and set to NULL by the kernel when it restarts an assembly
> instruction sequence block,
> as well as when the kernel detects that it is preempting or delivering
> a signal outside of the range targeted by the rseq_cs."
The kernel clears rseq_cs reliably when user space was interrupted and:
the task was preempted
or
the return from interrupt delivers a signal
If the task invoked a syscall then there is absolutely no reason to do
either of this because syscalls from within a critical section are a
bug and catched when enabling rseq debugging.
The original code did this along with unconditionally updating CPU/MMCID
which resulted in ~15% performance regression on a syscall heavy
database benchmark once glibc started to register rseq.
Thanks,
tglx
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathias Stearn @ 2026-04-23 10:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Thomas Gleixner, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Ingo Molnar,
Mark Rutland, Jinjie Ruan, Blake Oler
In-Reply-To: <20260422131338.GI3102924@noisy.programming.kicks-ass.net>
On Wed, Apr 22, 2026 at 3:13 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Apr 22, 2026 at 02:56:47PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
> >
> > > Additionally, it breaks tcmalloc specifically by failing to overwrite
> > > the cpu_id_start field at points where it was relied on for
> > > correctness.
> >
> > This specific behaviour was documented as being wrong and running with
> > DEBUG_RSEQ would have flagged it.
> >
> > The tcmalloc issue has been contentious for a long time. The tcmalloc
> > folks relied on something that was documented to be wrong. It has been
> > reported to the tcmalloc people many years ago and if you were to run
> > tcmalloc on most any kernel (very much including 6.19) with
> > DEBUG_RSEQ=y, it would have yelled.
> >
> > The tcmalloc people didn't care. There was a proposal for an RSEQ
> > extension for what they need, and they didn't care. All this should be
> > in their bugzilla or whatever.
> >
> > The RSEQ rework improved performance significantly for everyone, and
> > kept all the documented behaviour (+- arm64 bug). Tcmalloc got screwed
> > over because they relied on implementation behaviour that was
> > specifically documented to be broken. And they didn't care. Google was
> > very much aware of this. And hasn't lifted a finger to remedy it.
>
> Also: https://lore.kernel.org/all/874io5andc.ffs@tglx/
(Sorry for the resend to folks who got this already - I got an alert
that it was rejected by the mailinglists because it contained html so
attempting to resend as plain text)
I won't claim that tcmalloc _should_ be abusing cpu_id_start as it is.
I agree that it seems questionable at best. However, I will strongly
disagree with the following comment in that message:
> What it not longer does is updating the
> CPU number for the preemption case on the same CPU
> because that's just a massive waste of CPU cycles.
I don't think it will cost _any_ cycles to implement what I proposed.
And it especially should have no impact from just enabling rseq on a
thread as glibc now does. It should only result in different
instructions being executed when the program actually _uses_ rseq by
setting the rseq_cs variable to a non-null pointer. I will repeat the
proposal with a bit more commentary in case you missed some of the
details that make it free:
Any time a critical section might be aborted (migration, preemption,
signal delivery, and membarrier IPI), the kernel _already_ must check
the rseq_cs field to see if the thread is in a critical section [and
if it is null because the program isn't using rseq critical sections,
no further action is taken]. This is documented as nulling the pointer
after (I assume to make later checks cheaper) [if this changed, then
it *is* a change in _documented behavior_, not just an implementation
detail]. It would be sufficient for tcmalloc's internal usage if every
time the kernel nulled out rseq_cs, it also wrote the cpu id to
cpu_id_start. [This is one additional store to a cacheline you are
already writing to so it should be ~free on modern OoO CPUs and cheap
on others. There might be a small cost to loading the current cpu, but
since nothing depends on that other than the store, I still expect it
to be ~free]
To make this more concrete, I am proposing adding
unsafe_put_user((u32)task_cpu(t), &t->rseq.usrptr->cpu_id_start, efault);
after each place where you currently do
unsafe_put_user(0ULL, &t->rseq.usrptr->rseq_cs, efault);
in rseq_update_user_cs. Is that something that you would expect to
cause a performance issue?
Again, I'm not claiming that it is "good" that this needs to be done.
But it does seem like a small price to pay to keep existing binaries
working on new kernels. Quoting the first paragraph of
https://docs.kernel.org/admin-guide/reporting-regressions.html:
> “We don’t cause regressions” is the first rule of Linux kernel development; Linux founder and lead developer Linus Torvalds established it himself and ensures it’s obeyed.
I don't see anything on that page that says it doesn't count as a
regression if the userspace program "relied on implementation
behaviour that was specifically documented to be broken".
^ permalink raw reply
* Re: [RFC PATCH v2 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-23 10:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <865x5i13dl.wl-maz@kernel.org>
Hi Marc,
> On Wed, 22 Apr 2026 17:24:49 +0100,
> Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> >
> > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > Otherwise, pKVM cannot negotiate the FF-A version or
> > obtain RX/TX buffer information, leading to failures in FF-A calls.
> >
> > During FF-A driver initialization, check whether pKVM has been initialized.
> > If pKVM isn't initailised, register notifier and do initialisation
> > of FF-A driver when pKVM is initialized.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > arch/arm64/include/asm/virt.h | 11 ++++++++++
> > arch/arm64/kvm/arm.c | 21 ++++++++++++++++++
> > arch/arm64/kvm/pkvm.c | 2 ++
> > drivers/firmware/arm_ffa/common.h | 4 ++--
> > drivers/firmware/arm_ffa/driver.c | 36 ++++++++++++++++++++++++++++++-
> > drivers/firmware/arm_ffa/smccc.c | 2 +-
> > 6 files changed, 72 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> > index b51ab6840f9c..ad038a3b8727 100644
> > --- a/arch/arm64/include/asm/virt.h
> > +++ b/arch/arm64/include/asm/virt.h
> > @@ -68,6 +68,8 @@
> > #include <asm/sysreg.h>
> > #include <asm/cpufeature.h>
> >
> > +struct notifier_block;
> > +
> > /*
> > * __boot_cpu_mode records what mode CPUs were booted in.
> > * A correctly-implemented bootloader must start all CPUs in the same mode:
> > @@ -166,6 +168,15 @@ static inline bool is_hyp_nvhe(void)
> > return is_hyp_mode_available() && !is_kernel_in_hyp_mode();
> > }
> >
> > +enum kvm_arm_event {
> > + PKVM_INITIALISED,
> > + KVM_ARM_EVENT_MAX,
> > +};
>
> Well, no.
>
> You are adding a whole infrastructure for something that happens
> *once* in the lifetime of the system. What's next? D-Bus?
>
> We already have a dependency mechanism, which I pointed to you last
> time, and that you conveniently ignored. If that's not working for
> you, then consider improving it.
>
> If we had a whole set of in-kernel users depending on some global KVM
> state change, we could look into it. But they are none, and all KVM
> state changes are per-vcpu rather global.
>
> So I'm not entertaining this invasive infrastructure for something so
> limited.
I think I misunderstood your suggestion at first — I wasn’t ignoring it,
and I apologise for that.
I initially considered hooking into /dev/kvm registration,
but there doesn’t seem to be a dedicated class or bus notifier for misc devices:
- https://lore.kernel.org/all/aecf57rWloQwDh6v@e129823.arm.com/
Also, as I understand it, to make use of device_link,
FF-A would need to represent itself (and pKVM) as proper devices.
However, even if we rely on notifiers for when the pKVM device and
FF-A device are added, the ordering becomes problematic.
When the pKVM device is added and probed, the FF-A consumer would add into
deferred list be device core and deferred_probe is triggered later
(during late_initcall).
In other words, once FF-A itself is deferred,
the deferred probe queue would look something like:
(device depending on FF-A) → (some FF-A device) → (FF-A core)
especially since finalise_pkvm() runs at late_initcall_sync.
Unfortunately, deferred_probe_initcall() (also at late_initcall) only
calls driver_deferred_probe_trigger() twice. In this scenario,
the last device in the chain would not be probed immediately but only after a timeout.
As a result, IMA would also fail to find the device in time.
This is why I felt that device_link might not be suitable in this case —
although I may be misunderstanding something.
If this understanding is correct, I’m not sure what alternative we have,
other than adding some kind of notifier support (bus or class) to
the misc driver, or introducing a custom notifier.
Am I missing something?
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to flattened model
From: Xu Yang @ 2026-04-23 10:26 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel, jun.li
In-Reply-To: <aehGKE8qLXiBKvvB@lizhi-Precision-Tower-5810>
On Tue, Apr 21, 2026 at 11:53:12PM -0400, Frank Li wrote:
> On Tue, Apr 21, 2026 at 06:55:01PM +0800, Xu Yang wrote:
> > Switch to use flattened model for USB3 controller. To enable USB
> > controller with restricted DMA access range to work correctly, add a
> > pseudo simple-bus to constrain the dma address.
>
> i.mx95 should fix >4G dma space's problem. Does it impact other no-nxp
> boards?
Yes, i.MX95 has fixed >3G address DMA access problem.
It's another issue. HSIO domain only support 36 bit bus access. If not use smmu,
no any issue. If use smmu, it will allocate memory space of 36 bit < iova < 48bit.
HSIO can't handle this case.
>
> Need do break compatible judgement such as
>
> i.MX95 is new SoC and still is heave development. The break compatible is
> accepable at development early phase.
>
> You can rephrase it.
OK.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH] crypto: sun8i-ss - avoid hash and rng references
From: Arnd Bergmann @ 2026-04-23 10:26 UTC (permalink / raw)
To: Herbert Xu
Cc: Arnd Bergmann, Corentin Labbe, David S . Miller, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Eric Biggers, Ovidiu Panait,
linux-crypto, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <aenmEQNhhw9bnxEa@gondor.apana.org.au>
On Thu, Apr 23, 2026, at 11:27, Herbert Xu wrote:
> On Thu, Apr 23, 2026 at 11:25:19AM +0200, Arnd Bergmann wrote:
>>
>> Yes, I can rework the patch that way. I had considered this originally
>> but decided this would end up less readable in this case because
>> of the extra indentation level. The drivers already has a lot of
>> #ifdef checks, so adding more of those felt more in line with the
>> style used here.
>
> If we're adding new code I prefer doing it inline instead of as
> an ifdef so that we maximise compiler coverage.
Sure, but I'm not adding new code here, I only reported a regression
from Eric's (otherwise very nice) cleanup and tried to come up
with a better workaround than adding another 'select'.
I've tried to rework one driver to use IS_ENABLED() checks now
instead of the #ifdef, and also replace the for()/switch()
loop with three separate loops for simplicity. See below for
what I ended up with compared with my first patch.
I'm still not entirely happy with that version either, especially
since this is getting beyond a purely mechanical cleanup.
If you think this is better, I can do it for all three drivers,
otherwise I'd just send the oneline change to work around the
third driver link failure the same way that Eric did for the
other two, and let the sunxi maintainters worry about cleaning
it up.
Arnd
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
index 813c4bc6312a..330a1ed7eb03 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
@@ -31,7 +31,7 @@ static const struct ss_variant ss_a33_variant = {
.sha1_in_be = true,
};
-static struct sun4i_ss_alg_template ss_algs[] = {
+static struct sun4i_ss_alg_template ss_ahash_algs[] = {
{ .type = CRYPTO_ALG_TYPE_AHASH,
.mode = SS_OP_MD5,
.alg.hash = {
@@ -84,6 +84,9 @@ static struct sun4i_ss_alg_template ss_algs[] = {
}
}
},
+};
+
+static struct sun4i_ss_alg_template ss_skcipher_algs[] = {
{ .type = CRYPTO_ALG_TYPE_SKCIPHER,
.alg.crypto = {
.setkey = sun4i_ss_aes_setkey,
@@ -213,7 +216,9 @@ static struct sun4i_ss_alg_template ss_algs[] = {
}
}
},
-#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+};
+
+static struct sun4i_ss_alg_template ss_rng_algs[] = {
{
.type = CRYPTO_ALG_TYPE_RNG,
.alg.rng = {
@@ -229,40 +234,46 @@ static struct sun4i_ss_alg_template ss_algs[] = {
.seedsize = SS_SEED_LEN / BITS_PER_BYTE,
}
},
-#endif
};
static int sun4i_ss_debugfs_show(struct seq_file *seq, void *v)
{
unsigned int i;
- for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
- if (!ss_algs[i].ss)
+ for (i = 0; i < ARRAY_SIZE(ss_skcipher_algs); i++) {
+ if (!ss_skcipher_algs[i].ss)
continue;
- switch (ss_algs[i].type) {
- case CRYPTO_ALG_TYPE_SKCIPHER:
- seq_printf(seq, "%s %s reqs=%lu opti=%lu fallback=%lu tsize=%lu\n",
- ss_algs[i].alg.crypto.base.cra_driver_name,
- ss_algs[i].alg.crypto.base.cra_name,
- ss_algs[i].stat_req, ss_algs[i].stat_opti, ss_algs[i].stat_fb,
- ss_algs[i].stat_bytes);
- break;
-#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
- case CRYPTO_ALG_TYPE_RNG:
- seq_printf(seq, "%s %s reqs=%lu tsize=%lu\n",
- ss_algs[i].alg.rng.base.cra_driver_name,
- ss_algs[i].alg.rng.base.cra_name,
- ss_algs[i].stat_req, ss_algs[i].stat_bytes);
- break;
-#endif
- case CRYPTO_ALG_TYPE_AHASH:
- seq_printf(seq, "%s %s reqs=%lu\n",
- ss_algs[i].alg.hash.halg.base.cra_driver_name,
- ss_algs[i].alg.hash.halg.base.cra_name,
- ss_algs[i].stat_req);
- break;
- }
+ seq_printf(seq, "%s %s reqs=%lu opti=%lu fallback=%lu tsize=%lu\n",
+ ss_skcipher_algs[i].alg.crypto.base.cra_driver_name,
+ ss_skcipher_algs[i].alg.crypto.base.cra_name,
+ ss_skcipher_algs[i].stat_req,
+ ss_skcipher_algs[i].stat_opti,
+ ss_skcipher_algs[i].stat_fb,
+ ss_skcipher_algs[i].stat_bytes);
}
+
+ for (i = 0; i < ARRAY_SIZE(ss_ahash_algs); i++) {
+ if (!ss_ahash_algs[i].ss)
+ continue;
+
+ seq_printf(seq, "%s %s reqs=%lu tsize=%lu\n",
+ ss_ahash_algs[i].alg.rng.base.cra_driver_name,
+ ss_ahash_algs[i].alg.rng.base.cra_name,
+ ss_ahash_algs[i].stat_req,
+ ss_ahash_algs[i].stat_bytes);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(ss_rng_algs); i++) {
+ if (!IS_ENABLED(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) ||
+ !ss_rng_algs[i].ss)
+ continue;
+
+ seq_printf(seq, "%s %s reqs=%lu\n",
+ ss_rng_algs[i].alg.hash.halg.base.cra_driver_name,
+ ss_rng_algs[i].alg.hash.halg.base.cra_name,
+ ss_rng_algs[i].stat_req);
+ }
+
return 0;
}
DEFINE_SHOW_ATTRIBUTE(sun4i_ss_debugfs);
@@ -454,34 +465,36 @@ static int sun4i_ss_probe(struct platform_device *pdev)
pm_runtime_put_sync(ss->dev);
- for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
- ss_algs[i].ss = ss;
- switch (ss_algs[i].type) {
- case CRYPTO_ALG_TYPE_SKCIPHER:
- err = crypto_register_skcipher(&ss_algs[i].alg.crypto);
- if (err) {
- dev_err(ss->dev, "Fail to register %s\n",
- ss_algs[i].alg.crypto.base.cra_name);
- goto error_alg;
- }
- break;
- case CRYPTO_ALG_TYPE_AHASH:
- err = crypto_register_ahash(&ss_algs[i].alg.hash);
- if (err) {
- dev_err(ss->dev, "Fail to register %s\n",
- ss_algs[i].alg.hash.halg.base.cra_name);
- goto error_alg;
- }
- break;
-#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
- case CRYPTO_ALG_TYPE_RNG:
- err = crypto_register_rng(&ss_algs[i].alg.rng);
- if (err) {
- dev_err(ss->dev, "Fail to register %s\n",
- ss_algs[i].alg.rng.base.cra_name);
- }
+ for (i = 0; i < ARRAY_SIZE(ss_skcipher_algs); i++) {
+ ss_skcipher_algs[i].ss = ss;
+ err = crypto_register_skcipher(&ss_skcipher_algs[i].alg.crypto);
+ if (err) {
+ dev_err(ss->dev, "Fail to register %s\n",
+ ss_skcipher_algs[i].alg.crypto.base.cra_name);
+ goto error_skcipher_alg;
+ }
+ }
+
+ for (i = 0; i < ARRAY_SIZE(ss_ahash_algs); i++) {
+ ss_ahash_algs[i].ss = ss;
+ err = crypto_register_ahash(&ss_ahash_algs[i].alg.hash);
+ if (err) {
+ dev_err(ss->dev, "Fail to register %s\n",
+ ss_ahash_algs[i].alg.hash.halg.base.cra_name);
+ goto error_ahash_alg;
+ }
+ }
+
+ for (i = 0; i < ARRAY_SIZE(ss_rng_algs); i++) {
+ if (!IS_ENABLED(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG))
break;
-#endif
+
+ ss_rng_algs[i].ss = ss;
+ err = crypto_register_rng(&ss_rng_algs[i].alg.rng);
+ if (err) {
+ dev_err(ss->dev, "Fail to register %s\n",
+ ss_rng_algs[i].alg.rng.base.cra_name);
+ goto error_rng_alg;
}
}
@@ -491,23 +504,20 @@ static int sun4i_ss_probe(struct platform_device *pdev)
&sun4i_ss_debugfs_fops);
return 0;
-error_alg:
- i--;
- for (; i >= 0; i--) {
- switch (ss_algs[i].type) {
- case CRYPTO_ALG_TYPE_SKCIPHER:
- crypto_unregister_skcipher(&ss_algs[i].alg.crypto);
- break;
- case CRYPTO_ALG_TYPE_AHASH:
- crypto_unregister_ahash(&ss_algs[i].alg.hash);
- break;
-#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
- case CRYPTO_ALG_TYPE_RNG:
- crypto_unregister_rng(&ss_algs[i].alg.rng);
- break;
-#endif
- }
+
+error_rng_alg:
+ if (IS_ENABLED(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG)) {
+ for (i--; i >= 0; i--)
+ crypto_unregister_rng(&ss_rng_algs[i].alg.rng);
}
+ i = ARRAY_SIZE(ss_ahash_algs);
+error_ahash_alg:
+ for (i--; i >= 0; i--)
+ crypto_unregister_ahash(&ss_ahash_algs[i].alg.hash);
+ i = ARRAY_SIZE(ss_skcipher_algs);
+error_skcipher_alg:
+ for (i--; i >= 0; i--)
+ crypto_unregister_skcipher(&ss_skcipher_algs[i].alg.crypto);
error_pm:
sun4i_ss_pm_exit(ss);
return err;
@@ -518,21 +528,14 @@ static void sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
- for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
- switch (ss_algs[i].type) {
- case CRYPTO_ALG_TYPE_SKCIPHER:
- crypto_unregister_skcipher(&ss_algs[i].alg.crypto);
- break;
- case CRYPTO_ALG_TYPE_AHASH:
- crypto_unregister_ahash(&ss_algs[i].alg.hash);
- break;
-#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
- case CRYPTO_ALG_TYPE_RNG:
- crypto_unregister_rng(&ss_algs[i].alg.rng);
- break;
-#endif
- }
+ if (IS_ENABLED(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG)) {
+ for (i = ARRAY_SIZE(ss_rng_algs); i >= 0; i--)
+ crypto_unregister_rng(&ss_rng_algs[i].alg.rng);
}
+ for (i = ARRAY_SIZE(ss_ahash_algs); i >= 0; i--)
+ crypto_unregister_ahash(&ss_ahash_algs[i].alg.hash);
+ for (i = ARRAY_SIZE(ss_skcipher_algs) - 1; i >= 0; i--)
+ crypto_unregister_skcipher(&ss_skcipher_algs[i].alg.crypto);
sun4i_ss_pm_exit(ss);
}
^ permalink raw reply related
* Re: [PATCH v3 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Daniel Lezcano @ 2026-04-23 10:25 UTC (permalink / raw)
To: Ronald Claveau, Guillaume La Roque, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-4-a2e7215ed003@aliel.fr>
Hi Ronald,
On 4/21/26 09:19, Ronald Claveau wrote:
> Some SoCs (e.g. T7) expose thermal calibration data through the secure
> monitor rather than a directly accessible eFuse register. Add a use_sm
> flag to amlogic_thermal_data to select this path, and retrieve the
> firmware handle and tsensor_id from the "amlogic,secure-monitor" DT
> phandle with one fixed argument.
>
> Also introduce the amlogic,t7-thermal compatible using this new path.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> drivers/thermal/amlogic_thermal.c | 58 +++++++++++++++++++++++++++++++++++----
> 1 file changed, 53 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
> index 5448d772db12a..11e3948cc0669 100644
> --- a/drivers/thermal/amlogic_thermal.c
> +++ b/drivers/thermal/amlogic_thermal.c
> @@ -25,6 +25,7 @@
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> #include <linux/thermal.h>
> +#include <linux/firmware/meson/meson_sm.h>
>
> #include "thermal_hwmon.h"
>
> @@ -84,12 +85,14 @@ struct amlogic_thermal_soc_calib_data {
> * @u_efuse_off: register offset to read fused calibration value
> * @calibration_parameters: calibration parameters structure pointer
> * @regmap_config: regmap config for the device
> + * @use_sm: read data from secure monitor instead of efuse
> * This structure is required for configuration of amlogic thermal driver.
> */
> struct amlogic_thermal_data {
> int u_efuse_off;
> const struct amlogic_thermal_soc_calib_data *calibration_parameters;
> const struct regmap_config *regmap_config;
> + bool use_sm;
> };
>
> struct amlogic_thermal {
> @@ -100,6 +103,8 @@ struct amlogic_thermal {
> struct clk *clk;
> struct thermal_zone_device *tzd;
> u32 trim_info;
> + struct meson_sm_firmware *sm_fw;
> + u32 tsensor_id;
> };
>
> /*
> @@ -138,6 +143,12 @@ static int amlogic_thermal_initialize(struct amlogic_thermal *pdata)
> int ret = 0;
> int ver;
>
> + if (pdata->data->use_sm) {
> + return meson_sm_get_thermal_calib(pdata->sm_fw,
> + &pdata->trim_info,
> + pdata->tsensor_id);
> + }
> +
> regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
> &pdata->trim_info);
>
> @@ -226,6 +237,12 @@ static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
> .regmap_config = &amlogic_thermal_regmap_config_g12a,
> };
>
> +static const struct amlogic_thermal_data amlogic_thermal_t7_param = {
> + .use_sm = true,
> + .calibration_parameters = &amlogic_thermal_g12a,
> + .regmap_config = &amlogic_thermal_regmap_config_g12a,
> +};
> +
> static const struct of_device_id of_amlogic_thermal_match[] = {
> {
> .compatible = "amlogic,g12a-ddr-thermal",
> @@ -239,6 +256,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
> .compatible = "amlogic,a1-cpu-thermal",
> .data = &amlogic_thermal_a1_cpu_param,
> },
> + {
> + .compatible = "amlogic,t7-thermal",
> + .data = &amlogic_thermal_t7_param,
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
> @@ -271,11 +292,38 @@ static int amlogic_thermal_probe(struct platform_device *pdev)
> if (IS_ERR(pdata->clk))
> return dev_err_probe(dev, PTR_ERR(pdata->clk), "failed to get clock\n");
>
> - pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
> - (pdev->dev.of_node, "amlogic,ao-secure");
> - if (IS_ERR(pdata->sec_ao_map)) {
> - dev_err(dev, "syscon regmap lookup failed.\n");
> - return PTR_ERR(pdata->sec_ao_map);
> + if (pdata->data->use_sm) {
> + struct device_node *sm_np;
> + struct of_phandle_args ph_args;
> +
> + ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
> + "amlogic,secure-monitor",
> + 1, 0, &ph_args);
> + if (ret)
> + return ret;
> +
> + sm_np = ph_args.np;
> + if (!sm_np) {
> + dev_err(dev,
> + "Failed to parse secure monitor phandle\n");
> + return -ENODEV;
> + }
> +
> + pdata->sm_fw = meson_sm_get(sm_np);
> + of_node_put(sm_np);
> + if (!pdata->sm_fw) {
> + dev_err(dev, "Failed to get secure monitor firmware\n");
> + return -EPROBE_DEFER;
> + }
> +
> + pdata->tsensor_id = ph_args.args[0];
> + } else {
> + pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
> + (pdev->dev.of_node, "amlogic,ao-secure");
> + if (IS_ERR(pdata->sec_ao_map)) {
> + dev_err(dev, "syscon regmap lookup failed.\n");
> + return PTR_ERR(pdata->sec_ao_map);
> + }
> }
I suggest to separate these two routines into functions. That will help
the readability.
> pdata->tzd = devm_thermal_of_zone_register(&pdev->dev
The thermal zone is registered before calling
amlogic_thermal_initialize(), thus pdata->trim_info is not initialized.
When a thermal zone is registered the thermal framework reads the
temperature, so it reads an invalid value because:
devm_thermal_of_zone_register()
-> thermal_of_zone_register()
-> thermal_zone_device_register_with_trips()
-> thermal_zone_device_enable()
-> __thermal_zone_device_update()
-> __thermal_zone_get_temp()
-> amlogic_thermal_get_temp()
-> amlogic_thermal_code_to_millicelsius()
[ Use of uninitialized pdata->trim_info ]
Right ?
IIUC, amlogic_thermal_initialize() can be also split and moved the
corresponding blocks to the functions to be created in the comment above.
>
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: imx8mp: switch usb controller to flattened model
From: Xu Yang @ 2026-04-23 10:20 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel, jun.li
In-Reply-To: <aehEXEsiFl2PVIye@lizhi-Precision-Tower-5810>
On Tue, Apr 21, 2026 at 11:45:32PM -0400, Frank Li wrote:
> On Tue, Apr 21, 2026 at 06:55:00PM +0800, Xu Yang wrote:
> > Switch to use flattened model for all USB controllers. To enable USB
> > controllers with restricted DMA access range to work correctly, add a
> > pseudo simple-bus to constrain the dma address.
>
> This should not "pseudo", and bus is physical existed, which limited dma
> range since it transparent to SW, which may not mention in spec.
OK. Will remove the word "pseudo" in v2.
>
> >
> > Also reorder USB-related nodes.
>
> this need new patch to just do reorder.
OK. Will add a separate patch.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [RFC PATCH v2 2/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-04-23 10:17 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jgg, sudeep.holla,
maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <20260422162449.1814615-3-yeoreum.yun@arm.com>
On Wed, Apr 22, 2026 at 05:24:47PM +0100, Yeoreum Yun wrote:
> commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
>
> However, as IMA init function is changed to late_initcall_sync level.
> So, this change isn't required anymore.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> index 99f1c1e5644b..025c4d4b17ca 100644
> --- a/drivers/char/tpm/tpm_crb_ffa.c
> +++ b/drivers/char/tpm/tpm_crb_ffa.c
> @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> */
> int tpm_crb_ffa_init(void)
> {
> - int ret = 0;
> -
> - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> - ret = ffa_register(&tpm_crb_ffa_driver);
> - if (ret) {
> - tpm_crb_ffa = ERR_PTR(-ENODEV);
> - return ret;
> - }
> - }
> -
> if (!tpm_crb_ffa)
> - ret = -ENOENT;
> + return -ENOENT;
>
> if (IS_ERR_VALUE(tpm_crb_ffa))
> - ret = -ENODEV;
> + return -ENODEV;
>
> - return ret;
> + return 0;
> }
> EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
>
> @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> .id_table = tpm_crb_ffa_device_id,
> };
>
> -#ifdef MODULE
> module_ffa_driver(tpm_crb_ffa_driver);
> -#endif
>
> MODULE_AUTHOR("Arm");
> MODULE_DESCRIPTION("TPM CRB FFA driver");
> --
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
>
I'll hold review to next version i.e. after Mimi's concerns
have been addressed.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Thomas Gleixner @ 2026-04-23 10:08 UTC (permalink / raw)
To: Catalin Marinas, Jinjie Ruan
Cc: peterz, sudeep.holla, yangyicong, dietmar.eggemann,
Jonathan.Cameron, linux-kernel, James Morse, linux-arm-kernel
In-Reply-To: <aeNxKpHzTQX4_kId@arm.com>
On Sat, Apr 18 2026 at 12:55, Catalin Marinas wrote:
> Another option would have been to avoid marking such CPUs present but I
> think this will break other things. Yet another option is to register
> all CPU devices even if they never come up (like maxcpus greater than
> actual CPUs).
>
> Opinions? It might be an arm64+ACPI-only thing.
I think so. The proper thing to do is to apply sane limits:
1) The possible CPUs enumerated by firmware N_POSSIBLE_FW
2) The maxcpus limit on the command line N_MAXCPUS_CL
So the actual possible CPUs evaluates to:
num_possible = min(N_POSSIBLE_FW, N_MAXCPUS_CL, CONFIG_NR_CPUS);
The evaluation of the firmware should not mark CPUs present which are
actually not. ACPI gives you that information. See:
5.2.12.14 GIC CPU Interface (GICC) Structure
in the ACPI spec. That has two related bits:
Enabled:
If this bit is set, the processor is ready for use. If this bit is
clear and the Online Capable bit is set, the system supports enabling
this processor during OS runtime. If this bit is clear and the Online
Capable bit is also clear, this processor is un- usable, and the
operating system support will not attempt to use it.
Online Capable:
The information conveyed by this bit depends on the value of the
Enabled bit. If the Enabled bit is set, this bit is reserved and must
be zero. Otherwise, if this bit is set, the system supports enabling
this processor later during OS runtime
So the combination of those gives you the right answer:
Enabled Online
Capable
0 0 Not present, not possible
0 1 Not present, but possible to "hotplug" layter
1 0 Present
1 1 Invalid
The kernel sizes everything on the number of possible CPUs and the
present CPU mask is only there to figure out which CPUs are actually
usable and can be brought up.
The runtime physical hotplug mechanics use acpi_[un]map_cpu() to toggle
the present bit.
Thanks,
tglx
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table
From: bibek.patro @ 2026-04-23 10:02 UTC (permalink / raw)
To: Rob Clark, Will Deacon, Robin Murphy, Joerg Roedel
Cc: Dmitry Baryshkov, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel, srinivas.kandagatla, Bibek Kumar Patro,
Dmitry Baryshkov, Shawn Guo
From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
The qcom_smmu_actlr_client_of_match table contained "qcom,fastrpc" as
the compatible string for applying ACTLR prefetch settings to FastRPC
devices. However, "qcom,fastrpc" is the compatible string for the parent
rpmsg channel node, which is not an IOMMU client — it carries no
"iommus" property in the device tree and is never attached to an SMMU
context bank.
The actual IOMMU clients are the compute context bank (CB) child nodes,
which use the compatible string "qcom,fastrpc-compute-cb". These nodes
carry the "iommus" property and are probed by fastrpc_cb_driver via
fastrpc_cb_probe(), which sets up the DMA mask and IOMMU mappings for
each FastRPC session. The device tree structure is:
fastrpc {
compatible = "qcom,fastrpc"; /* rpmsg channel, no iommus */
...
compute-cb@3 {
compatible = "qcom,fastrpc-compute-cb";
iommus = <&apps_smmu 0x1823 0x0>; /* actual IOMMU client */
};
};
Since qcom_smmu_set_actlr_dev() calls of_match_device() against the
device being attached to the SMMU context bank, the "qcom,fastrpc"
entry was never matching any device. As a result, the ACTLR prefetch
settings (PREFETCH_DEEP | CPRE | CMTLB) were silently never applied
for FastRPC compute context banks.
Fix this by replacing "qcom,fastrpc" with "qcom,fastrpc-compute-cb"
in the match table so that the ACTLR settings are correctly applied
to the compute CB devices that are the true IOMMU clients.
Assisted-by: Claude:claude-sonnet-4-6
Fixes: 3e35c3e725de ("iommu/arm-smmu: Add ACTLR data and support for qcom_smmu_500")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
---
While there is an ongoing discussion [1] on how to differentiate ACTLR
prefetch settings between compute DSP and audio DSP fastrpc devices, it
is necessary to first fix the compatible string to
"qcom,fastrpc-compute-cb".
Both compute DSP and audio DSP fastrpc nodes use this compatible string,
so both will receive the ACTLR settings after this fix. However, for
audio DSP devices the effect remains the same as the current
state since they do not actively use prefetch — the write is effectively
a NOP for them. The fix is meaningful for compute DSP devices, which
actively use prefetch and were previously being silently skipped.
[1]:
https://lore.kernel.org/all/9b4c895a-c822-40e6-bb92-8fdcd09c82d3@oss.qualcomm.com/
v1->v2:
- Collect "Reviewed-by" tags.
- Address nit on "Assisted-by" tags format.
- [v1]:
https://lore.kernel.org/all/20260408130825.3268733-1-bibek.patro@oss.qualcomm.com/
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index edd41b5a3b6a..2d006049dd61 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -39,7 +39,7 @@ static const struct of_device_id qcom_smmu_actlr_client_of_match[] = {
.data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
{ .compatible = "qcom,adreno-smmu",
.data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
- { .compatible = "qcom,fastrpc",
+ { .compatible = "qcom,fastrpc-compute-cb",
.data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
{ .compatible = "qcom,qcm2290-mdss",
.data = (const void *) (PREFETCH_SHALLOW | CPRE | CMTLB) },
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox