* [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Nord SoC
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
In-Reply-To: <20260414035909.652992-1-shengchao.guo@oss.qualcomm.com>
From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Add RPMh power domains required for Nord SoC. This includes
new definitions for power domains supplying GFX1 and NSP3 subsystem.
Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
drivers/pmdomain/qcom/rpmhpd.c | 35 ++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index ba0cf4694435..63120e703923 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -122,6 +122,11 @@ static struct rpmhpd gfx = {
.res_name = "gfx.lvl",
};
+static struct rpmhpd gfx1 = {
+ .pd = { .name = "gfx1", },
+ .res_name = "gfx1.lvl",
+};
+
static struct rpmhpd lcx = {
.pd = { .name = "lcx", },
.res_name = "lcx.lvl",
@@ -217,6 +222,11 @@ static struct rpmhpd nsp2 = {
.res_name = "nsp2.lvl",
};
+static struct rpmhpd nsp3 = {
+ .pd = { .name = "nsp3", },
+ .res_name = "nsp3.lvl",
+};
+
static struct rpmhpd qphy = {
.pd = { .name = "qphy", },
.res_name = "qphy.lvl",
@@ -308,6 +318,30 @@ static const struct rpmhpd_desc sa8775p_desc = {
.num_pds = ARRAY_SIZE(sa8775p_rpmhpds),
};
+/* Nord RPMH powerdomains */
+static struct rpmhpd *nord_rpmhpds[] = {
+ [RPMHPD_CX] = &cx,
+ [RPMHPD_CX_AO] = &cx_ao,
+ [RPMHPD_EBI] = &ebi,
+ [RPMHPD_GFX] = &gfx,
+ [RPMHPD_GFX1] = &gfx1,
+ [RPMHPD_MX] = &mx,
+ [RPMHPD_MX_AO] = &mx_ao,
+ [RPMHPD_MMCX] = &mmcx,
+ [RPMHPD_MMCX_AO] = &mmcx_ao,
+ [RPMHPD_MXC] = &mxc,
+ [RPMHPD_MXC_AO] = &mxc_ao,
+ [RPMHPD_NSP0] = &nsp0,
+ [RPMHPD_NSP1] = &nsp1,
+ [RPMHPD_NSP2] = &nsp2,
+ [RPMHPD_NSP3] = &nsp3,
+};
+
+static const struct rpmhpd_desc nord_desc = {
+ .rpmhpds = nord_rpmhpds,
+ .num_pds = ARRAY_SIZE(nord_rpmhpds),
+};
+
/* SAR2130P RPMH powerdomains */
static struct rpmhpd *sar2130p_rpmhpds[] = {
[RPMHPD_CX] = &cx,
@@ -856,6 +890,7 @@ static const struct of_device_id rpmhpd_match_table[] = {
{ .compatible = "qcom,hawi-rpmhpd", .data = &hawi_desc },
{ .compatible = "qcom,kaanapali-rpmhpd", .data = &kaanapali_desc },
{ .compatible = "qcom,milos-rpmhpd", .data = &milos_desc },
+ { .compatible = "qcom,nord-rpmhpd", .data = &nord_desc },
{ .compatible = "qcom,qcs615-rpmhpd", .data = &qcs615_desc },
{ .compatible = "qcom,qcs8300-rpmhpd", .data = &qcs8300_desc },
{ .compatible = "qcom,qdu1000-rpmhpd", .data = &qdu1000_desc },
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Nord SoC
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
In-Reply-To: <20260414035909.652992-1-shengchao.guo@oss.qualcomm.com>
From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Document the RPMh power domain for Nord SoC, and add definitions for
the new power domains present on Nord SoC.
- RPMHPD_NSP3: power domain for the 4th NSP subsystem
- RPMHPD_GFX1: power domain for the 2nd GFX subsystem
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
include/dt-bindings/power/qcom,rpmhpd.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 0bf1e13a9964..779380cc7e44 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -35,6 +35,7 @@ properties:
- qcom,msm8994-rpmpd
- qcom,msm8996-rpmpd
- qcom,msm8998-rpmpd
+ - qcom,nord-rpmhpd
- qcom,qcm2290-rpmpd
- qcom,qcs404-rpmpd
- qcom,qcs615-rpmhpd
diff --git a/include/dt-bindings/power/qcom,rpmhpd.h b/include/dt-bindings/power/qcom,rpmhpd.h
index 74e910150956..07bd2a7b0150 100644
--- a/include/dt-bindings/power/qcom,rpmhpd.h
+++ b/include/dt-bindings/power/qcom,rpmhpd.h
@@ -30,6 +30,8 @@
#define RPMHPD_GMXC 20
#define RPMHPD_DCX 21
#define RPMHPD_GBX 22
+#define RPMHPD_NSP3 23
+#define RPMHPD_GFX1 24
/* RPMh Power Domain performance levels */
#define RPMH_REGULATOR_LEVEL_RETENTION 16
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: power: qcom,rpmhpd: Fix whitespace in RPMHPD defines
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
In-Reply-To: <20260414035909.652992-1-shengchao.guo@oss.qualcomm.com>
Some RPMHPD_* defines in the Generic RPMH Power Domain Indexes section
were using spaces instead of tabs for alignment. Fix them to be
consistent with the rest of the file.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
include/dt-bindings/power/qcom,rpmhpd.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/dt-bindings/power/qcom,rpmhpd.h b/include/dt-bindings/power/qcom,rpmhpd.h
index 67e2634fdc99..74e910150956 100644
--- a/include/dt-bindings/power/qcom,rpmhpd.h
+++ b/include/dt-bindings/power/qcom,rpmhpd.h
@@ -7,7 +7,7 @@
#define _DT_BINDINGS_POWER_QCOM_RPMHPD_H
/* Generic RPMH Power Domain Indexes */
-#define RPMHPD_CX 0
+#define RPMHPD_CX 0
#define RPMHPD_CX_AO 1
#define RPMHPD_EBI 2
#define RPMHPD_GFX 3
@@ -19,14 +19,14 @@
#define RPMHPD_MX_AO 9
#define RPMHPD_MXC 10
#define RPMHPD_MXC_AO 11
-#define RPMHPD_MSS 12
+#define RPMHPD_MSS 12
#define RPMHPD_NSP 13
-#define RPMHPD_NSP0 14
-#define RPMHPD_NSP1 15
-#define RPMHPD_QPHY 16
-#define RPMHPD_DDR 17
-#define RPMHPD_XO 18
-#define RPMHPD_NSP2 19
+#define RPMHPD_NSP0 14
+#define RPMHPD_NSP1 15
+#define RPMHPD_QPHY 16
+#define RPMHPD_DDR 17
+#define RPMHPD_XO 18
+#define RPMHPD_NSP2 19
#define RPMHPD_GMXC 20
#define RPMHPD_DCX 21
#define RPMHPD_GBX 22
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] pmdomain: qcom: rpmhpd: Add power domains for Nord SoC
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
This series adds RPMh power domain support for the Qualcomm Nord SoC.
The Nord SoC introduces two new power domains beyond the existing set: GFX1
for the second GFX subsystem and NSP3 for the fourth NSP subsystem. Patch 1
is a preparatory cleanup that fixes inconsistent whitespace in the RPMHPD
define block before the new entries are added. Patches 2-3 add the DT
bindings and driver support for Nord respectively.
Kamal Wadhwa (2):
dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Nord SoC
pmdomain: qcom: rpmhpd: Add power domains for Nord SoC
Shawn Guo (1):
dt-bindings: power: qcom,rpmhpd: Fix whitespace in RPMHPD defines
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
drivers/pmdomain/qcom/rpmhpd.c | 35 +++++++++++++++++++
include/dt-bindings/power/qcom,rpmhpd.h | 18 +++++-----
3 files changed, 46 insertions(+), 8 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [GIT PULL] power sequencing updates for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 3:35 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Linus Torvalds, linux-pm, linux-kernel, brgl, Bartosz Golaszewski
In-Reply-To: <20260410084643.14631-1-bartosz.golaszewski@oss.qualcomm.com>
The pull request you sent on Fri, 10 Apr 2026 10:46:43 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-updates-for-v7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d60bc140158342716e13ff0f8aa65642f43ba053
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Kairui Song @ 2026-04-14 3:28 UTC (permalink / raw)
To: YoungJun Park
Cc: Nhat Pham, Liam.Howlett, akpm, 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: <ad2rYH9tUPthHFoj@yjaykim-PowerEdge-T330>
On Tue, Apr 14, 2026 at 11:05 AM YoungJun Park <youngjun.park@lge.com> wrote:
>
Hi All,
> On Sat, Apr 11, 2026 at 06:40:44PM -0700, Nhat Pham wrote:
> > > 1. Modularization
> > >
> > > You removed CONFIG_* and went with a unified approach. I recall
> > > you were also considering a module-based structure at some point.
> > > What are your thoughts on that direction?
> > >
> >
> > The CONFIG-based approach was a huge mess. It makes me not want to
> > look at the code, and I'm the author :)
> >
> > > If we take that approach, we could extend the recent swap ops
> > > patchset (https://lore.kernel.org/linux-mm/20260302104016.163542-1-bhe@redhat.com/)
> > > as follows:
> > > - Make vswap a swap module
> > > - Have cluster allocation functions reside in swapops
> > > - Enable vswap through swapon
> >
> > Hmmmmm.
>
> I think this would be a happy world, but I wonder what others think.
> Anyway, I'm looking forward to the future direction.
>
Yeah, I agree with this.
And I do think swapoff of the virtual space itself is also necessary,
we really need a failsafe, e.g. a clean way to drop the swap
cache and data, kind of like drop_caches or shrinker fs are
commonly used.
> > > 2. Flash-friendly swap integration (for my use case)
> > >
> > > I've been thinking about the flash-friendly swap concept that
> > > I mentioned before and recently proposed:
> > > (https://lore.kernel.org/linux-mm/aZW0voL4MmnMQlaR@yjaykim-PowerEdge-T330/)
> > >
> > > One of its core functions requires buffering RAM-swapped pages
> > > and writing them sequentially at an appropriate time -- not
> > > immediately, but in proper block-sized units, sequentially.
> > >
> > > This means allocated offsets must essentially be virtual, and
> > > physical offsets need to be managed separately at the actual
> > > write time.
> > >
> > > If we integrate this into the current vswap, we would either
> > > need vswap itself to handle the sequential writes (bypassing
> > > the physical device and receiving pages directly), or swapon
> > > a swap device and have vswap obtain physical offsets from it.
> > > But since those offsets cannot be used directly (due to
> > > buffering and sequential write requirements), they become
> > > virtual too, resulting in:
> > >
> > > virtual -> virtual -> physical
> > >
> > > This triple indirection is not ideal.
> > >
> > > However, if the modularization from point 1 is achieved and
> > > vswap acts as a swap device itself, then we can cleanly
> > > establish a:
> > >
> > > virtual -> physical
> >
> > I read that thread sometimes ago. Some remarks:
> >
> > 1. I think Christoph has a point. Seems like some of your ideas ( are
> > broadly applicable to swap in general. Maybe fixing swap infra
> > generally would make a lot of sense?
>
> Broadly speaking, there are two main ideas:
> 1. Swap I/O buffering (which is also tied to cluster management issues)
> 2. Deduplication
>
> Are you leaning towards the view that these two should be placed in a
> higher layer?
IMHO the swap infra should be doing less, not more, so we can have
more flexible design, and different backends can implement their own
way to manage the data and layer. e.g. Having one backend being
flash friendly and it can do this without caring or affecting other devices
or backends.
> If it goes into ZSWAP, there would definitely be a clear advantage of
> seeing dedup benefits across all swap devices. It's a technically
> interesting area, and I'd like to discuss it in a separate thread if
> I have more ideas or thoughts.
Just branstorm... Why don't we just merge these identical pages like
KSM? Maybe at least zero folios might benefit a lot if we keep them
mapped as RO instead of recording them in swap, seems better in the
long term?
^ permalink raw reply
* Re: [GIT PULL] Thermal control updates for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 3:10 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, Linux PM, Linux Kernel Mailing List,
Daniel Lezcano
In-Reply-To: <CAJZ5v0gi8LtGAC=E16TRqx=gQxTSz2chzt=OmrQf8etnoE_QKA@mail.gmail.com>
The pull request you sent on Fri, 10 Apr 2026 16:29:09 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git thermal-7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fbfb6bd927c9ac6ea155471cc7ced8e16b37c2cb
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] ACPI support updates for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 3:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, ACPI Devel Maling List, Linux PM,
Linux Kernel Mailing List
In-Reply-To: <CAJZ5v0i9EjajGD55kAXtQz=NjvqT8ffcmEYS_dHoFvu901TjwA@mail.gmail.com>
The pull request you sent on Fri, 10 Apr 2026 16:27:36 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2e31b16101834bdc0b720967845d6a0a309cf27b
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] Power management updates for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 3:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, Linux PM, Linux Kernel Mailing List,
ACPI Devel Maling List, Viresh Kumar, Shuah Khan,
Chanwoo Choi (samsung.com), Mario Limonciello
In-Reply-To: <CAJZ5v0gdx4Gy3j2NBUtC+z3X7ZJ+GDg-R27pJ5AkZk7j8-36TQ@mail.gmail.com>
The pull request you sent on Fri, 10 Apr 2026 16:24:55 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d7c8087a9cd8979d70edfe7c7feda9423feae3ab
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: YoungJun Park @ 2026-04-14 3:09 UTC (permalink / raw)
To: Nhat Pham
Cc: Kairui Song, Liam.Howlett, akpm, 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: <CAKEwX=Pt04pYfhYOwmtXJKU5OqcxBC14SAf1wpBxBo1D7rPpGw@mail.gmail.com>
On Sat, Apr 11, 2026 at 06:03:04PM -0700, Nhat Pham wrote:
> On Wed, Mar 25, 2026 at 11:53 AM YoungJun Park <youngjun.park@lge.com> wrote:
> >
> > On Mon, Mar 23, 2026 at 11:32:57AM -0400, Nhat Pham wrote:
> >
> > > Interesting. Normally "lots of zero-filled page" is a very beneficial
> > > case for vswap. You don't need a swapfile, or any zram/zswap metadata
> > > overhead - it's a native swap backend. If production workload has this
> > > many zero-filled pages, I think the numbers of vswap would be much
> > > less alarming - perhaps even matching memory overhead because you
> > > don't need to maintain a zram entry metadata (it's at least 2 words
> > > per zram entry right?), while there's no reverse map overhead induced
> > > (so it's 24 bytes on both side), and no need to do zram-side locking
> > > :)
> > >
> > > So I was surprised to see that it's not working out very well here. I
> > > checked the implementation of memhog - let me know if this is wrong
> > > place to look:
> > >
> > > https://man7.org/linux/man-pages/man8/memhog.8.html
> > > https://github.com/numactl/numactl/blob/master/memhog.c#L52
> > >
> > > I think this is what happened here: memhog was populating the memory
> > > 0xff, which triggers the full overhead of a swapfile-backed swap entry
> > > because even though it's "same-filled" it's not zero-filled! I was
> > > following Usama's observation - "less than 1% of the same-filled pages
> > > were non-zero" - and so I only handled the zero-filled case here:
> > >
> > > https://lore.kernel.org/all/20240530102126.357438-1-usamaarif642@gmail.com/
> > >
> > > This sounds a bit artificial IMHO - as Usama pointed out above, I
> > > think most samefilled pages are zero pages, in real production
> > > workloads. However, if you think there are real use cases with a lot
> > > of non-zero samefilled pages, please let me know I can fix this real
> > > quick. We can support this in vswap with zero extra metadata overhead
> > > - change the VSWAP_ZERO swap entry type to VSWAP_SAME_FILLED, then use
> > > the backend field to store that value. I can send you a patch if
> > > you're interested.
> >
> > This brings back memories -- I'm pretty sure we talked about
> > exactly this at LPC. Our custom swap device already handles both
> > zero-filled and same-filled pages on its own, so what we really
> > wanted was a way to tell the swap layer "just skip the detection
> > and let it through."
> >
> > I looked at two approaches back then but never submitted either:
> >
> > - A per-swap_info flag to opt out of zero/same-filled handling.
> > But this felt wrong from vswap's perspective -- if even one
> > device opts out of the zeromap, the model gets messy.
> >
> > - Revisiting Usama's patch 2 approach.
> > Sounded good in theory, but as you said,
> > it's not as simple to verify in practice. And it is more clean design
> > swapout time zero check as I see. So, I gave up on it.
> >
> > Seeing this come up again is actually kind of nice :)
> >
> > One thought -- maybe a compile-time CONFIG or a boot param to
> > control the scope? e.g. zero-only, same-filled, or disabled.
> > That way vendors like us just turn it off, and setups like
> > Kairui's can opt into broader detection. Just an idea though --
> > open to other approaches if you have something in mind.
>
> Yeah for vswap it's probably going to be a CONFIG or boot param.
>
> But in the status quo, we can always add a swapfile flag. That one
> should work already, right?
I'm a bit hesitant about the swapfile flag approach. If vswap gets merged,
handling devices with this flag set might complicate the vswap design.
Moreover, exposing a new swap flag to the user interface (e.g., at swapon)
raises concerns about backward compatibility. Do you think that would be safe?
Since our use case isn't very common, we just need a simple knob to tune it.
That's why I still prefer a boot param or CONFIG approach.
Thanks :D
Youngjun Park
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: YoungJun Park @ 2026-04-14 2:50 UTC (permalink / raw)
To: Nhat Pham
Cc: kasong, Liam.Howlett, akpm, 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: <CAKEwX=NnHxpQKp9qBg2=r_euyjgxw2nHXjbgof3MymHTgJmRAQ@mail.gmail.com>
On Sat, Apr 11, 2026 at 06:40:44PM -0700, Nhat Pham wrote:
Hello Nhat!
> > 1. Modularization
> >
> > You removed CONFIG_* and went with a unified approach. I recall
> > you were also considering a module-based structure at some point.
> > What are your thoughts on that direction?
> >
>
> The CONFIG-based approach was a huge mess. It makes me not want to
> look at the code, and I'm the author :)
>
> > If we take that approach, we could extend the recent swap ops
> > patchset (https://lore.kernel.org/linux-mm/20260302104016.163542-1-bhe@redhat.com/)
> > as follows:
> > - Make vswap a swap module
> > - Have cluster allocation functions reside in swapops
> > - Enable vswap through swapon
>
> Hmmmmm.
I think this would be a happy world, but I wonder what others think.
Anyway, I'm looking forward to the future direction.
> > 2. Flash-friendly swap integration (for my use case)
> >
> > I've been thinking about the flash-friendly swap concept that
> > I mentioned before and recently proposed:
> > (https://lore.kernel.org/linux-mm/aZW0voL4MmnMQlaR@yjaykim-PowerEdge-T330/)
> >
> > One of its core functions requires buffering RAM-swapped pages
> > and writing them sequentially at an appropriate time -- not
> > immediately, but in proper block-sized units, sequentially.
> >
> > This means allocated offsets must essentially be virtual, and
> > physical offsets need to be managed separately at the actual
> > write time.
> >
> > If we integrate this into the current vswap, we would either
> > need vswap itself to handle the sequential writes (bypassing
> > the physical device and receiving pages directly), or swapon
> > a swap device and have vswap obtain physical offsets from it.
> > But since those offsets cannot be used directly (due to
> > buffering and sequential write requirements), they become
> > virtual too, resulting in:
> >
> > virtual -> virtual -> physical
> >
> > This triple indirection is not ideal.
> >
> > However, if the modularization from point 1 is achieved and
> > vswap acts as a swap device itself, then we can cleanly
> > establish a:
> >
> > virtual -> physical
>
> I read that thread sometimes ago. Some remarks:
>
> 1. I think Christoph has a point. Seems like some of your ideas ( are
> broadly applicable to swap in general. Maybe fixing swap infra
> generally would make a lot of sense?
Broadly speaking, there are two main ideas:
1. Swap I/O buffering (which is also tied to cluster management issues)
2. Deduplication
Are you leaning towards the view that these two should be placed in a
higher layer?
> 2. Why do we need to do two virtual layers here? For example, If you
> want to buffer multiple swap outs and turn them into a sequential
> request, you can:
>
> a. Allocate virtual swap space for them as you wish. They don't even
> need to be sequential.
>
> b. At swap_writeout() time, don't allocate physical swap space for
> them right away. Instead, accumulate them into a buffer. You can add a
> new virtual swap entry type to flag it if necessary.
>
> c. Once that buffer reaches a certain size, you can now allocate
> contiguous physical swap space for them. Then flush etc. You can flush
> at swap_writeout() time, or use a dedicated threads etc.
I initially thought implementing this in vswap would be complicated
(due to the ripple effects of altering behavior at swap_writeout timing),
but it seems entirely possible!
1. We could change the behavior (e.g., buffering) at vswap_alloc_swap_slot
timing by checking things like the si type.
2. Additionally, if we can handle the cluster data structures and
mechanisms in the swap_info_struct privately, a virtual-to-physical
one-direction approach seems feasible.
(Come to think of it, it might be better to refactor the infra to let
other modules handle this, potentially removing the swap_info_struct
mechanism entirely. Just imagination ;) )
> Deduplication sounds like something that should live at a lower layer
> - I was thinking about it for zswap/zsmalloc back then. I mean, I
> assume you don't want content sharing across different swap media? :)
> Something along the line of:
>
> 1. Maintain an content index for swapped out pages.
>
> 2. For the swap media that support deduplication, you'll need to add
> some sort of reference count (more overhead ew).
>
> 3. Each time we swapped out, we can content-check to see if the same
> piece of conent has been swapped out before. If so, set the vswap
> backend to the physical location of the data, increment some sort of
> reference count (perhaps we can use swap count) of the older entry,
> and have the swap type point to it.
As for reference count management, applying it loosely might be a good
approach. Instead of strictly managing the lifecycle of the dedup contents
with refcounts, we could just periodically clean up the hash. This also
has the benefit of reducing I/O for the same swap content compared to
deleting it immediately.
> But have you considered the implications of sharing swap data like
> this? I need to read the paper you cite - seems like a potential fun
> read. But what happen when these two pages that share the content
> belong to two different cgroups? How does the
> charging/uncharging/charge transferring story work? That's one of the
> things that made me pause when I wanted to implement deduplication for
> zswap/zsmalloc. Zram does not charge memory towards cgroup, but zswap
> does, so we'll need to handle this somehow, and at that point all the
> complexity might no longer be worth it.
Since our private swap device is similar to ZRAM, I hadn't considered
the charging aspect. It is indeed a complex issue.
If it goes into ZSWAP, there would definitely be a clear advantage of
seeing dedup benefits across all swap devices. It's a technically
interesting area, and I'd like to discuss it in a separate thread if
I have more ideas or thoughts.
Just a thought that comes to mind here: if vswap becomes modularized,
how about doing memcg charging for this entire area?
(Come to think of it, to fully benefit from vswap modularization,
zswap should also be applied within its scope.)
Best regards,
Youngjun Park
^ permalink raw reply
* RE: [EXT] Re: [PATCH v2] pmdomain: imx: Make IMX8M/IMX9 BLK_CTRL tristate
From: Zhipeng Wang @ 2026-04-14 1:59 UTC (permalink / raw)
To: Marco Felsch
Cc: ulfh@kernel.org, Frank Li, s.hauer@pengutronix.de,
imx@lists.linux.dev, linux-pm@vger.kernel.org, Xuegang Liu,
Jindong Yue, linux-kernel@vger.kernel.org, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ql2c6m54fjjwifycaan3hcr3p3bp4phva2vdux2qcramt7wrvy@4dsvpyct5tqx>
> On 26-04-13, Zhipeng Wang wrote:
> > Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate to
> > allow building as loadable modules.
>
> Out of curiosity, why do you want to have a PM driver to be buildable as
> module?
>
> Regards,
> Marco
>
Hi Marco,
Thank you for your question.
The primary motivation is to support Google's GKI (Generic Kernel Image)
requirement for Android devices.
GKI separates the kernel into two parts:
1. A unified kernel image (GKI) that is common across all Android devices
2. Vendor-specific drivers that must be built as loadable modules
Under the GKI architecture, SoC-specific drivers like IMX8M/IMX9 BLK_CTRL
cannot be built into the core kernel image. Instead, they must be loadable
modules that vendors can ship separately. This allows:
- A single kernel binary to support multiple hardware platforms
- Vendors to update their drivers independently without rebuilding the entire kernel
- Better compliance with Android's kernel update and security policies
For i.MX8M/i.MX9 devices running Android with GKI kernels, the BLK_CTRL
drivers need to be loaded as modules during boot. Without tristate support,
these devices cannot properly initialize their power domains, making them
non-functional under GKI.
Best regards,
Zhipeng Wang
> > Add prompt strings to make these options visible and configurable in
> > menuconfig, keeping them enabled by default on appropriate platforms.
> >
> > Also remove the IMX_GPCV2_PM_DOMAINS dependency from
> IMX9_BLK_CTRL.
> > This dependency was incorrect from the beginning - i.MX93 uses a
> > different power domain architecture compared to i.MX8M series:
> >
> > - i.MX8M uses GPCv2 (General Power Controller v2) for power domain
> > management, hence IMX8M_BLK_CTRL correctly depends on it.
> >
> > - i.MX93 uses BLK_CTRL directly without GPCv2. The hardware doesn't
> > have GPCv2 at all.
> >
> > Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
> > ---
> > drivers/pmdomain/imx/Kconfig | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pmdomain/imx/Kconfig
> > b/drivers/pmdomain/imx/Kconfig index 00203615c65e..9168d183b0c5
> 100644
> > --- a/drivers/pmdomain/imx/Kconfig
> > +++ b/drivers/pmdomain/imx/Kconfig
> > @@ -10,15 +10,18 @@ config IMX_GPCV2_PM_DOMAINS
> > default y if SOC_IMX7D
> >
> > config IMX8M_BLK_CTRL
> > - bool
> > - default SOC_IMX8M && IMX_GPCV2_PM_DOMAINS
> > + tristate "i.MX8M BLK CTRL driver"
> > + depends on SOC_IMX8M
> > + depends on IMX_GPCV2_PM_DOMAINS
> > depends on PM_GENERIC_DOMAINS
> > depends on COMMON_CLK
> > + default y
> >
> > config IMX9_BLK_CTRL
> > - bool
> > - default SOC_IMX9 && IMX_GPCV2_PM_DOMAINS
> > + tristate "i.MX93 BLK CTRL driver"
> > + depends on SOC_IMX9
> > depends on PM_GENERIC_DOMAINS
> > + default y
> >
> > config IMX_SCU_PD
> > bool "IMX SCU Power Domain driver"
> > --
> > 2.34.1
> >
> >
> >
>
> --
> #gernperDu
> #CallMeByMyFirstName
>
> Pengutronix e.K. |
> |
> Steuerwalder Str. 21 |
> https://www.pe/
> ngutronix.de%2F&data=05%7C02%7Czhipeng.wang_1%40nxp.com%7Cb056e
> 81e107a466e482a08de995e4054%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C639116827251261199%7CUnknown%7CTWFpbGZsb3d8eyJFb
> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qeSCoz6%2BawDiK1ISgG6Rs
> %2BtKScilTDoryyrt08WQYiA%3D&reserved=0 |
> 31137 Hildesheim, Germany | Phone:
> +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9
> |
^ permalink raw reply
* The "clockevents: Prevent timer interrupt starvation" patch causes lockups
From: Hanabishi @ 2026-04-13 21:20 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Calvin Owens, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, John Stultz, Stephen Boyd,
Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
Sebastian Reichel, linux-pm, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, netfilter-devel, coreteam
In-Reply-To: <20260407083247.562657657@kernel.org>
On 07/04/2026 08:54, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@kernel.org>
>
> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked
> up in user space. He provided a reproducer, which sets up a timerfd based
> timer and then rearms it in a loop with an absolute expiry time of 1ns.
>
> As the expiry time is in the past, the timer ends up as the first expiring
> timer in the per CPU hrtimer base and the clockevent device is programmed
> with the minimum delta value. If the machine is fast enough, this ends up
> in a endless loop of programming the delta value to the minimum value
> defined by the clock event device, before the timer interrupt can fire,
> which starves the interrupt and consequently triggers the lockup detector
> because the hrtimer callback of the lockup mechanism is never invoked.
>
> As a first step to prevent this, avoid reprogramming the clock event device
> when:
> - a forced minimum delta event is pending
> - the new expiry delta is less then or equal to the minimum delta
>
> Thanks to Calvin for providing the reproducer and to Borislav for testing
> and providing data from his Zen5 machine.
>
> The problem is not limited to Zen5, but depending on the underlying
> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed
> not necessarily observable.
>
> This change serves only as the last resort and further changes will be made
> to prevent this scenario earlier in the call chain as far as possible.
>
> Fixes: d316c57ff6bf ("[PATCH] clockevents: add core functionality")
> Reported-by: Calvin Owens <calvin@wbinvd.org>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/
> ---
> V2: Simplified the clockevents code - Peter
> ---
> include/linux/clockchips.h | 2 ++
> kernel/time/clockevents.c | 23 +++++++++++++++--------
> kernel/time/hrtimer.c | 1 +
> kernel/time/tick-common.c | 1 +
> kernel/time/tick-sched.c | 1 +
> 5 files changed, 20 insertions(+), 8 deletions(-)
> --- a/include/linux/clockchips.h
> +++ b/include/linux/clockchips.h
> @@ -80,6 +80,7 @@ enum clock_event_state {
> * @shift: nanoseconds to cycles divisor (power of two)
> * @state_use_accessors:current state of the device, assigned by the core code
> * @features: features
> + * @next_event_forced: True if the last programming was a forced event
> * @retries: number of forced programming retries
> * @set_state_periodic: switch state to periodic
> * @set_state_oneshot: switch state to oneshot
> @@ -108,6 +109,7 @@ struct clock_event_device {
> u32 shift;
> enum clock_event_state state_use_accessors;
> unsigned int features;
> + unsigned int next_event_forced;
> unsigned long retries;
>
> int (*set_state_periodic)(struct clock_event_device *);
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -172,6 +172,7 @@ void clockevents_shutdown(struct clock_e
> {
> clockevents_switch_state(dev, CLOCK_EVT_STATE_SHUTDOWN);
> dev->next_event = KTIME_MAX;
> + dev->next_event_forced = 0;
> }
>
> /**
> @@ -305,7 +306,6 @@ int clockevents_program_event(struct clo
> {
> unsigned long long clc;
> int64_t delta;
> - int rc;
>
> if (WARN_ON_ONCE(expires < 0))
> return -ETIME;
> @@ -324,16 +324,23 @@ int clockevents_program_event(struct clo
> return dev->set_next_ktime(expires, dev);
>
> delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
> - if (delta <= 0)
> - return force ? clockevents_program_min_delta(dev) : -ETIME;
>
> - delta = min(delta, (int64_t) dev->max_delta_ns);
> - delta = max(delta, (int64_t) dev->min_delta_ns);
> + if (delta > (int64_t)dev->min_delta_ns) {
> + delta = min(delta, (int64_t) dev->max_delta_ns);
> + clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
> + if (!dev->set_next_event((unsigned long) clc, dev))
> + return 0;
> + }
>
> - clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
> - rc = dev->set_next_event((unsigned long) clc, dev);
> + if (dev->next_event_forced)
> + return 0;
>
> - return (rc && force) ? clockevents_program_min_delta(dev) : rc;
> + if (dev->set_next_event(dev->min_delta_ticks, dev)) {
> + if (!force || clockevents_program_min_delta(dev))
> + return -ETIME;
> + }
> + dev->next_event_forced = 1;
> + return 0;
> }
>
> /*
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1888,6 +1888,7 @@ void hrtimer_interrupt(struct clock_even
> BUG_ON(!cpu_base->hres_active);
> cpu_base->nr_events++;
> dev->next_event = KTIME_MAX;
> + dev->next_event_forced = 0;
>
> raw_spin_lock_irqsave(&cpu_base->lock, flags);
> entry_time = now = hrtimer_update_base(cpu_base);
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -110,6 +110,7 @@ void tick_handle_periodic(struct clock_e
> int cpu = smp_processor_id();
> ktime_t next = dev->next_event;
>
> + dev->next_event_forced = 0;
> tick_periodic(cpu);
>
> /*
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -1513,6 +1513,7 @@ static void tick_nohz_lowres_handler(str
> struct tick_sched *ts = this_cpu_ptr(&tick_cpu_sched);
>
> dev->next_event = KTIME_MAX;
> + dev->next_event_forced = 0;
>
> if (likely(tick_nohz_handler(&ts->sched_timer) == HRTIMER_RESTART))
> tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
>
>
Hello.
Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my Ryzen 7700X machine.
I see such messages in the log:
clocksource: Long readout interval, skipping watchdog check: cs_nsec: 2897344852 wd_nsec: 2897356996
Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the issue for me.
^ permalink raw reply
* Re: [PATCH v3 0/2] Support BPF traversal of wakeup sources
From: Samuel Wu @ 2026-04-13 20:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexei Starovoitov, 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, Android Kernel Team, LKML, Linux Power Management,
driver-core, bpf, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <2026041315-oval-rut-cb8d@gregkh>
On Sun, Apr 12, 2026 at 9:48 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Sun, Apr 12, 2026 at 03:48:58PM -0700, Alexei Starovoitov wrote:
> > On Fri, Apr 3, 2026 at 9:28 AM Samuel Wu <wusamuel@google.com> wrote:
> > >
> > > On Fri, Apr 3, 2026 at 3:04 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > 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:
> > >
> > > [ ... ]
> > >
> > > > > 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?
> > >
> > > Almost all use cases want all this data at once, so AFAICT BPF offers
> > > the best performance for that. But of course, open to discussion if
> > > there is an alternative API that matches BPF's performance for this
> > > use case.
> > >
> > > I'm not opposed to dropping the sysfs approach, and I attempted to do
> > > so in the v1 patch [1]. I'm not sure who else currently uses those
> > > sysfs nodes, but a config flag should remove friction and could be a
> > > stepping stone toward deprecation/removal.
> > >
> > > [1]: https://lore.kernel.org/all/20260320160055.4114055-3-wusamuel@google.com/
> >
> > The patches make sense to me.
> >
> > Patch 2 adds a bpf selftest and corresponding:
> > +CONFIG_DIBS_LO=y
> > +CONFIG_PM_WAKELOCKS=y
> >
> > and almost green in BPF CI.
> >
> > Except s390 that fails with:
> >
> > Error: #682/1 wakeup_source/iterate_and_verify_times
> > Error: #682/1 wakeup_source/iterate_and_verify_times
> > libbpf: extern (func ksym) 'bpf_wakeup_sources_get_head': not found in
> > kernel or module BTFs
> > libbpf: failed to load BPF skeleton 'test_wakeup_source': -EINVAL
> > test_wakeup_source:FAIL:skel_open_and_load unexpected error: -22
> >
> > We can still land it into bpf-next for this merge window.
> >
> > Greg,
> > any objection ?
>
> Yes, it is too late for 7.1-rc1, sorry, there will have not been any
> time in linux-next to add it. Let's revisit it after -rc1 is out, and
> again, I feel that "walk all sysfs devices in bpf" is not the correct
> solution for a system-wide snapshot interface you want to have,
> especially as the one you previously added you feel is now obsolete.
Sounds good, when the merge window closes, I'll send out v4 with the
s390 errors and remaining comments fixed.
Regarding surfacing a system-wide snapshot of wakeup sources to
userspace, can you elaborate on the solution you're envisioning? My
understanding is that "walk all sysfs devices in bpf" is a canonical
BPF use case, especially in this scenario, where we see improvements
in every core metric.
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Manivannan Sadhasivam @ 2026-04-13 16:08 UTC (permalink / raw)
To: Chen-Yu Tsai, Manivannan Sadhasivam
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Andy Shevchenko, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <fpcs4p62f35a5qyqwgm5ysa73stbysxcr62tkmmkrrcvsuf4t4@4ivukyqjey57>
[Resending as my previous reply got bounced]
On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
> > > Hi,
> > >
> > > This series is the continuation of the series [1] that added the initial support
> > > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > > connectors. These connectors are used to connect the Wireless Connectivity
> > > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > > interfaces are left for future improvements.
> >
> > Thanks for working on this. I started playing with it now that it is in
> > -next. The PCIe part works fine. I'm looking into how to fit the pwrseq
> >
> > A couple questions:
> >
> > - Given that this connector actually represents two devices, how do I
> > say I want the BT part to be a wakeup source, but not the WiFi part?
> > Does wakeup-source even work at this point?
> >
>
> You can't use the DT property since the devices are not described in DT
> statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> wakeup.
>
> > - Are there plans to do the SDIO part?
> >
>
> No, not at the moment. Feel free to take it up if you have the hardware and
> motivation :)
>
> > - The matching done in the M.2 connector driver for pwrseq_get() seems a
> > bit naive. It simply checks if the remote device in the OF graph is
> > the same as the requesting device.
> >
> > I think this would run into issues with USB hubs. If I have a USB hub
> > and two M.2 connectors, with both connectors connected to the same
> > hub, pwrseq_get() is going to always return only one of the instances.
> > This is because the USB hub has one device node with multiple OF graph
> > ports.
> >
>
> Yeah, this is a known limitation. I'm trying to improve this part now and have
> the WIP commits here: https://github.com/Mani-Sadhasivam/linux/tree/pwrseq-bt-en-fixes
>
> Once the merge window closes, I'll submit these.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Conor Dooley @ 2026-04-13 15:42 UTC (permalink / raw)
To: Ronald Claveau
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-1-1002d90a0602@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]
On Mon, Apr 13, 2026 at 12:52:42PM +0200, Ronald Claveau wrote:
> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>
> Unlike existing variants which use a phandle to the ao-secure syscon,
> the T7 relies on a secure monitor interface described by a phandle and
> a sensor index argument.
>
> The T7 integrates multiple thermal sensors, all accessed through the
> same SMC call. The sensor index argument is required to identify which
> sensor's calibration data the secure monitor should return, as a single
> SM_THERMAL_CALIB_READ command serves all of them.
>
> Introduce the amlogic,secure-monitor property as a phandle-array and
> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
> depending on the compatible.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../bindings/thermal/amlogic,thermal.yaml | 42 ++++++++++++++++++++--
> 1 file changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> index 70b273271754b..1c096116b2dda 100644
> --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> @@ -21,7 +21,9 @@ properties:
> - amlogic,g12a-cpu-thermal
> - amlogic,g12a-ddr-thermal
> - const: amlogic,g12a-thermal
> - - const: amlogic,a1-cpu-thermal
> + - enum:
> + - amlogic,a1-cpu-thermal
> + - amlogic,t7-thermal
>
> reg:
> maxItems: 1
> @@ -42,12 +44,39 @@ properties:
> '#thermal-sensor-cells':
> const: 0
>
> + amlogic,secure-monitor:
> + description: phandle to the secure monitor
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle to the secure monitor
> + - description: sensor index to get specific calibration data
> +
> required:
> - compatible
> - reg
> - interrupts
> - clocks
> - - amlogic,ao-secure
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - amlogic,a1-cpu-thermal
> + - amlogic,g12a-thermal
> + then:
> + required:
> + - amlogic,ao-secure
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: amlogic,t7-thermal
This can just be replaced by a else I think.
> + then:
> + required:
> + - amlogic,secure-monitor
>
> unevaluatedProperties: false
>
> @@ -62,4 +91,13 @@ examples:
> #thermal-sensor-cells = <0>;
> amlogic,ao-secure = <&sec_AO>;
> };
> + - |
> + a73_tsensor: temperature-sensor@20000 {
Can drop the label here, it has no users.
Otherwise, seems fine.
Cheers,
Conor.
pw-bot: changes-requested
> + compatible = "amlogic,t7-thermal";
> + reg = <0x0 0x20000 0x0 0x50>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc_periphs CLKID_TS>;
> + #thermal-sensor-cells = <0>;
> + amlogic,secure-monitor = <&sm 1>;
> + };
> ...
>
> --
> 2.49.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Manivannan Sadhasivam @ 2026-04-13 14:02 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski
In-Reply-To: <20260413075459.GA2626902@google.com>
On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
> > Hi,
> >
> > This series is the continuation of the series [1] that added the initial support
> > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > connectors. These connectors are used to connect the Wireless Connectivity
> > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > interfaces are left for future improvements.
>
> Thanks for working on this. I started playing with it now that it is in
> -next. The PCIe part works fine. I'm looking into how to fit the pwrseq
>
> A couple questions:
>
> - Given that this connector actually represents two devices, how do I
> say I want the BT part to be a wakeup source, but not the WiFi part?
> Does wakeup-source even work at this point?
>
You can't use the DT property since the devices are not described in DT
statically. But you can still use the per-device 'wakeup' sysfs knob to enable
wakeup.
> - Are there plans to do the SDIO part?
>
No, not at the moment. Feel free to take it up if you have the hardware and
motivation :)
> - The matching done in the M.2 connector driver for pwrseq_get() seems a
> bit naive. It simply checks if the remote device in the OF graph is
> the same as the requesting device.
>
> I think this would run into issues with USB hubs. If I have a USB hub
> and two M.2 connectors, with both connectors connected to the same
> hub, pwrseq_get() is going to always return only one of the instances.
> This is because the USB hub has one device node with multiple OF graph
> ports.
>
Yeah, this is a known limitation. I'm trying to improve this part now and have
the WIP commits here: https://github.com/Mani-Sadhasivam/linux/tree/pwrseq-bt-en-fixes
Once the merge window closes, I'll submit these.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2] pmdomain: imx: Make IMX8M/IMX9 BLK_CTRL tristate
From: Marco Felsch @ 2026-04-13 13:11 UTC (permalink / raw)
To: Zhipeng Wang
Cc: ulfh, Frank.Li, s.hauer, imx, linux-pm, xuegang.liu, jindong.yue,
linux-kernel, kernel, festevam, linux-arm-kernel
In-Reply-To: <20260413053049.3041177-1-zhipeng.wang_1@nxp.com>
On 26-04-13, Zhipeng Wang wrote:
> Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate
> to allow building as loadable modules.
Out of curiosity, why do you want to have a PM driver to be buildable as
module?
Regards,
Marco
> Add prompt strings to make these options visible and configurable
> in menuconfig, keeping them enabled by default on appropriate platforms.
>
> Also remove the IMX_GPCV2_PM_DOMAINS dependency from IMX9_BLK_CTRL.
> This dependency was incorrect from the beginning - i.MX93 uses a
> different power domain architecture compared to i.MX8M series:
>
> - i.MX8M uses GPCv2 (General Power Controller v2) for power domain
> management, hence IMX8M_BLK_CTRL correctly depends on it.
>
> - i.MX93 uses BLK_CTRL directly without GPCv2. The hardware doesn't
> have GPCv2 at all.
>
> Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
> ---
> drivers/pmdomain/imx/Kconfig | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pmdomain/imx/Kconfig b/drivers/pmdomain/imx/Kconfig
> index 00203615c65e..9168d183b0c5 100644
> --- a/drivers/pmdomain/imx/Kconfig
> +++ b/drivers/pmdomain/imx/Kconfig
> @@ -10,15 +10,18 @@ config IMX_GPCV2_PM_DOMAINS
> default y if SOC_IMX7D
>
> config IMX8M_BLK_CTRL
> - bool
> - default SOC_IMX8M && IMX_GPCV2_PM_DOMAINS
> + tristate "i.MX8M BLK CTRL driver"
> + depends on SOC_IMX8M
> + depends on IMX_GPCV2_PM_DOMAINS
> depends on PM_GENERIC_DOMAINS
> depends on COMMON_CLK
> + default y
>
> config IMX9_BLK_CTRL
> - bool
> - default SOC_IMX9 && IMX_GPCV2_PM_DOMAINS
> + tristate "i.MX93 BLK CTRL driver"
> + depends on SOC_IMX9
> depends on PM_GENERIC_DOMAINS
> + default y
>
> config IMX_SCU_PD
> bool "IMX SCU Power Domain driver"
> --
> 2.34.1
>
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* Re: [PATCH] tools/power turbostat: Allow execution to continue after perf_l2_init() failure
From: David Arcari @ 2026-04-13 11:53 UTC (permalink / raw)
To: Mi, Dapeng1, Len Brown; +Cc: Linux PM list, Linux Kernel Mailing List
In-Reply-To: <MN0PR11MB6160DDF6952E2B595B2EA1C1CD242@MN0PR11MB6160.namprd11.prod.outlook.com>
Here is the -vvv output:
# sudo perf stat -e cache-misses -vvv sleep 1
Control descriptor is not initialized
Opening: cache-misses
------------------------------------------------------------
perf_event_attr:
type 10 (cpu_atom)
size 144
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'ldlat' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
unknown term 'offcore_rsp' for pmu 'cpu_atom' (valid terms:
event,pc,edge,inv,umask,cmask,config,config1,config2,config3,config4,name,period,percore,metric-id,cpu)
config 0x412e (cache-misses)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 9255 cpu -1 group_fd -1 flags 0x8
sys_perf_event_open failed, error -12
Warning:
skipping event cache-misses that kernel failed to open.
The sys_perf_event_open() syscall failed for event (cache-misses):
Cannot allocate memory
"dmesg | grep -i perf" may provide additional information.
Opening: cache-misses
------------------------------------------------------------
perf_event_attr:
type 4 (cpu_core)
size 144
config 0x412e (cache-misses)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 9255 cpu -1 group_fd -1 flags 0x8 = 3
cache-misses: -1: 11224 321150 321150
failed to read counter cache-misses
cache-misses: 11224 321150 321150
Performance counter stats for 'sleep 1':
<not supported> cpu_atom/cache-misses/
11,224 cpu_core/cache-misses/
1.003110088 seconds time elapsed
0.000000000 seconds user
0.000846000 seconds sys
On 4/12/26 8:34 PM, Mi, Dapeng1 wrote:
> The most possible reason for the "<not supported>" is that the "sleep 1"
> process runs on a P-core where "cpu_atom/cache-misses/" can't be
> supported. It's expected.
>
> BTW, you can add "-vvv" option which gives more details like "sudo perf
> stat -e cache-misses -vvv sleep 1".
>
> Thanks.
>
> ------------------------------------------------------------------------
> *From:* Len Brown <lenb@kernel.org>
> *Sent:* Saturday, April 11, 2026 2:09 AM
> *To:* Arcari, David <darcari@redhat.com>; Mi, Dapeng1 <dapeng1.mi@intel.com>
> *Cc:* Linux PM list <linux-pm@vger.kernel.org>; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>
> *Subject:* Re: [PATCH] tools/power turbostat: Allow execution to
> continue after perf_l2_init() failure
>
> On Fri, Apr 10, 2026 at 12:06 PM David Arcari <darcari@redhat.com> wrote:
>
> > I'm using a Fedora kernel:
> >
> > vmlinuz-7.0.0-0.rc4.260320g0e4f8f1a3d08.40.eln155.x86_64
> >
> > And turbostat is:
> >
> > # turbostat -v
> > turbostat version 2026.02.14 - Len Brown <lenb@kernel.org>
> >
> > >
> > > You can poke with "perf stat" as well, but this will depend on what
> > > .json counter list is compiled into
> > > your version of perf.
> > >
> > > probably a first sanity check would be if these commands for the LLC
> > > and the L2 work:
> > >
> > > sudo perf stat -e cache-misses sleep 1
> > > sudo perf stat -e L2_REQUEST.ALL sleep 1
> >
> > # sudo perf stat -e cache-misses sleep 1
> >
> > Performance counter stats for 'sleep 1':
> >
> > <not supported> cpu_atom/cache-misses/
>
> I think this should work. There may be an issue either with
> the perf utility or the perf kernel support on that system.
>
> I'll cc Dapeng. Already the weekend where he is, but maybe he
> can give us some perf insight next week.
>
> thx,
> -Len
^ permalink raw reply
* Re: [PATCH 04/14] powerpc/time: Prepare to stop elapsing in dynticks-idle
From: Christophe Leroy (CS GROUP) @ 2026-04-13 11:00 UTC (permalink / raw)
To: Frederic Weisbecker, LKML
Cc: Rafael J. Wysocki, Alexander Gordeev, Anna-Maria Behnsen,
Ben Segall, Boqun Feng, Christian Borntraeger, Dietmar Eggemann,
Heiko Carstens, Ingo Molnar, Jan Kiszka, Joel Fernandes,
Juri Lelli, Kieran Bingham, Madhavan Srinivasan, Mel Gorman,
Michael Ellerman, Neeraj Upadhyay, Nicholas Piggin,
Paul E . McKenney, Peter Zijlstra, Shrikanth Hegde,
Steven Rostedt, Sven Schnelle, Thomas Gleixner, Uladzislau Rezki,
Valentin Schneider, Vasily Gorbik, Vincent Guittot, Viresh Kumar,
Xin Zhao, linux-pm, linux-s390, linuxppc-dev
In-Reply-To: <20260331131622.30505-5-frederic@kernel.org>
Le 31/03/2026 à 15:16, Frederic Weisbecker a écrit :
> Currently the tick subsystem stores the idle cputime accounting in
> private fields, allowing cohabitation with architecture idle vtime
> accounting. The former is fetched on online CPUs, the latter on offline
> CPUs.
>
> For consolidation purpose, architecture vtime accounting will continue
> to account the cputime but will make a break when the idle tick is
> stopped. The dyntick cputime accounting will then be relayed by the tick
> subsystem so that the idle cputime is still seen advancing coherently
> even when the tick isn't there to flush the idle vtime.
>
> Prepare for that and introduce three new APIs which will be used in
> subsequent patches:
>
> _ vtime_dynticks_start() is deemed to be called when idle enters in
> dyntick mode. The idle cputime that elapsed so far is accumulated.
>
> - vtime_dynticks_stop() is deemed to be called when idle exits from
> dyntick mode. The vtime entry clocks are fast-forward to current time
> so that idle accounting restarts elapsing from now.
>
> - vtime_reset() is deemed to be called from dynticks idle IRQ entry to
> fast-forward the clock to current time so that the IRQ time is still
> accounted by vtime while nohz cputime is paused.
>
> Also accumulated vtime won't be flushed from dyntick-idle ticks to avoid
> accounting twice the idle cputime, along with nohz accounting.
>
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
> ---
> arch/powerpc/kernel/time.c | 41 ++++++++++++++++++++++++++++++++++++++
> include/linux/vtime.h | 6 ++++++
> 2 files changed, 47 insertions(+)
>
...
> diff --git a/include/linux/vtime.h b/include/linux/vtime.h
> index 336875bea767..61b94c12d7dd 100644
> --- a/include/linux/vtime.h
> +++ b/include/linux/vtime.h
> @@ -37,11 +37,17 @@ extern void vtime_account_irq(struct task_struct *tsk, unsigned int offset);
> extern void vtime_account_softirq(struct task_struct *tsk);
> extern void vtime_account_hardirq(struct task_struct *tsk);
> extern void vtime_flush(struct task_struct *tsk);
> +extern void vtime_reset(void);
> +extern void vtime_dyntick_start(void);
> +extern void vtime_dyntick_stop(void);
> #else /* !CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
> static inline void vtime_account_irq(struct task_struct *tsk, unsigned int offset) { }
> static inline void vtime_account_softirq(struct task_struct *tsk) { }
> static inline void vtime_account_hardirq(struct task_struct *tsk) { }
> static inline void vtime_flush(struct task_struct *tsk) { }
> +static inline void vtime_reset(void) { }
> +static inline void vtime_dyntick_start(void) { }
> +extern inline void vtime_dyntick_stop(void) { }
You mean 'static' inline, not 'extern' ?
Christophe
> #endif
>
> /*
^ permalink raw reply
* [PATCH v2 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr>
Add an active trip at 50°C to all six thermal zones and map it to the
khadas_mcu fan controller, using cooling states 30 to 100.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++++++++++++++
1 file changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 5d7f5390f3a66..ba9219073dd0a 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -157,6 +157,74 @@ wifi32k: wifi32k {
};
};
+&a53_thermal {
+ trips {
+ a53_active: a53-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a53_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&a73_thermal {
+ trips {
+ a73_active: a73-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a73_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&gpu_thermal {
+ trips {
+ gpu_active: gpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&gpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&hevc_thermal {
+ trips {
+ hevc_active: hevc-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&hevc_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&i2c_m_ao_a {
status = "okay";
pinctrl-0 = <&i2c0_ao_d_pins>;
@@ -170,6 +238,23 @@ khadas_mcu: system-controller@18 {
};
};
+&nna_thermal {
+ trips {
+ nna_active: nna-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&nna_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_pins>;
@@ -266,3 +351,20 @@ &uart_a {
clocks = <&xtal>, <&xtal>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
};
+
+&vpu_thermal {
+ trips {
+ vpu_active: vpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&vpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
--
2.49.0
^ permalink raw reply related
* [PATCH v2 7/8] arm64: dts: amlogic: t7: Add thermal zones
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr>
Add thermal zones for all six sensors: a53, a73, gpu, nna, vpu, and hevc.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 179 ++++++++++++++++++++++++++++
1 file changed, 179 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 62f259b2b17d2..c6ea0f20a879f 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -9,6 +9,7 @@
#include <dt-bindings/clock/amlogic,t7-scmi.h>
#include <dt-bindings/clock/amlogic,t7-pll-clkc.h>
#include <dt-bindings/clock/amlogic,t7-peripherals-clkc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&gic>;
@@ -829,6 +830,184 @@ hevc_tsensor: temperature-sensor@9a000 {
amlogic,secure-monitor = <&sm 5>;
};
};
+ };
+
+ thermal-zones {
+ a53_thermal: a53-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a53_tsensor>;
+
+ trips {
+ a53_passive: a53-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a53_hot: a53-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a53_critical: a53-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a53 {
+ trip = <&a53_passive>;
+ cooling-device =
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ a73_thermal: a73-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a73_tsensor>;
+
+ trips {
+ a73_passive: a73-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a73_hot: a73-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a73_critical: a73-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a73 {
+ trip = <&a73_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ gpu_thermal: gpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&gpu_tsensor>;
+
+ trips {
+ gpu_passive: gpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ gpu_hot: gpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+ gpu_critical: gpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ hevc_thermal: hevc-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&hevc_tsensor>;
+
+ trips {
+ hevc_passive: hevc-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_hot: hevc-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_critical: hevc-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ nna_thermal: nna-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&nna_tsensor>;
+
+ trips {
+ nna_passive: nna-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_hot: nna-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_critical: nna-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ vpu_thermal: vpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&vpu_tsensor>;
+
+ trips {
+ vpu_passive: vpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_hot: vpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_critical: vpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH v2 6/8] arm64: dts: amlogic: t7: Add thermal sensor nodes
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr>
Add six temperature sensor nodes using the amlogic,t7-thermal compatible:
a73, a53, gpu, nna, vpu, and hevc. Each sensor retrieves its calibration
data from the secure monitor via the amlogic,secure-monitor phandle with
the corresponding tsensor_id argument.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 58 +++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7aec65f036a9c..62f259b2b17d2 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -656,6 +656,24 @@ sec_ao: ao-secure@10220 {
amlogic,has-chip-id;
};
+ a73_tsensor: temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
+
+ a53_tsensor: temperature-sensor@22000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x22000 0x0 0x50>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 2>;
+ };
+
pwm_ao_ef: pwm@30000 {
compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
reg = <0x0 0x30000 0x0 0x24>;
@@ -770,6 +788,46 @@ sd_emmc_c: mmc@8c000 {
assigned-clock-parents = <&xtal>;
status = "disabled";
};
+
+ gpu_tsensor: temperature-sensor@94000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x94000 0x0 0x50>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_MALI_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 3>;
+ };
+
+ nna_tsensor: temperature-sensor@96000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x96000 0x0 0x50>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_NNA_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 4>;
+ };
+
+ vpu_tsensor: temperature-sensor@98000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x98000 0x0 0x50>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_VPU_HDMI_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 6>;
+ };
+
+ hevc_tsensor: temperature-sensor@9a000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x9a000 0x0 0x50>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_DOS_HEVC_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 5>;
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH v2 5/8] arm64: dts: amlogic: t7: Add cooling cells to all CPUs
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr>
Add #cooling-cells = <2> to all CPU nodes (both little and big cluster)
to allow them to be used as cooling devices in thermal zone mappings.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 560c9dce35266..7aec65f036a9c 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -63,6 +63,7 @@ cpu100: cpu@100 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu101: cpu@101 {
@@ -77,6 +78,7 @@ cpu101: cpu@101 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu102: cpu@102 {
@@ -91,6 +93,7 @@ cpu102: cpu@102 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu103: cpu@103 {
@@ -105,6 +108,7 @@ cpu103: cpu@103 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu0: cpu@0 {
@@ -119,6 +123,7 @@ cpu0: cpu@0 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -133,6 +138,7 @@ cpu1: cpu@1 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -147,6 +153,7 @@ cpu2: cpu@2 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -161,6 +168,7 @@ cpu3: cpu@3 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
l2_cache_l: l2-cache-cluster0 {
--
2.49.0
^ permalink raw reply related
* [PATCH v2 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr>
Some SoCs (e.g. T7) expose thermal calibration data through the secure
monitor rather than a directly accessible eFuse register. Add a use_sm
flag to amlogic_thermal_data to select this path, and retrieve the
firmware handle and tsensor_id from the "amlogic,secure-monitor" DT
phandle with one fixed argument.
Also introduce the amlogic,t7-thermal compatible using this new path.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/thermal/amlogic_thermal.c | 58 +++++++++++++++++++++++++++++++++++----
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
index 5448d772db12a..11e3948cc0669 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -25,6 +25,7 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/thermal.h>
+#include <linux/firmware/meson/meson_sm.h>
#include "thermal_hwmon.h"
@@ -84,12 +85,14 @@ struct amlogic_thermal_soc_calib_data {
* @u_efuse_off: register offset to read fused calibration value
* @calibration_parameters: calibration parameters structure pointer
* @regmap_config: regmap config for the device
+ * @use_sm: read data from secure monitor instead of efuse
* This structure is required for configuration of amlogic thermal driver.
*/
struct amlogic_thermal_data {
int u_efuse_off;
const struct amlogic_thermal_soc_calib_data *calibration_parameters;
const struct regmap_config *regmap_config;
+ bool use_sm;
};
struct amlogic_thermal {
@@ -100,6 +103,8 @@ struct amlogic_thermal {
struct clk *clk;
struct thermal_zone_device *tzd;
u32 trim_info;
+ struct meson_sm_firmware *sm_fw;
+ u32 tsensor_id;
};
/*
@@ -138,6 +143,12 @@ static int amlogic_thermal_initialize(struct amlogic_thermal *pdata)
int ret = 0;
int ver;
+ if (pdata->data->use_sm) {
+ return meson_sm_get_thermal_calib(pdata->sm_fw,
+ &pdata->trim_info,
+ pdata->tsensor_id);
+ }
+
regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
&pdata->trim_info);
@@ -226,6 +237,12 @@ static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
.regmap_config = &amlogic_thermal_regmap_config_g12a,
};
+static const struct amlogic_thermal_data amlogic_thermal_t7_param = {
+ .use_sm = true,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
static const struct of_device_id of_amlogic_thermal_match[] = {
{
.compatible = "amlogic,g12a-ddr-thermal",
@@ -239,6 +256,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
.compatible = "amlogic,a1-cpu-thermal",
.data = &amlogic_thermal_a1_cpu_param,
},
+ {
+ .compatible = "amlogic,t7-thermal",
+ .data = &amlogic_thermal_t7_param,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
@@ -271,11 +292,38 @@ static int amlogic_thermal_probe(struct platform_device *pdev)
if (IS_ERR(pdata->clk))
return dev_err_probe(dev, PTR_ERR(pdata->clk), "failed to get clock\n");
- pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
- (pdev->dev.of_node, "amlogic,ao-secure");
- if (IS_ERR(pdata->sec_ao_map)) {
- dev_err(dev, "syscon regmap lookup failed.\n");
- return PTR_ERR(pdata->sec_ao_map);
+ if (pdata->data->use_sm) {
+ struct device_node *sm_np;
+ struct of_phandle_args ph_args;
+
+ ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
+ "amlogic,secure-monitor",
+ 1, 0, &ph_args);
+ if (ret)
+ return ret;
+
+ sm_np = ph_args.np;
+ if (!sm_np) {
+ dev_err(dev,
+ "Failed to parse secure monitor phandle\n");
+ return -ENODEV;
+ }
+
+ pdata->sm_fw = meson_sm_get(sm_np);
+ of_node_put(sm_np);
+ if (!pdata->sm_fw) {
+ dev_err(dev, "Failed to get secure monitor firmware\n");
+ return -EPROBE_DEFER;
+ }
+
+ pdata->tsensor_id = ph_args.args[0];
+ } else {
+ pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
+ (pdev->dev.of_node, "amlogic,ao-secure");
+ if (IS_ERR(pdata->sec_ao_map)) {
+ dev_err(dev, "syscon regmap lookup failed.\n");
+ return PTR_ERR(pdata->sec_ao_map);
+ }
}
pdata->tzd = devm_thermal_of_zone_register(&pdev->dev,
--
2.49.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