* Re: [PATCH 9/9] pmdomain: renesas: rmobile-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Ulf Hansson @ 2026-03-20 10:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAMuHMdUK+xePxZc-OXRfDmvQ1v4q5d=HQ9c9aNqUg7gPAMxUAA@mail.gmail.com>
On Fri, 20 Mar 2026 at 10:37, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ulf,
>
> Thanks for your patch!
>
> On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > Due to the new fine grained sync_state support for onecell genpd provider
> > drivers, we should no longer need use the legacy behaviour. Therefore,
> > let's drop GENPD_FLAG_NO_STAY_ON.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Rmobile-sysc is not a onecell provider, and thus never needed this flag.
I see, thanks for clarifying. I will update the commit message to
reflect this properly.
> Regardless:
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
Thanks!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v6 3/4] cpufreq: Set policy->min and max as real QoS constraints
From: Viresh Kumar @ 2026-03-20 10:14 UTC (permalink / raw)
To: Pierre Gondois
Cc: linux-kernel, Jie Zhan, Lifeng Zheng, Ionela Voinescu,
Sumit Gupta, Huang Rui, Gautham R. Shenoy, Mario Limonciello,
Perry Yuan, Rafael J. Wysocki, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm
In-Reply-To: <20260317101753.2284763-4-pierre.gondois@arm.com>
On 17-03-26, 11:17, Pierre Gondois wrote:
> cpufreq_set_policy() will ultimately override the policy min/max
> values written in the .init() callback through:
> cpufreq_policy_online()
> \-cpufreq_init_policy()
> \-cpufreq_set_policy()
> \-/* Set policy->min/max */
> Thus the policy min/max values provided are only temporary.
I am not comfortable with this patch to be honest. policy->min/max are used at
so many places that it is really difficult to make sure if this patch will break
something or not.
For example:
cpufreq_set_policy()
cpufreq_driver->verify()
cpufreq_frequency_table_verify()
This uses min/max before it is set by the path you mentioned.
I would suggest dropping this change, or most of it and doing only what is
really required for this series.
--
viresh
^ permalink raw reply
* Re: [PATCH 4/9] pmdomain: core: Add initial fine grained sync_state support
From: Ulf Hansson @ 2026-03-20 10:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAMuHMdVZknduohmhed4dFBtXuSEowmfCJ=C8HeuCGXsCsvFyWQ@mail.gmail.com>
On Fri, 20 Mar 2026 at 10:29, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ulf,
>
> Thanks for your patch!
>
> On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > A onecell (#power-domain-cells = <1 or 2>; in DT) power domain provider
> > typically provides multiple independent power domains, each with their own
> > corresponding consumers. In these cases we have to wait for all consumers
> > for all the provided power domains before the ->sync_state() callback gets
> > called for the supplier.
> >
> > In a first step to improve this, let's implement support for fine grained
> > sync_state support a per genpd basis by using the ->queue_sync_state()
>
> ... support on a ...
>
> > callback. To take step by step, let's initially limit the improvement to
> > the internal genpd provider driver and to its corresponding genpd devices
> > for onecell providers.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> > --- a/drivers/pmdomain/core.c
> > +++ b/drivers/pmdomain/core.c
>
> > +static void genpd_queue_sync_state(struct device *dev)
> > +{
> > + struct device_node *np = dev->of_node;
> > + struct device_link *link;
> > +
> > + if (!genpd_should_wait_for_consumer(np))
> > + return;
> > +
> > + list_for_each_entry(link, &dev->links.consumers, s_node) {
> > + struct device *consumer = link->consumer;
> > +
> > + pr_info("%s:%s con=%s\n", __func__, dev_name(dev),
> > + dev_name(consumer));
>
> pr_debug? Or better, dev_dbg(), so you don't have to add dev_name(dev)
> explicitly.
>
> However, the printed provider name is again the name of the first
> domain. This is incorrect for all but the first domain of a onecell
> genpd provider, and thus confusing.
I agree, I think we should drop the print. In fact, this is a
left-over from my debugging, I didn't intend for it to be part of the
submission.
Although, perhaps there is a need for pr_debug/dev_dbg somewhere, but
I think we can better add those in separate patches on top instead.
>
> > +
> > + if (!device_link_test(link, DL_FLAG_MANAGED))
> > + continue;
> > +
> > + if (link->status == DL_STATE_ACTIVE)
> > + continue;
> > +
> > + if (!consumer->of_node)
> > + continue;
> > +
> > + /*
> > + * A consumer device has not been probed yet. Let's parse its
> > + * device node for the power-domains property, to find out the
> > + * genpds it may belong to and then prevent sync state for them.
> > + */
> > + genpd_parse_for_consumer(np, consumer->of_node);
> > + }
> > +
> > + _genpd_queue_sync_state(np);
> > +}
> > +
> > static void genpd_sync_state(struct device *dev)
> > {
> > return of_genpd_sync_state(dev->of_node);
>
Thanks for reviewing!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v6 1/4] cpufreq: Remove per-CPU QoS constraint
From: zhenglifeng (A) @ 2026-03-20 10:04 UTC (permalink / raw)
To: Pierre Gondois, Viresh Kumar
Cc: linux-kernel, Jie Zhan, Ionela Voinescu, Sumit Gupta, Huang Rui,
Gautham R. Shenoy, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm
In-Reply-To: <ad23c89f-776e-4788-88ee-08583c0aadaf@arm.com>
On 3/19/2026 5:30 PM, Pierre Gondois wrote:
>
> On 3/18/26 12:13, Viresh Kumar wrote:
>> On 17-03-26, 11:17, Pierre Gondois wrote:
>>> policy->max_freq_req represents the maximum allowed frequency as
>>> requested by the policyX/scaling_max_freq sysfs file. This request
>>> applies to all CPUs of the policy. It is not possible to request
>>> a per-CPU maximum frequency.
>>>
>>> Thus, the interaction between the policy boost and scaling_max_freq
>>> settings should be handled by adding a boost specific QoS constraint.
>>> This will be handled in the following patches.
>> I don't think the above is required anymore. This patch is removing stale code
>> now which isn't useful anymore. It has nothing to do with a boost specific QOS
>> constraint.
> Yes ok
>> And it would be better to know for sure why this isn't required anymore and
>> which patch exactly fixed this issue.
>>
> On a kernel based on 1608f0230510~, and replicating the
> process described in the commit message of
>
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")
>
> I could not see any issue regarding the values of:
>
> - policy1/cpuinfo_max_freq
> - policy1/scaling_max_freq
>
> The following sequence however had an issue:
>
> 1. echo 0 > /sys/devices/system/cpu/cpu1/online
> 2. echo 1 > /sys/devices/system/cpu/cpufreq/boost
> 3. echo 1 > /sys/devices/system/cpu/cpu1/online
>
> as after 1.:
>
> cpufreq_boost_trigger_state()
> \-for_each_active_policy()
>
> doesn't enable boost for inactive policies. This leads to
> CPU1 having the non-boosted frequency as its max freq.
>
> The above sequence is fixed by:
>
> commit a153c6049ab8 ("cpufreq: Introduce a more
> generic way to set default per-policy boost flag")
Yes, I think this commit fixed the issue but I didn't realize it before so
I sent them both. 😂
>
> ---
>
> @Lifeng, should I check something else than the value of:
>
> - policy1/cpuinfo_max_freq
> - policy1/scaling_max_freq
>
> in order to reproduce the issue fixed by:
>
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")
>
> ?
>
>
>
^ permalink raw reply
* Re: [PATCH V2] cpufreq: conservative: Reset requested_freq on limits change
From: Zhongqiu Han @ 2026-03-20 10:02 UTC (permalink / raw)
To: Viresh Kumar, Rafael J. Wysocki
Cc: linux-pm, Vincent Guittot, Sumit Semwal, Lifeng Zheng,
linux-kernel, zhongqiu.han
In-Reply-To: <d846a141a98ac0482f20560fcd7525c0f0ec2f30.1773999467.git.viresh.kumar@linaro.org>
On 3/20/2026 5:38 PM, Viresh Kumar wrote:
> A recently reported issue highlighted that the cached requested_freq
> is not guaranteed to stay in sync with policy->cur. If the platform
> changes the actual CPU frequency after the governor sets one (e.g.
> due to platform-specific frequency scaling) and a re-sync occurs
> later, policy->cur may diverge from requested_freq.
>
> This can lead to incorrect behavior in the conservative governor.
> For example, the governor may assume the CPU is already running at
> the maximum frequency and skip further increases even though there
> is still headroom.
>
> Avoid this by resetting the cached requested_freq to policy->cur on
> detecting a change in policy limits.
>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> Reported-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> Tested-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> Link: https://lore.kernel.org/all/20260210115458.3493646-1-zhenglifeng1@huawei.com/
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> [v2]
> - Completely different design to solve the problem.
>
> drivers/cpufreq/cpufreq_conservative.c | 12 ++++++++++++
> drivers/cpufreq/cpufreq_governor.c | 3 +++
> drivers/cpufreq/cpufreq_governor.h | 1 +
> 3 files changed, 16 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
> index e0e847764511..df01d33993d8 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -313,6 +313,17 @@ static void cs_start(struct cpufreq_policy *policy)
> dbs_info->requested_freq = policy->cur;
> }
>
> +static void cs_limits(struct cpufreq_policy *policy)
> +{
> + struct cs_policy_dbs_info *dbs_info = to_dbs_info(policy->governor_data);
> +
> + /*
> + * The limits have changed, so may have the current frequency. Reset
> + * requested_freq to avoid any unintended outcomes due to the mismatch.
> + */
> + dbs_info->requested_freq = policy->cur;
> +}
> +
> static struct dbs_governor cs_governor = {
> .gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"),
> .kobj_type = { .default_groups = cs_groups },
> @@ -322,6 +333,7 @@ static struct dbs_governor cs_governor = {
> .init = cs_init,
> .exit = cs_exit,
> .start = cs_start,
> + .limits = cs_limits,
> };
>
> #define CPU_FREQ_GOV_CONSERVATIVE (cs_governor.gov)
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index 36eb7aee4bcd..acf101878733 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -563,6 +563,7 @@ EXPORT_SYMBOL_GPL(cpufreq_dbs_governor_stop);
>
> void cpufreq_dbs_governor_limits(struct cpufreq_policy *policy)
> {
> + struct dbs_governor *gov = dbs_governor_of(policy);
> struct policy_dbs_info *policy_dbs;
>
> /* Protect gov->gdbs_data against cpufreq_dbs_governor_exit() */
> @@ -574,6 +575,8 @@ void cpufreq_dbs_governor_limits(struct cpufreq_policy *policy)
> mutex_lock(&policy_dbs->update_mutex);
> cpufreq_policy_apply_limits(policy);
> gov_update_sample_delay(policy_dbs, 0);
> + if (gov->limits)
> + gov->limits(policy);
> mutex_unlock(&policy_dbs->update_mutex);
>
> out:
> diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
> index 168c23fd7fca..1462d59277bd 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -138,6 +138,7 @@ struct dbs_governor {
> int (*init)(struct dbs_data *dbs_data);
> void (*exit)(struct dbs_data *dbs_data);
> void (*start)(struct cpufreq_policy *policy);
> + void (*limits)(struct cpufreq_policy *policy);
> };
>
> static inline struct dbs_governor *dbs_governor_of(struct cpufreq_policy *policy)
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* [PATCH] cpufreq: acpi-cpufreq: use DMI max speed when CPPC is unavailable
From: Henry Tseng @ 2026-03-20 9:56 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Len Brown, linux-pm, linux-acpi, SW Chen, Kevin Ko, Henry Tseng
On AMD Ryzen Embedded V1780B (Family 17h, Zen 1), the BIOS does not
provide ACPI _CPC objects and the CPU does not support MSR-based CPPC
(X86_FEATURE_CPPC). The _PSS table only lists nominal P-states
(P0 = 3350 MHz), so when get_max_boost_ratio() fails at
cppc_get_perf_caps(), cpuinfo_max_freq reports only the base frequency
instead of the rated boost frequency (3600 MHz).
dmesg:
ACPI CPPC: No CPC descriptor for CPU:0
acpi_cpufreq: CPU0: Unable to get performance capabilities (-19)
cppc-cpufreq already has a DMI fallback (cppc_get_dmi_max_khz()) that
reads the processor max speed from SMBIOS Type 4. Export it and reuse
it in acpi-cpufreq as a last-resort source for the boost frequency.
A sanity check ensures the DMI value is above the _PSS P0 frequency
and within 2x of it; values outside that range are ignored and the
existing arch_set_max_freq_ratio() path is taken instead. The 2x
upper bound is based on a survey of the AMD Ryzen Embedded V1000
series, where the highest boost-to-base ratio is 1.8x (V1404I:
2.0 GHz base / 3.6 GHz boost).
Tested on AMD Ryzen Embedded V1780B with v7.0-rc4:
Before: cpuinfo_max_freq = 3350000 (base only)
After: cpuinfo_max_freq = 3600000 (includes boost)
Link: https://www.amd.com/en/products/embedded/ryzen/ryzen-v1000-series.html#specifications
Signed-off-by: Henry Tseng <henrytseng@qnap.com>
---
drivers/acpi/cppc_acpi.c | 3 ++-
drivers/cpufreq/acpi-cpufreq.c | 21 ++++++++++++++++-----
include/acpi/cppc_acpi.h | 1 +
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index f0e513e9ed5d..f53de414acf2 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -1944,7 +1944,7 @@ static void cppc_find_dmi_mhz(const struct dmi_header *dm, void *private)
}
/* Look up the max frequency in DMI */
-static u64 cppc_get_dmi_max_khz(void)
+u64 cppc_get_dmi_max_khz(void)
{
u16 mhz = 0;
@@ -1958,6 +1958,7 @@ static u64 cppc_get_dmi_max_khz(void)
return KHZ_PER_MHZ * mhz;
}
+EXPORT_SYMBOL_GPL(cppc_get_dmi_max_khz);
/*
* If CPPC lowest_freq and nominal_freq registers are exposed then we can
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index e7eff6c2f092..9b4638ad27ba 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -849,13 +849,24 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
policy->cpuinfo.max_freq = freq * max_boost_ratio >> SCHED_CAPACITY_SHIFT;
} else {
+#ifdef CONFIG_ACPI_CPPC_LIB
+ unsigned int freq = freq_table[0].frequency;
+ u64 max_speed = cppc_get_dmi_max_khz();
/*
- * If the maximum "boost" frequency is unknown, ask the arch
- * scale-invariance code to use the "nominal" performance for
- * CPU utilization scaling so as to prevent the schedutil
- * governor from selecting inadequate CPU frequencies.
+ * Use DMI "Max Speed" if it looks plausible: must be
+ * above _PSS P0 frequency and within 2x of it.
*/
- arch_set_max_freq_ratio(true);
+ if (max_speed > freq && max_speed < freq * 2)
+ policy->cpuinfo.max_freq = max_speed;
+ else
+#endif
+ /*
+ * If the maximum "boost" frequency is unknown, ask the arch
+ * scale-invariance code to use the "nominal" performance for
+ * CPU utilization scaling so as to prevent the schedutil
+ * governor from selecting inadequate CPU frequencies.
+ */
+ arch_set_max_freq_ratio(true);
}
policy->freq_table = freq_table;
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index 4d644f03098e..e6c5ef3173c5 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -156,6 +156,7 @@ extern int cppc_set_enable(int cpu, bool enable);
extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
extern bool cppc_perf_ctrs_in_pcc_cpu(unsigned int cpu);
extern bool cppc_perf_ctrs_in_pcc(void);
+extern u64 cppc_get_dmi_max_khz(void);
extern unsigned int cppc_perf_to_khz(struct cppc_perf_caps *caps, unsigned int perf);
extern unsigned int cppc_khz_to_perf(struct cppc_perf_caps *caps, unsigned int freq);
extern bool acpi_cpc_valid(void);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 0/3] Fix swapoff race and cleanup in hibernation swap path
From: YoungJun Park @ 2026-03-20 9:49 UTC (permalink / raw)
To: Andrew Morton
Cc: rafael, chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
usama.arif, linux-mm, linux-pm
In-Reply-To: <20260319195032.5c3b187d5779cf43cd63fcd0@linux-foundation.org>
On Thu, Mar 19, 2026 at 07:50:32PM -0700, Andrew Morton wrote:
> On Thu, 19 Mar 2026 23:24:01 +0900 Youngjun Park <youngjun.park@lge.com> wrote:
>
> > Currently, in the uswsusp path, only the swap type value is retrieved at
> > lookup time without holding a reference. If swapoff races after the type
> > is acquired, subsequent slot allocations operate on a stale swap device.
> >
> > Additionally, grabbing and releasing the swap device reference on every
> > slot allocation is inefficient across the entire hibernation swap path.
>
> AI review has questions:
> https://sashiko.dev/#/patchset/20260319142404.3683019-1-youngjun.park%40lge.com
Hi Andrew,
Thanks for sharing the AI review. Some comments are indeed good catches.
patch 2 comments are wrong.
patch 3 comments are right.
Regarding patch 2, the AI review raised the following concerns:
> If this race occurs, swapoff clears SWP_WRITEOK and calls try_to_unuse()
> to scan and evict swap slots. Without the SWP_WRITEOK check here, it
> looks like uswsusp could successfully allocate slots while
> try_to_unuse() is actively scanning.
Right. but..
> If try_to_unuse() encounters these newly allocated slots, wouldn't it
> attempt to page them in and subsequently free them via
> folio_free_swap()?
I believe this concern is not valid.
swapoff calls try_to_unuse(), which scans swap_map[] entries:
(this logic is slightly different from each kerenl version but, fundamental is same)
...
for (i = prev + 1; i < si->max; i++) {
count = READ_ONCE(si->swap_map[i]);
if (count && swap_count(count) != SWAP_MAP_BAD)
break;
}
...
However, hibernation allocations marked with SWAP_HAS_CACHE are not
visible via this swap_map[] scanning logic, so they cannot be found
or reclaimed in that path.
As a result swapoff keeps retrying while swap_usage_in_pages(si) is
non-zero until user signal is delivered., rather than freeing those entrie.
I will also verify this behavior at runtime to be absolutely sure.
For patch 3, I agree with the comment and have responded in Rafael’s
thread.
I will update the series shortly.
Thanks,
Youngjun Park
^ permalink raw reply
* Re: [PATCH/RFC] PM: domains: Call pm_runtime_barrier() before dev_pm_domain_{attach*,detach}()
From: Geert Uytterhoeven @ 2026-03-20 9:47 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rafael J . Wysocki, Pavel Machek, Len Brown, Greg Kroah-Hartman,
Danilo Krummrich, Frank Binns, Matt Coster, Marek Vasut, linux-pm,
driver-core, linux-renesas-soc, linux-kernel
In-Reply-To: <CAPDyKFrMtsp5tRSAOx=ytfQ0xSONtRbC24gq2v4QdSh2wWSw1A@mail.gmail.com>
Hi Ulf,
On Thu, 19 Mar 2026 at 11:59, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Thu, 12 Mar 2026 at 10:54, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > If a device has multiple PM Domains, dev_pm_domain_detach() is called
> > multiple times on unbind or probe failure. If the PM Domain is also a
> > Clock Domain, and thus calls pm_clk_destroy() from its .detach()
> > callback, dev_pm_put_subsys_data() will set dev->power.subsys_data to
> > NULL when psd->refcount reaches zero.
> >
> > Later/in parallel, default_suspend_ok() calls dev_gpd_data():
> >
> > static inline struct generic_pm_domain_data *dev_gpd_data(struct device *dev)
> > {
> > return to_gpd_data(dev->power.subsys_data->domain_data);
> > }
> >
> > which may trigger a NULL pointer dereference.
> >
> > All dev_pm_domain_{at,de}tach*() functions document that callers must
> > ensure proper synchronization of these functions with power management
> > callbacks. Unfortunately no callers seem to actually do so. This
> > includes dev_pm_domain_attach_list() and dev_pm_domain_detach_list():
> > they call dev_pm_domain_{attach*,detach}() internally, which means they
> > should take care of this synchronization themselves.
> >
> > Add synchronization to dev_pm_domain_{at,de}tach_list() by calling
> > pm_runtime_barrier() before dev_pm_domain_{attach*,detach}(), and drop
> > the now obsolete comments.
>
> My apologies for not being able to respond earlier to your
> suggestions/questions. I have started looking into this now, and I
> will follow up with more replies and perhaps a patch shortly.
>
> Anyway, the principle is that callers of dev_pm_domain_detach() must
> manage the runtime PM enabling/disabling for its device. If runtime PM
> was enabled, it must typically be disabled before calling
> dev_pm_domain_detach().
>
> What makes this a bit more complicated is that we have two different
> scenarious to consider.
>
> 1) The legacy case, attachment via dev_pm_domain_attach() for the
> single PM domain case. Runtime PM should be enabled/disabled for the
> device, from its corresponding driver/bus. I assume this isn't the
> problem you are facing, right?
No, this is not the problem I am facing.
> 2) Attachment via dev_pm_domain_attach_by_id|name() (which is called
> for the *attach_list() case too), for the single/multi PM domain
> cases. In these cases, runtime PM is enabled in
> genpd_dev_pm_attach_by_id().
>
> For 2), I am inclined to think that the proper action is to call
> pm_runtime_disable() in genpd_dev_pm_detach() before it calls
> genpd_remove_device(). Although, I need to check more closely how
> suitable that would be.
Thanks, that sounds reasonable: genpd_dev_pm_attach_by_id() calls
pm_runtime_enable(), but there is no pm_runtime_disable() call to
balance that...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/9] driver core / pmdomain: Add support for fined grained sync_state
From: Geert Uytterhoeven @ 2026-03-20 9:39 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260303132305.438657-1-ulf.hansson@linaro.org>
Hi Ulf,
On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Since the introduction [1] of the common sync_state support for pmdomains
> (genpd), we have encountered a lot of various interesting problems. In most
> cases the new behaviour of genpd triggered some weird platform specific bugs.
>
> That said, in LPC in Tokyo me and Saravana hosted a session to walk through the
> remaining limitations that we have found for genpd's sync state support. In
> particular, we discussed the problems we have for the so-called onecell power
> domain providers, where a single provider typically provides multiple
> independent power domains, all with their own set of consumers.
>
> In these cases, the generic sync_state mechanism with fw_devlink isn't fine
> grained enough, as we end up waiting for all consumers for all power domains
> before the ->sync_callback gets called for the supplier/provider. In other
> words, we may end up keeping unused power domains powered-on, for no good
> reasons.
>
> The series intends to fix this problem. Please have a look at the commit
> messages for more details.
Thanks for your series!
I gave it a try on various R-Car and R/SH-Mobile platforms, and all
PM Domains are handled fine.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V2] cpufreq: conservative: Reset requested_freq on limits change
From: Viresh Kumar @ 2026-03-20 9:38 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: linux-pm, Vincent Guittot, Sumit Semwal, Lifeng Zheng,
linux-kernel
A recently reported issue highlighted that the cached requested_freq
is not guaranteed to stay in sync with policy->cur. If the platform
changes the actual CPU frequency after the governor sets one (e.g.
due to platform-specific frequency scaling) and a re-sync occurs
later, policy->cur may diverge from requested_freq.
This can lead to incorrect behavior in the conservative governor.
For example, the governor may assume the CPU is already running at
the maximum frequency and skip further increases even though there
is still headroom.
Avoid this by resetting the cached requested_freq to policy->cur on
detecting a change in policy limits.
Reported-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Tested-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Link: https://lore.kernel.org/all/20260210115458.3493646-1-zhenglifeng1@huawei.com/
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
[v2]
- Completely different design to solve the problem.
drivers/cpufreq/cpufreq_conservative.c | 12 ++++++++++++
drivers/cpufreq/cpufreq_governor.c | 3 +++
drivers/cpufreq/cpufreq_governor.h | 1 +
3 files changed, 16 insertions(+)
diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index e0e847764511..df01d33993d8 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -313,6 +313,17 @@ static void cs_start(struct cpufreq_policy *policy)
dbs_info->requested_freq = policy->cur;
}
+static void cs_limits(struct cpufreq_policy *policy)
+{
+ struct cs_policy_dbs_info *dbs_info = to_dbs_info(policy->governor_data);
+
+ /*
+ * The limits have changed, so may have the current frequency. Reset
+ * requested_freq to avoid any unintended outcomes due to the mismatch.
+ */
+ dbs_info->requested_freq = policy->cur;
+}
+
static struct dbs_governor cs_governor = {
.gov = CPUFREQ_DBS_GOVERNOR_INITIALIZER("conservative"),
.kobj_type = { .default_groups = cs_groups },
@@ -322,6 +333,7 @@ static struct dbs_governor cs_governor = {
.init = cs_init,
.exit = cs_exit,
.start = cs_start,
+ .limits = cs_limits,
};
#define CPU_FREQ_GOV_CONSERVATIVE (cs_governor.gov)
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 36eb7aee4bcd..acf101878733 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -563,6 +563,7 @@ EXPORT_SYMBOL_GPL(cpufreq_dbs_governor_stop);
void cpufreq_dbs_governor_limits(struct cpufreq_policy *policy)
{
+ struct dbs_governor *gov = dbs_governor_of(policy);
struct policy_dbs_info *policy_dbs;
/* Protect gov->gdbs_data against cpufreq_dbs_governor_exit() */
@@ -574,6 +575,8 @@ void cpufreq_dbs_governor_limits(struct cpufreq_policy *policy)
mutex_lock(&policy_dbs->update_mutex);
cpufreq_policy_apply_limits(policy);
gov_update_sample_delay(policy_dbs, 0);
+ if (gov->limits)
+ gov->limits(policy);
mutex_unlock(&policy_dbs->update_mutex);
out:
diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
index 168c23fd7fca..1462d59277bd 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -138,6 +138,7 @@ struct dbs_governor {
int (*init)(struct dbs_data *dbs_data);
void (*exit)(struct dbs_data *dbs_data);
void (*start)(struct cpufreq_policy *policy);
+ void (*limits)(struct cpufreq_policy *policy);
};
static inline struct dbs_governor *dbs_governor_of(struct cpufreq_policy *policy)
--
2.31.1.272.g89b43f80a514
^ permalink raw reply related
* Re: [PATCH 9/9] pmdomain: renesas: rmobile-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Geert Uytterhoeven @ 2026-03-20 9:37 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260303132305.438657-10-ulf.hansson@linaro.org>
Hi Ulf,
Thanks for your patch!
On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Due to the new fine grained sync_state support for onecell genpd provider
> drivers, we should no longer need use the legacy behaviour. Therefore,
> let's drop GENPD_FLAG_NO_STAY_ON.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Rmobile-sysc is not a onecell provider, and thus never needed this flag.
Regardless:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 8/9] pmdomain: renesas: rcar-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Geert Uytterhoeven @ 2026-03-20 9:31 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260303132305.438657-9-ulf.hansson@linaro.org>
On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Due to the new fine grained sync_state support for onecell genpd provider
> drivers, we should no longer need use the legacy behaviour. Therefore,
> let's drop GENPD_FLAG_NO_STAY_ON.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 7/9] pmdomain: renesas: rcar-gen4-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Geert Uytterhoeven @ 2026-03-20 9:31 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260303132305.438657-8-ulf.hansson@linaro.org>
On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Due to the new fine grained sync_state support for onecell genpd provider
> drivers, we should no longer need use the legacy behaviour. Therefore,
> let's drop GENPD_FLAG_NO_STAY_ON.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/9] pmdomain: core: Move genpd_get_from_provider()
From: Geert Uytterhoeven @ 2026-03-20 9:30 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260303132305.438657-4-ulf.hansson@linaro.org>
On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> To prepare for subsequent changes and to avoid an unnecessary function
> declaration, let's move genpd_get_from_provider() a bit earlier in the
> code.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/9] pmdomain: core: Add initial fine grained sync_state support
From: Geert Uytterhoeven @ 2026-03-20 9:29 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260303132305.438657-5-ulf.hansson@linaro.org>
Hi Ulf,
Thanks for your patch!
On Tue, 3 Mar 2026 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> A onecell (#power-domain-cells = <1 or 2>; in DT) power domain provider
> typically provides multiple independent power domains, each with their own
> corresponding consumers. In these cases we have to wait for all consumers
> for all the provided power domains before the ->sync_state() callback gets
> called for the supplier.
>
> In a first step to improve this, let's implement support for fine grained
> sync_state support a per genpd basis by using the ->queue_sync_state()
... support on a ...
> callback. To take step by step, let's initially limit the improvement to
> the internal genpd provider driver and to its corresponding genpd devices
> for onecell providers.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> --- a/drivers/pmdomain/core.c
> +++ b/drivers/pmdomain/core.c
> +static void genpd_queue_sync_state(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct device_link *link;
> +
> + if (!genpd_should_wait_for_consumer(np))
> + return;
> +
> + list_for_each_entry(link, &dev->links.consumers, s_node) {
> + struct device *consumer = link->consumer;
> +
> + pr_info("%s:%s con=%s\n", __func__, dev_name(dev),
> + dev_name(consumer));
pr_debug? Or better, dev_dbg(), so you don't have to add dev_name(dev)
explicitly.
However, the printed provider name is again the name of the first
domain. This is incorrect for all but the first domain of a onecell
genpd provider, and thus confusing.
> +
> + if (!device_link_test(link, DL_FLAG_MANAGED))
> + continue;
> +
> + if (link->status == DL_STATE_ACTIVE)
> + continue;
> +
> + if (!consumer->of_node)
> + continue;
> +
> + /*
> + * A consumer device has not been probed yet. Let's parse its
> + * device node for the power-domains property, to find out the
> + * genpds it may belong to and then prevent sync state for them.
> + */
> + genpd_parse_for_consumer(np, consumer->of_node);
> + }
> +
> + _genpd_queue_sync_state(np);
> +}
> +
> static void genpd_sync_state(struct device *dev)
> {
> return of_genpd_sync_state(dev->of_node);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 1/4] cpufreq: Remove per-CPU QoS constraint
From: Viresh Kumar @ 2026-03-20 9:25 UTC (permalink / raw)
To: Pierre Gondois
Cc: Lifeng Zheng, linux-kernel, Jie Zhan, Ionela Voinescu,
Sumit Gupta, Huang Rui, Gautham R. Shenoy, Mario Limonciello,
Perry Yuan, Rafael J. Wysocki, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm
In-Reply-To: <5ulxqpnblsbxhcg5m2rfscrvkokd43wwg5sihml4oytcsswh43@lqdwn5tqopf3>
On 20-03-26, 14:48, Viresh Kumar wrote:
> That change should be fixed with:
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 277884d91913..1f794524a1d9 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1427,12 +1427,9 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> * If there is a problem with its frequency table, take it
> * offline and drop it.
> */
> - if (policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_ASCENDING &&
> - policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_DESCENDING) {
> - ret = cpufreq_table_validate_and_sort(policy);
> - if (ret)
> - goto out_offline_policy;
> - }
> + ret = cpufreq_table_validate_and_sort(policy);
> + if (ret)
> + goto out_offline_policy;
>
> /* related_cpus should at least include policy->cpus. */
> cpumask_copy(policy->related_cpus, policy->cpus);
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index 7f251daf03ce..5b364d8da4f9 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -360,6 +360,10 @@ int cpufreq_table_validate_and_sort(struct cpufreq_policy *policy)
> if (policy_has_boost_freq(policy))
> policy->boost_supported = true;
>
> + if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING ||
> + policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_DESCENDING)
> + return 0;
> +
> return set_freq_table_sorted(policy);
> }
Posted as:
https://lore.kernel.org/all/65ba5c45749267c82e8a87af3dc788b37a0b3f48.1773998611.git.viresh.kumar@linaro.org/
--
viresh
^ permalink raw reply
* [PATCH] cpufreq: Don't skip cpufreq_frequency_table_cpuinfo()
From: Viresh Kumar @ 2026-03-20 9:24 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Zihuan Zhang
Cc: linux-pm, Vincent Guittot, Sumit Semwal, Pierre Gondois,
Lifeng Zheng, Rafael J. Wysocki, linux-kernel
The commit 6db0f533d320 ("cpufreq: preserve freq_table_sorted across
suspend/hibernate") unintentionally made a change where
cpufreq_frequency_table_cpuinfo() isn't getting called anymore for old
policies getting re-initialized.
This leads to potentially invalid values of policy->max and
policy->cpuinfo_max_freq.
Fix the issue by reverting the original commit and adding the condition
for just the sorting function.
Fixes: 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate")
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/cpufreq.c | 9 +++------
drivers/cpufreq/freq_table.c | 4 ++++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 277884d91913..1f794524a1d9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1427,12 +1427,9 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
* If there is a problem with its frequency table, take it
* offline and drop it.
*/
- if (policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_ASCENDING &&
- policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_DESCENDING) {
- ret = cpufreq_table_validate_and_sort(policy);
- if (ret)
- goto out_offline_policy;
- }
+ ret = cpufreq_table_validate_and_sort(policy);
+ if (ret)
+ goto out_offline_policy;
/* related_cpus should at least include policy->cpus. */
cpumask_copy(policy->related_cpus, policy->cpus);
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 7f251daf03ce..5b364d8da4f9 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -360,6 +360,10 @@ int cpufreq_table_validate_and_sort(struct cpufreq_policy *policy)
if (policy_has_boost_freq(policy))
policy->boost_supported = true;
+ if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING ||
+ policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_DESCENDING)
+ return 0;
+
return set_freq_table_sorted(policy);
}
--
2.31.1.272.g89b43f80a514
^ permalink raw reply related
* Re: [PATCH v6 1/4] cpufreq: Remove per-CPU QoS constraint
From: Viresh Kumar @ 2026-03-20 9:18 UTC (permalink / raw)
To: Pierre Gondois
Cc: Lifeng Zheng, linux-kernel, Jie Zhan, Ionela Voinescu,
Sumit Gupta, Huang Rui, Gautham R. Shenoy, Mario Limonciello,
Perry Yuan, Rafael J. Wysocki, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm
In-Reply-To: <ad23c89f-776e-4788-88ee-08583c0aadaf@arm.com>
On 19-03-26, 10:30, Pierre Gondois wrote:
>
> On 3/18/26 12:13, Viresh Kumar wrote:
> > On 17-03-26, 11:17, Pierre Gondois wrote:
> > > policy->max_freq_req represents the maximum allowed frequency as
> > > requested by the policyX/scaling_max_freq sysfs file. This request
> > > applies to all CPUs of the policy. It is not possible to request
> > > a per-CPU maximum frequency.
> > >
> > > Thus, the interaction between the policy boost and scaling_max_freq
> > > settings should be handled by adding a boost specific QoS constraint.
> > > This will be handled in the following patches.
> > I don't think the above is required anymore. This patch is removing stale code
> > now which isn't useful anymore. It has nothing to do with a boost specific QOS
> > constraint.
> Yes ok
> > And it would be better to know for sure why this isn't required anymore and
> > which patch exactly fixed this issue.
> >
> On a kernel based on 1608f0230510~, and replicating the
> process described in the commit message of
>
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")
>
> I could not see any issue regarding the values of:
>
> - policy1/cpuinfo_max_freq
> - policy1/scaling_max_freq
The commit message (of 1608f0230510) is confusing. The issue was discussed
properly in the following thread.
https://lore.kernel.org/all/20250120082723.am7rxujmdvzz4eky@vireshk-i7/
The problem is that policy->max and policy->cpuinfo_max_freq are incorrect after
the sequence mentioned in the commit, while max_freq_req is correct.
I think another commit has fixed that (incorrectly and unintentionally):
commit 6db0f533d320 ("cpufreq: preserve freq_table_sorted across suspend/hibernate")
@@ -1421,9 +1421,12 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
* If there is a problem with its frequency table, take it
* offline and drop it.
*/
- ret = cpufreq_table_validate_and_sort(policy);
- if (ret)
- goto out_offline_policy;
+ if (policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_ASCENDING &&
+ policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_DESCENDING) {
+ ret = cpufreq_table_validate_and_sort(policy);
+ if (ret)
+ goto out_offline_policy;
+ }
This skipped calling cpufreq_table_validate_and_sort() completely on online and
so max/cpuinfo_max_freq, max_freq_req are all in sync.
That change should be fixed with:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 277884d91913..1f794524a1d9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1427,12 +1427,9 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
* If there is a problem with its frequency table, take it
* offline and drop it.
*/
- if (policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_ASCENDING &&
- policy->freq_table_sorted != CPUFREQ_TABLE_SORTED_DESCENDING) {
- ret = cpufreq_table_validate_and_sort(policy);
- if (ret)
- goto out_offline_policy;
- }
+ ret = cpufreq_table_validate_and_sort(policy);
+ if (ret)
+ goto out_offline_policy;
/* related_cpus should at least include policy->cpus. */
cpumask_copy(policy->related_cpus, policy->cpus);
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 7f251daf03ce..5b364d8da4f9 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -360,6 +360,10 @@ int cpufreq_table_validate_and_sort(struct cpufreq_policy *policy)
if (policy_has_boost_freq(policy))
policy->boost_supported = true;
+ if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING ||
+ policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_DESCENDING)
+ return 0;
+
return set_freq_table_sorted(policy);
}
--
viresh
^ permalink raw reply related
* [PATCH] pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled
From: Jacky Bai @ 2026-03-20 8:43 UTC (permalink / raw)
To: Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Peng Fan
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Jacky Bai
Keep the NOC_HDCP clock always enabled to fix the potential hang
caused by the NoC ADB400 port power down handshake.
Fixes: 77b0ddb42add ("soc: imx: add i.MX8MP HDMI blk ctrl HDCP/HRV_MWR")
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
index 8fc79f9723f07e34fd3f5162f2c9c549dcdaeb5b..3f5b9499d30a0c8fb8ad8ba3b638d7de1fc55ab6 100644
--- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
@@ -352,9 +352,6 @@ static void imx8mp_hdmi_blk_ctrl_power_on(struct imx8mp_blk_ctrl *bc,
regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(12));
regmap_clear_bits(bc->regmap, HDMI_TX_CONTROL0, BIT(3));
break;
- case IMX8MP_HDMIBLK_PD_HDCP:
- regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(11));
- break;
case IMX8MP_HDMIBLK_PD_HRV:
regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(3) | BIT(4) | BIT(5));
regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(15));
@@ -408,9 +405,6 @@ static void imx8mp_hdmi_blk_ctrl_power_off(struct imx8mp_blk_ctrl *bc,
regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(7));
regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(22) | BIT(24));
break;
- case IMX8MP_HDMIBLK_PD_HDCP:
- regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL0, BIT(11));
- break;
case IMX8MP_HDMIBLK_PD_HRV:
regmap_clear_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(15));
regmap_clear_bits(bc->regmap, HDMI_RTX_CLK_CTL1, BIT(3) | BIT(4) | BIT(5));
@@ -439,7 +433,7 @@ static int imx8mp_hdmi_power_notifier(struct notifier_block *nb,
regmap_write(bc->regmap, HDMI_RTX_CLK_CTL0, 0x0);
regmap_write(bc->regmap, HDMI_RTX_CLK_CTL1, 0x0);
regmap_set_bits(bc->regmap, HDMI_RTX_CLK_CTL0,
- BIT(0) | BIT(1) | BIT(10));
+ BIT(0) | BIT(1) | BIT(10) | BIT(11));
regmap_set_bits(bc->regmap, HDMI_RTX_RESET_CTL0, BIT(0));
/*
---
base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
change-id: 20260122-imx8mp_hdmi_hang-e7c5b4bdf1bb
Best regards,
--
Jacky Bai <ping.bai@nxp.com>
^ permalink raw reply related
* Re: [PATCH v5 3/3] PM: hibernate: fix spurious GFP mask WARNING in uswsusp path
From: YoungJun Park @ 2026-03-20 8:18 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: akpm, chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
usama.arif, linux-mm, linux-pm
In-Reply-To: <CAJZ5v0i+KdG1FFTrrpt4fV_DDbY833yDzDs42Me7qmzxfCi73A@mail.gmail.com>
On Thu, Mar 19, 2026 at 08:55:43PM +0100, Rafael J. Wysocki wrote:
> On Thu, Mar 19, 2026 at 3:24 PM Youngjun Park <youngjun.park@lge.com> wrote:
> >
> > Commit 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask()
> > stacking") introduced refcount-based GFP mask management that warns
> > when pm_restore_gfp_mask() is called with saved_gfp_count == 0:
> >
> > WARNING: kernel/power/main.c:44 at pm_restore_gfp_mask+0xd7/0xf0
> > CPU: 0 UID: 0 PID: 373 Comm: s2disk
> > Call Trace:
> > snapshot_ioctl+0x964/0xbd0
> > __x64_sys_ioctl+0x724/0x1320
> > ...
> >
> > The uswsusp path calls pm_restore_gfp_mask() defensively in
> > SNAPSHOT_CREATE_IMAGE and SNAPSHOT_UNFREEZE where the GFP mask may
> > or may not be restricted depending on context (first call vs retry,
> > hibernate vs resume). Before the stacking patch this was a silent
> > no-op; now it triggers a WARNING.
> >
> > Introduce pm_restore_gfp_mask_safe() that skips the call when
> > saved_gfp_count is 0. This is preferred over tracking the restrict
> > state in snapshot_ioctl, as incorrect tracking risks leaving the
> > GFP mask permanently restricted.
> >
> > Fixes: 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask() stacking")
> > Signed-off-by: Youngjun Park <youngjun.park@lge.com>
> > ---
> > include/linux/suspend.h | 1 +
> > kernel/power/main.c | 7 +++++++
> > kernel/power/user.c | 4 ++--
> > 3 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> > index b02876f1ae38..7777931d88a5 100644
> > --- a/include/linux/suspend.h
> > +++ b/include/linux/suspend.h
> > @@ -454,6 +454,7 @@ extern void pm_report_hw_sleep_time(u64 t);
> > extern void pm_report_max_hw_sleep(u64 t);
> > void pm_restrict_gfp_mask(void);
> > void pm_restore_gfp_mask(void);
> > +void pm_restore_gfp_mask_safe(void);
> >
> > #define pm_notifier(fn, pri) { \
> > static struct notifier_block fn##_nb = \
> > diff --git a/kernel/power/main.c b/kernel/power/main.c
> > index 5f8c9e12eaec..e610a8c8b7ff 100644
> > --- a/kernel/power/main.c
> > +++ b/kernel/power/main.c
> > @@ -36,6 +36,13 @@
> > static unsigned int saved_gfp_count;
> > static gfp_t saved_gfp_mask;
> >
> > +void pm_restore_gfp_mask_safe(void)
> > +{
> > + if (!saved_gfp_count)
> > + return;
> > + pm_restore_gfp_mask();
> > +}
> > +
> > void pm_restore_gfp_mask(void)
> > {
> > WARN_ON(!mutex_is_locked(&system_transition_mutex));
> > diff --git a/kernel/power/user.c b/kernel/power/user.c
> > index 3e41544b99d5..41cff6a89a1c 100644
> > --- a/kernel/power/user.c
> > +++ b/kernel/power/user.c
> > @@ -306,7 +306,7 @@ static long snapshot_ioctl(struct file *filp, unsigned int cmd,
> > case SNAPSHOT_UNFREEZE:
> > if (!data->frozen || data->ready)
> > break;
> > - pm_restore_gfp_mask();
> > + pm_restore_gfp_mask_safe();
> > free_basic_memory_bitmaps();
> > data->free_bitmaps = false;
> > thaw_processes();
> > @@ -318,7 +318,7 @@ static long snapshot_ioctl(struct file *filp, unsigned int cmd,
> > error = -EPERM;
> > break;
> > }
> > - pm_restore_gfp_mask();
> > + pm_restore_gfp_mask_safe();
> > error = hibernation_snapshot(data->platform_support);
> > if (!error) {
> > error = put_user(in_suspend, (int __user *)arg);
> > --
>
> AFAICS, this patch doesn't depend on the rest of the series, so I can
> apply it separately unless there is a problem with that.
>
> However, for the other 2 patches in the series, I'd need some tags
> (preferably Reviewed-by) from mm people.
>
> Thanks!
Hi Rafael,
While double-checking the code based on Andrew’s AI-assisted review,
I noticed I missed one case.
If userspace issues SNAPSHOT_FREEZE and then closes the device,
snapshot_release() may call pm_restore_gfp_mask() without a matching
restriction, which reproduces the same WARN. So we should switch
snapshot_release() to pm_restore_gfp_mask_safe() as well.
Also, since the safe wrapper may return early when saved_gfp_count == 0,
the locking assertion would be skipped in that path. To preserve the
invariant, it is better to keep:
WARN_ON(!mutex_is_locked(&system_transition_mutex));
in the wrapper too.
This modification is intentional, but after review I think this is better.
I will update the patch and resend.
Best regards,
Youngjun park
^ permalink raw reply
* Re: [PATCH v3 1/1] writeback: don't block sync for filesystems with no data integrity guarantees
From: David Hildenbrand (Arm) @ 2026-03-20 8:12 UTC (permalink / raw)
To: Joanne Koong, brauner
Cc: linux-fsdevel, jack, miklos, therealgraysky, linux-pm, stable
In-Reply-To: <20260320005145.2483161-2-joannelkoong@gmail.com>
On 3/20/26 01:51, Joanne Koong wrote:
> Add a SB_I_NO_DATA_INTEGRITY superblock flag for filesystems that cannot
> guarantee data persistence on sync (eg fuse). For superblocks with this
> flag set, sync kicks off writeback of dirty inodes but does not wait
> for the flusher threads to complete the writeback.
>
> This replaces the per-inode AS_NO_DATA_INTEGRITY mapping flag added in
> commit f9a49aa302a0 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings
> in wait_sb_inodes()"). The flag belongs at the superblock level because
> data integrity is a filesystem-wide property, not a per-inode one.
> Having this flag at the superblock level also allows us to skip having
> to iterate every dirty inode in wait_sb_inodes() only to skip each inode
> individually.
>
> Prior to this commit, mappings with no data integrity guarantees skipped
> waiting on writeback completion but still waited on the flusher threads
> to finish initiating the writeback. Waiting on the flusher threads is
> unnecessary. This commit kicks off writeback but does not wait on the
> flusher threads. This change properly addresses a recent report [1] for
> a suspend-to-RAM hang seen on fuse-overlayfs that was caused by waiting
> on the flusher threads to finish:
>
> Workqueue: pm_fs_sync pm_fs_sync_work_fn
> Call Trace:
> <TASK>
> __schedule+0x457/0x1720
> schedule+0x27/0xd0
> wb_wait_for_completion+0x97/0xe0
> sync_inodes_sb+0xf8/0x2e0
> __iterate_supers+0xdc/0x160
> ksys_sync+0x43/0xb0
> pm_fs_sync_work_fn+0x17/0xa0
> process_one_work+0x193/0x350
> worker_thread+0x1a1/0x310
> kthread+0xfc/0x240
> ret_from_fork+0x243/0x280
> ret_from_fork_asm+0x1a/0x30
> </TASK>
>
> On fuse this is problematic because there are paths that may cause the
> flusher thread to block (eg if systemd freezes the user session cgroups
> first, which freezes the fuse daemon, before invoking the kernel
> suspend. The kernel suspend triggers ->write_node() which on fuse issues
> a synchronous setattr request, which cannot be processed since the
> daemon is frozen. Or if the daemon is buggy and cannot properly complete
> writeback, initiating writeback on a dirty folio already under writeback
> leads to writeback_get_folio() -> folio_prepare_writeback() ->
> unconditional wait on writeback to finish, which will cause a hang).
> This commit restores fuse to its prior behavior before tmp folios were
> removed, where sync was essentially a no-op.
>
> [1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1
>
> Fixes: 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree")
> Reported-by: John <therealgraysky@proton.me>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> ---
Looks reasonable to me. With my little experience in fs land:
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4 1/3] mm/swap, PM: hibernate: fix swapoff race in uswsusp by getting swap reference
From: YoungJun Park @ 2026-03-20 7:59 UTC (permalink / raw)
To: Kairui Song
Cc: rafael, akpm, chrisl, kasong, pavel, shikemeng, nphamcs, bhe,
baohua, usama.arif, linux-pm, linux-mm
In-Reply-To: <abp7aDgYLrxF3Me8@KASONG-MC4>
On Fri, Mar 20, 2026 at 12:34:02AM +0800, Kairui Song wrote:
> On Wed, Mar 18, 2026 at 03:13:16AM +0800, Youngjun Park wrote:
> Hi Youngjun,
>
> Thanks! This set of API looks better that before.
Hello Kairui! :)
> >
> > -/*
> > - * Find the swap type that corresponds to given device (if any).
> > - *
> > - * @offset - number of the PAGE_SIZE-sized block of the device, starting
> > - * from 0, in which the swap header is expected to be located.
> > - *
> > - * This is needed for the suspend to disk (aka swsusp).
> > - */
> > -int swap_type_of(dev_t device, sector_t offset)
> > +static int swap_type_of(dev_t device, sector_t offset)
>
> Maybe rename it while at it, it's a internal helper now and
> no one is using it.
I will change!
> > +/*
> > + * Finds the swap type and safely acquires a reference to the swap device
> > + * to prevent race conditions with swapoff.
> > + *
> > + * This should be used in environments like uswsusp where a race condition
> > + * exists between configuring the resume device and allocating a swap slot.
> > + * For sysfs hibernation where user-space is frozen (making swapoff
> > + * impossible), use find_hibernation_swap_type() instead.
> > + *
> > + * The caller must drop the reference using put_hibernation_swap_type().
> > + */
>
> You can follow the kernel doc format.
I will convert this to proper kernel-doc format as well. Thanks.
> > +int get_hibernation_swap_type(dev_t device, sector_t offset)
> > +{
> > + int type;
> > + struct swap_info_struct *sis;
> > +
> > + spin_lock(&swap_lock);
> > + type = swap_type_of(device, offset);
> > + sis = swap_type_to_info(type);
> > + if (!sis || !get_swap_device_info(sis))
> > + type = -1;
> > +
> > + spin_unlock(&swap_lock);
> > + return type;
> > +}
> > +
> > +/*
> > + * Drops the reference to the swap device previously acquired by
> > + * get_hibernation_swap_type().
> > + */
> > +void put_hibernation_swap_type(int type)
> > +{
> > + struct swap_info_struct *sis;
> > +
> > + sis = swap_type_to_info(type);
> > + if (!sis)
> > + return;
>
> I think it should never see sis == NULL here?
It can happen in the following cases:
1. The snapshot device is not configured at open time (i.e. no resume=
parameter and userspace intends to configure it later via ioctl).
2. The process exits or snapshot_release() is called with type = -1.
Although callers would normally check `type >= 0`, this helper
already handles invalid types defensively, so an extra check at the
call site is not strictly necessary.
> This looks really bad... It means swapoff will hung unless user send a
> signal to stop it? How does that happen?
>
> If hibernate may hold a reference without allocating any slot for a
> long time, then maybe we better introduce a new si->flags bit to
> indicate a device is used by hibernate, so swapoff can abort early
> with a -EBUSY.
>
> If hibernate only holds the swap device reference after it allocated
> any slot, then we can avoid use a flag but use a hibernate type in
> swap table instead:
>
> diff --git a/mm/swap_table.h b/mm/swap_table.h
> index 8415ffbe2b9c..025e004fc2e7 100644
> --- a/mm/swap_table.h
> +++ b/mm/swap_table.h
> @@ -25,6 +25,7 @@ struct swap_table {
> * PFN: | SWAP_COUNT |------ PFN -------|10| - Cached slot
> * Pointer: |----------- Pointer ----------|100| - (Unused)
> * Bad: |------------- 1 -------------|1000| - Bad slot
> + * Exclusive:|---- 0 ----| ------ 1 -----|10000| - Exclusive usage
> *
> * SWAP_COUNT is `SWP_TB_COUNT_BITS` long, each entry is an atomic long.
> *
> @@ -46,6 +47,8 @@ struct swap_table {
> * because only the lower three bits can be used as a marker for 8 bytes
> * aligned pointers.
> *
> + * - Exclusive usage: e.g. for hibernation.
> + *
> * - Bad: Swap slot is reserved, protects swap header or holes on swap devices.
> */
>
> Both readahead and swapoff (unuse scan) will abort upon seeing such slot,
> we solve both readahead and swapoff issue together.
>
> How do you think? We can use the flag idea first.
That makes sense. I also considered the pinning flag approach (and
mentioned my previously rejected strategy in response to Andrew’s
question).
Based on your feedback, I’m now convinced that introducing a dedicated
SWP_HIBERNATION pinning flag in `si->flags` is the right direction. It
makes the interaction with swapoff explicit and avoids long waits or
implicit dependency on slot allocation timing.
In the future, this pinning flag could potentially be reused in other
swap paths if we ever need to distinguish hibernation-specific
allocations. (this part is just imagination)
Regarding the swap table “exclusive bit” idea: I don’t think it fits
well here because there is a window between selecting the swap device
type and actually allocating a swap slot. During that gap, the user
context may change, so encoding exclusivity at the slot level would not
fully cover the race.
So I will proceed with the pinning flag approach !
> > */
> > percpu_ref_kill(&p->users);
> > synchronize_rcu();
> > - wait_for_completion(&p->comp);
> > + err = wait_for_completion_interruptible(&p->comp);
> > + if (err) {
> > + percpu_ref_resurrect(&p->users);
> > + synchronize_rcu();
>
> Do we need a synchronize_rcu here? It's required above because we are
> releasing the resources so all RCU readers must exit from grace
> period. But here we are aborting and not releasing anything so
> there is no such need?
This strategy has been dropped with the introduction of the
SWP_HIBERNATION pinning flag.
For clarification: the `synchronize_rcu()` here was intended to wait for
the final percpu_ref callback, since that callback runs in RCU context.
However, as you pointed out, since we are aborting rather than releasing
resources, that extra grace period is likely unnecessary.
I will update the patch accordingly and include additional testing
results.
Thanks again for the valuable review.
Best regards,
Youngjun
^ permalink raw reply
* Re: [PATCH] cpufreq: tegra194: remove COMPILE_TEST
From: Viresh Kumar @ 2026-03-20 5:33 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-pm, Rafael J. Wysocki, open list
In-Reply-To: <20260318191233.5851-1-rosenp@gmail.com>
On 18-03-26, 12:12, Rosen Penev wrote:
> The driver needs architecture specific headers to build. Problem gets
> exposed when TEGRA_BPMP gets COMPILE_TEST added to it.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/cpufreq/Kconfig.arm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 4014bc9dd73a..47c9b031f1b3 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -248,7 +248,7 @@ config ARM_TEGRA186_CPUFREQ
>
> config ARM_TEGRA194_CPUFREQ
> tristate "Tegra194 CPUFreq support"
> - depends on ARCH_TEGRA_194_SOC || ARCH_TEGRA_234_SOC || (64BIT && COMPILE_TEST)
> + depends on ARCH_TEGRA_194_SOC || ARCH_TEGRA_234_SOC
> depends on TEGRA_BPMP
> default ARCH_TEGRA_194_SOC || ARCH_TEGRA_234_SOC
> help
Applied. Thanks.
--
viresh
^ permalink raw reply
* Re: (subset) [PATCH v2 00/10] workqueue / drivers: Add device-managed allocate workqueue
From: Tzung-Bi Shih @ 2026-03-20 3:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Shuah Khan, Tejun Heo, Lai Jiangshan,
Tobias Schrammm, Sebastian Reichel, Andy Shevchenko,
Dan Carpenter, Krzysztof Kozlowski, Lee Jones, Dzmitry Sankouski,
Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Matti Vaittinen, driver-core, linux-doc, linux-kernel,
Sebastian Reichel, linux-pm, linux-arm-kernel, linux-mediatek,
chrome-platform, stable
In-Reply-To: <20260305-workqueue-devm-v2-0-66a38741c652@oss.qualcomm.com>
On Thu, Mar 05, 2026 at 10:45:39PM +0100, Krzysztof Kozlowski wrote:
> Merging / Dependency
> ====================
> All further patches depend on the first one, thus this probably should
> go via one tree, e.g. power supply. The first patch might be needed for
> other trees as well, e.g. if more drivers are discovered, so the best if
> it is on dedicated branch in case it has to be shared.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git for-next
[10/10] platform/chrome: cros_usbpd_logger: Simplify with devm
commit: 168e4b208ca8c2e04de20cc6cb7e2fb035dc1ec8
Thanks!
^ permalink raw reply
* Re: [PATCH v5 0/3] Fix swapoff race and cleanup in hibernation swap path
From: Andrew Morton @ 2026-03-20 2:50 UTC (permalink / raw)
To: Youngjun Park
Cc: rafael, chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
usama.arif, linux-mm, linux-pm
In-Reply-To: <20260319142404.3683019-1-youngjun.park@lge.com>
On Thu, 19 Mar 2026 23:24:01 +0900 Youngjun Park <youngjun.park@lge.com> wrote:
> Currently, in the uswsusp path, only the swap type value is retrieved at
> lookup time without holding a reference. If swapoff races after the type
> is acquired, subsequent slot allocations operate on a stale swap device.
>
> Additionally, grabbing and releasing the swap device reference on every
> slot allocation is inefficient across the entire hibernation swap path.
AI review has questions:
https://sashiko.dev/#/patchset/20260319142404.3683019-1-youngjun.park%40lge.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox