* [PATCH v2 3/8] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
From: Ronald Claveau @ 2026-04-03 16:08 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260403-add-mcu-fan-khadas-vim4-v2-0-70536b22439a@aliel.fr>
Introduce a per-variant configuration structure (khadas_mcu_data)
holding the regmap config and MFD cells,
selected at probe time via the of_device_id match data.
This makes adding other variants straightforward.
Also introduce khadas_mcu_fan_pdata to pass fan register address and
maximum level to the fan sub-driver, removing the hardcoded constants.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/mfd/khadas-mcu.h | 39 +++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/khadas-mcu.h b/include/linux/mfd/khadas-mcu.h
index a99ba2ed0e4e0..75e275d3fa8d9 100644
--- a/include/linux/mfd/khadas-mcu.h
+++ b/include/linux/mfd/khadas-mcu.h
@@ -70,6 +70,13 @@
#define KHADAS_MCU_WOL_INIT_START_REG 0x87 /* WO */
#define KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG 0x88 /* WO */
+/* VIM4 specific registers */
+#define KHADAS_MCU_VIM4_REST_CONF_REG 0x2c /* WO - reset EEPROM */
+#define KHADAS_MCU_VIM4_LED_ON_RAM_REG 0x89 /* WO - LED volatile */
+#define KHADAS_MCU_VIM4_FAN_CTRL_REG 0x8a /* WO */
+#define KHADAS_MCU_VIM4_WDT_EN_REG 0x8b /* WO */
+#define KHADAS_MCU_VIM4_SYS_RST_REG 0x91 /* WO */
+
enum {
KHADAS_BOARD_VIM1 = 0x1,
KHADAS_BOARD_VIM2,
@@ -82,10 +89,38 @@ enum {
* struct khadas_mcu - Khadas MCU structure
* @device: device reference used for logs
* @regmap: register map
+ * @data: pointer to variant-specific config
*/
struct khadas_mcu {
- struct device *dev;
- struct regmap *regmap;
+ struct device *dev;
+ struct regmap *regmap;
+ const struct khadas_mcu_data *data;
+};
+
+/**
+ * struct khadas_mcu_data - per-variant configuration
+ * @regmap_config: regmap configuration
+ * @cells: MFD sub-devices
+ * @ncells: number of sub-devices
+ * @fan_cells: MFD fan sub-devices
+ * @nfan_cells: number of fan sub-devices
+ */
+struct khadas_mcu_data {
+ const struct regmap_config *regmap_config;
+ const struct mfd_cell *cells;
+ int ncells;
+ const struct mfd_cell *fan_cells;
+ int nfan_cells;
+};
+
+/**
+ * struct khadas_mcu_fan_pdata - fan sub-driver configuration
+ * @fan_reg: register address to write the fan level
+ * @max_level: maximum fan level
+ */
+struct khadas_mcu_fan_pdata {
+ unsigned int fan_reg;
+ unsigned int max_level;
};
#endif /* MFD_KHADAS_MCU_H */
--
2.49.0
^ permalink raw reply related
* [PATCH v2 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Ronald Claveau @ 2026-04-03 16:08 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260403-add-mcu-fan-khadas-vim4-v2-0-70536b22439a@aliel.fr>
Add the T7 SOC compatible which fallback to AXG compatible.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
index c4cc8af182807..7b59b60b62e5b 100644
--- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -16,10 +16,15 @@ allOf:
properties:
compatible:
- enum:
- - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
- - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
- - amlogic,meson-axg-i2c # AXG and compatible SoCs
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-i2c
+ - const: amlogic,meson-axg-i2c
+ - enum:
+ - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
+ - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
+ - amlogic,meson-axg-i2c # AXG and compatible SoCs
reg:
maxItems: 1
--
2.49.0
^ permalink raw reply related
* [PATCH v2 0/8] Add VIM4 MCU/FAN support
From: Ronald Claveau @ 2026-04-03 16:08 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
The Khadas VIM4 board features a different MCU variant compared to
previous VIM boards.
While it shares the same I2C-based communication model,
it differs in some ways:
- A distinct register map with its own volatile/writeable register set
- A fan control with 0–100 levels instead of the 0–3 levels previously
- A fan power supply gated through a regulator
This series adds support for this new variant by:
1. Refactoring the khadas-mcu MFD driver to use per-variant data
structures (regmap config, cells, fan platform data),
and adding the khadas,vim4-mcu compatible string.
2. Extending the fan thermal driver to retrieve the fan register
and maximum level from platform_data,
and to optionally manage a power regulator for the fan supply.
3. Adding the corresponding DTS node for the VIM4, wiring the MCU to
the I2C AO_A bus and exposing it as a thermal cooling device.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v2:
- PATCH 5: Add regulator_disable on suspend thanks to Neil's feedback.
- Link to v1: https://lore.kernel.org/r/20260402-add-mcu-fan-khadas-vim4-v1-0-2b12eb4ac7b0@aliel.fr
---
Ronald Claveau (8):
dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
mfd: khadas-mcu: Add support for VIM4 MCU variant
thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
arm64: dts: amlogic: t7: Add i2c pinctrl node
arm64: dts: amlogic: t7: Add i2c controller node
arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
.../bindings/i2c/amlogic,meson6-i2c.yaml | 13 ++-
.../devicetree/bindings/mfd/khadas,mcu.yaml | 5 +
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 20 ++++
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++---
drivers/thermal/khadas_mcu_fan.c | 49 ++++++++--
include/linux/mfd/khadas-mcu.h | 39 +++++++-
7 files changed, 222 insertions(+), 23 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-03 16:08 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260403-add-mcu-fan-khadas-vim4-v2-0-70536b22439a@aliel.fr>
The Khadas VIM4 MCU register is slightly different
from previous boards' MCU.
This board also features a switchable power source for its fan.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 084960fd5a1fd..67769ef5d58b1 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- khadas,mcu # MCU revision is discoverable
+ - khadas,vim4-mcu
"#cooling-cells": # Only needed for boards having FAN control feature
const: 2
@@ -25,6 +26,10 @@ properties:
reg:
maxItems: 1
+ fan-supply:
+ description: Phandle to the regulator that powers the fan.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
required:
- compatible
- reg
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-04-03 15:50 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <da6f4566-a719-409b-80a9-40ca89e3e721@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 12:05:27AM +0530, Shivendra Pratap wrote:
>
>
> On 01-04-2026 20:07, Lorenzo Pieralisi wrote:
> > On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
> > >
> > >
> > > On 27-03-2026 19:25, Lorenzo Pieralisi wrote:
> > > > On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
> > > > > PSCI supports different types of resets like COLD reset, ARCH WARM
>
> [snip..]
>
> > > > > + * Predefined reboot-modes are defined as per the values
> > > > > + * of enum reboot_mode defined in the kernel: reboot.c.
> > > > > + */
> > > > > +static struct mode_info psci_resets[] = {
> > > > > + { .mode = "warm", .magic = REBOOT_WARM},
> > > > > + { .mode = "soft", .magic = REBOOT_SOFT},
> > > > > + { .mode = "cold", .magic = REBOOT_COLD},
> >
> > These strings match the command userspace issue right ? I think that we
> > should make them match the corresponding PSCI reset types, the list above
> > maps command to reboot_mode values and those can belong to any reboot
> > mode driver to be honest they don't make much sense in a PSCI reboot
> > mode driver only.
> >
> > It is a question for everyone here: would it make sense to make these
> > predefined resets a set of strings, eg:
> >
> > psci-system-reset
> > psci-system-reset2-arch-warm-reset
> >
> > and then vendor resets:
> >
> > psci-system-reset2-vendor-reset
>
> Can you share bit more details on this? We are already defining the string
> from userspace in the struct - eg: ".mode = "warm".
"warm","soft","cold" are not strictly speaking PSCI concepts and mean nothing
well defined to user space and even if they did, they would not belong in
the PSCI reboot mode driver but in generic code.
Spelling out what a reset is might help instead, again, this is just my
opinion, I don't know how the semantics of resets have been handled thus
far.
If userspace issues a LINUX_REBOOT_CMD_RESTART2 with arg, say,
"psci-system-reset2-arch-warm-reset" it is pretty clear what it wants
to do in PSCI.
Again, it is a suggestion, comments welcome.
> yes we can move away from enum reboot_mode and use custom psci defines one -
> Ack.
>
> >
>
> [snip ..]
>
> > > > > +
> > > > > +/*
> > > > > + * arg1 is reset_type(Low 32 bit of magic).
> > > > > + * arg2 is cookie(High 32 bit of magic).
> > > > > + * If reset_type is 0, cookie will be used to decide the reset command.
> > > > > + */
> > > > > +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
> > > > > +{
> > > > > + u32 reset_type = REBOOT_MODE_ARG1(magic);
> > > > > + u32 cookie = REBOOT_MODE_ARG2(magic);
> > > > > +
> > > > > + if (reset_type == 0) {
> > > > > + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
> > > > > + psci_set_reset_cmd(true, 0, 0);
> > > > > + else
> > > > > + psci_set_reset_cmd(false, 0, 0);
> > > > > + } else {
> > > > > + psci_set_reset_cmd(true, reset_type, cookie);
> > > > > + }
> > > >
> > > > I don't think that psci_set_reset_cmd() has the right interface (and this
> > > > nested if is too complicated for my taste). All we need to pass is reset-type
> > > > and cookie (and if the reset is one of the predefined ones, reset-type is 0
> > > > and cookie is the REBOOT_* cookie).
> > > >
> > > > Then the PSCI firmware driver will take the action according to what
> > > > resets are available.
> > > >
> > > > How does it sound ?
> > >
> > > So we mean these checks will move to the psci driver? Sorry for re-iterating
> > > the question.
> >
> > Given what I say above, I believe that something we can do is mapping the magic
> > to an enum like:
> >
> > PSCI_SYSTEM_RESET
> > PSCI_SYSTEM_RESET2_ARCH_SYSTEM_WARM_RESET
> > PSCI_SYSTEM_RESET2_VENDOR_RESET
> >
> > and can add a probe function into PSCI driver similar to psci_has_osi_support() but
> > to probe for SYSTEM_RESET2 and initialize the predefined strings accordingly,
> > depending on its presence.
>
> Not able to get it cleanly.
>
> 1. Will move away from reboot_mode enum for pre-defined modes and define new
> enum defining these modes- fine.
> 2. get SYSTEM_RESET2 is supported from psci exported function -- fine, but
> how we use it here now, as we do not want to send the reset_cmd from
> psci_set_reset_cmd now?
You do keep psci_set_reset_cmd() but all it is used for is setting a struct
shared with the PSCI driver where you initialize the enum above, possibly
with a cookie if it is a vendor reset.
> 3. For pre-defined modes, warm/soft or cold - reset_type and cookie, both
> are zero, sys_reset2 or sys_reset2 decides the ARCH reset vs cold reset.
> 4. For vendor-rest , we use sys_reset2 with reset_type and cookie.
Yes.
> All above is done in reboot_notifier call at psci-reboot-mode.
> --
>
> Now in the final restart_notifier->psci_sys_reset --
>
> If panic is in progress, we do not use any of the cmd based reset params and
> go with the legacy reset. So we need to preserve the values that were set
> from psci-reboot-mode.
>
> Did not understand the proposed suggestion in above usecase. Need more input
> on this.
I explained above. The reboot mode driver sets the command to carry out
depending on the string coming from user space and whether PSCI supports
SYSTEM_RESET2 or not.
> --
>
> One other option is to have a restart_notifier in psci-reboot-mode, with
> lesser priority than psci_sys_rest and then handle all the case including
> panic and sys_reset2.
No.
Thanks,
Lorenzo
^ permalink raw reply
* Re: (subset) [PATCH v3 1/5] dt-bindings: rtc: sc2731: Add compatible for SC2730
From: Alexandre Belloni @ 2026-04-03 14:53 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Orson Zhai,
Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel, Otto Pflüger
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm
In-Reply-To: <20260329-sc27xx-mfd-cells-v3-1-9158dee41f74@abscue.de>
On Sun, 29 Mar 2026 09:27:45 +0200, Otto Pflüger wrote:
> The RTC block found in the SC2730 PMIC is compatible with the one found
> in the SC2731 PMIC.
Applied, thanks!
[1/5] dt-bindings: rtc: sc2731: Add compatible for SC2730
https://git.kernel.org/abelloni/c/b2b0dcaa28d2
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH RESEND v1] thermal: core: fix blocking in unregistering zone
From: Guenter Roeck @ 2026-04-03 14:20 UTC (permalink / raw)
To: Rafael J. Wysocki, Jiajia Liu
Cc: Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-pm, linux-kernel,
Armin Wolf, linux-hwmon
In-Reply-To: <2432224.ElGaqSPkdT@rafael.j.wysocki>
On 4/3/26 05:52, Rafael J. Wysocki wrote:
.[ ... ]
> It appears to work for me, but I'm not sure if having multiple hwmon class
> devices with the same value in the name attribute is fine.
Like this ?
$ cd /sys/class/hwmon
$ grep . */name
hwmon0/name:r8169_0_c00:00
hwmon1/name:nvme
hwmon2/name:nvme
hwmon3/name:nct6687
hwmon4/name:k10temp
hwmon5/name:spd5118
hwmon6/name:spd5118
hwmon7/name:spd5118
hwmon8/name:spd5118
hwmon9/name:mt7921_phy0
Names such as "r8169_0_c00:00" and "mt7921_phy0" are actually overkill
since the "sensors" command makes it
r8169_0_c00:00-mdio-0
Adapter: MDIO adapter
temp1: +36.0°C (high = +120.0°C)
mt7921_phy0-pci-0d00
Adapter: PCI adapter
temp1: +30.0°C
essentially duplicating the device index.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare
From: Mario Limonciello @ 2026-04-03 13:26 UTC (permalink / raw)
To: Matthew Leach, Rafael J. Wysocki, Pavel Machek, Len Brown
Cc: linux-pm, linux-kernel, YoungJun Park, kernel
In-Reply-To: <20260403-hibernation-fixes-v3-1-31bc9fa3ba2d@collabora.com>
On 4/3/26 2:36 AM, Matthew Leach wrote:
> [You don't often get email from matthew.leach@collabora.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Certain drivers release resources (pinned pages, etc.) into system
> memory during the prepare freeze PM op, making them swappable.
> Currently, hibernate_preallocate_memory is called before prepare freeze,
> so those drivers have no opportunity to release resources first. If a
> driver is holding a large amount of unswappable system RAM, this can
> cause hibernate_preallocate_memory to fail.
>
> Move the call to hibernate_preallocate_memory after prepare freeze.
> According to the documentation for the prepare callback, devices should
> be left in a usable state, so storage drivers should still be able to
> service I/O requests. This allows drivers to release unswappable
> resources prior to preallocation, so they can be swapped out through
> hibernate_preallocate_memory's reclaim path. Also remove
> shrink_shmem_memory since hibernate_preallocate_memory will have
> reclaimed enough memory for the hibernation image.
>
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
LGTM.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> Changes in v3:
> - Changed error label names to 'Thaw' and 'Complete'.
> - Link to v2: https://patch.msgid.link/20260326-hibernation-fixes-v2-1-f6707d82b7b9@collabora.com
>
> Changes in v2:
> - Removed shrink_shmem_memory.
> - Fixed missing call to dpm_prepare in error path.
> - Link to v1: https://lore.kernel.org/r/20260321-hibernation-fixes-v1-1-5fe9637b6ff9@collabora.com
> ---
> kernel/power/hibernate.c | 46 +++++++++-------------------------------------
> 1 file changed, 9 insertions(+), 37 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index af8d07bafe02..d2479c69d71a 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -392,23 +392,6 @@ static int create_image(int platform_mode)
> return error;
> }
>
> -static void shrink_shmem_memory(void)
> -{
> - struct sysinfo info;
> - unsigned long nr_shmem_pages, nr_freed_pages;
> -
> - si_meminfo(&info);
> - nr_shmem_pages = info.sharedram; /* current page count used for shmem */
> - /*
> - * The intent is to reclaim all shmem pages. Though shrink_all_memory() can
> - * only reclaim about half of them, it's enough for creating the hibernation
> - * image.
> - */
> - nr_freed_pages = shrink_all_memory(nr_shmem_pages);
> - pr_debug("requested to reclaim %lu shmem pages, actually freed %lu pages\n",
> - nr_shmem_pages, nr_freed_pages);
> -}
> -
> /**
> * hibernation_snapshot - Quiesce devices and create a hibernation image.
> * @platform_mode: If set, use platform driver to prepare for the transition.
> @@ -425,14 +408,9 @@ int hibernation_snapshot(int platform_mode)
> if (error)
> goto Close;
>
> - /* Preallocate image memory before shutting down devices. */
> - error = hibernate_preallocate_memory();
> - if (error)
> - goto Close;
> -
> error = freeze_kernel_threads();
> if (error)
> - goto Cleanup;
> + goto Close;
>
> if (hibernation_test(TEST_FREEZER)) {
>
> @@ -445,19 +423,13 @@ int hibernation_snapshot(int platform_mode)
> }
>
> error = dpm_prepare(PMSG_FREEZE);
> - if (error) {
> - dpm_complete(PMSG_RECOVER);
> - goto Thaw;
> - }
> + if (error)
> + goto Complete;
>
> - /*
> - * Device drivers may move lots of data to shmem in dpm_prepare(). The shmem
> - * pages will use lots of system memory, causing hibernation image creation
> - * fail due to insufficient free memory.
> - * This call is to force flush the shmem pages to swap disk and reclaim
> - * the system memory so that image creation can succeed.
> - */
> - shrink_shmem_memory();
> + /* Preallocate image memory before shutting down devices. */
> + error = hibernate_preallocate_memory();
> + if (error)
> + goto Complete;
>
> console_suspend_all();
> pm_restrict_gfp_mask();
> @@ -492,10 +464,10 @@ int hibernation_snapshot(int platform_mode)
> platform_end(platform_mode);
> return error;
>
> + Complete:
> + dpm_complete(PMSG_RECOVER);
> Thaw:
> thaw_kernel_threads();
> - Cleanup:
> - swsusp_free();
> goto Close;
> }
>
>
> ---
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> change-id: 20260321-hibernation-fixes-69bca2ee5b65
>
> Best regards,
> --
> Matt
>
^ permalink raw reply
* Re: [PATCH v3 0/3] thermal: spacemit: Add support for SpacemiT K1 SoC thermal sensor
From: Vincent Legoll @ 2026-04-03 12:57 UTC (permalink / raw)
To: alex, aou, conor+dt, daniel.lezcano, devicetree, dlan, krzk+dt,
krzysztof.kozlowski, linux-kernel, linux-pm, linux-riscv,
lukasz.luba, p.zabel, palmer, pjw, rafael, robh, rui.zhang,
spacemit, gsh517025
In-Reply-To: <20260119-patchv2-k1-thermal-v3-0-3d82c9ebe8a4@163.com>
Hello,
I applied this series on top of:
- next-20260402
-
https://patchwork.kernel.org/project/linux-riscv/patch/20260330-orangepi-sd-card-uhs-v5-9-bd853604322d@gmail.com/
I need the the SD card series to boot from SD card.
I'm also seeing the same "it works" state as Gong Shuai.
So you can add another:
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Regards
Thanks
^ permalink raw reply
* Re: [PATCH RESEND v1] thermal: core: fix blocking in unregistering zone
From: Rafael J. Wysocki @ 2026-04-03 12:52 UTC (permalink / raw)
To: Jiajia Liu
Cc: Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-pm, linux-kernel,
Armin Wolf, Guenter Roeck, linux-hwmon
In-Reply-To: <20260402022742.17738-1-liujiajia@kylinos.cn>
On Thursday, April 2, 2026 4:27:42 AM CEST Jiajia Liu wrote:
> When hwmon->tz_list has more than one member,
> thermal_remove_hwmon_sysfs does not unregister hwmon->device.
> Unregistering the zone which is parent of hwmon->device blocks
> at wait_for_completion(&tz->removal). Add check and move hwmon
> to other zone in thermal_remove_hwmon_sysfs.
>
> One method of reproducing hung task is to unbind the first
> acpitz zone on systems with two acpitz zones.
>
> $ cd /sys/bus/platform/drivers/acpi-thermal/
> $ ls
> bind LNXTHERM:00 LNXTHERM:01 uevent unbind
> $ echo 'LNXTHERM:00' | sudo tee unbind > /dev/null
Right, this is a problem.
However, it is more of a design issue IMV because putting temperature
attributes for all of the (possibly unrelated) thermal zones of the
same type under one hwmon interface is not particularly useful (for
example, if there are more then one of them, it is not particularly
straightforward to find the thermal zone corresponding to a given
hwmon attribute and vice versa). Also it is asking for trouble
as demonstrated by the above.
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
> drivers/thermal/thermal_hwmon.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
> index b624892bc6d6..43cde079fef0 100644
> --- a/drivers/thermal/thermal_hwmon.c
> +++ b/drivers/thermal/thermal_hwmon.c
> @@ -242,6 +242,15 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz)
> list_del(&temp->hwmon_node);
> kfree(temp);
> if (!list_empty(&hwmon->tz_list)) {
> + if (hwmon->device->parent == &tz->device) {
> + struct thermal_hwmon_temp *first;
> +
> + first = list_first_entry(&hwmon->tz_list,
> + struct thermal_hwmon_temp,
> + hwmon_node);
> + device_move(hwmon->device, &first->tz->device,
> + DPM_ORDER_DEV_AFTER_PARENT);
> + }
This may just confuse user space if it started to use the hwmon
interface already.
> mutex_unlock(&thermal_hwmon_list_lock);
> return;
> }
>
So I'm wondering if something like the patch below can be done instead.
It will basically cause every thermal zone to get its own hwmon interface
regardless of the type.
It appears to work for me, but I'm not sure if having multiple hwmon class
devices with the same value in the name attribute is fine.
---
drivers/thermal/thermal_hwmon.c | 109 ++++++++--------------------------------
1 file changed, 24 insertions(+), 85 deletions(-)
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -19,19 +19,8 @@
#include "thermal_hwmon.h"
#include "thermal_core.h"
-/* hwmon sys I/F */
-/* thermal zone devices with the same type share one hwmon device */
-struct thermal_hwmon_device {
- char type[THERMAL_NAME_LENGTH];
- struct device *device;
- int count;
- struct list_head tz_list;
- struct list_head node;
-};
-
struct thermal_hwmon_attr {
struct device_attribute attr;
- char name[16];
};
/* one temperature input for each thermal zone */
@@ -42,6 +31,15 @@ struct thermal_hwmon_temp {
struct thermal_hwmon_attr temp_crit; /* hwmon sys attr */
};
+/* hwmon sys I/F */
+/* thermal zone devices with the same type share one hwmon device */
+struct thermal_hwmon_device {
+ char type[THERMAL_NAME_LENGTH];
+ struct device *device;
+ struct list_head node;
+ struct thermal_hwmon_temp tz_temp;
+};
+
static LIST_HEAD(thermal_hwmon_list);
static DEFINE_MUTEX(thermal_hwmon_list_lock);
@@ -87,41 +85,17 @@ temp_crit_show(struct device *dev, struc
return sysfs_emit(buf, "%d\n", temperature);
}
-
static struct thermal_hwmon_device *
-thermal_hwmon_lookup_by_type(const struct thermal_zone_device *tz)
+thermal_hwmon_lookup(const struct thermal_zone_device *tz)
{
struct thermal_hwmon_device *hwmon;
- char type[THERMAL_NAME_LENGTH];
- mutex_lock(&thermal_hwmon_list_lock);
+ guard(mutex)(&thermal_hwmon_list_lock);
+
list_for_each_entry(hwmon, &thermal_hwmon_list, node) {
- strscpy(type, tz->type);
- strreplace(type, '-', '_');
- if (!strcmp(hwmon->type, type)) {
- mutex_unlock(&thermal_hwmon_list_lock);
+ if (hwmon->tz_temp.tz == tz)
return hwmon;
- }
}
- mutex_unlock(&thermal_hwmon_list_lock);
-
- return NULL;
-}
-
-/* Find the temperature input matching a given thermal zone */
-static struct thermal_hwmon_temp *
-thermal_hwmon_lookup_temp(const struct thermal_hwmon_device *hwmon,
- const struct thermal_zone_device *tz)
-{
- struct thermal_hwmon_temp *temp;
-
- mutex_lock(&thermal_hwmon_list_lock);
- list_for_each_entry(temp, &hwmon->tz_list, hwmon_node)
- if (temp->tz == tz) {
- mutex_unlock(&thermal_hwmon_list_lock);
- return temp;
- }
- mutex_unlock(&thermal_hwmon_list_lock);
return NULL;
}
@@ -136,20 +110,15 @@ int thermal_add_hwmon_sysfs(struct therm
{
struct thermal_hwmon_device *hwmon;
struct thermal_hwmon_temp *temp;
- int new_hwmon_device = 1;
int result;
- hwmon = thermal_hwmon_lookup_by_type(tz);
- if (hwmon) {
- new_hwmon_device = 0;
- goto register_sys_interface;
- }
+ if (thermal_hwmon_lookup(tz))
+ return -EEXIST;
hwmon = kzalloc_obj(*hwmon);
if (!hwmon)
return -ENOMEM;
- INIT_LIST_HEAD(&hwmon->tz_list);
strscpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
strreplace(hwmon->type, '-', '_');
hwmon->device = hwmon_device_register_for_thermal(&tz->device,
@@ -159,31 +128,20 @@ int thermal_add_hwmon_sysfs(struct therm
goto free_mem;
}
- register_sys_interface:
- temp = kzalloc_obj(*temp);
- if (!temp) {
- result = -ENOMEM;
- goto unregister_name;
- }
+ temp = &hwmon->tz_temp;
temp->tz = tz;
- hwmon->count++;
- snprintf(temp->temp_input.name, sizeof(temp->temp_input.name),
- "temp%d_input", hwmon->count);
- temp->temp_input.attr.attr.name = temp->temp_input.name;
+ temp->temp_input.attr.attr.name = "temp1_input";
temp->temp_input.attr.attr.mode = 0444;
temp->temp_input.attr.show = temp_input_show;
sysfs_attr_init(&temp->temp_input.attr.attr);
result = device_create_file(hwmon->device, &temp->temp_input.attr);
if (result)
- goto free_temp_mem;
+ goto unregister_name;
if (thermal_zone_crit_temp_valid(tz)) {
- snprintf(temp->temp_crit.name,
- sizeof(temp->temp_crit.name),
- "temp%d_crit", hwmon->count);
- temp->temp_crit.attr.attr.name = temp->temp_crit.name;
+ temp->temp_crit.attr.attr.name = "temp1_crit";
temp->temp_crit.attr.attr.mode = 0444;
temp->temp_crit.attr.show = temp_crit_show;
sysfs_attr_init(&temp->temp_crit.attr.attr);
@@ -194,20 +152,15 @@ int thermal_add_hwmon_sysfs(struct therm
}
mutex_lock(&thermal_hwmon_list_lock);
- if (new_hwmon_device)
- list_add_tail(&hwmon->node, &thermal_hwmon_list);
- list_add_tail(&temp->hwmon_node, &hwmon->tz_list);
+ list_add_tail(&hwmon->node, &thermal_hwmon_list);
mutex_unlock(&thermal_hwmon_list_lock);
return 0;
unregister_input:
device_remove_file(hwmon->device, &temp->temp_input.attr);
- free_temp_mem:
- kfree(temp);
unregister_name:
- if (new_hwmon_device)
- hwmon_device_unregister(hwmon->device);
+ hwmon_device_unregister(hwmon->device);
free_mem:
kfree(hwmon);
@@ -220,31 +173,17 @@ void thermal_remove_hwmon_sysfs(struct t
struct thermal_hwmon_device *hwmon;
struct thermal_hwmon_temp *temp;
- hwmon = thermal_hwmon_lookup_by_type(tz);
- if (unlikely(!hwmon)) {
- /* Should never happen... */
- dev_dbg(&tz->device, "hwmon device lookup failed!\n");
+ hwmon = thermal_hwmon_lookup(tz);
+ if (!hwmon)
return;
- }
- temp = thermal_hwmon_lookup_temp(hwmon, tz);
- if (unlikely(!temp)) {
- /* Should never happen... */
- dev_dbg(&tz->device, "temperature input lookup failed!\n");
- return;
- }
+ temp = &hwmon->tz_temp;
device_remove_file(hwmon->device, &temp->temp_input.attr);
if (thermal_zone_crit_temp_valid(tz))
device_remove_file(hwmon->device, &temp->temp_crit.attr);
mutex_lock(&thermal_hwmon_list_lock);
- list_del(&temp->hwmon_node);
- kfree(temp);
- if (!list_empty(&hwmon->tz_list)) {
- mutex_unlock(&thermal_hwmon_list_lock);
- return;
- }
list_del(&hwmon->node);
mutex_unlock(&thermal_hwmon_list_lock);
^ permalink raw reply
* [GIT PULL] Power management fixes for v7.0-rc7
From: Rafael J. Wysocki @ 2026-04-03 12:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux PM, Linux Kernel Mailing List, Viresh Kumar
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-7.0-rc7
with top-most commit 744d5721d2d7abc84e5131c16002039c53465c89
Merge branch 'pm-em'
on top of commit 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
Linux 7.0-rc6
to receive power management fixes for 7.0-rc7.
These fix a potential NULL pointer dereference in the energy model
netlink interface and a potential double free in an error path in
the common cpufreq governor management code:
- Fix a NULL pointer dereference in the energy model netlink
interface that may occur if a given perf domain ID is not
recognized (Changwoo Min)
- Avoid double free in the cpufreq_dbs_governor_init() error path
when kobject_init_and_add() fails (Guangshuo Li)
Thanks!
---------------
Changwoo Min (1):
PM: EM: Fix NULL pointer dereference when perf domain ID is not found
Guangshuo Li (1):
cpufreq: governor: fix double free in
cpufreq_dbs_governor_init() error path
---------------
drivers/cpufreq/cpufreq_governor.c | 6 +++---
kernel/power/em_netlink.c | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
^ permalink raw reply
* [GIT PULL] Thermal control fixes for v7.0-rc7
From: Rafael J. Wysocki @ 2026-04-03 12:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux PM, Linux Kernel Mailing List, Daniel Lezcano
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
thermal-7.0-rc7
with top-most commit 9e07e3b81807edd356e1f794cffa00a428eff443
thermal: core: Fix thermal zone device registration error path
on top of commit 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
Linux 7.0-rc6
to receive thermal control fixes for 7.0-rc7.
These address potential races between thermal zone removal and system
resume that may lead to a use-after-free (in two different ways) and
a potential use-after-free in the thermal zone unregistration path.
Thanks!
---------------
Rafael J. Wysocki (2):
thermal: core: Address thermal zone removal races with resume
thermal: core: Fix thermal zone device registration error path
---------------
drivers/thermal/thermal_core.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH] power: sequencing: pcie-m2: enforce PCI and OF dependencies
From: Bartosz Golaszewski @ 2026-04-03 12:20 UTC (permalink / raw)
To: Bartosz Golaszewski, Manivannan Sadhasivam, Arnd Bergmann
Cc: Bartosz Golaszewski, Arnd Bergmann, Ulf Hansson,
Michal Wilczynski, linux-pm, linux-kernel
In-Reply-To: <20260401091847.305294-1-arnd@kernel.org>
On Wed, 01 Apr 2026 11:16:25 +0200, Arnd Bergmann wrote:
> The driver fails to build when PCI is disabled:
>
> drivers/power/sequencing/pwrseq-pcie-m2.c: In function 'pwrseq_pcie_m2_register_notifier':
> drivers/power/sequencing/pwrseq-pcie-m2.c:368:54: error: 'pci_bus_type' undeclared (first use in this function); did you mean 'pci_pcie_type'?
> 368 | ret = bus_register_notifier(&pci_bus_type, &ctx->nb);
> | ^~~~~~~~~~~~
> | pci_pcie_type
>
> [...]
Applied, thanks!
[1/1] power: sequencing: pcie-m2: enforce PCI and OF dependencies
https://git.kernel.org/brgl/c/19b8c8fc83f755cd52a2aa3dbdb091234592252e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] power: sequencing: pcie-m2: add SERIAL_DEV_BUS dependency
From: Bartosz Golaszewski @ 2026-04-03 12:20 UTC (permalink / raw)
To: Bartosz Golaszewski, Manivannan Sadhasivam, Arnd Bergmann
Cc: Bartosz Golaszewski, Arnd Bergmann, Ulf Hansson,
Michal Wilczynski, linux-pm, linux-kernel
In-Reply-To: <20260401191030.948046-1-arnd@kernel.org>
On Wed, 01 Apr 2026 21:10:13 +0200, Arnd Bergmann wrote:
> The newly added serdev code fails to link when serdev is turned off:
>
> arm-linux-gnueabi-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_pcie_m2_remove_serdev':
> pwrseq-pcie-m2.c:(.text+0xc8): undefined reference to `serdev_device_remove'
> arm-linux-gnueabi-ld: drivers/power/sequencing/pwrseq-pcie-m2.o: in function `pwrseq_m2_pcie_notify':
> pwrseq-pcie-m2.c:(.text+0x69c): undefined reference to `of_find_serdev_controller_by_node'
> arm-linux-gnueabi-ld: pwrseq-pcie-m2.c:(.text+0x6f8): undefined reference to `serdev_device_alloc'
> arm-linux-gnueabi-ld: pwrseq-pcie-m2.c:(.text+0x724): undefined reference to `serdev_device_add'
>
> [...]
Applied, thanks!
[1/1] power: sequencing: pcie-m2: add SERIAL_DEV_BUS dependency
https://git.kernel.org/brgl/c/b4464d8f313f903ba72db06042f3958a9a1e464a
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] PM / wakeup: Allocate class wakeup_class statically
From: Heiner Kallweit @ 2026-04-03 11:02 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Pavel Machek, Len Brown, Greg Kroah-Hartman, Danilo Krummrich,
Linux PM, driver-core
In-Reply-To: <CAJZ5v0jTTdJDPDk3ACVpjP=S5nrA-vddfKBnFRyWSbHCuWWKQQ@mail.gmail.com>
On 03.04.2026 12:45, Rafael J. Wysocki wrote:
> On Thu, Apr 2, 2026 at 3:05 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>
>> On 01.04.2026 19:32, Rafael J. Wysocki wrote:
>>> On Wed, Apr 1, 2026 at 5:45 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>>>
>>>> On 01.04.2026 16:19, Rafael J. Wysocki wrote:
>>>>> On Sun, Mar 29, 2026 at 6:14 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>>>>>
>>>>>> Allocating wakeup_class statically avoids a little runtime overhead.
>>>>>> Define groups and device release function as part of the class, so that
>>>>>> we don't have to repeat this for each class device.
>>>>>> Whilst at it, constify wakeup_source_attrs[].
>>>>>>
>>>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>>>
>>>>> Can you please have a look at this and let me know what you think:
>>>>>
>>>>> https://sashiko.dev/#/patchset/0fe1b679-ab28-4505-b0db-14e7ac3ba749%40gmail.com
>>>>>
>>>> Interesting finding! I think the diagnosis is right.
>>>>
>>>> But: I would say the current behavior isn't a nice solution as well:
>>>
>>> It is not fantastic, but it doesn't have this issue.
>>>
>>>> wakeup_source_device_create() does: dev->class = wakeup_class;
>>>> I think no reader will expect that wakeup_class may be NULL here due to
>>>> initcall ordering. In addition this behavior results in such early
>>>> wakeup sources not being shown in sysfs.
>>>
>>> They are registered too early to show up in sysfs, but they can work regardless.
>>>
>>> I think that it's just pointless to call device_register() for a given
>>> wakeup source if wakeup_class has not been registered yet.
>>>
>>>> But I'm not sure whether registering class "wakeup" (and registering
>>>> classes in general) would be possible early enough (core_initcall,
>>>> or even pure_initcall).
>>>
>>> driver_init() is called before do_initcalls() is do_basic_setup(), so
>>> class registration should work for all initcall levels AFAICS.
>>>
>> When testing the current code on my system, autosleep is the first wakeup
>> source, registered in a core_initcall, and it's not shown in sysfs.
>> Same result when class wakeup is registered in a core_initcall
>> (instead of postcore_initcall). Registering class wakeup in a pure_initcall
>> works and fixes the issue. So, would this be an acceptable solution for the
>> discussed issue?
>
> I don't see why not.
OK, then I'll send a patch for it. I was asking because comment in init.h says:
A "pure" initcall has no dependencies on anything else, and purely
*initializes variables* that couldn't be statically initialized.
^ permalink raw reply
* Re: [PATCH] PM / wakeup: Allocate class wakeup_class statically
From: Rafael J. Wysocki @ 2026-04-03 10:45 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Greg Kroah-Hartman,
Danilo Krummrich, Linux PM, driver-core
In-Reply-To: <0758441c-e88d-475a-80ef-061b227ae7fc@gmail.com>
On Thu, Apr 2, 2026 at 3:05 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 01.04.2026 19:32, Rafael J. Wysocki wrote:
> > On Wed, Apr 1, 2026 at 5:45 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>
> >> On 01.04.2026 16:19, Rafael J. Wysocki wrote:
> >>> On Sun, Mar 29, 2026 at 6:14 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>>>
> >>>> Allocating wakeup_class statically avoids a little runtime overhead.
> >>>> Define groups and device release function as part of the class, so that
> >>>> we don't have to repeat this for each class device.
> >>>> Whilst at it, constify wakeup_source_attrs[].
> >>>>
> >>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >>>
> >>> Can you please have a look at this and let me know what you think:
> >>>
> >>> https://sashiko.dev/#/patchset/0fe1b679-ab28-4505-b0db-14e7ac3ba749%40gmail.com
> >>>
> >> Interesting finding! I think the diagnosis is right.
> >>
> >> But: I would say the current behavior isn't a nice solution as well:
> >
> > It is not fantastic, but it doesn't have this issue.
> >
> >> wakeup_source_device_create() does: dev->class = wakeup_class;
> >> I think no reader will expect that wakeup_class may be NULL here due to
> >> initcall ordering. In addition this behavior results in such early
> >> wakeup sources not being shown in sysfs.
> >
> > They are registered too early to show up in sysfs, but they can work regardless.
> >
> > I think that it's just pointless to call device_register() for a given
> > wakeup source if wakeup_class has not been registered yet.
> >
> >> But I'm not sure whether registering class "wakeup" (and registering
> >> classes in general) would be possible early enough (core_initcall,
> >> or even pure_initcall).
> >
> > driver_init() is called before do_initcalls() is do_basic_setup(), so
> > class registration should work for all initcall levels AFAICS.
> >
> When testing the current code on my system, autosleep is the first wakeup
> source, registered in a core_initcall, and it's not shown in sysfs.
> Same result when class wakeup is registered in a core_initcall
> (instead of postcore_initcall). Registering class wakeup in a pure_initcall
> works and fixes the issue. So, would this be an acceptable solution for the
> discussed issue?
I don't see why not.
^ permalink raw reply
* [PATCH] dt-bindings: opp-v2: Fix example 3 CPU reg value
From: Vivian Wang @ 2026-04-03 10:34 UTC (permalink / raw)
To: Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Viresh Kumar, linux-pm, devicetree, linux-kernel, Vivian Wang
Example 3 is a dual-cluster example, meaning that the CPU nodes should
have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses
decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct
hexadecimal values.
Even though the value doesn't change for the first two CPUs, 0 and 1 in
example 3 are changed to 0x0 and 0x1 respectively for consistency. Other
examples all have reg less than 10, so they have not been changed.
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
---
Found while trying to figure out if cpu@* unit addresses are supposed to
be decimal or hexadecimal. This is AFAICT the only place in-tree where
an arm/arm64 DTS uses multi-digit decimal. See also:
- https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
- https://github.com/devicetree-org/devicetree-specification/issues/86
---
Documentation/devicetree/bindings/opp/opp-v2.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp-v2.yaml b/Documentation/devicetree/bindings/opp/opp-v2.yaml
index 6972d76233aa..10000a758572 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2.yaml
@@ -172,7 +172,7 @@ examples:
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
- reg = <0>;
+ reg = <0x0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
@@ -183,7 +183,7 @@ examples:
cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
- reg = <1>;
+ reg = <0x1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
@@ -194,7 +194,7 @@ examples:
cpu@100 {
compatible = "arm,cortex-a15";
device_type = "cpu";
- reg = <100>;
+ reg = <0x100>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
@@ -205,7 +205,7 @@ examples:
cpu@101 {
compatible = "arm,cortex-a15";
device_type = "cpu";
- reg = <101>;
+ reg = <0x101>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260403-dt-bindings-opp-v2-hex-cpu-reg-2d2dbec0bb15
Best regards,
--
Vivian "dramforever" Wang
^ permalink raw reply related
* Re: [PATCH v3 0/2] Support BPF traversal of wakeup sources
From: Greg Kroah-Hartman @ 2026-04-03 10:04 UTC (permalink / raw)
To: Samuel Wu
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Danilo Krummrich,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, kernel-team,
linux-kernel, linux-pm, driver-core, bpf, linux-kselftest
In-Reply-To: <CAG2Kctpr7vBm_=Xz4H5FHYAfFxg=bDt35j6B4EprfUGio=Ftew@mail.gmail.com>
On Thu, Apr 02, 2026 at 12:37:12PM -0700, Samuel Wu wrote:
> On Wed, Apr 1, 2026 at 9:06 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Apr 01, 2026 at 12:07:12PM -0700, Samuel Wu wrote:
> > > On Wed, Apr 1, 2026 at 2:15 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Mar 31, 2026 at 08:34:09AM -0700, Samuel Wu wrote:
> > > > > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > > > > wakeup_sources, and puts a config flag around the sysfs interface.
> > > > >
> > > > > Currently, a traversal of wakeup sources require going through
> > > > > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > > > > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > > > > wakeup source also having multiple attributes. debugfs is unstable and
> > > > > insecure.
> > > >
> > > > Describe "inefficient" please?
> > >
> > > Ack; I’ll provide a more detailed breakdown in the v4 cover letter. To
> > > summarize: the "inefficiency" isn't just the number of sources (150),
> > > but the fact that each source has 10 attributes. We are looking at
> > > 1,500+ sysfs nodes to get a full snapshot of the system.
> >
> > Wait, no, something is wrong here. You should NEVER be wanting to
> > combine multiple sysfs files at the same time into a "snapshot" of the
> > system because by virtue of how this works, it's going to change while
> > you are actually traversing all of those files!
>
> Agree, the current approach with sysfs might have stale values. The
> BPF approach holds a lock while traversing the list. It's not a
> perfect snapshot, but it's internally consistent and arguably better
> than the current sysfs implementation.
>
> > Why are you trying to read 1500+ sysfs files at once, and what are you
> > doing with that information? And if you really need it "all at once",
> > why can't we provide it for you in a sane manner, instead of being
> > forced to either walk the whole sysfs tree, or rely on a bpf script?
>
> The data is fundamental for debugging and improving power at scale.
> The original discussion and patch [1] provide more context of the
> intent. To summarize the history, debugfs was unstable and insecure,
> leading to the current sysfs implementation. However, sysfs has the
> constraint of one attribute per node, requiring 10 sysfs accesses per
> wakeup source.
Ok, as the sysfs api doesn't work your use case anymore, why do we need
to keep it around at all?
> That said, I completely agree that reading 1500+ sysfs files at once
> is unreasonable. Perhaps the sysfs approach was manageable at the time
> of [1], but moving forward we need a more scalable solution. This is
> the main motivator and makes BPF the sane approach, as it improves
> traversal in nearly every aspect (e.g. cycles, memory, simplicity,
> scalability).
I'm all for making this more scalable and work for your systems now, but
consider if you could drop the sysfs api entirely, would you want this
to be a different type of api entirely instead of having to plug through
these using ebpf?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Hawi SoC
From: Krzysztof Kozlowski @ 2026-04-03 8:58 UTC (permalink / raw)
To: Fenglin Wu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel
In-Reply-To: <20260402-haw-rpmhpd-v2-1-2bce0767f2ca@oss.qualcomm.com>
On 03/04/2026 02:35, Fenglin Wu wrote:
> Document the RPMh power domain for Hawi SoC, and add definitions for
> the new power domains which present in Hawi SoC:
> - RPMHPD_DCX (Display Core X): supplies VDD_DISP for the display
> subsystem
> - RPMHPD_GBX (Graphics Box): supplies VDD_GFX_BX for the GPU/graphics
> subsystem
>
> Also, add constants for new power domain levels that supported in Hawi
> SoC, including: LOW_SVS_D3_0, LOW_SVS_D1_0, LOW_SVS_D0_0, SVS_L2_0,
> TURBO_L1_0/1/2, TURBO_L1_0/1/2.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
> include/dt-bindings/power/qcom,rpmhpd.h | 12 ++++++++++++
> 2 files changed, 13 insertions(+)
>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] cpuidle: Deny idle entry when CPU already have IPI interrupt pending
From: kernel test robot @ 2026-04-03 8:45 UTC (permalink / raw)
To: Maulik Shah, Rafael J. Wysocki, Daniel Lezcano, Christian Loehle,
Ulf Hansson
Cc: llvm, oe-kbuild-all, linux-pm, linux-kernel, linux-arm-msm,
Maulik Shah
In-Reply-To: <20260316-cpuidle_ipi-v1-1-d0ff6350f4e2@oss.qualcomm.com>
Hi Maulik,
kernel test robot noticed the following build warnings:
[auto build test WARNING on b84a0ebe421ca56995ff78b66307667b62b3a900]
url: https://github.com/intel-lab-lkp/linux/commits/Maulik-Shah/cpuidle-Deny-idle-entry-when-CPU-already-have-IPI-interrupt-pending/20260316-155453
base: b84a0ebe421ca56995ff78b66307667b62b3a900
patch link: https://lore.kernel.org/r/20260316-cpuidle_ipi-v1-1-d0ff6350f4e2%40oss.qualcomm.com
patch subject: [PATCH] cpuidle: Deny idle entry when CPU already have IPI interrupt pending
config: x86_64-allmodconfig (https://download.01.org/0day-ci/archive/20260403/202604031016.SQiyhL8h-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260403/202604031016.SQiyhL8h-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604031016.SQiyhL8h-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> vmlinux.o: warning: objtool: cpuidle_enter_state+0x3d: call to cpus_peek_for_pending_ipi() leaves .noinstr.text section
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare
From: Matthew Leach @ 2026-04-03 7:36 UTC (permalink / raw)
To: Rafael J. Wysocki, Pavel Machek, Len Brown, Mario Limonciello
Cc: linux-pm, linux-kernel, YoungJun Park, kernel, Matthew Leach
Certain drivers release resources (pinned pages, etc.) into system
memory during the prepare freeze PM op, making them swappable.
Currently, hibernate_preallocate_memory is called before prepare freeze,
so those drivers have no opportunity to release resources first. If a
driver is holding a large amount of unswappable system RAM, this can
cause hibernate_preallocate_memory to fail.
Move the call to hibernate_preallocate_memory after prepare freeze.
According to the documentation for the prepare callback, devices should
be left in a usable state, so storage drivers should still be able to
service I/O requests. This allows drivers to release unswappable
resources prior to preallocation, so they can be swapped out through
hibernate_preallocate_memory's reclaim path. Also remove
shrink_shmem_memory since hibernate_preallocate_memory will have
reclaimed enough memory for the hibernation image.
Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
---
Changes in v3:
- Changed error label names to 'Thaw' and 'Complete'.
- Link to v2: https://patch.msgid.link/20260326-hibernation-fixes-v2-1-f6707d82b7b9@collabora.com
Changes in v2:
- Removed shrink_shmem_memory.
- Fixed missing call to dpm_prepare in error path.
- Link to v1: https://lore.kernel.org/r/20260321-hibernation-fixes-v1-1-5fe9637b6ff9@collabora.com
---
kernel/power/hibernate.c | 46 +++++++++-------------------------------------
1 file changed, 9 insertions(+), 37 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index af8d07bafe02..d2479c69d71a 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -392,23 +392,6 @@ static int create_image(int platform_mode)
return error;
}
-static void shrink_shmem_memory(void)
-{
- struct sysinfo info;
- unsigned long nr_shmem_pages, nr_freed_pages;
-
- si_meminfo(&info);
- nr_shmem_pages = info.sharedram; /* current page count used for shmem */
- /*
- * The intent is to reclaim all shmem pages. Though shrink_all_memory() can
- * only reclaim about half of them, it's enough for creating the hibernation
- * image.
- */
- nr_freed_pages = shrink_all_memory(nr_shmem_pages);
- pr_debug("requested to reclaim %lu shmem pages, actually freed %lu pages\n",
- nr_shmem_pages, nr_freed_pages);
-}
-
/**
* hibernation_snapshot - Quiesce devices and create a hibernation image.
* @platform_mode: If set, use platform driver to prepare for the transition.
@@ -425,14 +408,9 @@ int hibernation_snapshot(int platform_mode)
if (error)
goto Close;
- /* Preallocate image memory before shutting down devices. */
- error = hibernate_preallocate_memory();
- if (error)
- goto Close;
-
error = freeze_kernel_threads();
if (error)
- goto Cleanup;
+ goto Close;
if (hibernation_test(TEST_FREEZER)) {
@@ -445,19 +423,13 @@ int hibernation_snapshot(int platform_mode)
}
error = dpm_prepare(PMSG_FREEZE);
- if (error) {
- dpm_complete(PMSG_RECOVER);
- goto Thaw;
- }
+ if (error)
+ goto Complete;
- /*
- * Device drivers may move lots of data to shmem in dpm_prepare(). The shmem
- * pages will use lots of system memory, causing hibernation image creation
- * fail due to insufficient free memory.
- * This call is to force flush the shmem pages to swap disk and reclaim
- * the system memory so that image creation can succeed.
- */
- shrink_shmem_memory();
+ /* Preallocate image memory before shutting down devices. */
+ error = hibernate_preallocate_memory();
+ if (error)
+ goto Complete;
console_suspend_all();
pm_restrict_gfp_mask();
@@ -492,10 +464,10 @@ int hibernation_snapshot(int platform_mode)
platform_end(platform_mode);
return error;
+ Complete:
+ dpm_complete(PMSG_RECOVER);
Thaw:
thaw_kernel_threads();
- Cleanup:
- swsusp_free();
goto Close;
}
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260321-hibernation-fixes-69bca2ee5b65
Best regards,
--
Matt
^ permalink raw reply related
* [amd-pstate:bleeding-edge] BUILD SUCCESS 9487e2a00e7b3c6f258c5c99953f470eba6fb61d
From: kernel test robot @ 2026-04-03 5:17 UTC (permalink / raw)
To: Mario Limonciello (AMD); +Cc: linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git bleeding-edge
branch HEAD: 9487e2a00e7b3c6f258c5c99953f470eba6fb61d MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as reviewer
elapsed time: 747m
configs tested: 188
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm vf610m4_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260403 gcc-14
i386 randconfig-002-20260403 gcc-14
i386 randconfig-003-20260403 gcc-14
i386 randconfig-004-20260403 gcc-14
i386 randconfig-005-20260403 gcc-14
i386 randconfig-006-20260403 gcc-14
i386 randconfig-007-20260403 gcc-14
i386 randconfig-011-20260403 clang-20
i386 randconfig-012-20260403 clang-20
i386 randconfig-013-20260403 clang-20
i386 randconfig-014-20260403 clang-20
i386 randconfig-015-20260403 clang-20
i386 randconfig-016-20260403 clang-20
i386 randconfig-017-20260403 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc tqm5200_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh magicpanelr2_defconfig gcc-15.2.0
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260403 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260403 clang-20
um randconfig-002-20260403 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260403 clang-20
x86_64 randconfig-002-20260403 clang-20
x86_64 randconfig-003-20260403 clang-20
x86_64 randconfig-004-20260403 clang-20
x86_64 randconfig-005-20260403 clang-20
x86_64 randconfig-006-20260403 clang-20
x86_64 randconfig-011-20260403 gcc-14
x86_64 randconfig-012-20260403 gcc-14
x86_64 randconfig-013-20260403 gcc-14
x86_64 randconfig-014-20260403 gcc-14
x86_64 randconfig-015-20260403 gcc-14
x86_64 randconfig-016-20260403 gcc-14
x86_64 randconfig-071-20260403 gcc-14
x86_64 randconfig-072-20260403 gcc-14
x86_64 randconfig-073-20260403 gcc-14
x86_64 randconfig-074-20260403 gcc-14
x86_64 randconfig-075-20260403 gcc-14
x86_64 randconfig-076-20260403 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] cpuidle: Deny idle entry when CPU already have IPI interrupt pending
From: Maulik Shah @ 2026-04-03 4:08 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson
Cc: linux-pm, linux-kernel, linux-arm-msm, Maulik Shah
CPU can get IPI interrupt from another CPU while it is executing
cpuidle_select() or about to execute same. The selection do not account
for pending interrupts and may continue to enter selected idle state only
to exit immediately.
Example trace collected when there is cross CPU IPI.
[000] 154.892148: sched_waking: comm=sugov:4 pid=491 prio=-1 target_cpu=007
[000] 154.892148: ipi_raise: target_mask=00000000,00000080 (Function call interrupts)
[007] 154.892162: cpu_idle: state=2 cpu_id=7
[007] 154.892208: cpu_idle: state=4294967295 cpu_id=7
[007] 154.892211: irq_handler_entry: irq=2 name=IPI
[007] 154.892211: ipi_entry: (Function call interrupts)
[007] 154.892213: sched_wakeup: comm=sugov:4 pid=491 prio=-1 target_cpu=007
[007] 154.892214: ipi_exit: (Function call interrupts)
This impacts performance and the above count increments.
commit ccde6525183c ("smp: Introduce a helper function to check for pending
IPIs") already introduced a helper function to check the pending IPIs and
it is used in pmdomain governor to deny the cluster level idle state when
there is a pending IPI on any of cluster CPUs.
This however does not stop CPU to enter CPU level idle state. Make use of
same at CPUidle to deny the idle entry when there is already IPI pending.
With change observing glmark2 [1] off screen scores improving in the range
of 25% to 30% on Qualcomm lemans-evk board which is arm64 based having two
clusters each with 4 CPUs.
[1] https://github.com/glmark2/glmark2
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
Changes in v2:
- Fix cpumask argument of cpus_peek_for_pending_ipi() to take single cpu
- Link to v1: https://lore.kernel.org/r/20260316-cpuidle_ipi-v1-1-d0ff6350f4e2@oss.qualcomm.com
---
drivers/cpuidle/cpuidle.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index c7876e9e024f9076663063ad21cfc69343fdbbe7..c01e57df64ca5af8c28da3d971500b3f38306cdf 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -224,6 +224,9 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev,
bool broadcast = !!(target_state->flags & CPUIDLE_FLAG_TIMER_STOP);
ktime_t time_start, time_end;
+ if (cpus_peek_for_pending_ipi(cpumask_of(dev->cpu)))
+ return -EBUSY;
+
instrumentation_begin();
/*
---
base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
change-id: 20260316-cpuidle_ipi-4c64036f9a48
Best regards,
--
Maulik Shah <maulik.shah@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v4 1/2] cpufreq/amd-pstate: Pass the policy to amd_pstate_update()
From: K Prateek Nayak @ 2026-04-03 4:06 UTC (permalink / raw)
To: Mario Limonciello, Viresh Kumar
Cc: Rafael J. Wysocki, Huang Rui, Gautham R. Shenoy,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
Perry Yuan, linux-pm, linux-kernel, rust-for-linux,
linux-rt-devel, Mario Limonciello, Zhongqiu Han
In-Reply-To: <178f3a55-6faf-4070-9e38-85c547b27a03@amd.com>
Hello Mario,
On 4/2/2026 7:22 PM, Mario Limonciello wrote:
> On 4/2/26 01:39, Viresh Kumar wrote:
>> It is ready for Rafael to pick now.
>>
>
> I'm sending an amd-pstate PR later today after some more testing.
>
> I'll pick this up in my PR that goes to Rafael.
Thanks a ton! Much appreciated.
I'll send a separate follow up cleanup to remove the "!policy" check in
amd_pstate_adjust_perf() based on Zhongqiu suggestion after some testing
if all goes well :-)
--
Thanks and Regards,
Prateek
^ permalink raw reply
* [PATCH v2 2/2] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Fenglin Wu @ 2026-04-03 0:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu, Taniya Das
In-Reply-To: <20260402-haw-rpmhpd-v2-0-2bce0767f2ca@oss.qualcomm.com>
Add the RPMh power domains required for the Hawi SoC. This includes
new definitions for domains supplying specific hardware components:
- DCX: supplies VDD_DISP
- GBX: supplies VDD_GFX_BX
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index 19849703be4a..f5ae2a63765d 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -102,11 +102,21 @@ static struct rpmhpd cx_ao_w_mx_parent = {
.res_name = "cx.lvl",
};
+static struct rpmhpd dcx = {
+ .pd = { .name = "dcx", },
+ .res_name = "dcx.lvl",
+};
+
static struct rpmhpd ebi = {
.pd = { .name = "ebi", },
.res_name = "ebi.lvl",
};
+static struct rpmhpd gbx = {
+ .pd = { .name = "gbx", },
+ .res_name = "gbx.lvl",
+};
+
static struct rpmhpd gfx = {
.pd = { .name = "gfx", },
.res_name = "gfx.lvl",
@@ -622,6 +632,33 @@ static const struct rpmhpd_desc kaanapali_desc = {
.num_pds = ARRAY_SIZE(kaanapali_rpmhpds),
};
+/* Hawi RPMH powerdomains */
+static struct rpmhpd *hawi_rpmhpds[] = {
+ [RPMHPD_CX] = &cx,
+ [RPMHPD_CX_AO] = &cx_ao,
+ [RPMHPD_DCX] = &dcx,
+ [RPMHPD_EBI] = &ebi,
+ [RPMHPD_GBX] = &gbx,
+ [RPMHPD_GFX] = &gfx,
+ [RPMHPD_GMXC] = &gmxc,
+ [RPMHPD_LCX] = &lcx,
+ [RPMHPD_LMX] = &lmx,
+ [RPMHPD_MMCX] = &mmcx,
+ [RPMHPD_MMCX_AO] = &mmcx_ao,
+ [RPMHPD_MX] = &mx,
+ [RPMHPD_MX_AO] = &mx_ao,
+ [RPMHPD_MXC] = &mxc,
+ [RPMHPD_MXC_AO] = &mxc_ao,
+ [RPMHPD_MSS] = &mss,
+ [RPMHPD_NSP] = &nsp,
+ [RPMHPD_NSP2] = &nsp2,
+};
+
+static const struct rpmhpd_desc hawi_desc = {
+ .rpmhpds = hawi_rpmhpds,
+ .num_pds = ARRAY_SIZE(hawi_rpmhpds),
+};
+
/* QDU1000/QRU1000 RPMH powerdomains */
static struct rpmhpd *qdu1000_rpmhpds[] = {
[QDU1000_CX] = &cx,
@@ -796,6 +833,7 @@ static const struct rpmhpd_desc qcs615_desc = {
static const struct of_device_id rpmhpd_match_table[] = {
{ .compatible = "qcom,glymur-rpmhpd", .data = &glymur_desc },
+ { .compatible = "qcom,hawi-rpmhpd", .data = &hawi_desc },
{ .compatible = "qcom,kaanapali-rpmhpd", .data = &kaanapali_desc },
{ .compatible = "qcom,milos-rpmhpd", .data = &milos_desc },
{ .compatible = "qcom,qcs615-rpmhpd", .data = &qcs615_desc },
--
2.43.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