* Re: [PATCH] interconnect: debugfs: fix devm_kstrdup and kfree mismatch
From: Markus Elfring @ 2026-03-22 9:34 UTC (permalink / raw)
To: Gui-Dong Han, linux-pm, Georgi Djakov
Cc: LKML, kernel-janitors, Kuan-Wei Chiu, Wang Jiayue, Yao Zi
In-Reply-To: <20260318024815.7655-1-hanguidong02@gmail.com>
> debugfs_write_file_str() uses standard kfree() to release old strings.
Why would such information matter here?
> Initializing src_node and dst_node with devm_kstrdup() creates a memory
> management mismatch. If a user writes to these debugfs nodes, the
> devm-allocated memory is freed via kfree(), leaving a dangling pointer
> in the device resource list that can lead to a double free.
Would an other description approach be clearer for involved dependencies?
> Fix this by using standard kstrdup() instead.
Interesting …
https://elixir.bootlin.com/linux/v7.0-rc4/source/drivers/interconnect/debugfs-client.c#L139-L169
> Since the interconnect
> subsystem is strictly built-in and cannot be unloaded as a module, there
> is no exit path requiring manual cleanup of these strings.
Should string lifetimes be reconsidered for the mentioned function implementation?
> The error
> handling path is also simplified by taking advantage of the fact that
> kfree(NULL) is a safe no-op.
I tend to interpret source code simplifications in other directions.
See also once more:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-kernel-rules.rst?h=v7.0-rc4#n34
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Roman Gushchin @ 2026-03-22 2:18 UTC (permalink / raw)
To: Andrew Morton
Cc: Nhat Pham, kasong, Liam.Howlett, apopple, axelrasmussen, baohua,
baolin.wang, bhe, byungchul, cgroups, chengming.zhou, chrisl,
corbet, david, dev.jain, gourry, hannes, hughd, jannh,
joshua.hahnjy, lance.yang, lenb, linux-doc, linux-kernel,
linux-mm, linux-pm, lorenzo.stoakes, matthew.brost, mhocko,
muchun.song, npache, pavel, peterx, peterz, pfalcato, rafael,
rakie.kim, rppt, ryan.roberts, shakeel.butt, shikemeng, surenb,
tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <20260321112227.bbcf113a6eae634d12695fd9@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Fri, 20 Mar 2026 12:27:14 -0700 Nhat Pham <nphamcs@gmail.com> wrote:
>
>> This patch series implements the virtual swap space idea, based on Yosry's
>> proposals at LSFMMBPF 2023 (see [1], [2], [3]), as well as valuable
>> inputs from Johannes Weiner. The same idea (with different
>> implementation details) has been floated by Rik van Riel since at least
>> 2011 (see [8]).
>
> AI review got partway through then decided it couldn't apply patches. So
> a partial result: https://sashiko.dev/#/patchset/20260320192735.748051-1-nphamcs@gmail.com
It's a bug in the error handling. I've already fixed it, but haven't
deployed the new version yet. In the reality, the review failed for some
other reason (the most popular one now is backend/llm api transient errors).
Sashiko applies the entire patchset first and if it fails, it's not
reviewing anything.
^ permalink raw reply
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: Krzysztof Kozlowski @ 2026-03-21 19:14 UTC (permalink / raw)
To: André Draszik, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <20260318-gs101-pd-v8-4-241523460b10@linaro.org>
On 18/03/2026 16:27, André Draszik wrote:
> The power domains are a property of / implemented in the PMU. As such,
> they should be modelled as child nodes of the PMU.
>
> Note:
> Because the properties added are 'required', this commit breaks DT
> validation of the existing DT for Pixel 6, but a) that's simply because
> the DT is incomplete and b) a DT update will be posted once the binding
> is accepted.
> It is not possible to write the binding such that it supports old
> (incomplete) DTs in addition to the full version, but as per above
> it's not required to keep supporting old DTs.
>
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
> v8:
> - move comment from commit message footer into body (Rob)
> - fix incorrect use of ranges in example (Rob)
>
> v7:
> - really be consistent with quoting (Krzysztof)
> - drop invalid tested-by tag (Krzysztof)
>
> v4:
> - consistent quoting using " (Krzysztof)
> - add samsung,dtzpc to example
> ---
> .../bindings/soc/google/google,gs101-pmu.yaml | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
> index a06bd8ec3c20..52c47252b801 100644
> --- a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
> @@ -16,6 +16,14 @@ properties:
> reg:
> maxItems: 1
>
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + ranges: true
> +
> reboot-mode:
> $ref: /schemas/power/reset/syscon-reboot-mode.yaml
> type: object
> @@ -39,9 +47,23 @@ properties:
> description:
> Phandle to PMU interrupt generation interface.
>
> +patternProperties:
> + "^power-domain@[0-9a-f]+$":
> + type: object
> + description: Child node describing one power domain within the PMU
> +
> + additionalProperties: true
> +
> + properties:
> + compatible:
> + const: google,gs101-pd
> +
> required:
> - compatible
> - reg
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
This causes warnings, so I dropped the patches. I really do not
understand how this is organized. This is not a dependency for pm
domains driver but it is included here. It is a soft dependency for DTS,
but that is nowhere to be found.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Andrew Morton @ 2026-03-21 18:22 UTC (permalink / raw)
To: Nhat Pham
Cc: kasong, Liam.Howlett, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <20260320192735.748051-1-nphamcs@gmail.com>
On Fri, 20 Mar 2026 12:27:14 -0700 Nhat Pham <nphamcs@gmail.com> wrote:
> This patch series implements the virtual swap space idea, based on Yosry's
> proposals at LSFMMBPF 2023 (see [1], [2], [3]), as well as valuable
> inputs from Johannes Weiner. The same idea (with different
> implementation details) has been floated by Rik van Riel since at least
> 2011 (see [8]).
AI review got partway through then decided it couldn't apply patches. So
a partial result: https://sashiko.dev/#/patchset/20260320192735.748051-1-nphamcs@gmail.com
^ permalink raw reply
* Re: [PATCH v7 0/2] mm/swap, PM: hibernate: fix swapoff race and optimize swap
From: Andrew Morton @ 2026-03-21 17:59 UTC (permalink / raw)
To: Youngjun Park
Cc: rafael, chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
usama.arif, linux-pm, linux-mm
In-Reply-To: <20260321103309.439265-1-youngjun.park@lge.com>
On Sat, 21 Mar 2026 19:33:07 +0900 Youngjun Park <youngjun.park@lge.com> wrote:
> Apologies for the frequent revisions. Hopefully this version is close to final.
>
> Currently, in the uswsusp path, only the swap type value is retrieved at
> lookup time without holding a reference. If swapoff races after the type
> is acquired, subsequent slot allocations operate on a stale swap device.
>
> Additionally, grabbing and releasing the swap device reference on every
> slot allocation is inefficient across the entire hibernation swap path.
>
> This patch series addresses these issues:
> - Patch 1: Fixes the swapoff race in uswsusp by pinning the swap device
> from the point it is looked up until the session completes.
> - Patch 2: Removes the overhead of per-slot reference counting in alloc/free
> paths and cleans up the redundant SWP_WRITEOK check.
>
> ...
>
> v6 -> v7:
> - Dropped Patch 3 (pm_restore_gfp_mask fix) from series as it has
> no dependency on Patches 1-2. Will be sent separately.
> (Rafael J. Wysocki feedback)
> - Andrew Morton's AI review
Well. Roman, Chris, Google and others. I'm just a messenger ;)
> findings applied only to Patch 3;
> Patches 1-2 are unchanged. (no problem on AI's review)
Seems that it changed its mind!
https://sashiko.dev/#/patchset/20260321103309.439265-1-youngjun.park@lge.com
^ permalink raw reply
* Re: [PATCH v1 0/2] *** Support BPF traversal of wakeup sources ***
From: Kumar Kartikeya Dwivedi @ 2026-03-21 17:51 UTC (permalink / raw)
To: Samuel Wu
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Greg Kroah-Hartman,
Danilo Krummrich, andrii, bpf, kernel-team, linux-pm, driver-core,
linux-kernel
In-Reply-To: <20260320160055.4114055-1-wusamuel@google.com>
On Fri, 20 Mar 2026 at 17:01, Samuel Wu <wusamuel@google.com> 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.
>
> Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> traverse the wakeup sources list. The head address of wakeup_sources can
> safely be resolved through BPF helper functions or variable attributes.
>
> On a quiescent Pixel 6 traversing 150 wakeup_sources, I am seeing ~34x
> speedup (sampled 75 times in table below). For a device under load, the
> speedup is greater.
> +-------+----+----------+----------+
> | | n | AVG (ms) | STD (ms) |
> +-------+----+----------+----------+
> | sysfs | 75 | 44.9 | 12.6 |
> +-------+----+----------+----------+
> | BPF | 75 | 1.3 | 0.7 |
> +-------+----+----------+----------+
>
> On the memory side, between kernfs, dentry, and kmalloc, each wakeup source
> removed from sysfs saves at least 10kB.
>
> The initial attempts for BPF traversal of wakeup_sources was with BPF
> iterators [1]. However, BPF already allows for traversing of a simple list
> with bpf_for(), and this current patchset has the added benefit of being
> ~2-3x more performant than BPF iterators.
See, it ended up being faster ;-).
That said, I didn't understand why you dropped the test. We still need
unit tests that ensure the verifier causes the bpf_ws_lock to be
released before exit, and an example program (like the one you
benchmarked with) to demonstrate usage. Both are mandatory. See
various *_fail.c files in progs/ and RUN_TESTS() macro for running
negative tests easily. I doubt we will have any wakeup_sources in the
CI environment, but the example has value nonetheless.
pw-bot: cr
>
> [1]: https://lore.kernel.org/all/20260225210820.177674-1-wusamuel@google.com/
>
> Samuel Wu (2):
> PM: wakeup: Add kfuncs to lock/unlock wakeup_sources
> PM: Add config flag to gate sysfs wakeup_sources
>
> drivers/base/power/Makefile | 3 +-
> drivers/base/power/power.h | 14 +++++++++
> drivers/base/power/wakeup.c | 63 +++++++++++++++++++++++++++++++++++--
> kernel/power/Kconfig | 13 ++++++++
> 4 files changed, 90 insertions(+), 3 deletions(-)
>
> --
> 2.53.0.959.g497ff81fa9-goog
>
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS 156256523dae66754586951efb08784d52c33968
From: kernel test robot @ 2026-03-21 15:53 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 156256523dae66754586951efb08784d52c33968 Merge branch 'pm-sleep' into bleeding-edge
elapsed time: 1232m
configs tested: 120
configs skipped: 5
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 gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 randconfig-001-20260321 clang-23
arm64 randconfig-002-20260321 clang-23
arm64 randconfig-003-20260321 gcc-9.5.0
arm64 randconfig-004-20260321 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260321 gcc-15.2.0
csky randconfig-002-20260321 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon randconfig-001-20260321 clang-23
hexagon randconfig-002-20260321 clang-23
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260321 clang-20
i386 buildonly-randconfig-002-20260321 gcc-14
i386 buildonly-randconfig-003-20260321 gcc-14
i386 buildonly-randconfig-004-20260321 clang-20
i386 buildonly-randconfig-005-20260321 clang-20
i386 buildonly-randconfig-006-20260321 clang-20
i386 defconfig clang-20
i386 randconfig-001-20260321 gcc-14
i386 randconfig-002-20260321 gcc-14
i386 randconfig-003-20260321 clang-20
i386 randconfig-004-20260321 gcc-13
i386 randconfig-006-20260321 gcc-14
loongarch allnoconfig clang-23
loongarch randconfig-001-20260321 gcc-15.2.0
loongarch randconfig-002-20260321 clang-20
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 alldefconfig gcc-11.5.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260321 gcc-8.5.0
nios2 randconfig-002-20260321 gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260321 gcc-8.5.0
parisc randconfig-002-20260321 gcc-9.5.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-002-20260321 clang-23
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv randconfig-001-20260321 gcc-15.2.0
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 randconfig-001-20260321 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260321 gcc-15.2.0
sparc allnoconfig gcc-15.2.0
sparc randconfig-001-20260321 gcc-15.2.0
sparc randconfig-002-20260321 gcc-14.3.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260321 clang-23
sparc64 randconfig-002-20260321 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260321 gcc-14
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260321 clang-20
x86_64 randconfig-002-20260321 gcc-14
x86_64 randconfig-003-20260321 clang-20
x86_64 randconfig-004-20260321 gcc-14
x86_64 randconfig-005-20260321 gcc-14
x86_64 randconfig-006-20260321 clang-20
x86_64 randconfig-011-20260321 gcc-13
x86_64 randconfig-012-20260321 gcc-14
x86_64 randconfig-013-20260321 clang-20
x86_64 randconfig-014-20260321 gcc-14
x86_64 randconfig-015-20260321 clang-20
x86_64 randconfig-016-20260321 clang-20
x86_64 randconfig-071-20260321 gcc-14
x86_64 randconfig-072-20260321 clang-20
x86_64 randconfig-073-20260321 gcc-13
x86_64 randconfig-074-20260321 gcc-14
x86_64 randconfig-075-20260321 clang-20
x86_64 randconfig-076-20260321 gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [chanwoo:devfreq-next 5/5] drivers/devfreq/devfreq.c:1946:37: error: redefinition of 'devfreq_group'
From: Chanwoo Choi @ 2026-03-21 15:11 UTC (permalink / raw)
To: kernel test robot
Cc: Jori Koolstra, llvm, oe-kbuild-all, linux-pm, Chanwoo Choi
In-Reply-To: <202603211336.i375F7lD-lkp@intel.com>
HI Jori,
There are build errors in your patches.
DId you test it? I hope to fix and test the patch before posting.
On Sat, Mar 21, 2026 at 9:52 PM kernel test robot <lkp@intel.com> wrote:
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git devfreq-next
> head: 38aa14f9be920f3fea6fe3f16b69b7a0cd0478a1
> commit: 38aa14f9be920f3fea6fe3f16b69b7a0cd0478a1 [5/5] PM / devfreq: change devfreq_class to a const struct
> config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260321/202603211336.i375F7lD-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/20260321/202603211336.i375F7lD-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/202603211336.i375F7lD-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> >> drivers/devfreq/devfreq.c:1946:37: error: redefinition of 'devfreq_group'
> 1946 | static const struct attribute_group devfreq_group = {
> | ^
> drivers/devfreq/devfreq.c:40:1: note: previous definition is here
> 40 | ATTRIBUTE_GROUPS(devfreq);
> | ^
> include/linux/sysfs.h:291:37: note: expanded from macro 'ATTRIBUTE_GROUPS'
> 291 | static const struct attribute_group _name##_group = { \
> | ^
> <scratch space>:89:1: note: expanded from here
> 89 | devfreq_group
> | ^
> >> drivers/devfreq/devfreq.c:1955:38: error: redefinition of 'devfreq_groups'
> 1955 | static const struct attribute_group *devfreq_groups[] = {
> | ^
> drivers/devfreq/devfreq.c:40:1: note: previous definition is here
> 40 | ATTRIBUTE_GROUPS(devfreq);
> | ^
> include/linux/sysfs.h:298:11: note: expanded from macro 'ATTRIBUTE_GROUPS'
> 298 | }; \
> | ^
> include/linux/sysfs.h:285:38: note: expanded from macro '\
> __ATTRIBUTE_GROUPS'
> 285 | static const struct attribute_group *_name##_groups[] = { \
> | ^
> <scratch space>:93:1: note: expanded from here
> 93 | devfreq_groups
> | ^
> 2 errors generated.
>
>
> vim +/devfreq_group +1946 drivers/devfreq/devfreq.c
>
> 9005b65099ee4f MyungJoo Ham 2011-10-02 1945
> e4999090951abc Pengjie Zhang 2025-12-16 @1946 static const struct attribute_group devfreq_group = {
> e4999090951abc Pengjie Zhang 2025-12-16 1947 .attrs = devfreq_attrs,
> e4999090951abc Pengjie Zhang 2025-12-16 1948 };
> e4999090951abc Pengjie Zhang 2025-12-16 1949
> e4999090951abc Pengjie Zhang 2025-12-16 1950 static const struct attribute_group gov_attr_group = {
> e4999090951abc Pengjie Zhang 2025-12-16 1951 .attrs = governor_attrs,
> e4999090951abc Pengjie Zhang 2025-12-16 1952 .is_visible = gov_attr_visible,
> e4999090951abc Pengjie Zhang 2025-12-16 1953 };
> e4999090951abc Pengjie Zhang 2025-12-16 1954
> e4999090951abc Pengjie Zhang 2025-12-16 @1955 static const struct attribute_group *devfreq_groups[] = {
> e4999090951abc Pengjie Zhang 2025-12-16 1956 &devfreq_group,
> e4999090951abc Pengjie Zhang 2025-12-16 1957 &gov_attr_group,
> e4999090951abc Pengjie Zhang 2025-12-16 1958 NULL
> e4999090951abc Pengjie Zhang 2025-12-16 1959 };
> e4999090951abc Pengjie Zhang 2025-12-16 1960
>
> :::::: The code at line 1946 was first introduced by commit
> :::::: e4999090951abcf39543aa22b7a7a7f13c5a5857 PM / devfreq: use _visible attribute to replace create/remove_sysfs_files()
>
> :::::: TO: Pengjie Zhang <zhangpengjie2@huawei.com>
> :::::: CC: Chanwoo Choi <cw00.choi@samsung.com>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-21 13:17 UTC (permalink / raw)
To: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, André Draszik
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm, Marek Szyprowski
In-Reply-To: <20260318-gs101-pd-v8-0-241523460b10@linaro.org>
On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> This series adds support for the power domains on Google GS101.
>
> There are a few differences compared to SoCs already supported by this
> driver:
> * register access does not work via plain ioremap() / readl() /
> writel().
> Instead, the regmap created by the PMU driver must be used (which
> uses Arm SMCC calls under the hood).
> * DTZPC: a call needs to be made before and after power domain off/on,
> to inform the EL3 firmware of the request.
> * power domains can and are fed by a regulator rail and therefore
> regulator control needed be implemented.
>
> [...]
Applied, thanks!
[01/10] dt-bindings: soc: google: add google,gs101-dtzpc
https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
[03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
[04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 07/10] pmdomain: samsung: add support for google,gs101-pd
From: Krzysztof Kozlowski @ 2026-03-21 13:16 UTC (permalink / raw)
To: André Draszik
Cc: Krzysztof Kozlowski, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown,
Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm, Marek Szyprowski
In-Reply-To: <20260318-gs101-pd-v8-7-241523460b10@linaro.org>
On Wed, 18 Mar 2026 15:27:52 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> On Google gs101, direct mmio register access to the PMU registers
> doesn't work and access must happen via a regmap created by the PMU
> driver instead.
>
> Add a flag to the device match data to denote this case, and obtain
> the regmap using the parent node in DT if true, while keeping to use
> the traditional direct mmio regmap otherwise.
>
> Additionally, the status is just one bit on gs101.
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
There are few reviews from Sashiko which seem legitimate. Please check
them. If they are false positives, just reply that you carefully went
through them.
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 05/10] pmdomain: samsung: convert to using regmap
From: Krzysztof Kozlowski @ 2026-03-21 13:16 UTC (permalink / raw)
To: André Draszik
Cc: Krzysztof Kozlowski, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown,
Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm, Marek Szyprowski
In-Reply-To: <20260318-gs101-pd-v8-5-241523460b10@linaro.org>
On Wed, 18 Mar 2026 15:27:50 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> diff --git a/drivers/pmdomain/samsung/exynos-pm-domains.c b/drivers/pmdomain/samsung/exynos-pm-domains.c
> index 5c3aa8983087..68b1e7ba8729 100644
> --- a/drivers/pmdomain/samsung/exynos-pm-domains.c
> +++ b/drivers/pmdomain/samsung/exynos-pm-domains.c
> @@ -120,9 +140,26 @@ static int exynos_pd_probe(struct platform_device *pdev)
> [ ... skip 20 lines ... ]
> +
> + reg_config.max_register = resource_size(res) - reg_config.reg_stride;
> + pd->regmap = devm_regmap_init_mmio(dev, base, ®_config);
> + if (IS_ERR(pd->regmap))
> + return dev_err_probe(dev, PTR_ERR(base),
> + "failed to init regmap\n");
PTR_ERR(pd->regmap)
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: Krzysztof Kozlowski @ 2026-03-21 13:16 UTC (permalink / raw)
To: André Draszik
Cc: Krzysztof Kozlowski, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown,
Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <20260318-gs101-pd-v8-2-241523460b10@linaro.org>
On Wed, 18 Mar 2026 15:27:47 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> diff --git a/Documentation/devicetree/bindings/power/pd-samsung.yaml b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> index 9c2c51133457..3f1a2dc17862 100644
> --- a/Documentation/devicetree/bindings/power/pd-samsung.yaml
> +++ b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> @@ -44,11 +45,28 @@ properties:
> power-domains:
> maxItems: 1
>
> + samsung,dtzpc:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Distributed TrustZone Protection Control (DTZPC) node.
For what purpose?
Your patchset is organized in odd way - first patch for me, then not for
me, then again two patches for me. Please keep it consistent. Or better,
decouple since there are no dependencies according to cover letter.
Best regards,
Krzysztof
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* [chanwoo:devfreq-next 5/5] drivers/devfreq/devfreq.c:1946:37: error: redefinition of 'devfreq_group'
From: kernel test robot @ 2026-03-21 12:52 UTC (permalink / raw)
To: Jori Koolstra; +Cc: llvm, oe-kbuild-all, linux-pm, Chanwoo Choi
tree: https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git devfreq-next
head: 38aa14f9be920f3fea6fe3f16b69b7a0cd0478a1
commit: 38aa14f9be920f3fea6fe3f16b69b7a0cd0478a1 [5/5] PM / devfreq: change devfreq_class to a const struct
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260321/202603211336.i375F7lD-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/20260321/202603211336.i375F7lD-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/202603211336.i375F7lD-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/devfreq/devfreq.c:1946:37: error: redefinition of 'devfreq_group'
1946 | static const struct attribute_group devfreq_group = {
| ^
drivers/devfreq/devfreq.c:40:1: note: previous definition is here
40 | ATTRIBUTE_GROUPS(devfreq);
| ^
include/linux/sysfs.h:291:37: note: expanded from macro 'ATTRIBUTE_GROUPS'
291 | static const struct attribute_group _name##_group = { \
| ^
<scratch space>:89:1: note: expanded from here
89 | devfreq_group
| ^
>> drivers/devfreq/devfreq.c:1955:38: error: redefinition of 'devfreq_groups'
1955 | static const struct attribute_group *devfreq_groups[] = {
| ^
drivers/devfreq/devfreq.c:40:1: note: previous definition is here
40 | ATTRIBUTE_GROUPS(devfreq);
| ^
include/linux/sysfs.h:298:11: note: expanded from macro 'ATTRIBUTE_GROUPS'
298 | }; \
| ^
include/linux/sysfs.h:285:38: note: expanded from macro '\
__ATTRIBUTE_GROUPS'
285 | static const struct attribute_group *_name##_groups[] = { \
| ^
<scratch space>:93:1: note: expanded from here
93 | devfreq_groups
| ^
2 errors generated.
vim +/devfreq_group +1946 drivers/devfreq/devfreq.c
9005b65099ee4f MyungJoo Ham 2011-10-02 1945
e4999090951abc Pengjie Zhang 2025-12-16 @1946 static const struct attribute_group devfreq_group = {
e4999090951abc Pengjie Zhang 2025-12-16 1947 .attrs = devfreq_attrs,
e4999090951abc Pengjie Zhang 2025-12-16 1948 };
e4999090951abc Pengjie Zhang 2025-12-16 1949
e4999090951abc Pengjie Zhang 2025-12-16 1950 static const struct attribute_group gov_attr_group = {
e4999090951abc Pengjie Zhang 2025-12-16 1951 .attrs = governor_attrs,
e4999090951abc Pengjie Zhang 2025-12-16 1952 .is_visible = gov_attr_visible,
e4999090951abc Pengjie Zhang 2025-12-16 1953 };
e4999090951abc Pengjie Zhang 2025-12-16 1954
e4999090951abc Pengjie Zhang 2025-12-16 @1955 static const struct attribute_group *devfreq_groups[] = {
e4999090951abc Pengjie Zhang 2025-12-16 1956 &devfreq_group,
e4999090951abc Pengjie Zhang 2025-12-16 1957 &gov_attr_group,
e4999090951abc Pengjie Zhang 2025-12-16 1958 NULL
e4999090951abc Pengjie Zhang 2025-12-16 1959 };
e4999090951abc Pengjie Zhang 2025-12-16 1960
:::::: The code at line 1946 was first introduced by commit
:::::: e4999090951abcf39543aa22b7a7a7f13c5a5857 PM / devfreq: use _visible attribute to replace create/remove_sysfs_files()
:::::: TO: Pengjie Zhang <zhangpengjie2@huawei.com>
:::::: CC: Chanwoo Choi <cw00.choi@samsung.com>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v6 3/3] PM: hibernate: fix spurious GFP mask WARNING in uswsusp path
From: Rafael J. Wysocki @ 2026-03-21 11:45 UTC (permalink / raw)
To: YoungJun Park
Cc: akpm, chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
usama.arif, linux-pm, linux-mm
In-Reply-To: <CAJZ5v0gVbQQdpyWb72qDcsAoj7vg2v=pXOjdMuWzKHJsdJcHNw@mail.gmail.com>
On Sat, Mar 21, 2026 at 12:32 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Sat, Mar 21, 2026 at 11:48 AM YoungJun Park <youngjun.park@lge.com> wrote:
> >
> > On Fri, Mar 20, 2026 at 07:20:24PM +0100, Rafael J. Wysocki wrote:
> > >...
> >
> > Hi Rafael,
> >
> > Thanks for the review. Sorry for the back and forth on this one.
> > I'm preparing to send the uswsusp GFP mask fix separately as you
> > requested (with _nowarn rename and lockdep_assert_held).
> >
> > Before sending, I wanted to check on the approach. I originally
> > found this WARNING while testing uswsusp and thought it was a
> > localized issue. But AI review has kept uncovering more cases —
> > first SNAPSHOT_FREEZE + snapshot_release(), and now
> > dpm_resume_end() when dpm_prepare() fails.
>
> dpm_resume_end() should not be called after a failing dpm_prepare().
>
> Which code path is that?
OK, I see.
Let me have a deeper look at this.
^ permalink raw reply
* Re: [PATCH v6 3/3] PM: hibernate: fix spurious GFP mask WARNING in uswsusp path
From: Rafael J. Wysocki @ 2026-03-21 11:32 UTC (permalink / raw)
To: YoungJun Park
Cc: Rafael J. Wysocki, akpm, chrisl, kasong, pavel, shikemeng,
nphamcs, bhe, baohua, usama.arif, linux-pm, linux-mm
In-Reply-To: <ab53krr0y981Qyk8@yjaykim-PowerEdge-T330>
On Sat, Mar 21, 2026 at 11:48 AM YoungJun Park <youngjun.park@lge.com> wrote:
>
> On Fri, Mar 20, 2026 at 07:20:24PM +0100, Rafael J. Wysocki wrote:
> >...
>
> Hi Rafael,
>
> Thanks for the review. Sorry for the back and forth on this one.
> I'm preparing to send the uswsusp GFP mask fix separately as you
> requested (with _nowarn rename and lockdep_assert_held).
>
> Before sending, I wanted to check on the approach. I originally
> found this WARNING while testing uswsusp and thought it was a
> localized issue. But AI review has kept uncovering more cases —
> first SNAPSHOT_FREEZE + snapshot_release(), and now
> dpm_resume_end() when dpm_prepare() fails.
dpm_resume_end() should not be called after a failing dpm_prepare().
Which code path is that?
> More callers than I expected use this defensive restore pattern.
>
> So I'd like your thoughts on the approach:
>
> 1. Introduce pm_restore_gfp_mask_nowarn() and update each caller.
>
> 2. Remove the WARN_ON from pm_restore_gfp_mask() itself, restoring
> the pre-stacking no-op behavior.
>
> I'm leaning towards option 2. Defensive restores are an established
> pattern in multiple paths, and warning against a legitimate no-op
> seems counterproductive — we'd just be playing whack-a-mole with
> _nowarn conversions as more callers turn up.
>
> What do you think?
Using the _nowarn() wariant would help to annotate code paths where
omitting the warning is legitimate.
^ permalink raw reply
* Re: [PATCH v2 6.12.y 0/6] cpuidle: menu: Backport get_typical_interval() improvements
From: Greg KH @ 2026-03-21 11:03 UTC (permalink / raw)
To: Ionut Nechita (Wind River)
Cc: stable, rafael.j.wysocki, linux-pm, christian.loehle,
artem.bityutskiy, quic_zhonhan, aboorvad
In-Reply-To: <20260321103721.35114-1-ionut.nechita@windriver.com>
On Sat, Mar 21, 2026 at 12:37:15PM +0200, Ionut Nechita (Wind River) wrote:
> From: "Ionut Nechita" <ionut.nechita@windriver.com>
>
> This series backports 6 upstream commits that improve the menu
> governor's get_typical_interval() function to linux-6.12.y stable.
>
> These patches are already present in linux-6.18.y but were not picked
> up for 6.12.y because they lack Cc: stable tags.
>
> The key improvement is in patch 2/6 which merges the two separate loops
> for average and variance computation into a single pass, reducing the
> latency of menu_select() on isolated (nohz_full) cores. The remaining
> patches refactor outlier detection to cover both ends of the sample set,
> update documentation to match the new code, and add a minor bucket
> assignment optimization.
>
> After applying this series, drivers/cpuidle/governors/menu.c matches
> linux-6.18.y exactly.
>
> All patches are clean cherry-picks from mainline with one trivial
> conflict resolution in Documentation/admin-guide/pm/cpuidle.rst
> (patch 5/6).
>
> Changes since v1:
> - Added upstream commit IDs to each patch (Greg KH)
Still incorrect :(
^ permalink raw reply
* Re: [PATCH v6 3/3] PM: hibernate: fix spurious GFP mask WARNING in uswsusp path
From: YoungJun Park @ 2026-03-21 10:48 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: akpm, chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
usama.arif, linux-pm, linux-mm
In-Reply-To: <CAJZ5v0gHTPCkVySAuPBkPoV=SwmBRG_c-TtPbz0CNsUUPEkY8w@mail.gmail.com>
On Fri, Mar 20, 2026 at 07:20:24PM +0100, Rafael J. Wysocki wrote:
>...
Hi Rafael,
Thanks for the review. Sorry for the back and forth on this one.
I'm preparing to send the uswsusp GFP mask fix separately as you
requested (with _nowarn rename and lockdep_assert_held).
Before sending, I wanted to check on the approach. I originally
found this WARNING while testing uswsusp and thought it was a
localized issue. But AI review has kept uncovering more cases —
first SNAPSHOT_FREEZE + snapshot_release(), and now
dpm_resume_end() when dpm_prepare() fails. More callers than I
expected use this defensive restore pattern.
So I'd like your thoughts on the approach:
1. Introduce pm_restore_gfp_mask_nowarn() and update each caller.
2. Remove the WARN_ON from pm_restore_gfp_mask() itself, restoring
the pre-stacking no-op behavior.
I'm leaning towards option 2. Defensive restores are an established
pattern in multiple paths, and warning against a legitimate no-op
seems counterproductive — we'd just be playing whack-a-mole with
_nowarn conversions as more callers turn up.
What do you think?
Youngjun Park
^ permalink raw reply
* [PATCH v2 6.12.y 6/6] cpuidle: menu: Optimize bucket assignment when next_timer_ns equals KTIME_MAX
From: Ionut Nechita (Wind River) @ 2026-03-21 10:37 UTC (permalink / raw)
To: stable
Cc: rafael.j.wysocki, linux-pm, christian.loehle, artem.bityutskiy,
quic_zhonhan, aboorvad, Ionut Nechita
In-Reply-To: <20260321103721.35114-1-ionut.nechita@windriver.com>
From: Ionut Nechita <ionut.nechita@windriver.com>
From: Zhongqiu Han <quic_zhonhan@quicinc.com>
commit d4a7882f93bf2520315d10ab600ea4701e22be69 upstream.
Directly assign the last bucket value instead of calling which_bucket()
when next_timer_ns equals KTIME_MAX, the largest possible value that
always falls into the last bucket.
This avoids unnecessary calculations and enhances performance.
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
Link: https://patch.msgid.link/20250405135308.1854342-1-quic_zhonhan@quicinc.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index a18477ecce433..ca863ba03d454 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -278,7 +278,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
*/
data->next_timer_ns = KTIME_MAX;
delta_tick = TICK_NSEC / 2;
- data->bucket = which_bucket(KTIME_MAX);
+ data->bucket = BUCKETS - 1;
}
if (unlikely(drv->state_count <= 1 || latency_req == 0) ||
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6.12.y 4/6] cpuidle: menu: Eliminate outliers on both ends of the sample set
From: Ionut Nechita (Wind River) @ 2026-03-21 10:37 UTC (permalink / raw)
To: stable
Cc: rafael.j.wysocki, linux-pm, christian.loehle, artem.bityutskiy,
quic_zhonhan, aboorvad, Ionut Nechita
In-Reply-To: <20260321103721.35114-1-ionut.nechita@windriver.com>
From: Ionut Nechita <ionut.nechita@windriver.com>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 8de7606f0fe2bf5a918fe97d425e16e190a24fe6 upstream.
Currently, get_typical_interval() attempts to eliminate outliers at the
high end of the sample set only (probably in order to bias the prediction
toward lower values), but this it problematic because if the outliers are
present at the low end of the sample set, discarding the highest values
will not help to reduce the variance.
Since the presence of outliers at the low end of the sample set is
generally as likely as their presence at the high end of the sample
set, modify get_typical_interval() to treat samples at the largest
distances from the average (on both ends of the sample set) as outliers.
This should increase the likelihood of making a meaningful prediction
in some cases.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Link: https://patch.msgid.link/2301940.iZASKD2KPV@rjwysocki.net
---
| 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 96bee77b8354f..8ab5123c81040 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -124,30 +124,37 @@ static void menu_update(struct cpuidle_driver *drv, struct cpuidle_device *dev);
*/
static unsigned int get_typical_interval(struct menu_device *data)
{
- unsigned int max, divisor, thresh = UINT_MAX;
+ s64 value, min_thresh = -1, max_thresh = UINT_MAX;
+ unsigned int max, min, divisor;
u64 avg, variance, avg_sq;
int i;
again:
/* Compute the average and variance of past intervals. */
max = 0;
+ min = UINT_MAX;
avg = 0;
variance = 0;
divisor = 0;
for (i = 0; i < INTERVALS; i++) {
- unsigned int value = data->intervals[i];
-
- /* Discard data points above or at the threshold. */
- if (value >= thresh)
+ value = data->intervals[i];
+ /*
+ * Discard the samples outside the interval between the min and
+ * max thresholds.
+ */
+ if (value <= min_thresh || value >= max_thresh)
continue;
divisor++;
avg += value;
- variance += (u64)value * value;
+ variance += value * value;
if (value > max)
max = value;
+
+ if (value < min)
+ min = value;
}
if (!max)
@@ -183,10 +190,10 @@ static unsigned int get_typical_interval(struct menu_device *data)
}
/*
- * If we have outliers to the upside in our distribution, discard
- * those by setting the threshold to exclude these outliers, then
+ * If there are outliers, discard them by setting thresholds to exclude
+ * data points at a large enough distance from the average, then
* calculate the average and standard deviation again. Once we get
- * down to the bottom 3/4 of our samples, stop excluding samples.
+ * down to the last 3/4 of our samples, stop excluding samples.
*
* This can deal with workloads that have long pauses interspersed
* with sporadic activity with a bunch of short pauses.
@@ -202,7 +209,12 @@ static unsigned int get_typical_interval(struct menu_device *data)
if (divisor * 4 <= INTERVALS * 3)
return UINT_MAX;
- thresh = max;
+ /* Update the thresholds for the next round. */
+ if (avg - min > max - avg)
+ min_thresh = min;
+ else
+ max_thresh = max;
+
goto again;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6.12.y 5/6] cpuidle: menu: Update documentation after get_typical_interval() changes
From: Ionut Nechita (Wind River) @ 2026-03-21 10:37 UTC (permalink / raw)
To: stable
Cc: rafael.j.wysocki, linux-pm, christian.loehle, artem.bityutskiy,
quic_zhonhan, aboorvad, Ionut Nechita
In-Reply-To: <20260321103721.35114-1-ionut.nechita@windriver.com>
From: Ionut Nechita <ionut.nechita@windriver.com>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 5c350410999653dff8d2975d794088e4c166e8b5 upstream.
The documentation of the menu cpuidle governor needs to be updated
to match the code behavior after some changes made recently.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/4998484.31r3eYUQgx@rjwysocki.net
[ rjw: More specific subject, two typos fixed in the changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Documentation/admin-guide/pm/cpuidle.rst | 56 +++++++++++++++---------
| 29 +++++-------
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst
index 19754beb5a4e6..9fcc35498fb0e 100644
--- a/Documentation/admin-guide/pm/cpuidle.rst
+++ b/Documentation/admin-guide/pm/cpuidle.rst
@@ -295,30 +295,44 @@ values and, when predicting the idle duration next time, it computes the average
and variance of them. If the variance is small (smaller than 400 square
milliseconds) or it is small relative to the average (the average is greater
that 6 times the standard deviation), the average is regarded as the "typical
-interval" value. Otherwise, the longest of the saved observed idle duration
+interval" value. Otherwise, either the longest or the shortest (depending on
+which one is farther from the average) of the saved observed idle duration
values is discarded and the computation is repeated for the remaining ones.
+
Again, if the variance of them is small (in the above sense), the average is
taken as the "typical interval" value and so on, until either the "typical
-interval" is determined or too many data points are disregarded, in which case
-the "typical interval" is assumed to equal "infinity" (the maximum unsigned
-integer value). The "typical interval" computed this way is compared with the
-sleep length multiplied by the correction factor and the minimum of the two is
-taken as the predicted idle duration.
-
-Then, the governor computes an extra latency limit to help "interactive"
-workloads. It uses the observation that if the exit latency of the selected
-idle state is comparable with the predicted idle duration, the total time spent
-in that state probably will be very short and the amount of energy to save by
-entering it will be relatively small, so likely it is better to avoid the
-overhead related to entering that state and exiting it. Thus selecting a
-shallower state is likely to be a better option then. The first approximation
-of the extra latency limit is the predicted idle duration itself which
-additionally is divided by a value depending on the number of tasks that
-previously ran on the given CPU and now they are waiting for I/O operations to
-complete. The result of that division is compared with the latency limit coming
-from the power management quality of service, or `PM QoS <cpu-pm-qos_>`_,
-framework and the minimum of the two is taken as the limit for the idle states'
-exit latency.
+interval" is determined or too many data points are disregarded. In the latter
+case, if the size of the set of data points still under consideration is
+sufficiently large, the next idle duration is not likely to be above the largest
+idle duration value still in that set, so that value is taken as the predicted
+next idle duration. Finally, if the set of data points still under
+consideration is too small, no prediction is made.
+
+If the preliminary prediction of the next idle duration computed this way is
+long enough, the governor obtains the time until the closest timer event with
+the assumption that the scheduler tick will be stopped. That time, referred to
+as the *sleep length* in what follows, is the upper bound on the time before the
+next CPU wakeup. It is used to determine the sleep length range, which in turn
+is needed to get the sleep length correction factor.
+
+The ``menu`` governor maintains an array containing several correction factor
+values that correspond to different sleep length ranges organized so that each
+range represented in the array is approximately 10 times wider than the previous
+one.
+
+The correction factor for the given sleep length range (determined before
+selecting the idle state for the CPU) is updated after the CPU has been woken
+up and the closer the sleep length is to the observed idle duration, the closer
+to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
+The sleep length is multiplied by the correction factor for the range that it
+falls into to obtain an approximation of the predicted idle duration that is
+compared to the "typical interval" determined previously and the minimum of
+the two is taken as the final idle duration prediction.
+
+If the "typical interval" value is small, which means that the CPU is likely
+to be woken up soon enough, the sleep length computation is skipped as it may
+be costly and the idle duration is simply predicted to equal the "typical
+interval" value.
Now, the governor is ready to walk the list of idle states and choose one of
them. For this purpose, it compares the target residency of each state with
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 8ab5123c81040..a18477ecce433 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -41,7 +41,7 @@
* the C state is required to actually break even on this cost. CPUIDLE
* provides us this duration in the "target_residency" field. So all that we
* need is a good prediction of how long we'll be idle. Like the traditional
- * menu governor, we start with the actual known "next timer event" time.
+ * menu governor, we take the actual known "next timer event" time.
*
* Since there are other source of wakeups (interrupts for example) than
* the next timer event, this estimation is rather optimistic. To get a
@@ -50,30 +50,21 @@
* duration always was 50% of the next timer tick, the correction factor will
* be 0.5.
*
- * menu uses a running average for this correction factor, however it uses a
- * set of factors, not just a single factor. This stems from the realization
- * that the ratio is dependent on the order of magnitude of the expected
- * duration; if we expect 500 milliseconds of idle time the likelihood of
- * getting an interrupt very early is much higher than if we expect 50 micro
- * seconds of idle time. A second independent factor that has big impact on
- * the actual factor is if there is (disk) IO outstanding or not.
- * (as a special twist, we consider every sleep longer than 50 milliseconds
- * as perfect; there are no power gains for sleeping longer than this)
- *
- * For these two reasons we keep an array of 12 independent factors, that gets
- * indexed based on the magnitude of the expected duration as well as the
- * "is IO outstanding" property.
+ * menu uses a running average for this correction factor, but it uses a set of
+ * factors, not just a single factor. This stems from the realization that the
+ * ratio is dependent on the order of magnitude of the expected duration; if we
+ * expect 500 milliseconds of idle time the likelihood of getting an interrupt
+ * very early is much higher than if we expect 50 micro seconds of idle time.
+ * For this reason, menu keeps an array of 6 independent factors, that gets
+ * indexed based on the magnitude of the expected duration.
*
* Repeatable-interval-detector
* ----------------------------
* There are some cases where "next timer" is a completely unusable predictor:
* Those cases where the interval is fixed, for example due to hardware
- * interrupt mitigation, but also due to fixed transfer rate devices such as
- * mice.
+ * interrupt mitigation, but also due to fixed transfer rate devices like mice.
* For this, we use a different predictor: We track the duration of the last 8
- * intervals and if the stand deviation of these 8 intervals is below a
- * threshold value, we use the average of these intervals as prediction.
- *
+ * intervals and use them to estimate the duration of the next one.
*/
struct menu_device {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6.12.y 3/6] cpuidle: menu: Tweak threshold use in get_typical_interval()
From: Ionut Nechita (Wind River) @ 2026-03-21 10:37 UTC (permalink / raw)
To: stable
Cc: rafael.j.wysocki, linux-pm, christian.loehle, artem.bityutskiy,
quic_zhonhan, aboorvad, Ionut Nechita
In-Reply-To: <20260321103721.35114-1-ionut.nechita@windriver.com>
From: Ionut Nechita <ionut.nechita@windriver.com>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 60256e458e1c29652b2f9e4f2ba71fc7b09bd30c upstream.
To prepare get_typical_interval() for subsequent changes, rearrange
the use of the data point threshold in it a bit and initialize that
threshold to UINT_MAX which is more consistent with its data type.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Link: https://patch.msgid.link/8490144.T7Z3S40VBb@rjwysocki.net
---
| 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 8943bb8f19190..96bee77b8354f 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -124,7 +124,7 @@ static void menu_update(struct cpuidle_driver *drv, struct cpuidle_device *dev);
*/
static unsigned int get_typical_interval(struct menu_device *data)
{
- unsigned int max, divisor, thresh = INT_MAX;
+ unsigned int max, divisor, thresh = UINT_MAX;
u64 avg, variance, avg_sq;
int i;
@@ -137,8 +137,8 @@ static unsigned int get_typical_interval(struct menu_device *data)
for (i = 0; i < INTERVALS; i++) {
unsigned int value = data->intervals[i];
- /* Discard data points above the threshold. */
- if (value > thresh)
+ /* Discard data points above or at the threshold. */
+ if (value >= thresh)
continue;
divisor++;
@@ -202,7 +202,7 @@ static unsigned int get_typical_interval(struct menu_device *data)
if (divisor * 4 <= INTERVALS * 3)
return UINT_MAX;
- thresh = max - 1;
+ thresh = max;
goto again;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6.12.y 2/6] cpuidle: menu: Use one loop for average and variance computations
From: Ionut Nechita (Wind River) @ 2026-03-21 10:37 UTC (permalink / raw)
To: stable
Cc: rafael.j.wysocki, linux-pm, christian.loehle, artem.bityutskiy,
quic_zhonhan, aboorvad, Ionut Nechita
In-Reply-To: <20260321103721.35114-1-ionut.nechita@windriver.com>
From: Ionut Nechita <ionut.nechita@windriver.com>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit 13982929fb08ed4691256072856f50bf7b206b9b upstream.
Use the observation that one loop is sufficient to compute the average
of an array of values and their variance to eliminate one of the loops
from get_typical_interval().
While at it, make get_typical_interval() consistently use u64 as the
64-bit unsigned integer data type and rearrange some white space and the
declarations of local variables in it (to make them follow the reverse
X-mas tree pattern).
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Link: https://patch.msgid.link/3339073.aeNJFYEL58@rjwysocki.net
---
| 61 +++++++++++++++-----------------
1 file changed, 28 insertions(+), 33 deletions(-)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index dd7e2a965878e..8943bb8f19190 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -124,49 +124,45 @@ static void menu_update(struct cpuidle_driver *drv, struct cpuidle_device *dev);
*/
static unsigned int get_typical_interval(struct menu_device *data)
{
- int i, divisor;
- unsigned int max, thresh, avg;
- uint64_t sum, variance;
-
- thresh = INT_MAX; /* Discard outliers above this value */
+ unsigned int max, divisor, thresh = INT_MAX;
+ u64 avg, variance, avg_sq;
+ int i;
again:
-
- /* First calculate the average of past intervals */
+ /* Compute the average and variance of past intervals. */
max = 0;
- sum = 0;
+ avg = 0;
+ variance = 0;
divisor = 0;
for (i = 0; i < INTERVALS; i++) {
unsigned int value = data->intervals[i];
- if (value <= thresh) {
- sum += value;
- divisor++;
- if (value > max)
- max = value;
- }
+
+ /* Discard data points above the threshold. */
+ if (value > thresh)
+ continue;
+
+ divisor++;
+
+ avg += value;
+ variance += (u64)value * value;
+
+ if (value > max)
+ max = value;
}
if (!max)
return UINT_MAX;
- if (divisor == INTERVALS)
- avg = sum >> INTERVAL_SHIFT;
- else
- avg = div_u64(sum, divisor);
-
- /* Then try to determine variance */
- variance = 0;
- for (i = 0; i < INTERVALS; i++) {
- unsigned int value = data->intervals[i];
- if (value <= thresh) {
- int64_t diff = (int64_t)value - avg;
- variance += diff * diff;
- }
- }
- if (divisor == INTERVALS)
+ if (divisor == INTERVALS) {
+ avg >>= INTERVAL_SHIFT;
variance >>= INTERVAL_SHIFT;
- else
+ } else {
+ do_div(avg, divisor);
do_div(variance, divisor);
+ }
+
+ avg_sq = avg * avg;
+ variance -= avg_sq;
/*
* The typical interval is obtained when standard deviation is
@@ -181,10 +177,9 @@ static unsigned int get_typical_interval(struct menu_device *data)
* Use this result only if there is no timer to wake us up sooner.
*/
if (likely(variance <= U64_MAX/36)) {
- if ((((u64)avg*avg > variance*36) && (divisor * 4 >= INTERVALS * 3))
- || variance <= 400) {
+ if ((avg_sq > variance * 36 && divisor * 4 >= INTERVALS * 3) ||
+ variance <= 400)
return avg;
- }
}
/*
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6.12.y 1/6] cpuidle: menu: Drop a redundant local variable
From: Ionut Nechita (Wind River) @ 2026-03-21 10:37 UTC (permalink / raw)
To: stable
Cc: rafael.j.wysocki, linux-pm, christian.loehle, artem.bityutskiy,
quic_zhonhan, aboorvad, Ionut Nechita
In-Reply-To: <20260321103721.35114-1-ionut.nechita@windriver.com>
From: Ionut Nechita <ionut.nechita@windriver.com>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit d2cd195b57cf5ffbe432be01e96f35637e7bd403 upstream.
Local variable min in get_typical_interval() is updated, but never
accessed later, so drop it.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Tested-by: Christian Loehle <christian.loehle@arm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Link: https://patch.msgid.link/13699686.uLZWGnKmhe@rjwysocki.net
---
| 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 0ce7323450011..dd7e2a965878e 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -125,7 +125,7 @@ static void menu_update(struct cpuidle_driver *drv, struct cpuidle_device *dev);
static unsigned int get_typical_interval(struct menu_device *data)
{
int i, divisor;
- unsigned int min, max, thresh, avg;
+ unsigned int max, thresh, avg;
uint64_t sum, variance;
thresh = INT_MAX; /* Discard outliers above this value */
@@ -133,7 +133,6 @@ static unsigned int get_typical_interval(struct menu_device *data)
again:
/* First calculate the average of past intervals */
- min = UINT_MAX;
max = 0;
sum = 0;
divisor = 0;
@@ -144,9 +143,6 @@ static unsigned int get_typical_interval(struct menu_device *data)
divisor++;
if (value > max)
max = value;
-
- if (value < min)
- min = value;
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6.12.y 0/6] cpuidle: menu: Backport get_typical_interval() improvements
From: Ionut Nechita (Wind River) @ 2026-03-21 10:37 UTC (permalink / raw)
To: stable
Cc: rafael.j.wysocki, linux-pm, christian.loehle, artem.bityutskiy,
quic_zhonhan, aboorvad, Ionut Nechita
From: "Ionut Nechita" <ionut.nechita@windriver.com>
This series backports 6 upstream commits that improve the menu
governor's get_typical_interval() function to linux-6.12.y stable.
These patches are already present in linux-6.18.y but were not picked
up for 6.12.y because they lack Cc: stable tags.
The key improvement is in patch 2/6 which merges the two separate loops
for average and variance computation into a single pass, reducing the
latency of menu_select() on isolated (nohz_full) cores. The remaining
patches refactor outlier detection to cover both ends of the sample set,
update documentation to match the new code, and add a minor bucket
assignment optimization.
After applying this series, drivers/cpuidle/governors/menu.c matches
linux-6.18.y exactly.
All patches are clean cherry-picks from mainline with one trivial
conflict resolution in Documentation/admin-guide/pm/cpuidle.rst
(patch 5/6).
Changes since v1:
- Added upstream commit IDs to each patch (Greg KH)
Upstream commits:
d2cd195b57cf ("cpuidle: menu: Drop a redundant local variable")
13982929fb08 ("cpuidle: menu: Use one loop for average and variance computations")
60256e458e1c ("cpuidle: menu: Tweak threshold use in get_typical_interval()")
8de7606f0fe2 ("cpuidle: menu: Eliminate outliers on both ends of the sample set")
5c3504109996 ("cpuidle: menu: Update documentation after get_typical_interval() changes")
d4a7882f93bf ("cpuidle: menu: Optimize bucket assignment when next_timer_ns equals KTIME_MAX")
Rafael J. Wysocki (5):
cpuidle: menu: Drop a redundant local variable
cpuidle: menu: Use one loop for average and variance computations
cpuidle: menu: Tweak threshold use in get_typical_interval()
cpuidle: menu: Eliminate outliers on both ends of the sample set
cpuidle: menu: Update documentation after get_typical_interval()
changes
Zhongqiu Han (1):
cpuidle: menu: Optimize bucket assignment when next_timer_ns equals
KTIME_MAX
Documentation/admin-guide/pm/cpuidle.rst | 56 +++++++----
drivers/cpuidle/governors/menu.c | 118 +++++++++++------------
2 files changed, 91 insertions(+), 83 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH v7 2/2] mm/swap: remove redundant swap device reference in alloc/free
From: Youngjun Park @ 2026-03-21 10:33 UTC (permalink / raw)
To: rafael, akpm
Cc: chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
youngjun.park, usama.arif, linux-pm, linux-mm
In-Reply-To: <20260321103309.439265-1-youngjun.park@lge.com>
In the previous commit, uswsusp was modified to pin the swap device
when the swap type is determined, ensuring the device remains valid
throughout the hibernation I/O path.
Therefore, it is no longer necessary to repeatedly get and put the swap
device reference for each swap slot allocation and free operation.
For hibernation via the sysfs interface, user-space tasks are frozen
before swap allocation begins, so swapoff cannot race with allocation.
After resume, tasks remain frozen while swap slots are freed, so
additional reference management is not required there either.
Remove the redundant swap device get/put operations from the
hibernation swap allocation and free paths.
Also remove the SWP_WRITEOK check before allocation, as the cluster
allocation logic already validates the swap device state.
Signed-off-by: Youngjun Park <youngjun.park@lge.com>
---
mm/swapfile.c | 43 ++++++++++++++++++++-----------------------
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index ac1574acade7..dd9631658808 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1923,7 +1923,12 @@ void swap_put_entries_direct(swp_entry_t entry, int nr)
}
#ifdef CONFIG_HIBERNATION
-/* Allocate a slot for hibernation */
+/*
+ * Allocate a slot for hibernation.
+ *
+ * Note: The caller must ensure the swap device is stable, either by
+ * holding a reference or by freezing user-space before calling this.
+ */
swp_entry_t swap_alloc_hibernation_slot(int type)
{
struct swap_info_struct *si = swap_type_to_info(type);
@@ -1933,43 +1938,35 @@ swp_entry_t swap_alloc_hibernation_slot(int type)
if (!si)
goto fail;
- /* This is called for allocating swap entry, not cache */
- if (get_swap_device_info(si)) {
- if (si->flags & SWP_WRITEOK) {
- /*
- * Grab the local lock to be compliant
- * with swap table allocation.
- */
- local_lock(&percpu_swap_cluster.lock);
- offset = cluster_alloc_swap_entry(si, NULL);
- local_unlock(&percpu_swap_cluster.lock);
- if (offset)
- entry = swp_entry(si->type, offset);
- }
- put_swap_device(si);
- }
+ /*
+ * Grab the local lock to be compliant
+ * with swap table allocation.
+ */
+ local_lock(&percpu_swap_cluster.lock);
+ offset = cluster_alloc_swap_entry(si, NULL);
+ local_unlock(&percpu_swap_cluster.lock);
+ if (offset)
+ entry = swp_entry(si->type, offset);
fail:
return entry;
}
-/* Free a slot allocated by swap_alloc_hibernation_slot */
+/*
+ * Free a slot allocated by swap_alloc_hibernation_slot.
+ * As with allocation, the caller must ensure the swap device is stable.
+ */
void swap_free_hibernation_slot(swp_entry_t entry)
{
- struct swap_info_struct *si;
+ struct swap_info_struct *si = __swap_entry_to_info(entry);
struct swap_cluster_info *ci;
pgoff_t offset = swp_offset(entry);
- si = get_swap_device(entry);
- if (WARN_ON(!si))
- return;
-
ci = swap_cluster_lock(si, offset);
swap_put_entry_locked(si, ci, offset);
swap_cluster_unlock(ci);
/* In theory readahead might add it to the swap cache by accident */
__try_to_reclaim_swap(si, offset, TTRS_ANYWAY);
- put_swap_device(si);
}
static int __find_hibernation_swap_type(dev_t device, sector_t offset)
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox