* [PATCH] dt-bindings: thermal: Fix false warning with 'phandle' in trips nodes
From: Rob Herring (Arm) @ 2026-04-10 22:36 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-pm, devicetree, linux-kernel
A pattern property matching essentially anything doesn't work if there
are implicit properties such as 'phandle' which can occur on any node.
One such example popped up recently:
arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: thermal-zones: gpuss0-thermal:trips:phandle: 531 is not of type 'object'
from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml
Instead of a pattern property, use an "additionalProperties" schema
instead which is the fallback in case of no matching property.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
Daniel, Please pick this up for v7.1 as the above warning is in next. Or
if you prefer, I can take it.
.../bindings/thermal/thermal-zones.yaml | 111 +++++++++---------
1 file changed, 54 insertions(+), 57 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
index 0de0a9757ccc..07d9f576ffe7 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -129,63 +129,60 @@ patternProperties:
which the thermal framework needs to take action. The actions to
be taken are defined in another node called cooling-maps.
- patternProperties:
- "^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$":
- type: object
-
- properties:
- temperature:
- $ref: /schemas/types.yaml#/definitions/int32
- minimum: -273000
- maximum: 200000
- description:
- An integer expressing the trip temperature in millicelsius.
-
- hysteresis:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- An unsigned integer expressing the hysteresis delta with
- respect to the trip temperature property above, also in
- millicelsius. Any cooling action initiated by the framework is
- maintained until the temperature falls below
- (trip temperature - hysteresis). This potentially prevents a
- situation where the trip gets constantly triggered soon after
- cooling action is removed.
-
- type:
- $ref: /schemas/types.yaml#/definitions/string
- enum:
- - active # enable active cooling e.g. fans
- - passive # enable passive cooling e.g. throttling cpu
- - hot # send notification to driver
- - critical # send notification to driver, trigger shutdown
- description: |
- There are four valid trip types: active, passive, hot,
- critical.
-
- The critical trip type is used to set the maximum
- temperature threshold above which the HW becomes
- unstable and underlying firmware might even trigger a
- reboot. Hitting the critical threshold triggers a system
- shutdown.
-
- The hot trip type can be used to send a notification to
- the thermal driver (if a .notify callback is registered).
- The action to be taken is left to the driver.
-
- The passive trip type can be used to slow down HW e.g. run
- the CPU, GPU, bus at a lower frequency.
-
- The active trip type can be used to control other HW to
- help in cooling e.g. fans can be sped up or slowed down
-
- required:
- - temperature
- - hysteresis
- - type
- additionalProperties: false
-
- additionalProperties: false
+ additionalProperties:
+ type: object
+ additionalProperties: false
+
+ properties:
+ temperature:
+ $ref: /schemas/types.yaml#/definitions/int32
+ minimum: -273000
+ maximum: 200000
+ description:
+ An integer expressing the trip temperature in millicelsius.
+
+ hysteresis:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ An unsigned integer expressing the hysteresis delta with
+ respect to the trip temperature property above, also in
+ millicelsius. Any cooling action initiated by the framework is
+ maintained until the temperature falls below
+ (trip temperature - hysteresis). This potentially prevents a
+ situation where the trip gets constantly triggered soon after
+ cooling action is removed.
+
+ type:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - active # enable active cooling e.g. fans
+ - passive # enable passive cooling e.g. throttling cpu
+ - hot # send notification to driver
+ - critical # send notification to driver, trigger shutdown
+ description: |
+ There are four valid trip types: active, passive, hot,
+ critical.
+
+ The critical trip type is used to set the maximum
+ temperature threshold above which the HW becomes
+ unstable and underlying firmware might even trigger a
+ reboot. Hitting the critical threshold triggers a system
+ shutdown.
+
+ The hot trip type can be used to send a notification to
+ the thermal driver (if a .notify callback is registered).
+ The action to be taken is left to the driver.
+
+ The passive trip type can be used to slow down HW e.g. run
+ the CPU, GPU, bus at a lower frequency.
+
+ The active trip type can be used to control other HW to
+ help in cooling e.g. fans can be sped up or slowed down
+
+ required:
+ - temperature
+ - hysteresis
+ - type
cooling-maps:
type: object
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Kevin Hilman @ 2026-04-10 22:25 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <CAPDyKFrR2zyMFXTAkKs1XRgB-u5jSP256g730s=7SLuOZKsKVg@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On Fri, 10 Apr 2026 at 02:45, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>
>> > On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
>> >>
>> >> Currently, PM domains can only support hierarchy for simple
>> >> providers (e.g. ones with #power-domain-cells = 0).
>> >>
>> >> Add support for oncell providers as well by adding a new property
>> >> `power-domains-child-ids` to describe the parent/child relationship.
>> >>
>> >> For example, an SCMI PM domain provider has multiple domains, each of
>> >> which might be a child of diffeent parent domains. In this example,
>> >> the parent domains are MAIN_PD and WKUP_PD:
>> >>
>> >> scmi_pds: protocol@11 {
>> >> reg = <0x11>;
>> >> #power-domain-cells = <1>;
>> >> power-domains = <&MAIN_PD>, <&WKUP_PD>;
>> >> power-domains-child-ids = <15>, <19>;
>> >> };
>> >>
>> >> With this example using the new property, SCMI PM domain 15 becomes a
>> >> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
>> >> WKUP_PD.
>> >>
>> >> To support this feature, add two new core functions
>> >>
>> >> - of_genpd_add_child_ids()
>> >> - of_genpd_remove_child_ids()
>> >>
>> >> which can be called by pmdomain providers to add/remove child domains
>> >> if they support the new property power-domains-child-ids.
>> >>
>> >> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
>> >
>> > Thanks for working on this! It certainly is a missing feature!
>>
>> You're welcome, thanks for the detailed review.
>>
>> >> ---
>> >> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> include/linux/pm_domain.h | 16 ++++++++++++++++
>> >> 2 files changed, 185 insertions(+)
>> >>
>> >> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
>> >> index 61c2277c9ce3..acb45dd540b7 100644
>> >> --- a/drivers/pmdomain/core.c
>> >> +++ b/drivers/pmdomain/core.c
>> >> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
>> >> return genpd;
>> >> }
>> >>
>> >> +/**
>> >> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
>> >> + * @np: Device node pointer associated with the PM domain provider.
>> >> + * @data: Pointer to the onecell data associated with the PM domain provider.
>> >> + *
>> >> + * Parse the power-domains and power-domains-child-ids properties to establish
>> >> + * parent-child relationships for PM domains. The power-domains property lists
>> >> + * parent domains, and power-domains-child-ids lists which child domain IDs
>> >> + * should be associated with each parent.
>> >> + *
>> >> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
>> >
>> > I think we should avoid returning specific error codes for specific
>> > errors, simply because it usually becomes messy.
>> >
>> > If I understand correctly the intent here is to allow the caller to
>> > check for -ENOENT and potentially avoid bailing out as it may not
>> > really be an error, right?
>>
>> Right, -ENOENT is not an error of parsing, it's to indicate that there
>> are no child-ids to be parsed.
>>
>> > Perhaps a better option is to return the number of children for whom
>> > we successfully assigned parents. Hence 0 or a positive value allows
>> > the caller to understand what happened. More importantly, a negative
>> > error code then really becomes an error for the caller to consider.
>>
>> I explored this a bit, but it gets messy quick. It means we have to
>> track cases where only some of the children were added as well as when
>> all children were added. Personally, I think this should be an "all or
>> nothing" thing. If all the children cannot be parsed/added, then none
>> of them should be added.
>>
>> This also allows the remove to not have to care about how many were
>> added, and just remove them all, with the additional benefit of not
>> having to track the state of how many children were successfully added.
>>
>
> I fully agree, it should be all or nothing. Failing with one
> child/parent should end up with an error code being returned.
>
> That said, it still seems to make perfect sense to return the number
> of children for whom we assigned parents for, no?
No, because what will the caller use that number for? If we are
assuming "all or nothing", what would we use it for (other than a debug print?)
It also makes it a bit confusing what a zero return value means. Does
that mean success? Or that zero children were added (which would be
fail.)
I prefer to keep it as is.
Kevin
^ permalink raw reply
* Re: [patch 01/12] clockevents: Prevent timer interrupt starvation
From: Nathan Chancellor @ 2026-04-10 21:13 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, 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: <87fr52zfze.ffs@tglx>
On Fri, Apr 10, 2026 at 11:02:13PM +0200, Thomas Gleixner wrote:
> On Fri, Apr 10 2026 at 13:52, Nathan Chancellor wrote:
> >> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/
> >
> > This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer
> > interrupt starvation") appears to make one of my test machines
> > consistently lock up on boot (at least I never get to userspace). Most
> > of the time I get stall messages such as
>
> Can you please retest the changes I just pushed out into:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent
>
> namely: d6e152d905bd ("clockevents: Prevent timer interrupt starvation")
Hah, funny timing. I can confirm that the following diff against the
version in -next appears to fix the issue for me. Thanks for the quick
response!
Cheers,
Nathan
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index f63c65881364..7e57fa31ee26 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -76,8 +76,10 @@ const struct clock_event_device *tick_get_wakeup_device(int cpu)
*/
static void tick_broadcast_start_periodic(struct clock_event_device *bc)
{
- if (bc)
+ if (bc) {
+ bc->next_event_forced = 0;
tick_setup_periodic(bc, 1);
+ }
}
/*
@@ -403,6 +405,7 @@ static void tick_handle_periodic_broadcast(struct clock_event_device *dev)
bool bc_local;
raw_spin_lock(&tick_broadcast_lock);
+ tick_broadcast_device.evtdev->next_event_forced = 0;
/* Handle spurious interrupts gracefully */
if (clockevent_state_shutdown(tick_broadcast_device.evtdev)) {
@@ -696,6 +699,7 @@ static void tick_handle_oneshot_broadcast(struct clock_event_device *dev)
raw_spin_lock(&tick_broadcast_lock);
dev->next_event = KTIME_MAX;
+ tick_broadcast_device.evtdev->next_event_forced = 0;
next_event = KTIME_MAX;
cpumask_clear(tmpmask);
now = ktime_get();
@@ -1063,6 +1067,7 @@ static void tick_broadcast_setup_oneshot(struct clock_event_device *bc,
bc->event_handler = tick_handle_oneshot_broadcast;
+ bc->next_event_forced = 0;
bc->next_event = KTIME_MAX;
/*
@@ -1175,6 +1180,7 @@ void hotplug_cpu__broadcast_tick_pull(int deadcpu)
}
/* This moves the broadcast assignment to this CPU: */
+ bc->next_event_forced = 0;
clockevents_program_event(bc, bc->next_event, 1);
}
raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
^ permalink raw reply related
* Re: [patch 01/12] clockevents: Prevent timer interrupt starvation
From: Thomas Gleixner @ 2026-04-10 21:02 UTC (permalink / raw)
To: Nathan Chancellor
Cc: LKML, 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: <20260410205203.GA3922321@ax162>
On Fri, Apr 10 2026 at 13:52, Nathan Chancellor wrote:
>> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/
>
> This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer
> interrupt starvation") appears to make one of my test machines
> consistently lock up on boot (at least I never get to userspace). Most
> of the time I get stall messages such as
Can you please retest the changes I just pushed out into:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent
namely: d6e152d905bd ("clockevents: Prevent timer interrupt starvation")
Thanks,
tglx
^ permalink raw reply
* Re: [patch 01/12] clockevents: Prevent timer interrupt starvation
From: Nathan Chancellor @ 2026-04-10 20:52 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, 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>
Hi Thomas,
On Tue, Apr 07, 2026 at 10:54:17AM +0200, 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/
This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer
interrupt starvation") appears to make one of my test machines
consistently lock up on boot (at least I never get to userspace). Most
of the time I get stall messages such as
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 14-...!: (20 GPs behind) idle=f380/0/0x0 softirq=1272/1273 fqs=4 (false positive?)
rcu: (detected by 2, t=60002 jiffies, g=3673, q=12382 ncpus=16)
Sending NMI from CPU 2 to CPUs 14:
NMI backtrace for cpu 14 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
rcu: rcu_preempt kthread timer wakeup didn't happen for 59984 jiffies! g3673 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: Possible timer handling issue on cpu=4 timer-softirq=170
rcu: rcu_preempt kthread starved for 59987 jiffies! g3673 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=4
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:I stack:0 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00000010
Call trace:
__switch_to+0x100/0x1c8 (T)
__schedule+0x2b0/0x710
schedule+0x3c/0xc0
schedule_timeout+0x88/0x128
rcu_gp_fqs_loop+0x12c/0x640
rcu_gp_kthread+0x308/0x350
kthread+0x10c/0x128
ret_from_fork+0x10/0x20
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 2 to CPUs 4:
NMI backtrace for cpu 4 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 0-...!: (21 GPs behind) idle=a4a0/0/0x0 softirq=1775/1776 fqs=0 (false positive?)
rcu: 3-...!: (28 GPs behind) idle=5b00/0/0x0 softirq=1437/1438 fqs=0 (false positive?)
rcu: 7-...!: (21 GPs behind) idle=0c18/0/0x0 softirq=1658/1659 fqs=0 (false positive?)
rcu: 8-...!: (21 GPs behind) idle=1418/0/0x0 softirq=1231/1231 fqs=0 (false positive?)
rcu: 9-...!: (18 GPs behind) idle=1288/0/0x0 softirq=1440/1440 fqs=0 (false positive?)
rcu: 12-...!: (21 GPs behind) idle=ae70/0/0x0 softirq=1339/1339 fqs=0 (false positive?)
rcu: 13-...!: (28 GPs behind) idle=02c8/0/0x0 softirq=1785/1787 fqs=0 (false positive?)
rcu: 14-...!: (21 GPs behind) idle=f428/0/0x0 softirq=1272/1273 fqs=0 (false positive?)
rcu: 15-...!: (21 GPs behind) idle=0fb8/0/0x0 softirq=1562/1562 fqs=0 (false positive?)
rcu: (detected by 5, t=60002 jiffies, g=3677, q=12637 ncpus=16)
Sending NMI from CPU 5 to CPUs 0:
NMI backtrace for cpu 0 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170
Sending NMI from CPU 5 to CPUs 3:
NMI backtrace for cpu 3 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170
Sending NMI from CPU 5 to CPUs 7:
NMI backtrace for cpu 7 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 8:
NMI backtrace for cpu 8 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 9:
NMI backtrace for cpu 9 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 12:
NMI backtrace for cpu 12 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 13:
NMI backtrace for cpu 13 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
Sending NMI from CPU 5 to CPUs 14:
NMI backtrace for cpu 14 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
Sending NMI from CPU 5 to CPUs 15:
NMI backtrace for cpu 15 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170
rcu: rcu_preempt kthread timer wakeup didn't happen for 60008 jiffies! g3677 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: Possible timer handling issue on cpu=4 timer-softirq=170
rcu: rcu_preempt kthread starved for 60011 jiffies! g3677 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=4
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:I stack:0 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00000010
Call trace:
__switch_to+0x100/0x1c8 (T)
__schedule+0x2b0/0x710
schedule+0x3c/0xc0
schedule_timeout+0x88/0x128
rcu_gp_fqs_loop+0x12c/0x640
rcu_gp_kthread+0x308/0x350
kthread+0x10c/0x128
ret_from_fork+0x10/0x20
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 5 to CPUs 4:
NMI backtrace for cpu 4
CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.0.0-rc7-next-20260409 #1 PREEMPT(lazy)
Hardware name: SolidRun Ltd. SolidRun CEX7 Platform, BIOS EDK II Jun 21 2022
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : tick_check_broadcast_expired+0x4/0x40
lr : cpu_idle_poll.isra.0+0x54/0x170
sp : ffff80008017be20
x29: ffff80008017be20 x28: 0000000000000000 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
x23: 00000000000000c0 x22: ffffb3ce21fad000 x21: 0000000000000004
x20: ffffb3ce21fadd50 x19: ffffb3ce21fad000 x18: 0000000000000004
x17: 0000000000000000 x16: 0000000000000000 x15: ffffb3ce21fb3b98
x14: ffffb3ce21788180 x13: 0000000000000000 x12: 000000124d69be59
x11: 00000000000000c0 x10: 0000000000001c80 x9 : ffffb3ce1f8a6e68
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000004
x5 : ffff00275c3682c8 x4 : 0000000000020a3c x3 : 0000000000000000
x2 : 0000000000000004 x1 : ffffb3ce223ca0c0 x0 : ffff002020da2140
Call trace:
tick_check_broadcast_expired+0x4/0x40 (P)
do_idle+0x64/0x130
cpu_startup_entry+0x40/0x50
secondary_start_kernel+0xe4/0x128
__secondary_switched+0xc0/0xc8
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 0-...!: (22 GPs behind) idle=ae48/0/0x0 softirq=1775/1776 fqs=0 (false positive?)
rcu: 3-...!: (29 GPs behind) idle=7ce8/0/0x0 softirq=1437/1438 fqs=0 (false positive?)
rcu: 7-...!: (22 GPs behind) idle=0df8/0/0x0 softirq=1658/1659 fqs=0 (false positive?)
rcu: 8-...!: (22 GPs behind) idle=1548/0/0x0 softirq=1231/1231 fqs=0 (false positive?)
rcu: 9-...!: (19 GPs behind) idle=1360/0/0x0 softirq=1440/1440 fqs=0 (false positive?)
rcu: 12-...!: (22 GPs behind) idle=af40/0/0x0 softirq=1339/1339 fqs=0 (false positive?)
rcu: 13-...!: (29 GPs behind) idle=04e0/0/0x0 softirq=1785/1787 fqs=0 (false positive?)
rcu: 14-...!: (22 GPs behind) idle=f528/0/0x0 softirq=1272/1273 fqs=0 (false positive?)
rcu: 15-...!: (22 GPs behind) idle=0fd8/0/0x0 softirq=1562/1562 fqs=0 (false positive?)
rcu: (detected by 5, t=60002 jiffies, g=3681, q=13149 ncpus=16)
but other times, there is no output after it locks up. Is there any
initial information I can provide to help debug this? Reverting the
change on top of next-20260409 avoids the issue.
Cheers,
Nathan
# bad: [3fa7d958829eb9bc3b469ed07f11de3d2804ef71] Add linux-next specific files for 20260409
# good: [7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594] Merge tag 'hid-for-linus-2026040801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
git bisect start '3fa7d958829eb9bc3b469ed07f11de3d2804ef71' '7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594'
# bad: [443e04732ac2cdc17e3b90aa2345730a298fab37] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
git bisect bad 443e04732ac2cdc17e3b90aa2345730a298fab37
# bad: [ea33e83d9fa24b34e79c8df57b8927a8d94deb15] Merge branch 'xtensa-for-next' of https://github.com/jcmvbkbc/linux-xtensa.git
git bisect bad ea33e83d9fa24b34e79c8df57b8927a8d94deb15
# bad: [429057750b3d3a7477df48d17aa605dc47bc2344] Merge branch 'for-next/perf' of https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
git bisect bad 429057750b3d3a7477df48d17aa605dc47bc2344
# bad: [e98894f89da72f392141d9eecf1c7a8f13faa67f] Merge branch 'mm-stable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect bad e98894f89da72f392141d9eecf1c7a8f13faa67f
# good: [668937b7b2256f4b2a982e8f69b07d9ee8f81d36] mm: allow handling of stacked mmap_prepare hooks in more drivers
git bisect good 668937b7b2256f4b2a982e8f69b07d9ee8f81d36
# good: [a0fbc8dd44a27011537268e2a974b1180b848796] Merge branch 'dma-mapping-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux.git
git bisect good a0fbc8dd44a27011537268e2a974b1180b848796
# good: [8a23051ed8584215b22368e9501f771ef98f0c1d] Merge tag 'pin-init-v7.1' of https://github.com/Rust-for-Linux/linux into rust-next
git bisect good 8a23051ed8584215b22368e9501f771ef98f0c1d
# good: [716b25a9dc20f4fb94d521581331a0565a43f3bb] Merge branch 'urgent' of https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
git bisect good 716b25a9dc20f4fb94d521581331a0565a43f3bb
# bad: [1a49dc272e25dae6cbb506a02bb70e0201a1498e] Merge branch 'tip/urgent' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
git bisect bad 1a49dc272e25dae6cbb506a02bb70e0201a1498e
# good: [30023353b2171cd36b10615a788a985f5caa29e3] Merge branch into tip/master: 'sched/urgent'
git bisect good 30023353b2171cd36b10615a788a985f5caa29e3
# good: [34ef164adaf00982d5f45037a7e37689c4555271] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
git bisect good 34ef164adaf00982d5f45037a7e37689c4555271
# bad: [4fc7108ff756267ad53ecdeaa1e847d378887511] Merge branch into tip/master: 'timers/urgent'
git bisect bad 4fc7108ff756267ad53ecdeaa1e847d378887511
# bad: [1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4] clockevents: Prevent timer interrupt starvation
git bisect bad 1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4
# good: [82b915051d32a68ea3bbe261c93f5620699ff047] tick/nohz: Fix inverted return value in check_tick_dependency() fast path
git bisect good 82b915051d32a68ea3bbe261c93f5620699ff047
# first bad commit: [1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4] clockevents: Prevent timer interrupt starvation
^ permalink raw reply
* Re: [PATCH] tools/power turbostat: Allow execution to continue after perf_l2_init() failure
From: Len Brown @ 2026-04-10 18:09 UTC (permalink / raw)
To: David Arcari, dapeng1.mi; +Cc: Linux PM list, Linux Kernel Mailing List
In-Reply-To: <5ec684ae-b778-40ba-8a10-dfbf274da7dd@redhat.com>
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
* [PATCH 6/8] arm64: dts: amlogic: t7: Add thermal sensor nodes
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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 7/8] arm64: dts: amlogic: t7: Add thermal zones
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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 5/8] arm64: dts: amlogic: t7: Add cooling cells to all CPUs
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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
* [PATCH 3/8] firmware: meson: sm: Add thermal calibration SMC call
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add SM_THERMAL_CALIB_READ at SMC ID 0x82000047 in the command
table and implement meson_sm_get_thermal_calib(), which forwards the
tsensor_id argument to the secure monitor and returns the calibration data.
Also realign the CMD() column to improve readability.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/firmware/meson/meson_sm.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 3ab67aaa9e5da..da0dbcd8a2ff2 100644
--- a/drivers/firmware/meson/meson_sm.c
+++ b/drivers/firmware/meson/meson_sm.c
@@ -41,12 +41,13 @@ static const struct meson_sm_chip gxbb_chip = {
.cmd_shmem_in_base = 0x82000020,
.cmd_shmem_out_base = 0x82000021,
.cmd = {
- CMD(SM_EFUSE_READ, 0x82000030),
- CMD(SM_EFUSE_WRITE, 0x82000031),
+ CMD(SM_EFUSE_READ, 0x82000030),
+ CMD(SM_EFUSE_WRITE, 0x82000031),
CMD(SM_EFUSE_USER_MAX, 0x82000033),
- CMD(SM_GET_CHIP_ID, 0x82000044),
- CMD(SM_A1_PWRC_SET, 0x82000093),
- CMD(SM_A1_PWRC_GET, 0x82000095),
+ CMD(SM_GET_CHIP_ID, 0x82000044),
+ CMD(SM_THERMAL_CALIB_READ, 0x82000047),
+ CMD(SM_A1_PWRC_SET, 0x82000093),
+ CMD(SM_A1_PWRC_GET, 0x82000095),
{ /* sentinel */ },
},
};
@@ -245,6 +246,14 @@ struct meson_sm_firmware *meson_sm_get(struct device_node *sm_node)
}
EXPORT_SYMBOL_GPL(meson_sm_get);
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id)
+{
+ return meson_sm_call(fw, SM_THERMAL_CALIB_READ, trim_info, tsensor_id,
+ 0, 0, 0, 0);
+}
+EXPORT_SYMBOL_GPL(meson_sm_get_thermal_calib);
+
#define SM_CHIP_ID_LENGTH 119
#define SM_CHIP_ID_OFFSET 4
#define SM_CHIP_ID_SIZE 12
--
2.49.0
^ permalink raw reply related
* [PATCH 2/8] firmware: meson: sm: Thermal calibration read via secure monitor
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add SM_THERMAL_CALIB_READ to the secure monitor command enum and
introduce meson_sm_get_thermal_calib() to allow drivers to retrieve
thermal sensor calibration data through the firmware interface.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/firmware/meson/meson_sm.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/firmware/meson/meson_sm.h b/include/linux/firmware/meson/meson_sm.h
index 8eaf8922ab020..3ebc2bd9a9760 100644
--- a/include/linux/firmware/meson/meson_sm.h
+++ b/include/linux/firmware/meson/meson_sm.h
@@ -12,6 +12,7 @@ enum {
SM_EFUSE_WRITE,
SM_EFUSE_USER_MAX,
SM_GET_CHIP_ID,
+ SM_THERMAL_CALIB_READ,
SM_A1_PWRC_SET,
SM_A1_PWRC_GET,
};
@@ -27,5 +28,7 @@ int meson_sm_call_read(struct meson_sm_firmware *fw, void *buffer,
unsigned int bsize, unsigned int cmd_index, u32 arg0,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
struct meson_sm_firmware *meson_sm_get(struct device_node *firmware_node);
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id);
#endif /* _MESON_SM_FW_H_ */
--
2.49.0
^ permalink raw reply related
* [PATCH 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
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.
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 | 40 +++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 70b273271754b..85ee73c6e1161 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -22,6 +22,7 @@ properties:
- amlogic,g12a-ddr-thermal
- const: amlogic,g12a-thermal
- const: amlogic,a1-cpu-thermal
+ - const: amlogic,t7-thermal
reg:
maxItems: 1
@@ -42,12 +43,40 @@ 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
+
required:
- compatible
- reg
- interrupts
- clocks
- - amlogic,ao-secure
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - amlogic,a1-cpu-thermal
+ then:
+ required:
+ - amlogic,ao-secure
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,t7-thermal
+ 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 {
+ 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
^ permalink raw reply related
* [PATCH 0/8] arm64: amlogic: T7 thermal support
From: Ronald Claveau @ 2026-04-10 16:48 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
This series adds thermal monitoring support for the Amlogic T7 SoC,
used on the Khadas VIM4 board.
The T7 exposes six thermal sensors (a53, a73, gpu, nna, vpu, hevc),
each accessible through the secure monitor firmware interface rather
than a directly mapped eFuse register as on older SoCs.
The series is organized as follows:
- Patch 1 extends the amlogic,t7-thermal DT binding to describe the
new amlogic,secure-monitor property.
- Patches 2-3 extend the Meson secure monitor driver to expose a
thermal calibration read command (SMC ID 0x82000047).
- Patch 4 adds the secure monitor readout path to the amlogic thermal
driver and introduces the amlogic,t7-thermal compatible.
- Patches 5-7 wire up the T7 DTSI with CPU cooling cells, sensor
nodes, and thermal zones.
- Patch 8 extends the Khadas VIM4 DTS to map all thermal zones to the
on-board MCU fan controller (states 30–100, corresponding to the
FAN_CTRL register range 0x1E–0x64).
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Ronald Claveau (8):
dt-bindings: thermal: amlogic: Add support for T7
firmware: meson: sm: Thermal calibration read via secure monitor
firmware: meson: sm: Add thermal calibration SMC call
thermal: amlogic: Add support for secure monitor calibration readout
arm64: dts: amlogic: t7: Add cooling cells to all CPUs
arm64: dts: amlogic: t7: Add thermal sensor nodes
arm64: dts: amlogic: t7: Add thermal zones
arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
.../bindings/thermal/amlogic,thermal.yaml | 40 +++-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 245 +++++++++++++++++++++
drivers/firmware/meson/meson_sm.c | 19 +-
drivers/thermal/amlogic_thermal.c | 58 ++++-
include/linux/firmware/meson/meson_sm.h | 3 +
6 files changed, 456 insertions(+), 11 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260410-add-thermal-t7-vim4-00e571badcc1
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b:v2
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-patch-id: 34a2bbfe3ce30c530e69af5083aa26534b2c2560
prerequisite-patch-id: 406f88d7dabd3a870b358fb53c21686f29eb32b7
prerequisite-patch-id: d7a75ae3be0f54e0a7e81ccb0043a2f05423c9d0
prerequisite-patch-id: 5e19dc5ace12b532284246f5c2ff3f214d8a9c4f
prerequisite-patch-id: d6a87ebcf5246eb67b94ca0908afa3df9f9383fe
prerequisite-patch-id: 4809bbedf79f59e1abc52c17cffc0b1bbb43d365
prerequisite-patch-id: c050e8bac4b5491f6c7008a5ccb26f20fad38b46
prerequisite-patch-id: 30677db8fc57270787245103c0d5acf8791307b0
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [GIT PULL] turbostat fixes for 7.0
From: pr-tracker-bot @ 2026-04-10 16:45 UTC (permalink / raw)
To: Len Brown; +Cc: Linus Torvalds, Linux PM list, Linux Kernel Mailing List
In-Reply-To: <CAJvTdKnLmCFKQevH7-Am-TQZcvtgRhhMbyfrb5zG6EbEsQheqg@mail.gmail.com>
The pull request you sent on Fri, 10 Apr 2026 09:40:59 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git tags/turbostat-fixes-for-7.0
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/96463e4e0268dddbdb60fd1b96800736aa2bade9
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: (subset) [PATCH v6 00/11] Add support for the TI BQ25792 battery charger
From: Mark Brown @ 2026-04-10 10:52 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Liam Girdwood, Sebastian Reichel, Alexey Charkov
Cc: devicetree, linux-kernel, Sebastian Reichel, linux-pm,
Krzysztof Kozlowski, stable
In-Reply-To: <20260331-bq25792-v6-0-0278fba33eb9@flipper.net>
On Tue, 31 Mar 2026 19:43:37 +0400, Alexey Charkov wrote:
> Add support for the TI BQ25792 battery charger
>
> This adds support for the TI BQ25792 battery charger, which is similar in
> overall logic to the BQ25703A, but has a different register layout and
> slightly different lower-level programming logic.
>
> The series is organized as follows:
> - Patch 1 adds the new variant to the existing DT binding, including the
> changes in electrical characteristics
> - Patches 2-4 are minor cleanups to the existing BQ25703A OTG regulator
> driver, slimming down the code and making it more reusable for the new
> BQ25792 variant
> - Patch 5 is a logical fix to the BQ25703A clamping logic for VSYSMIN
> (this is a standalone fix which can be applied independently and may be
> backported to stable)
> - Patches 6-8 are slight refactoring of the existing BQ25703A charger
> driver to make it more reusable for the new BQ25792 variant
> - Patch 9 adds platform data to distinguish between the two variants in
> the parent MFD driver, and binds it to the new compatible string
> - Patches 10-11 add variant-specific code to support the new BQ25792
> variant in the regulator part and the charger part respectively,
> selected by the platform data added in patch 9
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[02/11] regulator: bq257xx: Remove reference to the parent MFD's dev
https://git.kernel.org/broonie/regulator/c/aef4d87f2c1f
[04/11] regulator: bq257xx: Make OTG enable GPIO really optional
https://git.kernel.org/broonie/regulator/c/de76a763805d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] tools/power turbostat: Allow execution to continue after perf_l2_init() failure
From: David Arcari @ 2026-04-10 16:06 UTC (permalink / raw)
To: Len Brown; +Cc: linux-pm, linux-kernel
In-Reply-To: <CAJvTdKmepvPzWDM+6s9YERe27H6pSKbDb62yfpTSs57hWsEmRg@mail.gmail.com>
Hi Len,
On 4/10/26 8:59 AM, Len Brown wrote:
> Thank you for the patch, David, it is helpful.
>
> I agree that turbostat should do its best to run properly when the
> underlying kernel
> doesn't have full support, and you found a configuration that I missed.
>
> I'd like to understand how/why your kernel perf support is failing on alder lake
> to be sure turbostat is coping the best it can.
>
> If you can identify an upstream kernel version that fails this way,
> that would be great.
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/
11,212 cpu_core/cache-misses/
1.001044852 seconds time elapsed
0.000793000 seconds user
0.000000000 seconds sys
# sudo perf stat -e L2_REQUEST.ALL sleep 1
Performance counter stats for 'sleep 1':
<not supported> cpu_atom/L2_REQUEST.ALL/
98,451 cpu_core/L2_REQUEST.ALL/
1.001072723 seconds time elapsed
0.000761000 seconds user
0.000000000 seconds sys
>
> Also, with your L2 patch applied, does turbostat still successfully
> show the LLC stats?
>
# ./turbostat --quiet -s Core,CPU,LLCMRPS,LLC%hit -n 1
Core CPU LLCMRPS LLC%hit
- - 1 91.33
0 0 0 93.48
0 1 0 86.86
1 2 0 90.68
1 3 0 98.61
2 4 0 98.59
2 5 0 98.79
3 6 0 90.86
3 7 0 97.64
4 8 0 97.52
4 9 0 99.33
5 10 0 85.54
5 11 0 90.85
Let me know if you need something else.
Thanks,
-DA
> thanks,
> Len Brown, Intel Open Source Technology Center
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: interconnect: qcom: document the RPMh NoC for Hawi SoC
From: Mike Tipton @ 2026-04-10 15:42 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260409-icc-hawi-v3-1-851cac12a81d@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 02:01:37PM -0700, Vivek Aknurwar wrote:
> Document the RPMh Network-On-Chip interconnect for the Qualcomm Hawi SoC.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> .../bindings/interconnect/qcom,hawi-rpmh.yaml | 131 ++++++++++++++++
> include/dt-bindings/interconnect/qcom,hawi-rpmh.h | 164 +++++++++++++++++++++
> 2 files changed, 295 insertions(+)
Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v11 10/16] KVM: guest_memfd: Add flag to remove from direct map
From: Nikita Kalyazin @ 2026-04-10 15:30 UTC (permalink / raw)
To: Ackerley Tng, Kalyazin, Nikita, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <CAEvNRgGb95C3uRxPy2_Uj7SmTW45hNNdJxi5RR209s5KYcHgBw@mail.gmail.com>
On 23/03/2026 21:15, Ackerley Tng wrote:
> "Kalyazin, Nikita" <kalyazin@amazon.co.uk> writes:
>
>>
>> [...snip...]
>>
>> static vm_fault_t kvm_gmem_fault_user_mapping(struct vm_fault *vmf)
>> {
>> struct inode *inode = file_inode(vmf->vma->vm_file);
>> struct folio *folio;
>> vm_fault_t ret = VM_FAULT_LOCKED;
>> + int err;
>>
>> if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode))
>> return VM_FAULT_SIGBUS;
>> @@ -418,6 +454,14 @@ static vm_fault_t kvm_gmem_fault_user_mapping(struct vm_fault *vmf)
>> folio_mark_uptodate(folio);
>> }
>>
>> + if (kvm_gmem_no_direct_map(folio_inode(folio))) {
>> + err = kvm_gmem_folio_zap_direct_map(folio);
>> + if (err) {
>> + ret = vmf_error(err);
>> + goto out_folio;
>> + }
>> + }
>> +
>> vmf->page = folio_file_page(folio, vmf->pgoff);
>>
>
> Sashiko pointed out that kvm_gmem_populate() might try and write to
> direct-map-removed folios, but I think that's handled because populate
> will first try and GUP folios, which is already blocked for
> direct-map-removed folios.
As far as I can see, it is a valid issue as populate only GUPs the
source pages, not gmem. I think this is similar to what was discussed
about TDX at some point and decided to exclude TDX support [1]. I
followed the same path and excluded SEV-SNP in the patch 8 [2]. I kept
your and David's "Reviewed-by:" for that patch, but please let me know
if this makes you change your minds.
[1] https://lore.kernel.org/kvm/aWpcDrGVLrZOqdcg@google.com
[2] https://lore.kernel.org/kvm/20260410151746.61150-9-kalyazin@amazon.com
>
>> out_folio:
>> @@ -528,6 +572,9 @@ static void kvm_gmem_free_folio(struct folio *folio)
>> kvm_pfn_t pfn = page_to_pfn(page);
>> int order = folio_order(folio);
>>
>> + if (kvm_gmem_folio_no_direct_map(folio))
>> + kvm_gmem_folio_restore_direct_map(folio);
>> +
>> kvm_arch_gmem_invalidate(pfn, pfn + (1ul << order));
>> }
>>
>
> Sashiko says to invalidate then restore direct map, I think in this case
> it doesn't matter since if the folio needed invalidation, it must be
> private, and the host shouldn't be writing to the private pages anyway.
>
> One benefit of retaining this order (restore, invalidate) is that it
> opens the invalidate hook to possibly do something regarding memory
> contents?
>
> Or perhaps we should just take the suggestion (invalidate, restore) and
> align that invalidate should not touch memory contents.
>
>> @@ -591,6 +638,9 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
>> /* Unmovable mappings are supposed to be marked unevictable as well. */
>> WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping));
>>
>> + if (flags & GUEST_MEMFD_FLAG_NO_DIRECT_MAP)
>> + mapping_set_no_direct_map(inode->i_mapping);
>> +
>> GMEM_I(inode)->flags = flags;
>>
>> file = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, &kvm_gmem_fops);
>> @@ -803,13 +853,22 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
>> }
>>
>> r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
>> + if (r)
>> + goto out_unlock;
>>
>> + if (kvm_gmem_no_direct_map(folio_inode(folio))) {
>> + r = kvm_gmem_folio_zap_direct_map(folio);
>> + if (r)
>> + goto out_unlock;
>> + }
>> +
>>
>> [...snip...]
>>
>
> Preparing a folio used to involve zeroing, but that has since been
> refactored out, so I believe zapping can come before preparing.
>
> Similar to the above point on invalidation: perhaps we should take the
> suggestion to zap then prepare
>
> + And align that preparation should not touch memory contents
> + Avoid needing to undo the preparation on zapping failure (.free_folio
> is not called on folio_put(), it is only called folio on removal from
> filemap).
I reordered both, thanks.
^ permalink raw reply
* Re: [PATCH v11 10/16] KVM: guest_memfd: Add flag to remove from direct map
From: Nikita Kalyazin @ 2026-04-10 15:29 UTC (permalink / raw)
To: David Hildenbrand (Arm), Kalyazin, Nikita, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
ackerleytng@google.com, yosry@kernel.org, ajones@ventanamicro.com,
maobibo@loongson.cn, tabba@google.com, prsampat@amd.com,
wu.fei9@sanechips.com.cn, mlevitsk@redhat.com,
jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <50bfaeb5-551e-403f-bd00-a7d8b6bbf6e2@kernel.org>
On 23/03/2026 18:05, David Hildenbrand (Arm) wrote:
> On 3/17/26 15:12, Kalyazin, Nikita wrote:
>> From: Patrick Roy <patrick.roy@linux.dev>
>>
>> Add GUEST_MEMFD_FLAG_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD()
>> ioctl. When set, guest_memfd folios will be removed from the direct map
>> after preparation, with direct map entries only restored when the folios
>> are freed.
>>
>> To ensure these folios do not end up in places where the kernel cannot
>> deal with them, set AS_NO_DIRECT_MAP on the guest_memfd's struct
>> address_space if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is requested.
>>
>> Note that this flag causes removal of direct map entries for all
>> guest_memfd folios independent of whether they are "shared" or "private"
>> (although current guest_memfd only supports either all folios in the
>> "shared" state, or all folios in the "private" state if
>> GUEST_MEMFD_FLAG_MMAP is not set). The usecase for removing direct map
>> entries of also the shared parts of guest_memfd are a special type of
>> non-CoCo VM where, host userspace is trusted to have access to all of
>> guest memory, but where Spectre-style transient execution attacks
>> through the host kernel's direct map should still be mitigated. In this
>> setup, KVM retains access to guest memory via userspace mappings of
>> guest_memfd, which are reflected back into KVM's memslots via
>> userspace_addr. This is needed for things like MMIO emulation on x86_64
>> to work.
>>
>> Direct map entries are zapped right before guest or userspace mappings
>> of gmem folios are set up, e.g. in kvm_gmem_fault_user_mapping() or
>> kvm_gmem_get_pfn() [called from the KVM MMU code]. The only place where
>> a gmem folio can be allocated without being mapped anywhere is
>> kvm_gmem_populate(), where handling potential failures of direct map
>> removal is not possible (by the time direct map removal is attempted,
>> the folio is already marked as prepared, meaning attempting to re-try
>> kvm_gmem_populate() would just result in -EEXIST without fixing up the
>> direct map state). These folios are then removed form the direct map
>> upon kvm_gmem_get_pfn(), e.g. when they are mapped into the guest later.
>>
>> Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
>
> I you changed this patch significantly, you should likely add a
>
> Co-developed-by: Nikita Kalyazin <kalyazin@amazon.com>
>
> above your sob.
>
> (applies to other patches as well, please double check)
Added.
>
>> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
>> ---
>> Documentation/virt/kvm/api.rst | 21 ++++++-----
>> include/linux/kvm_host.h | 3 ++
>> include/uapi/linux/kvm.h | 1 +
>> virt/kvm/guest_memfd.c | 67 ++++++++++++++++++++++++++++++++--
>> 4 files changed, 79 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>> index 032516783e96..8feec77b03fe 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -6439,15 +6439,18 @@ a single guest_memfd file, but the bound ranges must not overlap).
>> The capability KVM_CAP_GUEST_MEMFD_FLAGS enumerates the `flags` that can be
>> specified via KVM_CREATE_GUEST_MEMFD. Currently defined flags:
>>
>> - ============================ ================================================
>> - GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file
>> - descriptor.
>> - GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during
>> - KVM_CREATE_GUEST_MEMFD (memory files created
>> - without INIT_SHARED will be marked private).
>> - Shared memory can be faulted into host userspace
>> - page tables. Private memory cannot.
>> - ============================ ================================================
>> + ============================== ================================================
>> + GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file
>> + descriptor.
>> + GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during
>> + KVM_CREATE_GUEST_MEMFD (memory files created
>> + without INIT_SHARED will be marked private).
>> + Shared memory can be faulted into host userspace
>> + page tables. Private memory cannot.
>> + GUEST_MEMFD_FLAG_NO_DIRECT_MAP The guest_memfd instance will unmap the memory
>> + backing it from the kernel's address space
>> + before passing it off to userspace or the guest.
>> + ============================== ================================================
>>
>> When the KVM MMU performs a PFN lookup to service a guest fault and the backing
>> guest_memfd has the GUEST_MEMFD_FLAG_MMAP set, then the fault will always be
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index ce8c5fdf2752..c95747e2278c 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -738,6 +738,9 @@ static inline u64 kvm_gmem_get_supported_flags(struct kvm *kvm)
>> if (!kvm || kvm_arch_supports_gmem_init_shared(kvm))
>> flags |= GUEST_MEMFD_FLAG_INIT_SHARED;
>>
>> + if (!kvm || kvm_arch_gmem_supports_no_direct_map(kvm))
>> + flags |= GUEST_MEMFD_FLAG_NO_DIRECT_MAP;
>> +
>> return flags;
>> }
>> #endif
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 80364d4dbebb..d864f67efdb7 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -1642,6 +1642,7 @@ struct kvm_memory_attributes {
>> #define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd)
>> #define GUEST_MEMFD_FLAG_MMAP (1ULL << 0)
>> #define GUEST_MEMFD_FLAG_INIT_SHARED (1ULL << 1)
>> +#define GUEST_MEMFD_FLAG_NO_DIRECT_MAP (1ULL << 2)
>>
>> struct kvm_create_guest_memfd {
>> __u64 size;
>> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
>> index 651649623448..c9344647579c 100644
>> --- a/virt/kvm/guest_memfd.c
>> +++ b/virt/kvm/guest_memfd.c
>> @@ -7,6 +7,7 @@
>> #include <linux/mempolicy.h>
>> #include <linux/pseudo_fs.h>
>> #include <linux/pagemap.h>
>> +#include <linux/set_memory.h>
>>
>> #include "kvm_mm.h"
>>
>> @@ -76,6 +77,35 @@ static int __kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slo
>> return 0;
>> }
>>
>> +#define KVM_GMEM_FOLIO_NO_DIRECT_MAP BIT(0)
>> +
>> +static bool kvm_gmem_folio_no_direct_map(struct folio *folio)
>> +{
>> + return ((u64)folio->private) & KVM_GMEM_FOLIO_NO_DIRECT_MAP;
>> +}
>> +
>> +static int kvm_gmem_folio_zap_direct_map(struct folio *folio)
>> +{
>> + u64 gmem_flags = GMEM_I(folio_inode(folio))->flags;
>> + int r = 0;
>> +
>> + if (kvm_gmem_folio_no_direct_map(folio) || !(gmem_flags & GUEST_MEMFD_FLAG_NO_DIRECT_MAP))
>
> The function is only called when
>
> kvm_gmem_no_direct_map(folio_inode(folio))
>
> Does it really make sense to check for GUEST_MEMFD_FLAG_NO_DIRECT_MAP again?
>
> If, at all, it should be a warning if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is
> not set?
>
> Further, kvm_gmem_folio_zap_direct_map() uses the folio lock to
> synchronize, right? Might be worth pointing that out somehow (e.g.,
> lockdep check if possible).
Added a WARN_ON. I couldn't find a way to have a lockdep check here.
>
>> + goto out;
^ permalink raw reply
* Re: [PATCH v11 10/16] KVM: guest_memfd: Add flag to remove from direct map
From: Nikita Kalyazin @ 2026-04-10 15:28 UTC (permalink / raw)
To: Ackerley Tng, David Hildenbrand (Arm), Kalyazin, Nikita,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <CAEvNRgEXp6busURR20cazeG2DQWdU5=ZaJv21OcSq+mhVKwJ4g@mail.gmail.com>
On 23/03/2026 20:47, Ackerley Tng wrote:
> "David Hildenbrand (Arm)" <david@kernel.org> writes:
>
>>
>> [...snip...]
>>
>>> +static int kvm_gmem_folio_zap_direct_map(struct folio *folio)
>>> +{
>>> + u64 gmem_flags = GMEM_I(folio_inode(folio))->flags;
>>> + int r = 0;
>>> +
>>> + if (kvm_gmem_folio_no_direct_map(folio) || !(gmem_flags & GUEST_MEMFD_FLAG_NO_DIRECT_MAP))
>>
>> The function is only called when
>>
>> kvm_gmem_no_direct_map(folio_inode(folio))
>>
>> Does it really make sense to check for GUEST_MEMFD_FLAG_NO_DIRECT_MAP again?
>>
>
> Good point that GUEST_MEMFD_FLAG_NO_DIRECT_MAP was already checked in
> the caller. I think we can drop this second check.
Dropped, thanks.
>
>> If, at all, it should be a warning if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is
>> not set?
>>
>> Further, kvm_gmem_folio_zap_direct_map() uses the folio lock to
>> synchronize, right? Might be worth pointing that out somehow (e.g.,
>> lockdep check if possible).
>>
>>> + goto out;
>>> +
>>> + r = folio_zap_direct_map(folio);
>>> + if (!r)
>>> + folio->private = (void *)((u64)folio->private | KVM_GMEM_FOLIO_NO_DIRECT_MAP);
>>> +
>>> +out:
>>> + return r;
>>> +}
>>> +
>>> +static void kvm_gmem_folio_restore_direct_map(struct folio *folio)
>>> +{
^ permalink raw reply
* Re: [PATCH v11 05/16] mm/gup: drop local variable in gup_fast_folio_allowed
From: Nikita Kalyazin @ 2026-04-10 15:27 UTC (permalink / raw)
To: Ackerley Tng, David Hildenbrand (Arm), Kalyazin, Nikita,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <CAEvNRgHqJGwmAfS8TuGBbUoQehpqY9GdtjUS=+Hc1ViK79RL4w@mail.gmail.com>
On 23/03/2026 20:22, Ackerley Tng wrote:
> "David Hildenbrand (Arm)" <david@kernel.org> writes:
>
>> On 3/17/26 15:11, Kalyazin, Nikita wrote:
>>> From: Nikita Kalyazin <kalyazin@amazon.com>
>>>
>>> Move the check for pinning closer to where the result is used.
>>> No functional changes.
>>>
>>> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
>>> ---
>>> mm/gup.c | 23 ++++++++++++-----------
>>> 1 file changed, 12 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/mm/gup.c b/mm/gup.c
>>> index 5856d35be385..869d79c8daa4 100644
>>> --- a/mm/gup.c
>>> +++ b/mm/gup.c
>>> @@ -2737,18 +2737,9 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
>>> */
>>> static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>>> {
>>> - bool reject_file_backed = false;
>>> struct address_space *mapping;
>>> unsigned long mapping_flags;
>>>
>>> - /*
>>> - * If we aren't pinning then no problematic write can occur. A long term
>>> - * pin is the most egregious case so this is the one we disallow.
>>> - */
>>> - if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE)) ==
>>> - (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE))
>>> - reject_file_backed = true;
>>> -
>>> /* We hold a folio reference, so we can safely access folio fields. */
>>> if (WARN_ON_ONCE(folio_test_slab(folio)))
>>> return false;
>>> @@ -2793,8 +2784,18 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>>> */
>>> if (secretmem_mapping(mapping))
>>> return false;
>>> - /* The only remaining allowed file system is shmem. */
>>> - return !reject_file_backed || shmem_mapping(mapping);
>>> +
>>> + /*
>>> + * If we aren't pinning then no problematic write can occur. A writable
>>> + * long term pin is the most egregious case, so this is the one we
>>> + * allow only for ...
>>> + */
>>> + if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE)) !=
>>> + (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE))
>>> + return true;
>>> +
>>> + /* ... hugetlb (which we allowed above already) and shared memory. */
>>> + return shmem_mapping(mapping);
>>
>> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
>>
>> I'm wondering if it would be a good idea to check for a hugetlb mapping
>> here instead of having the folio_test_hugetlb() check above.
>>
>
> I think it's nice that hugetlb folios are determined immediately to be
> eligible for GUP-fast regardless of whether the folio is file-backed or
> not.
Ok, I'll leave it as is for now.
>
>> Something to ponder about :)
>>
>> --
>> Cheers,
>>
>> David
^ permalink raw reply
* Re: [PATCH v11 04/16] mm/gup: drop secretmem optimization from gup_fast_folio_allowed
From: Nikita Kalyazin @ 2026-04-10 15:27 UTC (permalink / raw)
To: David Hildenbrand (Arm), Kalyazin, Nikita, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
ackerleytng@google.com, yosry@kernel.org, ajones@ventanamicro.com,
maobibo@loongson.cn, tabba@google.com, prsampat@amd.com,
wu.fei9@sanechips.com.cn, mlevitsk@redhat.com,
jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek, Vlastimil Babka, Dan Williams, Alistair Popple
In-Reply-To: <76f14d3e-c8fb-4380-9d12-2375f199b53f@kernel.org>
On 23/03/2026 18:31, David Hildenbrand (Arm) wrote:
> On 3/17/26 15:11, Kalyazin, Nikita wrote:
>> From: Patrick Roy <patrick.roy@linux.dev>
>>
>> This drops an optimization in gup_fast_folio_allowed() where
>> secretmem_mapping() was only called if CONFIG_SECRETMEM=y. secretmem is
>> enabled by default since commit b758fe6df50d ("mm/secretmem: make it on
>> by default"), so the secretmem check did not actually end up elided in
>> most cases anymore anyway.
>>
>> This is in preparation of the generalization of handling mappings where
>> direct map entries of folios are set to not present. Currently,
>> mappings that match this description are secretmem mappings
>> (memfd_secret()). Later, some guest_memfd configurations will also fall
>> into this category.
>>
>> Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
>> Acked-by: Vlastimil Babka <vbabka@suse.cz>
>> Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
>> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
>> ---
>> mm/gup.c | 11 +----------
>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index 8e7dc2c6ee73..5856d35be385 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -2739,7 +2739,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>> {
>> bool reject_file_backed = false;
>> struct address_space *mapping;
>> - bool check_secretmem = false;
>> unsigned long mapping_flags;
>>
>> /*
>> @@ -2751,14 +2750,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>> reject_file_backed = true;
>>
>> /* We hold a folio reference, so we can safely access folio fields. */
>> -
>> - /* secretmem folios are always order-0 folios. */
>> - if (IS_ENABLED(CONFIG_SECRETMEM) && !folio_test_large(folio))
>> - check_secretmem = true;
>> -
>> - if (!reject_file_backed && !check_secretmem)
>> - return true;
>> -
>
> The AI review says that this will force all small folios through the
> mapping check (which we obviously need later :) ).
>
> It brings up two cases where page->mapping is not set up:
>
> 1) ZONE_DEVICE pages (like Device DAX and PCI P2PDMA)
>
> 2) large shmem folios in the swap cache
>
>
> 2) doesn't make sense, because the folio cannot be mapped in user space
> when that happens.
>
> I am also skeptical about 1), especially as large folios are also
> supported for device dax and would be problematic here.
> __dev_dax_pte_fault() clearly sets folio->mapping through dax_set_mapping().
>
>
> If 1) is ever a case we could allow them by checking for
> folio_is_zone_device(). But I am not sure if that is really required.
> Sounds weird.
I went ahead and added a check for folio_is_zone_device().
>
>
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH v11 03/16] mm/secretmem: make use of folio_{zap, restore}_direct_map
From: Nikita Kalyazin @ 2026-04-10 15:26 UTC (permalink / raw)
To: Ackerley Tng, Kalyazin, Nikita, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <CAEvNRgEBdi49ZkfGo0xmM+J1yzKOzfT2ThAXEN=S0j7vC7Fu3w@mail.gmail.com>
On 23/03/2026 18:46, Ackerley Tng wrote:
> "Kalyazin, Nikita" <kalyazin@amazon.co.uk> writes:
>
>> From: Nikita Kalyazin <kalyazin@amazon.com>
>>
>> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
>> ---
>> mm/secretmem.c | 8 ++------
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/mm/secretmem.c b/mm/secretmem.c
>> index fd29b33c6764..27b176af8fc4 100644
>> --- a/mm/secretmem.c
>> +++ b/mm/secretmem.c
>> @@ -53,7 +53,6 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
>> struct inode *inode = file_inode(vmf->vma->vm_file);
>> pgoff_t offset = vmf->pgoff;
>> gfp_t gfp = vmf->gfp_mask;
>> - unsigned long addr;
>> struct folio *folio;
>> vm_fault_t ret;
>> int err;
>> @@ -72,7 +71,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
>> goto out;
>> }
>>
>> - err = set_direct_map_invalid_noflush(folio_address(folio));
>> + err = folio_zap_direct_map(folio);
>> if (err) {
>> folio_put(folio);
>> ret = vmf_error(err);
>> @@ -87,7 +86,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
>> * already happened when we marked the page invalid
>> * which guarantees that this call won't fail
>> */
>> - set_direct_map_default_noflush(folio_address(folio));
>> + folio_restore_direct_map(folio);
>> folio_put(folio);
>> if (err == -EEXIST)
>> goto retry;
>> @@ -95,9 +94,6 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
>> ret = vmf_error(err);
>> goto out;
>> }
>> -
>> - addr = (unsigned long)folio_address(folio);
>> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>> }
>>
>> vmf->page = folio_file_page(folio, vmf->pgoff);
>> --
>> 2.50.1
>
> Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox