* Re: [PATCH v3 0/5] ASoC / rpmsg / remoteproc / soc: qcom: Constify buffer passed to send functions
From: Bjorn Andersson @ 2026-04-06 15:10 UTC (permalink / raw)
To: Mathieu Poirier, Matthias Brugger, AngeloGioacchino Del Regno,
Srinivas Kandagatla, Konrad Dybcio, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Mauro Carvalho Chehab,
Krzysztof Kozlowski
Cc: linux-remoteproc, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-arm-msm, linux-sound, linux-media
In-Reply-To: <20260317-rpmsg-send-const-v3-0-4d7fd27f037f@oss.qualcomm.com>
On Tue, 17 Mar 2026 13:36:49 +0100, Krzysztof Kozlowski wrote:
> This got acks from Mathieu (remoteproc) and Mark (audio), so can we
> funnel everything via Qualcomm remoteproc tree?
>
> Dependencies / merging
> ======================
> Entire patchset is one logical chain, all further patches depend on
> previous ones, thus everything should be taken via same tree or shared
> between trees with tags. Probably everything should go via ASoC with
> necessary acks.
>
> [...]
Applied, thanks!
[1/5] remoteproc: mtk_scp_ipi: Constify buffer passed to scp_ipi_send()
commit: 4251dab9d176212afdf4ced263b59bc0d5292c7f
[2/5] remoteproc: mtk_scp: Constify buffer passed to scp_send_ipi()
commit: 90dacbf4bf13410c727ffaca8fe3ce3276ae58c2
[3/5] rpmsg: Constify buffer passed to send API
commit: b8077b4da2e89917ec4c632b66e60d49089bbda3
[4/5] ASoC: qcom:: Constify GPR packet being send over GPR interface
commit: 66ec83627902d2585e14911692b317496731767a
[5/5] media: platform: mtk-mdp3: Constify buffer passed to mdp_vpu_sendmsg()
commit: 3e2fa997d1e2b651993ae7e81646aadd55470bce
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/4] arm64: Kconfig: Add ARCH_HPE platform
From: Krzysztof Kozlowski @ 2026-04-06 14:52 UTC (permalink / raw)
To: nick.hawkins, catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260406143821.1843621-3-nick.hawkins@hpe.com>
On 06/04/2026 16:38, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
You have duplicated From fields. Not sure if this will apply correctly.
>
> Add the ARCH_HPE config for HPE ARM64 BMC SoCs to Kconfig.platforms.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL] Allwinner Device Tree Changes for 7.1 - Part 2
From: Chen-Yu Tsai @ 2026-04-06 14:51 UTC (permalink / raw)
To: soc
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-sunxi,
linux-arm-kernel
The following changes since commit b912e48bee355b6b1faf86efc4a23191324ffecb:
arm64: dts: allwinner: h6: Add TaiqiCat (TQC) A01 support (2026-03-14 15:27:04 +0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-7.1-2
for you to fetch changes up to c755e39836ec492b0bc210fd96c2b720b5b4a690:
arm64: dts: allwinner: enable h616 timer support (2026-03-29 21:20:49 +0800)
----------------------------------------------------------------
Allwinner Device Tree Changes for 7.1 - Part 2
UART DMA channels added for A64 and H6. Standard resolution MMIO timer added
for H616. This timer can be used as a broadcast timer for wakeup from idle
states.
----------------------------------------------------------------
Chen-Yu Tsai (2):
arm64: dts: allwinner: sun50i-a64: add UART DMA channels
arm64: dts: allwinner: sun50i-h6: add UART DMA channels
Michal Piekos (1):
arm64: dts: allwinner: enable h616 timer support
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++++++++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
3 files changed, 27 insertions(+)
^ permalink raw reply
* [PATCH v4 0/4] arm64: Add HPE GSC platform support
From: nick.hawkins @ 2026-04-06 14:38 UTC (permalink / raw)
To: catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: nick.hawkins, linux-arm-kernel, devicetree, linux-kernel
From: Nick Hawkins <nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add initial platform support for the HPE GSC ARM64 BMC SoC.
Changes since v3:
- Patch 1: Moved GSC entry before GXP in hpe,gxp.yaml to maintain
alphabetical ordering by fallback compatible (Krzysztof Kozlowski)
- Patch 2: Added Reviewed-by from Krzysztof Kozlowski
- Patch 3: Changed SPDX in gsc-dl340gen12.dts from GPL-2.0-only to
GPL-2.0 to be consistent with gsc.dtsi (Krzysztof Kozlowski);
reordered nodes within soc by ascending unit-address, placing UARTs
before GIC per DTS coding style (Krzysztof Kozlowski);
moved interrupt-parent before interrupts in timer and all UART nodes
per DTS coding style (Krzysztof Kozlowski);
reordered root-level nodes alphabetically: clock-33333333 before cpus
before timer per DTS coding style (Krzysztof Kozlowski);
reordered properties within all nodes to follow DTS coding style:
compatible, reg first, then remaining alphabetically (Krzysztof
Kozlowski)
- Patch 4: New patch adding CONFIG_ARCH_HPE=y to arm64 defconfig
(Krzysztof Kozlowski)
Nick Hawkins (4):
dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
arm64: Kconfig: Add ARCH_HPE platform
arm64: dts: hpe: Add HPE GSC SoC and DL340 Gen12 board DTS
arm64: defconfig: Enable ARCH_HPE
.../devicetree/bindings/arm/hpe,gxp.yaml | 7 +-
MAINTAINERS | 3 +-
arch/arm64/Kconfig.platforms | 11 ++
arch/arm64/boot/dts/hpe/Makefile | 2 +
arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts | 18 +++
arch/arm64/boot/dts/hpe/gsc.dtsi | 104 ++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
7 files changed, 144 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/hpe/Makefile
create mode 100644 arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
create mode 100644 arch/arm64/boot/dts/hpe/gsc.dtsi
--
2.34.1
^ permalink raw reply
* [PATCH v4 3/4] arm64: dts: hpe: Add HPE GSC SoC and DL340 Gen12 board DTS
From: nick.hawkins @ 2026-04-06 14:38 UTC (permalink / raw)
To: catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: nick.hawkins, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260406143821.1843621-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add SoC-level DTSI for the HPE GSC ARM64 BMC SoC, covering the CPU
cluster, GIC v3 interrupt controller, ARM64 generic timer, and console
UART.
Add the board-level DTS for the HPE DL340 Gen12, which includes
gsc.dtsi and adds memory and chosen nodes.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
arch/arm64/boot/dts/hpe/Makefile | 2 +
arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts | 18 ++++
arch/arm64/boot/dts/hpe/gsc.dtsi | 104 +++++++++++++++++++++
3 files changed, 124 insertions(+)
create mode 100644 arch/arm64/boot/dts/hpe/Makefile
create mode 100644 arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
create mode 100644 arch/arm64/boot/dts/hpe/gsc.dtsi
diff --git a/arch/arm64/boot/dts/hpe/Makefile b/arch/arm64/boot/dts/hpe/Makefile
new file mode 100644
index 000000000000..6b547b8a8154
--- /dev/null
+++ b/arch/arm64/boot/dts/hpe/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+dtb-$(CONFIG_ARCH_HPE) += gsc-dl340gen12.dtb
diff --git a/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts b/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
new file mode 100644
index 000000000000..7a3d9f1c4b2e
--- /dev/null
+++ b/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "gsc.dtsi"
+
+/ {
+ compatible = "hpe,gsc-dl340gen12", "hpe,gsc";
+ model = "HPE ProLiant DL340 Gen12";
+
+ chosen {
+ stdout-path = &uartc;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/hpe/gsc.dtsi b/arch/arm64/boot/dts/hpe/gsc.dtsi
new file mode 100644
index 000000000000..1f4c2a7b3d91
--- /dev/null
+++ b/arch/arm64/boot/dts/hpe/gsc.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE GSC
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ osc: clock-33333333 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "osc";
+ clock-frequency = <33333333>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0xa0008048>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <1>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0 0xa0008048>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic>;
+ 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>;
+ };
+
+ soc: soc@80000000 {
+ compatible = "simple-bus";
+ reg = <0x80000000 0x80000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ uarta: serial@c00000e0 {
+ compatible = "ns16550a";
+ reg = <0xc00000e0 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ uartb: serial@c00000e8 {
+ compatible = "ns16550a";
+ reg = <0xc00000e8 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ uartc: serial@c00000f0 {
+ compatible = "ns16550a";
+ reg = <0xc00000f0 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ uarte: serial@c00003e0 {
+ compatible = "ns16550a";
+ reg = <0xc00003e0 0x8>;
+ clock-frequency = <1846153>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ };
+
+ gic: gic@ce000000 {
+ compatible = "arm,gic-v3";
+ reg = <0xce000000 0x10000>,
+ <0xce060000 0x40000>,
+ <0xce200000 0x40000>;
+ #address-cells = <0>;
+ #interrupt-cells = <3>;
+ #redistributor-regions = <1>;
+ interrupt-controller;
+ redistributor-stride = <0x0 0x20000>;
+ };
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/4] arm64: Kconfig: Add ARCH_HPE platform
From: nick.hawkins @ 2026-04-06 14:38 UTC (permalink / raw)
To: catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: nick.hawkins, linux-arm-kernel, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260406143821.1843621-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add the ARCH_HPE config for HPE ARM64 BMC SoCs to Kconfig.platforms.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/Kconfig.platforms | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 54eb1d7fd419..b4217809c774 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -168,6 +168,17 @@ config ARCH_HISI
help
This enables support for Hisilicon ARMv8 SoC family
+config ARCH_HPE
+ bool "HPE SoC Support"
+ select PINCTRL
+ select GENERIC_IRQ_CHIP
+ select CLKSRC_MMIO
+ help
+ This enables support for HPE ARM-based SoC chips used
+ on HPE servers. HPE SoCs serve as the Baseboard
+ Management Controller (BMC) providing out-of-band server
+ management.
+
config ARCH_KEEMBAY
bool "Keem Bay SoC"
help
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/4] arm64: defconfig: Enable ARCH_HPE
From: nick.hawkins @ 2026-04-06 14:38 UTC (permalink / raw)
To: catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: nick.hawkins, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260406143821.1843621-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Enable ARCH_HPE in the arm64 defconfig to include HPE GSC BMC SoC
support in the default build.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index xxxxxxxxxxxxxxx..xxxxxxxxxxxxxxx 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -xx,6 +xx,7 @@
CONFIG_ARCH_HISI=y
+CONFIG_ARCH_HPE=y
CONFIG_ARCH_KEEMBAY=y
--
2.34.1
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: nick.hawkins @ 2026-04-06 14:38 UTC (permalink / raw)
To: catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: nick.hawkins, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260406143821.1843621-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add the HPE GSC ARM64 BMC SoC compatibles to the existing
hpe,gxp.yaml binding.
The initial board compatible is hpe,gsc-dl340gen12 for the DL340 Gen12
server platform.
Add the arm64 DTS path to the existing ARM/HPE GXP MAINTAINERS entry,
renamed to ARM/HPE GXP/GSC ARCHITECTURE.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
Documentation/devicetree/bindings/arm/hpe,gxp.yaml | 7 ++++++-
MAINTAINERS | 3 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
index 224bbcb93f95..6f057cd58571 100644
--- a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
+++ b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/hpe,gxp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: HPE BMC GXP platforms
+title: HPE BMC GXP and GSC platforms
maintainers:
- Nick Hawkins <nick.hawkins@hpe.com>
@@ -15,6 +15,11 @@ properties:
oneOf:
+ - description: GSC Based Boards
+ items:
+ - enum:
+ - hpe,gsc-dl340gen12
+ - const: hpe,gsc
- description: GXP Based Boards
items:
- enum:
- hpe,gxp-dl360gen10
- const: hpe,gxp
required:
- compatible
diff --git a/MAINTAINERS b/MAINTAINERS
index 2265e2c9bfbe..80c66de5e342 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2859,7 +2859,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
F: arch/arm/mach-sa1100/include/mach/jornada720.h
F: arch/arm/mach-sa1100/jornada720.c
-ARM/HPE GXP ARCHITECTURE
+ARM/HPE GXP/GSC ARCHITECTURE
M: Jean-Marie Verdun <verdun@hpe.com>
M: Nick Hawkins <nick.hawkins@hpe.com>
S: Maintained
@@ -2870,6 +2870,7 @@ F: Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml
F: Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
F: Documentation/hwmon/gxp-fan-ctrl.rst
F: arch/arm/boot/dts/hpe/
+F: arch/arm64/boot/dts/hpe/
F: drivers/clocksource/timer-gxp.c
F: drivers/hwmon/gxp-fan-ctrl.c
F: drivers/i2c/busses/i2c-gxp.c
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Manivannan Sadhasivam @ 2026-04-06 14:29 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Manivannan Sadhasivam, mark.rutland, lpieralisi, bjorn.andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, Konrad Dybcio,
Konrad Dybcio, Sudeep Holla
In-Reply-To: <adO1lS2g8Hewj0Ol@baldur>
On Mon, Apr 06, 2026 at 08:48:44AM -0500, Bjorn Andersson wrote:
> On Tue, Mar 31, 2026 at 12:09:38PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Mar 30, 2026 at 03:48:05PM -0500, Bjorn Andersson wrote:
> > > On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
> > > > From: Konrad Dybcio <konradybcio@kernel.org>
> > > >
> > > > PSCI specification defines the SYSTEM_SUSPEND feature which enables the
> > > > firmware to implement the suspend to RAM (S2RAM) functionality by
> > > > transitioning the system to a deeper low power state. When the system
> > > > enters such state, the power to the peripheral devices might be removed.
> > >
> > > What is the actual extent of "peripheral devices" in this definition?
> > >
> >
> > All devices except the ones backing volatile memory (DDR).
> >
>
> I do not agree that this should be the interpretation on a Qualcomm
> platform.
>
>
> We do have the corner case of DeepSleep, where this indeed is what will
> happen (not sure if other resource votes in the system are ignored
> though?). For all typical targets making the PSCI jump might result in
> CX being turned off (unless something else votes for it...).
>
> State is still retained on a case-by-case basis and some parts of the
> system are still functional when we enter such state - and that is the
> system state we desire.
>
> Making the interpretation that all SoC resources will be disabled will
> result in a large amount of unnecessary save/restore work, in addition
> to breaking many use cases.
>
I think adding these kind of per-device power state might be cumbersome as it
may vary from SoC to SoC. But I do agree on the pain point of context
save/restore work which will happen majority of the times since DeepSleep
platforms are limited as of now.
> I do however not think that such interpretation is necessary, the
> pm_suspend_via_firmware() kernel-doc describes that the firmware might
> perform actions to power down things, it isn't specific about the
> extent, so I think that's fine - while equating this to DeepSleep (SoC
> fully powered down) is too extreme.
>
>
> What bothers me with this patch in itself is that the behavior in
> relation to PCIe does match the description of pm_suspend_via_firmware()
> - the firmware does things which causes PCIe to "break", but IMHO this
> is merely because PCIe operates without voting for the resources that it
> depends on. But you keep telling me that this can't be solved in the PCI
> layer...
>
We do not want to vote for any resources during system suspend from the PCI
layer (host controller driver in specific), and that's the problem (only a few
platforms are exceptions).
Let's say if we have connected a NVMe to the PCIe bus. Since this is a passive
device i.e, not supporting wakeup, we can safely put the PCIe bus into low power
mode (turning off resources) to save power during system suspend (let's
ignore the NVMe driver behavior now). Now the suspend (s2ram) behavior will be:
CXPC - Controller context will be retained by switching the power domain to
always ON domain
DeepSleep - Controller context will be lost once the SoC enters CXPC, since CXPC
is the pre-requisite for entering DeepSleep
So only if the NVMe driver had prepared for the power loss, the driver will
resume successfully, if the platform used DeepSleep.
> If we can agree that pm_suspend_via_firmware() relates to the state of
> CX - and merely the implicit PCSI-owned vote thereof - then I think we
> should merge this patch.
>
Sure. It makes logical sense to relate this API behavior with the state of CX.
I'll send v2 with the updated commit message.
>
> But regardless of this interpretation. If PCI/NVMe relies on the PSCI
> implementation's implicit vote for CX and its absence breaks NVMe during
> suspend, then we're faced with exactly the same problem if the user
> chooses s2idle as their means of suspending the system.
>
From the PCIe controller driver, we are going to keep the votes in s2idle, but
just let go in s2ram.
> I.e. on a Qualcomm platform, we should flag PM_SUSPEND_FLAG_FW_SUSPEND
> in s2idle as well - because from PCI/NVMe's point of view, the relevant
> resources will be gone in either configuration.
>
No they don't, as we do not plan to drop votes in s2idle. So
PM_SUSPEND_FLAG_FW_SUSPEND only applies to s2ram.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 32/33] rust: kbuild: support global per-version flags
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-33-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:53:08 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Sometimes it is useful to gate global Rust flags per compiler version.
> For instance, we may want to disable a lint that has false positives in
> a single version [1].
>
> We already had helpers like `rustc-min-version` for that, which we use
> elsewhere, but we cannot currently use them for `rust_common_flags`,
> which contains the global flags for all Rust code (kernel and host),
> because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which
> does not exist when `rust_common_flags` is defined.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 15/33] rust: macros: simplify code using `feature(extract_if)`
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-16-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:52:51 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> `feature(extract_if)` [1] was stabilized in Rust 1.87.0 [2], and the last
> significant change happened in Rust 1.85.0 [3] when the range parameter
> was added.
>
> That is, with our new minimum version, we can start using the feature.
>
> Thus simplify the code using the feature and remove the TODO comment.
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-8-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:52:43 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> diff --git a/Makefile b/Makefile
> index a63684c36d60..78f5ee173eda 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -486,6 +486,7 @@ export rust_common_flags := --edition=2021 \
> -Wclippy::as_underscore \
> -Wclippy::cast_lossless \
> -Wclippy::ignored_unit_patterns \
> + -Aclippy::incompatible_msrv \
Could you add a reference to the upstream bug report [0] here?
Link: https://github.com/rust-lang/rust-clippy/issues/14425 [0]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 01/33] rust: kbuild: remove `--remap-path-prefix` workarounds
From: Tamir Duberstein @ 2026-04-06 14:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <20260405235309.418950-2-ojeda@kernel.org>
On Mon, 06 Apr 2026 01:52:37 +0200, Miguel Ojeda <ojeda@kernel.org> wrote:
> Commit 8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix
> to make paths relative"") removed `--remap-path-prefix` from the build
> system, so the workarounds are not needed anymore.
>
> Thus remove them.
>
> Note that the flag has landed again in parallel in this cycle in
> commit dda135077ecc ("rust: build: remap path to avoid absolute path"),
> together with `--remap-path-scope=macro` [1]. However, they are gated on
> `rustc-option-yn, --remap-path-scope=macro`, which means they are both
> only passed starting with Rust 1.95.0 [2]:
>
> [...]
Reviewed-by: Tamir Duberstein <tamird@kernel.org>
--
Tamir Duberstein <tamird@kernel.org>
^ permalink raw reply
* [PATCH v2] phy: exynos5-usbdrd: fix USB 2.0 HS PHY tuning values for Exynos7870
From: Łukasz Lebiedziński @ 2026-04-06 13:56 UTC (permalink / raw)
To: vkoul
Cc: neil.armstrong, krzk, alim.akhtar, andre.draszik, pritam.sutar,
kauschluss, johan, ivo.ivanov.ivanov1, linux-phy,
linux-arm-kernel, linux-samsung-soc, linux-kernel,
Łukasz Lebiedziński, stable, Krzysztof Kozlowski
The existing PHYPARAM0 tuning values for Exynos7870 are incorrect,
causing the USB 2.0 PHY to fail high-speed negotiation and fall back
to full-speed (12Mbps) operation.
Fix TXVREFTUNE (transmitter voltage reference) from 14 to 3,
TXRESTUNE (transmitter impedance) from 3 to 2, and SQRXTUNE
(squelch threshold) from 6 to 5. Also explicitly set
TXPREEMPPULSETUNE to 0, which was previously missing from the
tuning table despite being included in the register mask.
All values are derived from the vendor kernel for the Samsung
Galaxy A6 (SM-A600FN), as no public hardware documentation is
available for the Exynos7870 USB DRD PHY. With these corrections,
the PHY successfully negotiates high-speed (480Mbps) operation.
Fixes: 588d5d20ca8d ("phy: exynos5-usbdrd: add exynos7870 USBDRD support")
Cc: stable@vger.kernel.org
Tested-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Łukasz Lebiedziński <kernel@lvkasz.us>
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 5a181cb4597e..8711a3b62c8e 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -1958,13 +1958,14 @@ const struct exynos5_usbdrd_phy_tuning exynos7870_tunes_utmi_postinit[] = {
PHYPARAM0_TXPREEMPAMPTUNE | PHYPARAM0_TXHSXVTUNE |
PHYPARAM0_TXFSLSTUNE | PHYPARAM0_SQRXTUNE |
PHYPARAM0_OTGTUNE | PHYPARAM0_COMPDISTUNE),
- (FIELD_PREP_CONST(PHYPARAM0_TXVREFTUNE, 14) |
+ (FIELD_PREP_CONST(PHYPARAM0_TXVREFTUNE, 3) |
FIELD_PREP_CONST(PHYPARAM0_TXRISETUNE, 1) |
- FIELD_PREP_CONST(PHYPARAM0_TXRESTUNE, 3) |
+ FIELD_PREP_CONST(PHYPARAM0_TXRESTUNE, 2) |
+ FIELD_PREP_CONST(PHYPARAM0_TXPREEMPPULSETUNE, 0) |
FIELD_PREP_CONST(PHYPARAM0_TXPREEMPAMPTUNE, 0) |
FIELD_PREP_CONST(PHYPARAM0_TXHSXVTUNE, 0) |
FIELD_PREP_CONST(PHYPARAM0_TXFSLSTUNE, 3) |
- FIELD_PREP_CONST(PHYPARAM0_SQRXTUNE, 6) |
+ FIELD_PREP_CONST(PHYPARAM0_SQRXTUNE, 5) |
FIELD_PREP_CONST(PHYPARAM0_OTGTUNE, 2) |
FIELD_PREP_CONST(PHYPARAM0_COMPDISTUNE, 3))),
PHY_TUNING_ENTRY_LAST
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Bjorn Andersson @ 2026-04-06 13:48 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, mark.rutland, lpieralisi, bjorn.andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, Konrad Dybcio,
Konrad Dybcio, Sudeep Holla
In-Reply-To: <ces6pczk5yo2v5h6sga2dl2xuncqv4pmudunc7dhyeiy6swfh7@bk7vxdxrsrzz>
On Tue, Mar 31, 2026 at 12:09:38PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 30, 2026 at 03:48:05PM -0500, Bjorn Andersson wrote:
> > On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
> > > From: Konrad Dybcio <konradybcio@kernel.org>
> > >
> > > PSCI specification defines the SYSTEM_SUSPEND feature which enables the
> > > firmware to implement the suspend to RAM (S2RAM) functionality by
> > > transitioning the system to a deeper low power state. When the system
> > > enters such state, the power to the peripheral devices might be removed.
> >
> > What is the actual extent of "peripheral devices" in this definition?
> >
>
> All devices except the ones backing volatile memory (DDR).
>
I do not agree that this should be the interpretation on a Qualcomm
platform.
We do have the corner case of DeepSleep, where this indeed is what will
happen (not sure if other resource votes in the system are ignored
though?). For all typical targets making the PSCI jump might result in
CX being turned off (unless something else votes for it...).
State is still retained on a case-by-case basis and some parts of the
system are still functional when we enter such state - and that is the
system state we desire.
Making the interpretation that all SoC resources will be disabled will
result in a large amount of unnecessary save/restore work, in addition
to breaking many use cases.
I do however not think that such interpretation is necessary, the
pm_suspend_via_firmware() kernel-doc describes that the firmware might
perform actions to power down things, it isn't specific about the
extent, so I think that's fine - while equating this to DeepSleep (SoC
fully powered down) is too extreme.
What bothers me with this patch in itself is that the behavior in
relation to PCIe does match the description of pm_suspend_via_firmware()
- the firmware does things which causes PCIe to "break", but IMHO this
is merely because PCIe operates without voting for the resources that it
depends on. But you keep telling me that this can't be solved in the PCI
layer...
If we can agree that pm_suspend_via_firmware() relates to the state of
CX - and merely the implicit PCSI-owned vote thereof - then I think we
should merge this patch.
But regardless of this interpretation. If PCI/NVMe relies on the PSCI
implementation's implicit vote for CX and its absence breaks NVMe during
suspend, then we're faced with exactly the same problem if the user
chooses s2idle as their means of suspending the system.
I.e. on a Qualcomm platform, we should flag PM_SUSPEND_FLAG_FW_SUSPEND
in s2idle as well - because from PCI/NVMe's point of view, the relevant
resources will be gone in either configuration.
Regards,
Bjorn
> > > So
> > > the respective device drivers must prepare for the possible removal of the
> > > power by performing actions such as shutting down or resetting the device
> > > in their system suspend callbacks.
> > >
> >
> > Our typical interpretation of this state is that IP-blocks might be
> > non-functional during this time, but typically some state is retained.
> >
> > Will the acceptance of this patch result in that we in the Qualcomm case
> > should start accepting/writing patches that implement save/restore of
> > state that is generally retained throughout the drivers - in the name of
> > "power might be removed"?
> >
>
> From the PSCI spec perspective, the underlying implementation of the
> SYSTEM_SUSPEND is implementation defined. So whether the vendor firmware retains
> the state or drops it completely, is out of the scope for PSCI. That's why
> *assuming* that the devices will loose power is the best possible approach.
>
> For sure, assuming that the power will be lost always will result in some
> overhead with drivers saving and restoring the context unnecessarily if the
> power if retained. But I can't think of any other way to make the driver work
> across all firmware implementations.
>
> > > The Linux PM framework allows the platform drivers to convey this info to
> > > device drivers by calling the pm_set_suspend_via_firmware() and
> > > pm_set_resume_via_firmware() APIs.
> > >
> > > Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
> > > mentioned APIs in the psci_system_suspend_begin() and
> > > psci_system_suspend_enter() callbacks.
> > >
> >
> > With the right interpretation of what this means for us, I think this
> > patch looks good - but as we've discussed, I'm a bit worried about how
> > to deal with the alternative interpretations.
> >
>
> Just for the sake of clarity to others, 'alternative interpretations' is
> referring to Qcom DeepSleep firmware implementation, which cuts power to almost
> all components except DDR with no wakeup source other than PMIC.
>
> > Specifically, if we fully adopt "power might be removed", we should to
> > take actions which will prevent a typical Qualcomm system from waking up
> > from sleep again.
> >
>
> I think for wakeup, the driver should just save the device context and call
> enable_irq_wake() if the user has configured the device as a wakeup source and
> assume that the device will wakeup the system from suspend/sleep.
>
> The underlying firmware should honor the wakeup and not cut the power to the
> devices. But if it does, then wakeup will be broken anyway.
>
> So from Qcom drivers perspective:
>
> 1. They should save and restore the context if those drivers are going to be
> used in both PSCI SYSTEM_SUSPEND (power retained) and DeepSleep (power lost)
> firmware implementations.
>
> 2. If the user has configured wakeup, they should enable wakeup using
> enable_irq_wake() during suspend. On PSCI SYSTEM_SUSPEND implementations, wakeup
> should just work, but on DeepSleep, it may not if the power is cut off
> completely. But that's the limitation on those platforms and the OS policy
> should ensure that wakeup is not configured for devices.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] phy: exynos5-usbdrd: fix USB 2.0 HS PHY tuning values for Exynos7870
From: Krzysztof Kozlowski @ 2026-04-06 13:38 UTC (permalink / raw)
To: Łukasz Lebiedziński, vkoul
Cc: neil.armstrong, alim.akhtar, andre.draszik, pritam.sutar,
kauschluss, johan, ivo.ivanov.ivanov1, linux-phy,
linux-arm-kernel, linux-samsung-soc, linux-kernel, stable
In-Reply-To: <20260406070548.132491-1-kernel@lvkasz.us>
On 06/04/2026 09:05, Łukasz Lebiedziński wrote:
> The existing PHYPARAM0 tuning values for Exynos7870 are incorrect,
> causing the USB 2.0 PHY to fail high-speed negotiation and fall back
> to full-speed (12Mbps) operation.
>
> Fix TXVREFTUNE (transmitter voltage reference) from 14 to 3,
> TXRESTUNE (transmitter impedance) from 3 to 2, and SQRXTUNE
> (squelch threshold) from 6 to 5. Also explicitly set
> TXPREEMPPULSETUNE to 0, which was previously missing from the
> tuning table despite being included in the register mask.
>
> All values are derived from the vendor kernel for the Samsung
> Galaxy A6 (SM-A600FN), as no public hardware documentation is
> available for the Exynos7870 USB DRD PHY. With these corrections,
> the PHY successfully negotiates high-speed (480Mbps) operation.
>
> Fixes: 588d5d20ca8d ("phy: exynos5-usbdrd: add exynos7870 USBDRD support")
> Cc: stable@vger.kernel.org
> Tested-by: Łukasz Lebiedziński <kernel@lvkasz.us>
Drop you are the author. This is for 3rd party credits.
> Tested-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> Signed-off-by: Łukasz Lebiedziński <kernel@lvkasz.us>
> ---
> drivers/phy/samsung/phy-exynos5-usbdrd.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> index 5a181cb4597e..8711a3b62c8e 100644
> --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> @@ -1958,13 +1958,14 @@ const struct exynos5_usbdrd_phy_tuning exynos7870_tunes_utmi_postinit[] = {
> PHYPARAM0_TXPREEMPAMPTUNE | PHYPARAM0_TXHSXVTUNE |
> PHYPARAM0_TXFSLSTUNE | PHYPARAM0_SQRXTUNE |
> PHYPARAM0_OTGTUNE | PHYPARAM0_COMPDISTUNE),
> - (FIELD_PREP_CONST(PHYPARAM0_TXVREFTUNE, 14) |
> + (FIELD_PREP_CONST(PHYPARAM0_TXVREFTUNE, 3) |
> FIELD_PREP_CONST(PHYPARAM0_TXRISETUNE, 1) |
> - FIELD_PREP_CONST(PHYPARAM0_TXRESTUNE, 3) |
> + FIELD_PREP_CONST(PHYPARAM0_TXRESTUNE, 2) |
> + FIELD_PREP_CONST(PHYPARAM0_TXPREEMPPULSETUNE, 0) |
> FIELD_PREP_CONST(PHYPARAM0_TXPREEMPAMPTUNE, 0) |
> FIELD_PREP_CONST(PHYPARAM0_TXHSXVTUNE, 0) |
> FIELD_PREP_CONST(PHYPARAM0_TXFSLSTUNE, 3) |
> - FIELD_PREP_CONST(PHYPARAM0_SQRXTUNE, 6) |
> + FIELD_PREP_CONST(PHYPARAM0_SQRXTUNE, 5) |
> FIELD_PREP_CONST(PHYPARAM0_OTGTUNE, 2) |
> FIELD_PREP_CONST(PHYPARAM0_COMPDISTUNE, 3))),
With tags corrected:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL] One more Qualcomm driver update for v7.1
From: Bjorn Andersson @ 2026-04-06 13:21 UTC (permalink / raw)
To: arm, soc; +Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Bjorn Andersson
The following changes since commit d6e766e391ef0b2be62682e007223fc72ba7764f:
Merge branch '20260125-iris-ubwc-v4-1-1ff30644ac81@oss.qualcomm.com' into drivers-for-7.1 (2026-03-30 12:46:14 -0500)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-7.1-2
for you to fetch changes up to a31ad9339eff4ce401dec816b01a94b4e3c47898:
firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X (2026-04-02 16:09:01 -0500)
----------------------------------------------------------------
One more Qualcomm driver update for v7.1
Flag Lenovo IdeaCentre Mini X to have functional QSEECOM/uefisecapp.
----------------------------------------------------------------
Bjorn Andersson (1):
firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X
drivers/firmware/qcom/qcom_scm.c | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [GIT PULL] A few more Arm64 DeviceTree updates for v7.1
From: Bjorn Andersson @ 2026-04-06 13:20 UTC (permalink / raw)
To: arm, soc
Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Paul Sajna,
Wenmeng Liu, Sudarshan Shetty, Bjorn Andersson, Casey Connolly,
Jie Zhang, Abel Vesa, Alexander Martinz, Amir Dahan,
Christopher Brown, Gaurav Kohli, Mukesh Ojha, Odelu Kukatla,
Qingqing Zhou
The following changes since commit b683730e27ba4f91986c4c92f5cb7297f1e01a6d:
arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP (2026-03-30 09:35:01 -0500)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-7.1-2
for you to fetch changes up to af241225893ac4933bb8f0615f2dfda8ea2326ce:
arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X (2026-04-02 16:08:54 -0500)
----------------------------------------------------------------
A few more Arm64 DeviceTree updates for v7.1
Introduce the Hamoa-based Lenovo IdeaCentre Mini X, the Dragonwing
IQ-615 (Talos) EVK, and a Talos EVK camera overlay.
Enable DisplayPort support on the Glymur CRD.
Add WiFi, Bluetooh, LEDs, and venus on LG-based SDM845 devices. Add
battery, charger, and display on the LG G7 ThinQ.
Enable SD-card, describe the audio amplifier, and increase the speed of
the i2c clock for touchscreen on the SHIFT SHIFT6mq.
Add camera subsystem, camera control interface, GPU, GMU, and GPU
cooling on the Talos platform. Enable the GPU on the Ride board.
----------------------------------------------------------------
Abel Vesa (1):
arm64: dts: qcom: glymur-crd: Enable DisplayPort support
Alexander Martinz (1):
arm64: dts: qcom: sdm845-shift-axolotl: Enable TFA9890 codec
Amir Dahan (1):
arm64: dts: qcom: sdm845-lg-common: Add LEDs
Bjorn Andersson (2):
dt-bindings: arm: qcom: Document the Lenovo IdeaCentre Mini X
arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X
Casey Connolly (2):
arm64: dts: qcom: sdm845-shift-axolotl: Enable sdcard
arm64: dts: qcom: sdm845-shift-axolotl: Set higher touchscreen i2c clock
Christopher Brown (1):
arm64: dts: qcom: sdm845-lg-judyln: Add battery and charger
Gaurav Kohli (1):
arm64: dts: qcom: talos: Add GPU cooling
Jie Zhang (2):
arm64: dts: qcom: talos: Add gpu and rgmu nodes
arm64: dts: qcom: qcs615-ride: Enable Adreno 612 GPU
Mukesh Ojha (1):
arm64: dts: qcom: talos: Add EL2 overlay
Odelu Kukatla (1):
arm64: dts: qcom: talos: Add clocks for QoS configuration
Paul Sajna (10):
arm64: dts: qcom: sdm845-lg-common: Sort nodes and properties
arm64: dts: qcom: sdm845-lg-judyln: Add firmware nodes, change path
arm64: dts: qcom: sdm845-lg-judyp: Define firmware paths for judyp
arm64: dts: qcom: sdm845-lg-common: Enable venus
arm64: dts: qcom: sdm845-lg-common: Enable qups and their dma controllers
arm64: dts: qcom: sdm845-lg: Add uarts and Bluetooth
arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibb
arm64: dts: qcom: sdm845-lg-judyln: Add display panel
arm64: dts: qcom: sdm845-lg: Add wifi nodes
arm64: dts: qcom: sdm845-lg-common: Add chassis-type
Qingqing Zhou (1):
arm64: dts: qcom: talos: add the GPU SMMU node
Sudarshan Shetty (3):
dt-bindings: arm: qcom: talos-evk: Add QCS615 Talos EVK SMARC platform
arm64: dts: qcom: talos/qcs615-ride: Fix inconsistent USB PHY node naming
arm64: dts: qcom: talos-evk: Add support for QCS615 talos evk board
Wenmeng Liu (4):
arm64: dts: qcom: talos: Add camss node
arm64: dts: qcom: talos: Add CCI definitions
arm64: dts: qcom: talos: Add camera MCLK pinctrl
arm64: dts: qcom: talos-evk-camera: Add DT overlay
Documentation/devicetree/bindings/arm/qcom.yaml | 2 +
arch/arm64/boot/dts/qcom/Makefile | 14 +
arch/arm64/boot/dts/qcom/glymur-crd.dts | 16 +
.../qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts | 1200 ++++++++++++++++++++
arch/arm64/boot/dts/qcom/qcs615-ride.dts | 10 +-
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 210 +++-
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 127 ++-
arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts | 28 +-
arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts | 59 +
arch/arm64/boot/dts/qcom/talos-el2.dtso | 25 +
.../boot/dts/qcom/talos-evk-camera-imx577.dtso | 63 +
.../dts/qcom/talos-evk-lvds-auo,g133han01.dtso | 127 +++
arch/arm64/boot/dts/qcom/talos-evk-som.dtsi | 617 ++++++++++
.../boot/dts/qcom/talos-evk-usb1-peripheral.dtso | 27 +
arch/arm64/boot/dts/qcom/talos-evk.dts | 139 +++
arch/arm64/boot/dts/qcom/talos.dtsi | 436 ++++++-
16 files changed, 3033 insertions(+), 67 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts
create mode 100644 arch/arm64/boot/dts/qcom/talos-el2.dtso
create mode 100644 arch/arm64/boot/dts/qcom/talos-evk-camera-imx577.dtso
create mode 100644 arch/arm64/boot/dts/qcom/talos-evk-lvds-auo,g133han01.dtso
create mode 100644 arch/arm64/boot/dts/qcom/talos-evk-som.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/talos-evk-usb1-peripheral.dtso
create mode 100644 arch/arm64/boot/dts/qcom/talos-evk.dts
^ permalink raw reply
* Re: [PATCH v2 8/8] mips: dts: Add PCIe to EcoNet EN751221
From: Thomas Bogendoerfer @ 2026-04-06 12:37 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-mips, naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt,
ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani, bhelgaas,
vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
In-Reply-To: <20260309131818.74467-9-cjd@cjdns.fr>
On Mon, Mar 09, 2026 at 01:18:18PM +0000, Caleb James DeLisle wrote:
> Add PCIe based on EN7528 PCIe driver, also add two MT76 wifi devices
> to SmartFiber XP8421-B.
>
> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
> ---
> arch/mips/boot/dts/econet/en751221.dtsi | 114 ++++++++++++++++++
> .../econet/en751221_smartfiber_xp8421-b.dts | 21 ++++
> arch/mips/econet/Kconfig | 2 +
> 3 files changed, 137 insertions(+)
>
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 3/3] mips: pci-mt7620: rework initialization procedure
From: Thomas Bogendoerfer @ 2026-04-06 12:29 UTC (permalink / raw)
To: Shiji Yang
Cc: linux-mips, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <OSBPR01MB167090804D80D1166900D7BCBC72A@OSBPR01MB1670.jpnprd01.prod.outlook.com>
On Wed, Jun 18, 2025 at 11:42:07AM +0800, Shiji Yang wrote:
> Move the reset operation to the common part to reduce the code
> redundancy. They are actually the same and needed for all SoCs.
> Disabling power and clock are unnecessary for MT7620 and will be
> removed. In vendor SDK, it's used to save the power when the PCI
> driver is not selected. The MT7628 GPIO pinctrl has been removed
> because this should be done in device-tree. Some delay intervals
> have also been increased to follow the recommendations of the SoC
> SDK and datasheet. Tested on both MT7620 and MT7628.
>
> Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
> ---
> arch/mips/pci/pci-mt7620.c | 38 +++++++++++++-------------------------
> 1 file changed, 13 insertions(+), 25 deletions(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 1/3] mips: pci-mt7620: fix bridge register access
From: Thomas Bogendoerfer @ 2026-04-06 12:28 UTC (permalink / raw)
To: Shiji Yang
Cc: linux-mips, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <OSBPR01MB1670555F549B69B9A5E7F133BC72A@OSBPR01MB1670.jpnprd01.prod.outlook.com>
On Wed, Jun 18, 2025 at 11:42:05AM +0800, Shiji Yang wrote:
> Host bridge registers and PCI RC control registers have different
> memory base. pcie_m32() is used to write the RC control registers
> instead of bridge registers. This patch introduces bridge_m32()
> and use it to operate bridge registers to fix the access issue.
>
> Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
> ---
> arch/mips/pci/pci-mt7620.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 2/3] mips: pci-mt7620: add more register init values
From: Thomas Bogendoerfer @ 2026-04-06 12:29 UTC (permalink / raw)
To: Shiji Yang
Cc: linux-mips, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <OSBPR01MB167036A58FE6FB745311AF5FBC72A@OSBPR01MB1670.jpnprd01.prod.outlook.com>
On Wed, Jun 18, 2025 at 11:42:06AM +0800, Shiji Yang wrote:
> These missing register init values are ported from the vendor SDK.
> It should have some stability enhancements. Tested on both MT7620
> and MT7628.
>
> Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
> ---
> arch/mips/pci/pci-mt7620.c | 59 +++++++++++++++++++++++++++++---------
> 1 file changed, 46 insertions(+), 13 deletions(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v5 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Frank Li @ 2026-04-06 10:54 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <20260327-pinctrl-mux-v5-0-d4aec9d62c62@nxp.com>
On Fri, Mar 27, 2026 at 05:33:57PM -0400, Frank Li wrote:
Linus Walleij:
Any chance to pick this for 7.1?
Frank
>
^ permalink raw reply
* [PATCH net-next v3 12/12] net: airoha: Rename get_src_port_id callback in get_sport
From: Lorenzo Bianconi @ 2026-04-06 10:34 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
For code consistency, rename get_src_port_id callback in get_sport.
Please note this patch does not introduce any logical change and it is
just a cosmetic patch.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 12 ++++++------
drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 9988011dca53..c14dee3c9bfb 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1770,7 +1770,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
- src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
+ src_port = eth->soc->ops.get_sport(port, dev->nbq);
if (src_port < 0)
return src_port;
@@ -3102,7 +3102,7 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
/* Verify the provided nbq parameter is valid */
nbq = be32_to_cpup(nbq_ptr);
- err = eth->soc->ops.get_src_port_id(port, nbq);
+ err = eth->soc->ops.get_sport(port, nbq);
if (err < 0) {
of_node_put(node);
return err;
@@ -3309,7 +3309,7 @@ static const char * const en7581_xsi_rsts_names[] = {
"xfp-mac",
};
-static int airoha_en7581_get_src_port_id(struct airoha_gdm_port *port, int nbq)
+static int airoha_en7581_get_sport(struct airoha_gdm_port *port, int nbq)
{
switch (port->id) {
case AIROHA_GDM3_IDX:
@@ -3373,7 +3373,7 @@ static const char * const an7583_xsi_rsts_names[] = {
"xfp-mac",
};
-static int airoha_an7583_get_src_port_id(struct airoha_gdm_port *port, int nbq)
+static int airoha_an7583_get_sport(struct airoha_gdm_port *port, int nbq)
{
switch (port->id) {
case AIROHA_GDM3_IDX:
@@ -3431,7 +3431,7 @@ static const struct airoha_eth_soc_data en7581_soc_data = {
.num_xsi_rsts = ARRAY_SIZE(en7581_xsi_rsts_names),
.num_ppe = 2,
.ops = {
- .get_src_port_id = airoha_en7581_get_src_port_id,
+ .get_sport = airoha_en7581_get_sport,
.get_dev_from_sport = airoha_en7581_get_dev_from_sport,
},
};
@@ -3442,7 +3442,7 @@ static const struct airoha_eth_soc_data an7583_soc_data = {
.num_xsi_rsts = ARRAY_SIZE(an7583_xsi_rsts_names),
.num_ppe = 1,
.ops = {
- .get_src_port_id = airoha_an7583_get_src_port_id,
+ .get_sport = airoha_an7583_get_sport,
.get_dev_from_sport = airoha_an7583_get_dev_from_sport,
},
};
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 8dec25fa0478..ec31a3b5efc3 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -591,7 +591,7 @@ struct airoha_eth_soc_data {
int num_xsi_rsts;
int num_ppe;
struct {
- int (*get_src_port_id)(struct airoha_gdm_port *port, int nbq);
+ int (*get_sport)(struct airoha_gdm_port *port, int nbq);
int (*get_dev_from_sport)(struct airoha_qdma_desc *desc,
u16 *port, u16 *dev);
} ops;
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 11/12] net: airoha: Introduce WAN device flag
From: Lorenzo Bianconi @ 2026-04-06 10:34 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
Introduce WAN flag to specify if a given device is used to transmit/receive
WAN or LAN traffic. Current codebase supports specifying LAN/WAN device
configuration in ndo_init() callback during device bootstrap.
Please note it is possible to specify multiple LAN devices but just a
single WAN one.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 69 +++++++++++++++++++++++++-------
drivers/net/ethernet/airoha/airoha_eth.h | 13 +++---
drivers/net/ethernet/airoha/airoha_ppe.c | 2 +-
3 files changed, 62 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5b0cd37b155e..9988011dca53 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1796,36 +1796,77 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
return 0;
}
-static int airoha_dev_init(struct net_device *netdev)
+static struct airoha_gdm_dev *
+airoha_get_wan_gdm_dev(struct airoha_eth *eth)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
+ struct airoha_gdm_port *port = eth->ports[i];
+ int j;
+
+ if (!port)
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
+ struct airoha_gdm_dev *dev = port->devs[j];
+
+ if (dev && !airoha_is_lan_gdm_dev(dev))
+ return dev;
+ }
+ }
+
+ return NULL;
+}
+
+static void airoha_dev_set_qdma(struct airoha_gdm_dev *dev)
{
- struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_gdm_port *port = dev->port;
struct airoha_eth *eth = dev->eth;
int i;
/* QDMA0 is used for lan ports while QDMA1 is used for WAN ports */
dev->qdma = ð->qdma[!airoha_is_lan_gdm_dev(dev)];
dev->dev->irq = dev->qdma->irq_banks[0].irq;
- airoha_set_macaddr(dev, netdev->dev_addr);
+
+ for (i = 0; i < eth->soc->num_ppe; i++)
+ airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
+}
+
+static int airoha_dev_init(struct net_device *netdev)
+{
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_gdm_port *port = dev->port;
switch (port->id) {
case AIROHA_GDM3_IDX:
- case AIROHA_GDM4_IDX:
- /* If GDM2 is active we can't enable loopback */
- if (!eth->ports[1]) {
- int err;
+ case AIROHA_GDM4_IDX: {
+ struct airoha_eth *eth = dev->eth;
- err = airoha_set_gdm2_loopback(dev);
- if (err)
- return err;
- }
+ if (eth->ports[1] || airoha_get_wan_gdm_dev(eth))
+ break;
+ fallthrough;
+ }
+ case AIROHA_GDM2_IDX:
+ /* GDM2 is always used as wan */
+ dev->flags |= PRIV_FLAG_WAN;
break;
default:
break;
}
- for (i = 0; i < eth->soc->num_ppe; i++)
- airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
+ airoha_dev_set_qdma(dev);
+ airoha_set_macaddr(dev, netdev->dev_addr);
+
+ if (!airoha_is_lan_gdm_dev(dev) &&
+ (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
+ int err;
+
+ err = airoha_set_gdm2_loopback(dev);
+ if (err) {
+ dev->flags &= ~PRIV_FLAG_WAN;
+ return err;
+ }
+ }
return 0;
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 3e77bbae630a..8dec25fa0478 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -533,12 +533,17 @@ struct airoha_qdma {
struct airoha_queue q_rx[AIROHA_NUM_RX_RING];
};
+enum airoha_priv_flags {
+ PRIV_FLAG_WAN = BIT(0),
+};
+
struct airoha_gdm_dev {
struct airoha_gdm_port *port;
struct airoha_qdma *qdma;
struct airoha_eth *eth;
struct net_device *dev;
+ u32 flags;
int nbq;
};
@@ -642,13 +647,7 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
static inline bool airoha_is_lan_gdm_dev(struct airoha_gdm_dev *dev)
{
- struct airoha_gdm_port *port = dev->port;
-
- /* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
- * GDM{2,3,4} can be used as wan port connected to an external
- * phy module.
- */
- return port->id == 1;
+ return !(dev->flags & PRIV_FLAG_WAN);
}
static inline bool airoha_is_7581(struct airoha_eth *eth)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index a6b188fab053..87bb20b6ee49 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -343,7 +343,7 @@ static int airoha_ppe_foe_entry_prepare(struct airoha_eth *eth,
return -EINVAL;
port = dev->port;
- if (dsa_port >= 0 || eth->ports[1])
+ if (dsa_port >= 0 || airoha_is_lan_gdm_dev(dev))
pse_port = port->id == 4 ? FE_PSE_PORT_GDM4
: port->id;
else
--
2.53.0
^ 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