* [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
* 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
* 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
* [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 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
* 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 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 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] 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
* [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
* [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 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 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 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
* [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
* 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
* 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 0/2] hwspinlock: remove platform_data from subsystem
From: Bjorn Andersson @ 2026-04-06 15:10 UTC (permalink / raw)
To: linux-renesas-soc, Wolfram Sang
Cc: linux-arm-kernel, Baolin Wang, linux-remoteproc, Russell King
In-Reply-To: <20260401071141.4718-1-wsa+renesas@sang-engineering.com>
On Wed, 01 Apr 2026 09:11:38 +0200, Wolfram Sang wrote:
> This series removes the use of platform_data from the hwspinlock
> subsystem. First, the last user is removed because it turned out to be
> obsolete. Then, platform_data support is removed from the header.
>
> This has been in a larger refactoring series before. But this
> refactoring turns out to be a rabbit hole where more and more fixes are
> needed before I can do the actual refactoring.
>
> [...]
Applied, thanks!
[1/2] hwspinlock: u8500: delete driver
commit: 392035c8b88b0198721e3b273f0a19ec2150710f
[2/2] hwspinlock: remove now unused pdata from header file
commit: ad5fd5aeb65a4426635cf55ef06c96e60a66e648
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
From: Simon Horman @ 2026-04-06 15:25 UTC (permalink / raw)
To: lorenzo
Cc: 'Simon Horman', andrew+netdev, davem, edumazet, kuba,
pabeni, xuegang.lu, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260403-airoha_qdma_rx_process-fix-reordering-v2-1-181e6e23d27b@kernel.org>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
This commit adds a missing dma_rmb() to ensure DMA read operations are
completed and uses READ_ONCE() to prevent compiler reordering when accessing
descriptor fields.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 95ba99b89428e..f1843bc5b9914 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -612,15 +611,17 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> while (done < budget) {
> struct airoha_queue_entry *e = &q->entry[q->tail];
> struct airoha_qdma_desc *desc = &q->desc[q->tail];
> - u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> - struct page *page = virt_to_head_page(e->buf);
> - u32 desc_ctrl = le32_to_cpu(desc->ctrl);
> + u32 hash, reason, msg1, desc_ctrl;
> struct airoha_gdm_port *port;
> int data_len, len, p;
> + struct page *page;
>
> + desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
> if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> break;
[ ... ]
> @@ -633,10 +634,12 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> if (!len || data_len < len)
> goto free_frag;
Could this jump lead to an uninitialized pointer dereference?
The initialization of page was removed from the declarations above, so it
is uninitialized at this point.
Later in the function, the error path looks like this:
free_frag:
if (q->skb) {
dev_kfree_skb(q->skb);
q->skb = NULL;
} else {
page_pool_put_full_page(q->page_pool, page, true);
}
If q->skb is NULL, passing the uninitialized page to
page_pool_put_full_page() might cause a crash.
Also, this isn't a bug introduced by this patch, but does this error path
leak the page associated with the current descriptor?
If we hit an error on a scattered fragment while q->skb is not NULL, the
SKB is freed, but the current page (which hasn't been attached to the SKB
yet) bypasses the else branch and isn't returned to the page pool.
>
> - p = airoha_qdma_get_gdm_port(eth, desc);
> + msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
> + p = airoha_qdma_get_gdm_port(eth, msg1);
> if (p < 0 || !eth->ports[p])
> goto free_frag;
Similarly, taking this jump leaves page uninitialized before reaching the
error handling path.
>
> + page = virt_to_head_page(e->buf);
> port = eth->ports[p];
> if (!q->skb) { /* first buffer */
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags
From: Marek Vasut @ 2026-04-06 14:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang,
Viorel Suman, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-5-krzysztof.kozlowski@oss.qualcomm.com>
On 4/6/26 8:38 AM, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Marek Vasut <marex@nabladev.com>
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags
From: Marek Vasut @ 2026-04-06 14:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang,
Viorel Suman, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-4-krzysztof.kozlowski@oss.qualcomm.com>
On 4/6/26 8:38 AM, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Marek Vasut <marex@nabladev.com>
^ permalink raw reply
* Re: [PATCH RFC 0/2] clk: scmi: DT support for SCMI clock rate rounding modes (per‑clock policy)
From: Brian Masney @ 2026-04-06 15:38 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sudeep Holla, Cristian Marussi, linux-kernel,
linux-clk, devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <20260306-scmi-clk-round-v1-0-61e2a5df9051@nxp.com>
Hi Peng,
On Fri, Mar 06, 2026 at 02:20:11PM +0800, Peng Fan (OSS) wrote:
> The ARM SCMI specification (DEN0056E) defines rounding‑mode flags for the
> CLOCK_RATE_SET command, allowing a client to request that the firmware
> round a requested clock rate down, up, or autonomously choose the
> closest achievable rate.
> This series introduces DT support in the SCMI clock provider to carry a
> per‑clock rounding policy from the device tree into the SCMI protocol.
>
> Patch 1 adds dt‑bindings constants for rounding modes:
> ROUND_DOWN, ROUND_UP, ROUND_AUTO.
>
> Patch 2 extends the SCMI clock provider to optionally support
> "#clock-cells = <2>", where the second cell encodes the rounding mode.
> The first consumer that references a given clock latches the per‑clock
> policy. Subsequent consumers of the same clock must specify the same
> mode; otherwise, the request is rejected to avoid non‑deterministic
> behavior. The selected mode is passed through to the SCMI Clock protocol
> and mapped to the corresponding CLOCK_SET_* flag.
>
> Patch 2 includes changes to drivers/clk/clk-scmi.c and drivers/firmware
> arm_scmi/clock.c, it is hard to separate the changes without breaking,
> so I put the changes in one patch.
>
> This design adopts a per‑clock policy model, not per‑consumer. The rounding
> mode is applied by the provider per clock (index).
> All consumers of the same clock must agree on the rounding mode.
> Conflicting per‑consumer requests for the same clock are invalid and
> are rejected during phandle translation.
>
> This avoids silent clobbering and preserves deterministic behavior.
>
> Existing device trees using #clock-cells = <1> continue to work and
> default to ROUND_DOWN, exactly as before.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
My high level feedback about this:
1) Since you are making changes to the DT schema for the clock-cells,
does the SCMI DT schema document also need to be updated to allow
clock-cells to be 1 or 2?
2) For the ROUND_XXX constants, I would prefix them with something
since the existing ROUND names are fairly generic sounding. Maybe
CLK_SCMI_?
Brian
^ permalink raw reply
* Re: [PATCH v2] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Jakub Kicinski @ 2026-04-06 15:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Julian Braha, davem, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, linux, netdev, linux-arm-kernel, linux-kernel,
Russell King (Oracle)
In-Reply-To: <CAMuHMdUfzVSQpadJYpEqPJ_UOBAgswnGzD_bp_U3U6jt2dy0dg@mail.gmail.com>
On Mon, 6 Apr 2026 10:23:46 +0200 Geert Uytterhoeven wrote:
> > config STMMAC_PLATFORM
> > tristate "STMMAC Platform bus support"
> > - depends on STMMAC_ETH
> > select MFD_SYSCON
> > default y
>
> This now lets us have STMMAC_PLATFORM=y and STMMAC_ETH=m.
> Does that actually link?
Hm. Sashiko didn't complain when patch was posted.
Typical LLM indeterminism?
^ permalink raw reply
* [RFC][PATCH] firmware: arm_scmi: Rename struct scmi_revision_info to scmi_base_info
From: Marek Vasut @ 2026-04-06 15:52 UTC (permalink / raw)
To: arm-scmi
Cc: Marek Vasut, Cristian Marussi, Geert Uytterhoeven, Sudeep Holla,
linux-arm-kernel, linux-renesas-soc
Rename struct scmi_revision_info to struct scmi_base_info , to
accurately represent its content. The scmi_revision_info is no
longer accurate, because the structure now contains more than
only SCMI base protocol revision, it now also contains number
of protocols, agents, vendor and subvendor strings. All those
are fetched from the base protocol, so rename the structure to
scmi_base_info, to match the other scmi_*_info structure names.
No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Sudeep Holla <sudeep.holla@kernel.org>
Cc: arm-scmi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/firmware/arm_scmi/base.c | 10 +++++-----
drivers/firmware/arm_scmi/common.h | 2 +-
drivers/firmware/arm_scmi/driver.c | 14 +++++++-------
include/linux/scmi_protocol.h | 6 +++---
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
index cd1331c2fc403..4df2620e3c5d0 100644
--- a/drivers/firmware/arm_scmi/base.c
+++ b/drivers/firmware/arm_scmi/base.c
@@ -69,7 +69,7 @@ static int scmi_base_attributes_get(const struct scmi_protocol_handle *ph)
int ret;
struct scmi_xfer *t;
struct scmi_msg_resp_base_attributes *attr_info;
- struct scmi_revision_info *rev = ph->get_priv(ph);
+ struct scmi_base_info *rev = ph->get_priv(ph);
ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES,
0, sizeof(*attr_info), &t);
@@ -103,7 +103,7 @@ scmi_base_vendor_id_get(const struct scmi_protocol_handle *ph, bool sub_vendor)
int ret, size;
char *vendor_id;
struct scmi_xfer *t;
- struct scmi_revision_info *rev = ph->get_priv(ph);
+ struct scmi_base_info *rev = ph->get_priv(ph);
if (sub_vendor) {
cmd = BASE_DISCOVER_SUB_VENDOR;
@@ -143,7 +143,7 @@ scmi_base_implementation_version_get(const struct scmi_protocol_handle *ph)
int ret;
__le32 *impl_ver;
struct scmi_xfer *t;
- struct scmi_revision_info *rev = ph->get_priv(ph);
+ struct scmi_base_info *rev = ph->get_priv(ph);
ret = ph->xops->xfer_get_init(ph, BASE_DISCOVER_IMPLEMENT_VERSION,
0, sizeof(*impl_ver), &t);
@@ -180,7 +180,7 @@ scmi_base_implementation_list_get(const struct scmi_protocol_handle *ph,
__le32 *num_skip, *num_ret;
u32 tot_num_ret = 0, loop_num_ret;
struct device *dev = ph->dev;
- struct scmi_revision_info *rev = ph->get_priv(ph);
+ struct scmi_base_info *rev = ph->get_priv(ph);
ret = ph->xops->xfer_get_init(ph, BASE_DISCOVER_LIST_PROTOCOLS,
sizeof(*num_skip), 0, &t);
@@ -377,7 +377,7 @@ static int scmi_base_protocol_init(const struct scmi_protocol_handle *ph)
u8 *prot_imp;
char name[SCMI_SHORT_NAME_MAX_SIZE];
struct device *dev = ph->dev;
- struct scmi_revision_info *rev = scmi_revision_area_get(ph);
+ struct scmi_base_info *rev = scmi_revision_area_get(ph);
rev->major_ver = PROTOCOL_REV_MAJOR(ph->version);
rev->minor_ver = PROTOCOL_REV_MINOR(ph->version);
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 7c9617d080a02..07a127dec0319 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -138,7 +138,7 @@ static inline void unpack_scmi_header(u32 msg_hdr, struct scmi_msg_hdr *hdr)
xfer_; \
})
-struct scmi_revision_info *
+struct scmi_base_info *
scmi_revision_area_get(const struct scmi_protocol_handle *ph);
void scmi_setup_protocol_implemented(const struct scmi_protocol_handle *ph,
u8 *prot_imp);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 57785c0c04241..00329935926d3 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -134,7 +134,7 @@ struct scmi_protocol_instance {
* usage.
* @protocols_mtx: A mutex to protect protocols instances initialization.
* @protocols_imp: List of protocols implemented, currently maximum of
- * scmi_revision_info.num_protocols elements allocated by the
+ * scmi_base_info.num_protocols elements allocated by the
* base protocol
* @active_protocols: IDR storing device_nodes for protocols actually defined
* in the DT and confirmed as implemented by fw.
@@ -152,7 +152,7 @@ struct scmi_info {
int id;
struct device *dev;
const struct scmi_desc *desc;
- struct scmi_revision_info version;
+ struct scmi_base_info version;
struct scmi_handle handle;
struct scmi_xfers_info tx_minfo;
struct scmi_xfers_info rx_minfo;
@@ -266,7 +266,7 @@ scmi_vendor_protocol_lookup(int protocol_id, char *vendor_id,
}
static const struct scmi_protocol *
-scmi_vendor_protocol_get(int protocol_id, struct scmi_revision_info *version)
+scmi_vendor_protocol_get(int protocol_id, struct scmi_base_info *version)
{
const struct scmi_protocol *proto;
@@ -304,7 +304,7 @@ scmi_vendor_protocol_get(int protocol_id, struct scmi_revision_info *version)
}
static const struct scmi_protocol *
-scmi_protocol_get(int protocol_id, struct scmi_revision_info *version)
+scmi_protocol_get(int protocol_id, struct scmi_base_info *version)
{
const struct scmi_protocol *proto = NULL;
@@ -2095,7 +2095,7 @@ static const struct scmi_proto_helpers_ops helpers_ops = {
* Return: A reference to the version memory area associated to the SCMI
* instance underlying this protocol handle.
*/
-struct scmi_revision_info *
+struct scmi_base_info *
scmi_revision_area_get(const struct scmi_protocol_handle *ph)
{
const struct scmi_protocol_instance *pi = ph_to_pi(ph);
@@ -2408,7 +2408,7 @@ scmi_is_protocol_implemented(const struct scmi_handle *handle, u8 prot_id)
{
int i;
struct scmi_info *info = handle_to_scmi_info(handle);
- struct scmi_revision_info *rev = handle->version;
+ struct scmi_base_info *rev = handle->version;
if (!info->protocols_imp)
return false;
@@ -3203,7 +3203,7 @@ static const struct scmi_desc *scmi_transport_setup(struct device *dev)
static void scmi_enable_matching_quirks(struct scmi_info *info)
{
- struct scmi_revision_info *rev = &info->version;
+ struct scmi_base_info *rev = &info->version;
dev_dbg(info->dev, "Looking for quirks matching: %s/%s/0x%08X\n",
rev->vendor_id, rev->sub_vendor_id, rev->impl_ver);
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index c710107c2120a..49cc39e0cbca5 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -17,7 +17,7 @@
#define SCMI_SHORT_NAME_MAX_SIZE 16
/**
- * struct scmi_revision_info - version information structure
+ * struct scmi_base_info - version information structure
*
* @major_ver: Major ABI version. Change here implies risk of backward
* compatibility break.
@@ -30,7 +30,7 @@
* @vendor_id: A vendor identifier(Null terminated ASCII string)
* @sub_vendor_id: A sub-vendor identifier(Null terminated ASCII string)
*/
-struct scmi_revision_info {
+struct scmi_base_info {
u16 major_ver;
u16 minor_ver;
u8 num_protocols;
@@ -906,7 +906,7 @@ struct scmi_notify_ops {
*/
struct scmi_handle {
struct device *dev;
- struct scmi_revision_info *version;
+ struct scmi_base_info *version;
int __must_check (*devm_protocol_acquire)(struct scmi_device *sdev,
u8 proto);
--
2.53.0
^ permalink raw reply related
* Re: [PATCHv2] clk: mvebu: use kzalloc_flex
From: Brian Masney @ 2026-04-06 16:22 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260403194701.11902-1-rosenp@gmail.com>
Hi Rosen,
On Fri, Apr 03, 2026 at 12:47:01PM -0700, Rosen Penev wrote:
> Use a flexible array member to combine kzalloc and kcalloc in one
> allocation so they can be freed together.
>
> Add __counted_by for extra runtime analysis. Move counting variable
> assignment right after allocation as done by kzalloc_flex with GCC >=
> 15.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> v2: remove now unused goto label.
Reviewed-by: Brian Masney <bmasney@redhat.com>
This is the third time that I've asked you this [1]: For the future, if
someone asks for changes in a previous version, then be sure to CC them
on the next revision. I was the one that found the unused goto in v1.
[1] https://lore.kernel.org/linux-clk/acvUoSOOF_9UQC75@redhat.com/
https://lore.kernel.org/linux-clk/ac0o7XbBm8aBOa7a@redhat.com/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox