* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Markus Elfring @ 2026-04-08 7:28 UTC (permalink / raw)
To: vulab, imx, linux-pm, linux-arm-kernel, Georgi Djakov,
Sascha Hauer, Shawn Guo
Cc: kernel, stable, LKML, Fabio Estevam
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
How do you think about to increase the application of scope-based resource management?
https://elixir.bootlin.com/linux/v7.0-rc7/source/include/linux/of.h#L138
https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/interconnect/imx/imx.c#L117-L160
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Frank Li @ 2026-04-08 7:24 UTC (permalink / raw)
To: Wentao Liang
Cc: Georgi Djakov, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-pm, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260408031004.309483-1-vulab@iscas.ac.cn>
On Wed, Apr 08, 2026 at 03:10:04AM +0000, Wentao Liang wrote:
> Move of_node_put(dn) after the last use of dn, and add a missing put
> in the error path to avoid both use-after-free and reference leak.
>
> Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/interconnect/imx/imx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> index 9511f80cf041..75431b5ccef8 100644
> --- a/drivers/interconnect/imx/imx.c
> +++ b/drivers/interconnect/imx/imx.c
> @@ -143,15 +143,16 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
> }
>
Please use auto cleanup to fix this problem
struct device_node * __free(device_nod) dn = of_parse_phandle(dev->of_node, adj->phandle_name, 0);
Frank
> pdev = of_find_device_by_node(dn);
> - of_node_put(dn);
> if (!pdev) {
> dev_warn(dev, "node %s[%d] missing device for %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> return -EPROBE_DEFER;
> }
> node_data->qos_dev = &pdev->dev;
> dev_dbg(dev, "node %s[%d] has device node %pOF\n",
> node->name, node->id, dn);
> + of_node_put(dn);
> }
>
> return dev_pm_qos_add_request(node_data->qos_dev,
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] cpuidle: powerpc: avoid double clear when breaking snooze
From: Madhavan Srinivasan @ 2026-04-08 4:29 UTC (permalink / raw)
To: linuxppc-dev, Shrikanth Hegde
Cc: chleroy, nysal, mkchauras, rafael, daniel.lezcano,
christian.loehle, mkchauras, npiggin, linux-pm, stable
In-Reply-To: <20260311061709.1230440-1-sshegde@linux.ibm.com>
On Wed, 11 Mar 2026 11:47:09 +0530, Shrikanth Hegde wrote:
> snooze_loop is done often in any system which has fair bit of
> idle time. So it qualifies for even micro-optimizations.
>
> When breaking the snooze due to timeout, TIF_POLLING_NRFLAG is cleared
> twice. Clearing the bit invokes atomics. Avoid double clear and thereby
> avoid one atomic write.
>
> [...]
Applied to powerpc/next.
[1/1] cpuidle: powerpc: avoid double clear when breaking snooze
https://git.kernel.org/powerpc/c/64ed1e3e728afb57ba9acb59e69de930ead847d9
cheers
^ permalink raw reply
* [PATCH] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Wentao Liang @ 2026-04-08 3:10 UTC (permalink / raw)
To: Georgi Djakov, Shawn Guo, Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, linux-pm, imx,
linux-arm-kernel, linux-kernel, Wentao Liang, stable
Move of_node_put(dn) after the last use of dn, and add a missing put
in the error path to avoid both use-after-free and reference leak.
Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/interconnect/imx/imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
index 9511f80cf041..75431b5ccef8 100644
--- a/drivers/interconnect/imx/imx.c
+++ b/drivers/interconnect/imx/imx.c
@@ -143,15 +143,16 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
}
pdev = of_find_device_by_node(dn);
- of_node_put(dn);
if (!pdev) {
dev_warn(dev, "node %s[%d] missing device for %pOF\n",
node->name, node->id, dn);
+ of_node_put(dn);
return -EPROBE_DEFER;
}
node_data->qos_dev = &pdev->dev;
dev_dbg(dev, "node %s[%d] has device node %pOF\n",
node->name, node->id, dn);
+ of_node_put(dn);
}
return dev_pm_qos_add_request(node_data->qos_dev,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] cpufreq: fix race between hotplug and suspend
From: Tianxiang Chen @ 2026-04-08 1:46 UTC (permalink / raw)
To: rafael; +Cc: viresh.kumar, lingyue, linux-pm, linux-kernel
In-Reply-To: <CAJZ5v0hzhgf3mvdtHgT4Hwiqv22=P=xsWO8QZpeSGayOP-HO3w@mail.gmail.com>
On Tue, 7 Apr 2026, Rafael J. Wysocki wrote:
> So how exactly would CPU hotplug be started during a system suspend or resume?
Hi Rafael,
Thank you for your question. Let me explain the two scenarios:
1. cpufreq_suspend() During Reboot (Confirmed Issue)
The real and reproducible race I encountered occurs during system reboot.
Call chain:
kernel_restart() -> kernel_restart_prepare()
-> device_shutdown() -> cpufreq_suspend()
Different from the regular suspend path, the reboot path does NOT call
freeze_processes() at all.
All userspace processes, drivers and kernel threads are
still running when cpufreq_suspend() executes. This allows CPU hotplug
(offline/online) operations to run concurrently with cpufreq_suspend().
2. System suspend/resume (Less Likely but Possible)
CPU hotplug is less likely during system suspend/resume. However,
non-freezable kernel threads may keep running throughout the entire
process, which may still trigger CPU hotplug in theory.
So I added cpus_read_lock()/cpus_read_unlock() to block CPU hotplug
while resume is in progress.
--
Thx and BRs,
Tianxiang Chen
^ permalink raw reply
* Re: [PATCH v3 2/2] m68k: virt: Switch to qemu-virt-ctrl driver
From: Kuan-Wei Chiu @ 2026-04-08 1:17 UTC (permalink / raw)
To: geert
Cc: jserv, eleanor15x, daniel, laurent, linux-kernel, linux-m68k,
linux-pm, sre
In-Reply-To: <20260222173225.1105572-3-visitorckw@gmail.com>
Hi Geert,
On Sun, Feb 22, 2026 at 05:32:25PM +0000, Kuan-Wei Chiu wrote:
> Register the "qemu-virt-ctrl" platform device during board
> initialization to utilize the new generic power/reset driver.
>
> Consequently, remove the legacy reset and power-off implementations
> specific to the virt machine. The platform's mach_reset callback is
> updated to call do_kernel_restart(), bridging the legacy m68k reboot
> path to the generic kernel restart handler framework for this machine.
>
> To prevent any regressions in reboot or power-off functionality when
> the driver is not built-in, explicitly select POWER_RESET and
> POWER_RESET_QEMU_VIRT_CTRL for the VIRT machine in Kconfig.machine.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Since the next merge window is approaching, is there anything else
needed for this to be picked up via the m68k tree?
Regards,
Kuan-Wei
> ---
> Changes in v3:
> - Add 'select POWER_RESET' and 'select POWER_RESET_QEMU_VIRT_CTRL' in
> Kconfig.machine to avoid restart/power-off regressions.
>
> arch/m68k/Kconfig.machine | 2 ++
> arch/m68k/virt/config.c | 42 +--------------------------------------
> arch/m68k/virt/platform.c | 20 ++++++++++++++++---
> 3 files changed, 20 insertions(+), 44 deletions(-)
>
> diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
> index de39f23b180e..624e6b27f394 100644
> --- a/arch/m68k/Kconfig.machine
> +++ b/arch/m68k/Kconfig.machine
> @@ -133,6 +133,8 @@ config VIRT
> select GOLDFISH_TIMER
> select GOLDFISH_TTY
> select M68040
> + select POWER_RESET
> + select POWER_RESET_QEMU_VIRT_CTRL
> select RTC_CLASS
> select RTC_DRV_GOLDFISH
> select TTY
> diff --git a/arch/m68k/virt/config.c b/arch/m68k/virt/config.c
> index 632ba200ad42..b338e2a8da6a 100644
> --- a/arch/m68k/virt/config.c
> +++ b/arch/m68k/virt/config.c
> @@ -13,18 +13,6 @@
>
> struct virt_booter_data virt_bi_data;
>
> -#define VIRT_CTRL_REG_FEATURES 0x00
> -#define VIRT_CTRL_REG_CMD 0x04
> -
> -static struct resource ctrlres;
> -
> -enum {
> - CMD_NOOP,
> - CMD_RESET,
> - CMD_HALT,
> - CMD_PANIC,
> -};
> -
> static void virt_get_model(char *str)
> {
> /* str is 80 characters long */
> @@ -33,25 +21,9 @@ static void virt_get_model(char *str)
> (u8)(virt_bi_data.qemu_version >> 16),
> (u8)(virt_bi_data.qemu_version >> 8));
> }
> -
> -static void virt_halt(void)
> -{
> - void __iomem *base = (void __iomem *)virt_bi_data.ctrl.mmio;
> -
> - iowrite32be(CMD_HALT, base + VIRT_CTRL_REG_CMD);
> - local_irq_disable();
> - while (1)
> - ;
> -}
> -
> static void virt_reset(void)
> {
> - void __iomem *base = (void __iomem *)virt_bi_data.ctrl.mmio;
> -
> - iowrite32be(CMD_RESET, base + VIRT_CTRL_REG_CMD);
> - local_irq_disable();
> - while (1)
> - ;
> + do_kernel_restart(NULL);
> }
>
> /*
> @@ -113,20 +85,8 @@ void __init config_virt(void)
> virt_bi_data.tty.mmio);
> setup_earlycon(earlycon);
>
> - ctrlres = (struct resource)
> - DEFINE_RES_MEM_NAMED(virt_bi_data.ctrl.mmio, 0x100,
> - "virtctrl");
> -
> - if (request_resource(&iomem_resource, &ctrlres)) {
> - pr_err("Cannot allocate virt controller resource\n");
> - return;
> - }
> -
> mach_init_IRQ = virt_init_IRQ;
> mach_sched_init = virt_sched_init;
> mach_get_model = virt_get_model;
> mach_reset = virt_reset;
> - mach_halt = virt_halt;
> -
> - register_platform_power_off(virt_halt);
> }
> diff --git a/arch/m68k/virt/platform.c b/arch/m68k/virt/platform.c
> index 1560c4140ab9..764f556b4b32 100644
> --- a/arch/m68k/virt/platform.c
> +++ b/arch/m68k/virt/platform.c
> @@ -30,7 +30,10 @@ static int __init virt_platform_init(void)
> DEFINE_RES_MEM(virt_bi_data.rtc.mmio + 0x1000, 0x1000),
> DEFINE_RES_IRQ(virt_bi_data.rtc.irq + 1),
> };
> - struct platform_device *pdev1, *pdev2;
> + const struct resource virt_ctrl_res[] = {
> + DEFINE_RES_MEM(virt_bi_data.ctrl.mmio, 0x100),
> + };
> + struct platform_device *pdev1, *pdev2, *pdev3;
> struct platform_device *pdevs[VIRTIO_BUS_NB];
> unsigned int i;
> int ret = 0;
> @@ -57,19 +60,30 @@ static int __init virt_platform_init(void)
> goto err_unregister_tty;
> }
>
> + pdev3 = platform_device_register_simple("qemu-virt-ctrl",
> + PLATFORM_DEVID_NONE,
> + virt_ctrl_res,
> + ARRAY_SIZE(virt_ctrl_res));
> + if (IS_ERR(pdev3)) {
> + ret = PTR_ERR(pdev3);
> + goto err_unregister_rtc;
> + }
> +
> for (i = 0; i < VIRTIO_BUS_NB; i++) {
> pdevs[i] = virt_virtio_init(i);
> if (IS_ERR(pdevs[i])) {
> ret = PTR_ERR(pdevs[i]);
> - goto err_unregister_rtc_virtio;
> + goto err_unregister_virtio;
> }
> }
>
> return 0;
>
> -err_unregister_rtc_virtio:
> +err_unregister_virtio:
> while (i > 0)
> platform_device_unregister(pdevs[--i]);
> + platform_device_unregister(pdev3);
> +err_unregister_rtc:
> platform_device_unregister(pdev2);
> err_unregister_tty:
> platform_device_unregister(pdev1);
> --
> 2.53.0.345.g96ddfc5eaa-goog
>
^ permalink raw reply
* Re: [patch 00/12] hrtimers: Prevent hrtimer interrupt starvation
From: Thomas Gleixner @ 2026-04-07 20:58 UTC (permalink / raw)
To: Calvin Owens
Cc: LKML, 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: <adVOdTnyIbKz2F91@mozart.vkv.me>
On Tue, Apr 07 2026 at 11:35, Calvin Owens wrote:
> On Tuesday 04/07 at 20:03 +0200, Thomas Gleixner wrote:
>> On Tue, Apr 07 2026 at 10:38, Calvin Owens wrote:
>> > On Tuesday 04/07 at 10:54 +0200, Thomas Gleixner wrote:
>> >> 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.
>> >
>> > The original AMD machines survive the reproducer with this series.
>> >
>> > Tested-by: Calvin Owens <calvin@wbinvd.org>
>> >
>> > I'm happy to test subsets of it and stable backports too, if that's
>> > helpful, just let me know.
>>
>> We'll only backport the first patch, so confirming that it still
>> prevents the issue would be nice. The rest is slated for upstream only.
>
> Confirmed, [1/12] alone passes.
Thanks a lot for all your help. Very appreciated.
tglx
^ permalink raw reply
* Re: [patch 07/12] alarmtimer: Provide alarmtimer_start()
From: John Stultz @ 2026-04-07 20:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Stephen Boyd, Calvin Owens, Peter Zijlstra,
Anna-Maria Behnsen, Frederic Weisbecker, Ingo Molnar,
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.965539525@kernel.org>
On Tue, Apr 7, 2026 at 1:54 AM Thomas Gleixner <tglx@kernel.org> wrote:
>
> Alarm timers utilize hrtimers for normal operation and only switch to the
> RTC on suspend. In order to catch already expired timers early and without
> going through a timer interrupt cycle, provide a new start function which
> internally uses hrtimer_start_range_ns_user().
>
> If hrtimer_start_range_ns_user() detects an already expired timer, it does
> not queue it. In that case remove the timer from the alarm base as well.
>
> Return the status queued or not back to the caller to handle the early
> expiry.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: John Stultz <jstultz@google.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
Acked-by: John Stultz <jstultz@google.com> (also with Peter's
suggested name change)
^ permalink raw reply
* Re: [patch 12/12] alarmtimer: Remove unused interfaces
From: John Stultz @ 2026-04-07 20:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Stephen Boyd, Calvin Owens, Peter Zijlstra,
Anna-Maria Behnsen, Frederic Weisbecker, Ingo Molnar,
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: <20260407083248.303293327@kernel.org>
On Tue, Apr 7, 2026 at 1:55 AM Thomas Gleixner <tglx@kernel.org> wrote:
>
> All alarmtimer users are converted to alarmtimer_start(). Remove the now
> unused interfaces.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: John Stultz <jstultz@google.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
Acked-by: John Stultz <jstultz@google.com>
^ permalink raw reply
* Re: [patch 04/12] posix-timers: Expand timer_[re]arm() callbacks with a boolean return value
From: John Stultz @ 2026-04-07 20:20 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Calvin Owens, Peter Zijlstra, Ingo Molnar, 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.763539663@kernel.org>
On Tue, Apr 7, 2026 at 1:54 AM Thomas Gleixner <tglx@kernel.org> wrote:
>
> In order to catch expiry times which are already in the past the
> timer_arm() and timer_rearm() callbacks need to be able to report back to
> the caller whether the timer has been queued or not.
>
> Change the function signature and let all implementations return true for
> now. While at it simplify posix_cpu_timer_rearm().
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: John Stultz <jstultz@google.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
Acked-by: John Stultz <jstultz@google.com>
^ permalink raw reply
* Re: [patch 08/12] alarmtimer: Convert posix timer functions to alarmtimer_start()
From: John Stultz @ 2026-04-07 20:19 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Stephen Boyd, Calvin Owens, Peter Zijlstra,
Anna-Maria Behnsen, Frederic Weisbecker, Ingo Molnar,
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: <20260407083248.035227538@kernel.org>
On Tue, Apr 7, 2026 at 1:54 AM Thomas Gleixner <tglx@kernel.org> wrote:
>
> Use the new alarmtimer_start() for arming and rearming posix interval
> timers and for clock_nanosleep() so that already expired timers do not go
> through the full timer interrupt cycle.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: John Stultz <jstultz@google.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> ---
> kernel/time/alarmtimer.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
Acked-by: John Stultz <jstultz@google.com>
^ permalink raw reply
* Re: [PATCH v2] cpufreq/amd-pstate: Add POWER_SUPPLY select for dynamic EPP
From: Rafael J. Wysocki @ 2026-04-07 20:03 UTC (permalink / raw)
To: Mario Limonciello
Cc: K Prateek Nayak, Perry Yuan,
open list:X86 ARCHITECTURE (32-BIT AND 64-BIT),
open list:CPU FREQUENCY SCALING FRAMEWORK, kernel test robot
In-Reply-To: <20260407194949.310114-1-mario.limonciello@amd.com>
On Tue, Apr 7, 2026 at 9:50 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> The dynamic EPP feature uses power_supply_reg_notifier() and
> power_supply_unreg_notifier() but doesn't declare a dependency on
> POWER_SUPPLY, causing linker errors when POWER_SUPPLY is not enabled.
>
> Add POWER_SUPPLY to the selects.
>
> Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202604040742.ySEdkuAa-lkp@intel.com/
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> v2:
> * Use Prateek's suggestion
>
> drivers/cpufreq/Kconfig.x86 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
> index 53e2702e6f1c..7cd156b5e0fc 100644
> --- a/drivers/cpufreq/Kconfig.x86
> +++ b/drivers/cpufreq/Kconfig.x86
> @@ -41,6 +41,7 @@ config X86_AMD_PSTATE
> select ACPI_CPPC_LIB if X86_64
> select CPU_FREQ_GOV_SCHEDUTIL if SMP
> select ACPI_PLATFORM_PROFILE
> + select POWER_SUPPLY
> help
> This driver adds a CPUFreq driver which utilizes a fine grain
> processor performance frequency control range instead of legacy
> --
Applied (instead of the previous version), thanks!
^ permalink raw reply
* [PATCH v2] cpufreq/amd-pstate: Add POWER_SUPPLY select for dynamic EPP
From: Mario Limonciello @ 2026-04-07 19:49 UTC (permalink / raw)
To: K Prateek Nayak
Cc: Perry Yuan, open list:X86 ARCHITECTURE (32-BIT AND 64-BIT),
open list:CPU FREQUENCY SCALING FRAMEWORK, Mario Limonciello,
kernel test robot
The dynamic EPP feature uses power_supply_reg_notifier() and
power_supply_unreg_notifier() but doesn't declare a dependency on
POWER_SUPPLY, causing linker errors when POWER_SUPPLY is not enabled.
Add POWER_SUPPLY to the selects.
Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604040742.ySEdkuAa-lkp@intel.com/
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v2:
* Use Prateek's suggestion
drivers/cpufreq/Kconfig.x86 | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index 53e2702e6f1c..7cd156b5e0fc 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -41,6 +41,7 @@ config X86_AMD_PSTATE
select ACPI_CPPC_LIB if X86_64
select CPU_FREQ_GOV_SCHEDUTIL if SMP
select ACPI_PLATFORM_PROFILE
+ select POWER_SUPPLY
help
This driver adds a CPUFreq driver which utilizes a fine grain
processor performance frequency control range instead of legacy
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: thermal: idle: Complete the example code
From: Rob Herring (Arm) @ 2026-04-07 19:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Conor Dooley, linux-pm, Krzysztof Kozlowski, linux-kernel,
Daniel Lezcano, devicetree, Lukasz Luba, Zhang Rui,
Rafael J. Wysocki
In-Reply-To: <20260407053957.10508-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 07 Apr 2026 07:39:58 +0200, Krzysztof Kozlowski wrote:
> Thermal bindings expect the node name with all the zones to be named
> 'thermal-zones' (hyphen instead of underscore) and thermal zones to end
> with '-thermal'. Also DTS coding style is not to use underscores for
> node names. After using correct names, bindings point warnings for
> missing properties, so add also thermal-sensors. Drop fake top
> compatible as it is not useful in this context.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v2:
> 1. Drop top level compatible and other properties
> 2. Add thermal-sensors
> 3. Rename also trips and cpu-thermal
> ---
> .../bindings/thermal/thermal-idle.yaml | 18 +++++++-----------
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: 'compatible' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: '#address-cells' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: '#size-cells' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260407053957.10508-2-krzysztof.kozlowski@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS 7bbddc5f2768eb97b02e81babd9f8ee0c502dd76
From: kernel test robot @ 2026-04-07 18:59 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 7bbddc5f2768eb97b02e81babd9f8ee0c502dd76 Merge branch 'acpi-cpu-uid' into bleeding-edge
elapsed time: 1231m
configs tested: 153
configs skipped: 10
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260407 gcc-11.5.0
arc randconfig-002-20260407 gcc-9.5.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001-20260407 gcc-12.5.0
arm randconfig-003-20260407 gcc-10.5.0
arm randconfig-004-20260407 clang-20
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260407 clang-16
arm64 randconfig-002-20260407 gcc-13.4.0
arm64 randconfig-003-20260407 gcc-8.5.0
arm64 randconfig-004-20260407 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260407 gcc-13.4.0
csky randconfig-002-20260407 gcc-9.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001-20260407 clang-19
hexagon randconfig-002-20260407 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 buildonly-randconfig-001-20260407 gcc-14
i386 buildonly-randconfig-002-20260407 gcc-14
i386 buildonly-randconfig-003-20260407 clang-20
i386 buildonly-randconfig-004-20260407 clang-20
i386 buildonly-randconfig-005-20260407 gcc-14
i386 buildonly-randconfig-006-20260407 clang-20
i386 defconfig clang-20
i386 randconfig-002-20260407 gcc-14
i386 randconfig-004-20260407 gcc-14
i386 randconfig-005-20260407 clang-20
i386 randconfig-006-20260407 gcc-14
i386 randconfig-007-20260407 gcc-14
i386 randconfig-011-20260407 gcc-14
i386 randconfig-012-20260407 clang-20
i386 randconfig-013-20260407 clang-20
i386 randconfig-014-20260407 clang-20
i386 randconfig-015-20260407 gcc-14
i386 randconfig-016-20260407 clang-20
i386 randconfig-017-20260407 gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch randconfig-001-20260407 clang-23
loongarch randconfig-002-20260407 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260407 gcc-11.5.0
nios2 randconfig-002-20260407 gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260407 gcc-8.5.0
parisc randconfig-002-20260407 gcc-8.5.0
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260407 gcc-13.4.0
powerpc randconfig-002-20260407 gcc-8.5.0
powerpc tqm5200_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260407 gcc-12.5.0
powerpc64 randconfig-002-20260407 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260407 clang-23
riscv randconfig-002-20260407 gcc-12.5.0
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260407 gcc-14.3.0
s390 randconfig-002-20260407 clang-20
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260407 gcc-13.4.0
sh randconfig-002-20260407 gcc-15.2.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260407 gcc-15.2.0
sparc randconfig-002-20260407 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260407 clang-23
sparc64 randconfig-002-20260407 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260407 gcc-12
um randconfig-002-20260407 gcc-14
um x86_64_defconfig clang-23
x86_64 allnoconfig clang-20
x86_64 buildonly-randconfig-001-20260407 gcc-14
x86_64 buildonly-randconfig-002-20260407 gcc-14
x86_64 buildonly-randconfig-003-20260407 gcc-14
x86_64 buildonly-randconfig-004-20260407 clang-20
x86_64 buildonly-randconfig-005-20260407 gcc-14
x86_64 buildonly-randconfig-006-20260407 gcc-14
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260407 clang-20
x86_64 randconfig-002-20260407 clang-20
x86_64 randconfig-003-20260407 clang-20
x86_64 randconfig-004-20260407 gcc-14
x86_64 randconfig-005-20260407 gcc-14
x86_64 randconfig-006-20260407 gcc-14
x86_64 randconfig-011-20260407 gcc-14
x86_64 randconfig-012-20260407 clang-20
x86_64 randconfig-013-20260407 clang-20
x86_64 randconfig-014-20260407 clang-20
x86_64 randconfig-015-20260407 gcc-14
x86_64 randconfig-016-20260407 gcc-14
x86_64 randconfig-071-20260407 clang-20
x86_64 randconfig-072-20260407 clang-20
x86_64 randconfig-073-20260407 clang-20
x86_64 randconfig-074-20260407 clang-20
x86_64 randconfig-075-20260407 clang-20
x86_64 randconfig-076-20260407 clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa randconfig-001-20260407 gcc-12.5.0
xtensa randconfig-002-20260407 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [patch 00/12] hrtimers: Prevent hrtimer interrupt starvation
From: Calvin Owens @ 2026-04-07 18:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, 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: <87ika24phf.ffs@tglx>
On Tuesday 04/07 at 20:03 +0200, Thomas Gleixner wrote:
> On Tue, Apr 07 2026 at 10:38, Calvin Owens wrote:
> > On Tuesday 04/07 at 10:54 +0200, Thomas Gleixner wrote:
> >> 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.
> >
> > The original AMD machines survive the reproducer with this series.
> >
> > Tested-by: Calvin Owens <calvin@wbinvd.org>
> >
> > I'm happy to test subsets of it and stable backports too, if that's
> > helpful, just let me know.
>
> We'll only backport the first patch, so confirming that it still
> prevents the issue would be nice. The rest is slated for upstream only.
Confirmed, [1/12] alone passes.
Thanks,
Calvin
^ permalink raw reply
* Re: [PATCH v6 17/27] of: property: Allow fw_devlink device-tree on x86
From: Rob Herring (Arm) @ 2026-04-07 18:09 UTC (permalink / raw)
To: Herve Codina
Cc: Arnd Bergmann, linux-acpi, Daniel Scally, Charles Keepax,
Richard Fitzgerald, Andy Shevchenko, Jonathan Cameron,
Fabio Estevam, Dave Jiang, Thomas Petazzoni, Andi Shyti,
Ulf Hansson, Saravana Kannan, Ira Weiny, Dan Williams,
Steen Hegelund, Linus Walleij, imx, linux-gpio, patches,
Sakari Ailus, Andrew Lunn, devicetree, Geert Uytterhoeven,
linux-arm-kernel, Rafael J. Wysocki, Stephen Boyd,
Greg Kroah-Hartman, David Rhodes, Bjorn Helgaas, Conor Dooley,
linux-kernel, Luca Ceresoli, Shawn Guo, Vishal Verma, Mark Brown,
Davidlohr Bueso, linux-pm, Allan Nielsen, Pengutronix Kernel Team,
Wolfram Sang, Len Brown, Sascha Hauer, Danilo Krummrich,
Michael Turquette, Frank Li, Krzysztof Kozlowski, driver-core,
linux-i2c, linux-sound, Horatiu Vultur, Heikki Krogerus,
Kalle Niemi, linux-cxl, Alison Schofield, linux-clk, linux-pci,
Matti Vaittinen, Wolfram Sang, linux-spi, Peter Rosin
In-Reply-To: <20260325143555.451852-18-herve.codina@bootlin.com>
On Wed, 25 Mar 2026 15:35:44 +0100, Herve Codina wrote:
> PCI drivers can use a device-tree overlay to describe the hardware
> available on the PCI board. This is the case, for instance, of the
> LAN966x PCI device driver.
>
> Adding some more nodes in the device-tree overlay adds some more
> consumer/supplier relationship between devices instantiated from this
> overlay.
>
> Those fw_node consumer/supplier relationships are handled by fw_devlink
> and are created based on the device-tree parsing done by the
> of_fwnode_add_links() function.
>
> Those consumer/supplier links are needed in order to ensure a correct PM
> runtime management and a correct removal order between devices.
>
> For instance, without those links a supplier can be removed before its
> consumers is removed leading to all kind of issue if this consumer still
> want the use the already removed supplier.
>
> The support for the usage of an overlay from a PCI driver has been added
> on x86 systems in commit 1f340724419ed ("PCI: of: Create device tree PCI
> host bridge node").
>
> In the past, support for fw_devlink on x86 had been tried but this
> support has been removed in commit 4a48b66b3f52 ("of: property: Disable
> fw_devlink DT support for X86"). Indeed, this support was breaking some
> x86 systems such as OLPC system and the regression was reported in [0].
>
> Instead of disabling this support for all x86 system, use a finer grain
> and disable this support only for the possible problematic subset of x86
> systems (at least OLPC and CE4100).
>
> Those systems use a device-tree to describe their hardware. Identify
> those systems using key properties in the device-tree.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> Link: https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ [0]
> ---
> drivers/of/property.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v6 02/27] of: dynamic: Fix overlayed devices not probing because of fw_devlink
From: Rob Herring (Arm) @ 2026-04-07 18:06 UTC (permalink / raw)
To: Herve Codina
Cc: Daniel Scally, Mark Brown, linux-i2c, Conor Dooley, Sascha Hauer,
David Rhodes, Michael Turquette, imx, Arnd Bergmann,
Linus Walleij, Thomas Petazzoni, Andy Shevchenko,
linux-arm-kernel, linux-sound, linux-acpi, Len Brown, Shawn Guo,
Bjorn Helgaas, Ira Weiny, Dave Jiang, Andrew Lunn, Ulf Hansson,
Danilo Krummrich, Alison Schofield, linux-pm, linux-clk,
linux-cxl, Stephen Boyd, Charles Keepax, linux-spi, patches,
Saravana Kannan, devicetree, Luca Ceresoli, Fabio Estevam,
Wolfram Sang, Pengutronix Kernel Team, Geert Uytterhoeven,
linux-kernel, Steen Hegelund, Rafael J. Wysocki, driver-core,
Jonathan Cameron, Greg Kroah-Hartman, Krzysztof Kozlowski,
Saravana Kannan, Heikki Krogerus, Frank Li, Wolfram Sang,
Vishal Verma, Sakari Ailus, Dan Williams, Horatiu Vultur,
Davidlohr Bueso, Andi Shyti, linux-gpio, Allan Nielsen,
Richard Fitzgerald, Kalle Niemi, Matti Vaittinen, Peter Rosin,
linux-pci
In-Reply-To: <20260325143555.451852-3-herve.codina@bootlin.com>
On Wed, 25 Mar 2026 15:35:29 +0100, Herve Codina wrote:
> From: Saravana Kannan <saravanak@google.com>
>
> When an overlay is applied, if the target device has already probed
> successfully and bound to a device, then some of the fw_devlink logic
> that ran when the device was probed needs to be rerun. This allows newly
> created dangling consumers of the overlayed device tree nodes to be
> moved to become consumers of the target device.
>
> Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays")
> Reported-by: Herve Codina <herve.codina@bootlin.com>
> Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
> Closes: https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
> Closes: https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> Link: https://lore.kernel.org/lkml/20240411235623.1260061-3-saravanak@google.com/
> [Herve: Rebase on top of recent kernel]
> [Herve: Add the call to driver_deferred_probe_trigger()]
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> Tested-by: Kalle Niemi <kaleposti@gmail.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/base/core.c | 83 +++++++++++++++++++++++++++++++++++++-----
> drivers/of/overlay.c | 15 ++++++++
> include/linux/fwnode.h | 1 +
> 3 files changed, 90 insertions(+), 9 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 00/27] lan966x pci device: Add support for SFPs
From: Rob Herring @ 2026-04-07 18:05 UTC (permalink / raw)
To: Herve Codina
Cc: Andrew Lunn, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Kalle Niemi, Matti Vaittinen,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Andi Shyti, Wolfram Sang,
Peter Rosin, Arnd Bergmann, Saravana Kannan, Bjorn Helgaas,
Charles Keepax, Richard Fitzgerald, David Rhodes, Linus Walleij,
Ulf Hansson, Mark Brown, Len Brown, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Davidlohr Bueso,
Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma,
Ira Weiny, Dan Williams, Shawn Guo, Wolfram Sang, linux-kernel,
driver-core, imx, linux-arm-kernel, linux-clk, linux-i2c,
devicetree, linux-pci, linux-sound, patches, linux-gpio, linux-pm,
linux-spi, linux-acpi, linux-cxl, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260407180315.GA3175985-robh@kernel.org>
On Tue, Apr 7, 2026 at 1:03 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Mar 25, 2026 at 03:35:27PM +0100, Herve Codina wrote:
> > Hi,
> >
> > This series add support for SFPs ports available on the LAN966x PCI
> > device. In order to have the SFPs supported, additional devices are
> > needed such as clock controller and I2C.
> >
> > As a reminder, the LAN966x PCI device driver use a device-tree overlay
> > to describe devices available on the PCI board. Adding support for SFPs
> > ports consists in adding more devices in the already existing
> > device-tree overlay.
> >
> > With those devices added, the device-tree overlay is more complex and
> > some consumer/supplier relationship are needed in order to remove
> > devices in correct order when the LAN966x PCI driver is removed.
> >
> > Those links are typically provided by fw_devlink and we faced some
> > issues with fw_devlink and overlays.
> >
> > This series gives the big picture related to the SFPs support from
> > fixing issues to adding new devices. Of course, it can be split if
> > needed.
> >
> > The first part of the series (patch 1 and 2 ) fixes fw_devlink when it
> > is used with overlay. Those patches were previously sent by Saravana
> > [0]. I rebased them on top of v7.0-rc1.
> >
> > Also I added a call to driver_deferred_probe_trigger() in Saravana's
> > patch (patch 2) to ensure that probes are retried after the modification
> > performed on the dangling consumers. This allows to fix issues reported
> > by Matti and Geert [2] with the previous iteration patches.
> >
> > Those modification were not sufficient in our case and so, on top of
> > that, patches 3 to 5 fix some more issues related to fw_devlink.
> >
> > Patches 6 to 11 introduce and use fw_devlink_set_device() in already
> > existing code.
> >
> > Patches 12 and 13 are related also to fw_devlink but specific to PCI and
> > the device-tree nodes created during enumeration.
> >
> > Patches 14, 15 and 16 are related fw_devlink too but specific to I2C
> > muxes. Patches purpose is to correctly set a link between an adapter
> > supplier and its consumer. Indeed, an i2c mux adapter's parent is not
> > the i2c mux supplier but the adapter the i2c mux is connected to. Adding
> > a new link between the adapter supplier involved when i2c muxes are used
> > avoid a freeze observed during device removal.
> >
> > Patch 17 adds support for fw_delink on x86. fw_devlink is needed to have
> > the consumer/supplier relationship between devices in order to ensure a
> > correct device removal order. Adding fw_devlink support for x86 has been
> > tried in the past but was reverted [1] because it broke some systems.
> > Instead of enabling fw_devlink on *all* x86 system, enable it on *all*
> > x86 except on those where it leads to issue.
> >
> > Patches 18 and 19 allow to build clock and i2c controller used by the
> > LAN966x PCI device when the LAN966x PCI device is enabled.
> >
> > Patches 20 to 24 are specific to the LAN966x. They touch the current
> > dtso, split it in dtsi/dtso files, rename the dtso and improve the
> > driver to allow easier support for other boards.
> >
> > The next patch (patch 25) update the LAN966x device-tree overlay itself
> > to have the SPF ports and devices they depends on described.
> >
> > The last two patches (patches 26 and 27) sort the existing drivers in
> > the needed driver list available in the Kconfig help and add new drivers
> > in this list keep the list up to date with the devices described in the
> > device-tree overlay.
> >
> > We believe some items from the above list can be merged separately, with
> > no build dependencies. We expect:
> >
> > - Patches 1 to 5 to be taken by driver core maintainers
>
> From a quick look, can't the first 2 DT patches be taken by me?
Err, I guess patch 2 is really more driver core than DT.
Rob
^ permalink raw reply
* Re: [PATCH v6 01/27] Revert "treewide: Fix probing of devices in DT overlays"
From: Rob Herring (Arm) @ 2026-04-07 18:05 UTC (permalink / raw)
To: Herve Codina
Cc: Conor Dooley, linux-pci, Ulf Hansson, Jonathan Cameron,
Danilo Krummrich, linux-gpio, Luca Ceresoli, linux-cxl,
Kalle Niemi, linux-spi, linux-i2c, Len Brown, Shawn Guo,
Dave Jiang, imx, linux-sound, Saravana Kannan, Vishal Verma,
Ira Weiny, Stephen Boyd, Sascha Hauer, Linus Walleij,
Charles Keepax, Peter Rosin, Geert Uytterhoeven, Davidlohr Bueso,
linux-kernel, linux-pm, linux-clk, Allan Nielsen, Frank Li,
Wolfram Sang, Andi Shyti, Andy Shevchenko, Rafael J. Wysocki,
Richard Fitzgerald, Alison Schofield, Wolfram Sang, Arnd Bergmann,
Steen Hegelund, David Rhodes, Pengutronix Kernel Team,
driver-core, Fabio Estevam, Krzysztof Kozlowski,
Michael Turquette, Heikki Krogerus, linux-arm-kernel,
Thomas Petazzoni, linux-acpi, Horatiu Vultur, patches,
Sakari Ailus, Andrew Lunn, Saravana Kannan, Bjorn Helgaas,
devicetree, Dan Williams, Mark Brown, Greg Kroah-Hartman,
Daniel Scally, Matti Vaittinen
In-Reply-To: <20260325143555.451852-2-herve.codina@bootlin.com>
On Wed, 25 Mar 2026 15:35:28 +0100, Herve Codina wrote:
> From: Saravana Kannan <saravanak@google.com>
>
> This reverts commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924.
>
> While the commit fixed fw_devlink overlay handling for one case, it
> broke it for another case. So revert it and redo the fix in a separate
> patch.
>
> Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays")
> Reported-by: Herve Codina <herve.codina@bootlin.com>
> Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
> Closes: https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
> Closes: https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> Link: https://lore.kernel.org/lkml/20240411235623.1260061-2-saravanak@google.com/
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> ---
> drivers/bus/imx-weim.c | 6 ------
> drivers/i2c/i2c-core-of.c | 5 -----
> drivers/of/dynamic.c | 1 -
> drivers/of/platform.c | 5 -----
> drivers/spi/spi.c | 5 -----
> 5 files changed, 22 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [patch 00/12] hrtimers: Prevent hrtimer interrupt starvation
From: Thomas Gleixner @ 2026-04-07 18:03 UTC (permalink / raw)
To: Calvin Owens
Cc: LKML, 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: <adVA_uv1srA_bsKj@mozart.vkv.me>
On Tue, Apr 07 2026 at 10:38, Calvin Owens wrote:
> On Tuesday 04/07 at 10:54 +0200, Thomas Gleixner wrote:
>> 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.
>
> The original AMD machines survive the reproducer with this series.
>
> Tested-by: Calvin Owens <calvin@wbinvd.org>
>
> I'm happy to test subsets of it and stable backports too, if that's
> helpful, just let me know.
We'll only backport the first patch, so confirming that it still
prevents the issue would be nice. The rest is slated for upstream only.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v6 00/27] lan966x pci device: Add support for SFPs
From: Rob Herring @ 2026-04-07 18:03 UTC (permalink / raw)
To: Herve Codina
Cc: Andrew Lunn, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Kalle Niemi, Matti Vaittinen,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Andi Shyti, Wolfram Sang,
Peter Rosin, Arnd Bergmann, Saravana Kannan, Bjorn Helgaas,
Charles Keepax, Richard Fitzgerald, David Rhodes, Linus Walleij,
Ulf Hansson, Mark Brown, Len Brown, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Davidlohr Bueso,
Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma,
Ira Weiny, Dan Williams, Shawn Guo, Wolfram Sang, linux-kernel,
driver-core, imx, linux-arm-kernel, linux-clk, linux-i2c,
devicetree, linux-pci, linux-sound, patches, linux-gpio, linux-pm,
linux-spi, linux-acpi, linux-cxl, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260325143555.451852-1-herve.codina@bootlin.com>
On Wed, Mar 25, 2026 at 03:35:27PM +0100, Herve Codina wrote:
> Hi,
>
> This series add support for SFPs ports available on the LAN966x PCI
> device. In order to have the SFPs supported, additional devices are
> needed such as clock controller and I2C.
>
> As a reminder, the LAN966x PCI device driver use a device-tree overlay
> to describe devices available on the PCI board. Adding support for SFPs
> ports consists in adding more devices in the already existing
> device-tree overlay.
>
> With those devices added, the device-tree overlay is more complex and
> some consumer/supplier relationship are needed in order to remove
> devices in correct order when the LAN966x PCI driver is removed.
>
> Those links are typically provided by fw_devlink and we faced some
> issues with fw_devlink and overlays.
>
> This series gives the big picture related to the SFPs support from
> fixing issues to adding new devices. Of course, it can be split if
> needed.
>
> The first part of the series (patch 1 and 2 ) fixes fw_devlink when it
> is used with overlay. Those patches were previously sent by Saravana
> [0]. I rebased them on top of v7.0-rc1.
>
> Also I added a call to driver_deferred_probe_trigger() in Saravana's
> patch (patch 2) to ensure that probes are retried after the modification
> performed on the dangling consumers. This allows to fix issues reported
> by Matti and Geert [2] with the previous iteration patches.
>
> Those modification were not sufficient in our case and so, on top of
> that, patches 3 to 5 fix some more issues related to fw_devlink.
>
> Patches 6 to 11 introduce and use fw_devlink_set_device() in already
> existing code.
>
> Patches 12 and 13 are related also to fw_devlink but specific to PCI and
> the device-tree nodes created during enumeration.
>
> Patches 14, 15 and 16 are related fw_devlink too but specific to I2C
> muxes. Patches purpose is to correctly set a link between an adapter
> supplier and its consumer. Indeed, an i2c mux adapter's parent is not
> the i2c mux supplier but the adapter the i2c mux is connected to. Adding
> a new link between the adapter supplier involved when i2c muxes are used
> avoid a freeze observed during device removal.
>
> Patch 17 adds support for fw_delink on x86. fw_devlink is needed to have
> the consumer/supplier relationship between devices in order to ensure a
> correct device removal order. Adding fw_devlink support for x86 has been
> tried in the past but was reverted [1] because it broke some systems.
> Instead of enabling fw_devlink on *all* x86 system, enable it on *all*
> x86 except on those where it leads to issue.
>
> Patches 18 and 19 allow to build clock and i2c controller used by the
> LAN966x PCI device when the LAN966x PCI device is enabled.
>
> Patches 20 to 24 are specific to the LAN966x. They touch the current
> dtso, split it in dtsi/dtso files, rename the dtso and improve the
> driver to allow easier support for other boards.
>
> The next patch (patch 25) update the LAN966x device-tree overlay itself
> to have the SPF ports and devices they depends on described.
>
> The last two patches (patches 26 and 27) sort the existing drivers in
> the needed driver list available in the Kconfig help and add new drivers
> in this list keep the list up to date with the devices described in the
> device-tree overlay.
>
> We believe some items from the above list can be merged separately, with
> no build dependencies. We expect:
>
> - Patches 1 to 5 to be taken by driver core maintainers
From a quick look, can't the first 2 DT patches be taken by me?
Rob
^ permalink raw reply
* Re: [patch 01/12] clockevents: Prevent timer interrupt starvation
From: Thomas Gleixner @ 2026-04-07 18:01 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Calvin Owens, Peter Zijlstra, Anna-Maria Behnsen,
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: <87tstm4uss.ffs@tglx>
On Tue, Apr 07 2026 at 18:08, Thomas Gleixner wrote:
> On Tue, Apr 07 2026 at 16:00, Frederic Weisbecker wrote:
> As I had to introduce the flag and prevent the other scenraio I just
> consolidated everything into one code path.
Just for the record. This whole -ETIME handling is restricted to HPET
like devices where the hardware people decided it's a brilliant idea to
build a 'equal' comparator and then followed up by making the write
posted to reduce the costs of the write. The original direct write was
already flawed vs. NMI/SMI, but the delayed commit into the comparator
made it insanely broken.
AFAICT that's a handful devices in the zoo of clockevent IPs the kernel
supports, so I'm really not too worried about the impact of this change.
Any sane hardware will never hit that code path so no point for
optimizing for it.
Thanks,
tglx
^ permalink raw reply
* Re: [patch 00/12] hrtimers: Prevent hrtimer interrupt starvation
From: Calvin Owens @ 2026-04-07 17:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, 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: <20260407083219.478203185@kernel.org>
On Tuesday 04/07 at 10:54 +0200, Thomas Gleixner wrote:
> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked
> up in user space:
>
> https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/
>
> 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.
The original AMD machines survive the reproducer with this series.
Tested-by: Calvin Owens <calvin@wbinvd.org>
I'm happy to test subsets of it and stable backports too, if that's
helpful, just let me know.
Thanks,
Calvin
> 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.
>
> The first patch in the series changes the clockevent set next event
> mechanism to prevent reprogramming of the clockevent device when the
> minimum delta value was programmed unless the new delta is larger than
> that. It's a less convoluted variant of the patch which was posted in the
> above linked thread and was confirmed to prevent the starvation problem.
>
> But that's only to be considered the last resort because it results in an
> insane amount of avoidable hrtimer interrupts.
>
> The problem of user controlled timers is that the input value is only
> sanity checked vs. validity of the provided timespec and clamped to be in
> the maximum allowable range. But for performance reasons for in kernel
> usage there is no check whether a to be armed timer might have been expired
> already at enqueue time.
>
> The rest of the series addresses this by providing a separate interface to
> arm user controlled timers. This works the same way as the existing
> hrtimer_start_range_ns(), but in case that the timer ends up as the first
> timer in the clock base after enqueue it provides additional checks:
>
> - Whether the timer becomes the first expiring timer in the CPU base.
>
> If not the timer is considered to expire in the future as there is
> already an earlier event programmed.
>
> - Whether the timer has expired already by comparing the expiry value
> against current time.
>
> If it is expired, the timer is removed from the clock base and the
> function returns false, so that the caller can handle it. That's
> required because the function cannot invoke the callback as that
> might need to acquire a lock which is held by the caller.
>
> This function is then used for the user controlled timer arming interfaces
> mainly by converting hrtimer sleeper over to it. That affects a few in
> kernel users too, but the overhead is minimal in that case and it spares a
> tedious whack the mole game all over the tree.
>
> The other usage sites in posixtimers, alarmtimers and timerfd are converted
> as well, which should cover the vast majority of user space controllable
> timers as far as my investigation goes.
>
> The series applies against Linux tree and is also available from git:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git hrtimer-exp-v1
>
> There needs to be some discussion about the scope of backporting. The first
> patch preventing the stall is obviously a backport candidate. The remaining
> series can be obviously argued about, but in my opinion it should be
> backported as well as it prevents stupid or malicious user space from
> generating tons of pointless timer interrupts.
>
> Thanks,
>
> tglx
> ---
> drivers/power/supply/charger-manager.c | 12 +-
> fs/timerfd.c | 115 +++++++++++++++-----------
> include/linux/alarmtimer.h | 9 +-
> include/linux/clockchips.h | 2
> include/linux/hrtimer.h | 20 +++-
> include/trace/events/timer.h | 13 +++
> kernel/time/alarmtimer.c | 70 +++++++---------
> kernel/time/clockevents.c | 23 +++--
> kernel/time/hrtimer.c | 142 +++++++++++++++++++++++++++++----
> kernel/time/posix-cpu-timers.c | 18 ++--
> kernel/time/posix-timers.c | 35 +++++---
> kernel/time/posix-timers.h | 4
> kernel/time/tick-common.c | 1
> kernel/time/tick-sched.c | 1
> net/netfilter/xt_IDLETIMER.c | 24 ++++-
> 15 files changed, 341 insertions(+), 148 deletions(-)
>
>
^ permalink raw reply
* Re: [PATCH] thermal/of: Move OF code where it belongs to
From: Rafael J. Wysocki @ 2026-04-07 17:10 UTC (permalink / raw)
To: Daniel Lezcano
Cc: rafael, Daniel Lezcano, Zhang Rui, Lukasz Luba, open list:THERMAL,
open list
In-Reply-To: <20260407155110.3920703-1-daniel.lezcano@kernel.org>
On Tue, Apr 7, 2026 at 5:51 PM Daniel Lezcano <daniel.lezcano@kernel.org> wrote:
>
> From: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
>
> The functions:
> - thermal_of_cooling_device_register()
> - devm_thermal_of_cooling_device_register()
>
> are related to thermal-of but they are implemented in
> thermal-core. Move these functions to the right file.
>
> Pure move patch.
>
> No functional change intended.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
> ---
> drivers/thermal/thermal_core.c | 75 +---------------------------------
> drivers/thermal/thermal_core.h | 5 +++
> drivers/thermal/thermal_of.c | 72 ++++++++++++++++++++++++++++++++
> 3 files changed, 78 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index b7d706ed7ed9..f0049cff1128 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1054,7 +1054,7 @@ static void thermal_cooling_device_init_complete(struct thermal_cooling_device *
> * Return: a pointer to the created struct thermal_cooling_device or an
> * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
> */
> -static struct thermal_cooling_device *
> +struct thermal_cooling_device *
> __thermal_cooling_device_register(struct device_node *np,
> const char *type, void *devdata,
> const struct thermal_cooling_device_ops *ops)
> @@ -1162,79 +1162,6 @@ thermal_cooling_device_register(const char *type, void *devdata,
> }
> EXPORT_SYMBOL_GPL(thermal_cooling_device_register);
>
> -/**
> - * thermal_of_cooling_device_register() - register an OF thermal cooling device
> - * @np: a pointer to a device tree node.
> - * @type: the thermal cooling device type.
> - * @devdata: device private data.
> - * @ops: standard thermal cooling devices callbacks.
> - *
> - * This function will register a cooling device with device tree node reference.
> - * This interface function adds a new thermal cooling device (fan/processor/...)
> - * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
> - * to all the thermal zone devices registered at the same time.
> - *
> - * Return: a pointer to the created struct thermal_cooling_device or an
> - * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
> - */
> -struct thermal_cooling_device *
> -thermal_of_cooling_device_register(struct device_node *np,
> - const char *type, void *devdata,
> - const struct thermal_cooling_device_ops *ops)
> -{
> - return __thermal_cooling_device_register(np, type, devdata, ops);
> -}
> -EXPORT_SYMBOL_GPL(thermal_of_cooling_device_register);
> -
> -static void thermal_cooling_device_release(struct device *dev, void *res)
> -{
> - thermal_cooling_device_unregister(
> - *(struct thermal_cooling_device **)res);
> -}
> -
> -/**
> - * devm_thermal_of_cooling_device_register() - register an OF thermal cooling
> - * device
> - * @dev: a valid struct device pointer of a sensor device.
> - * @np: a pointer to a device tree node.
> - * @type: the thermal cooling device type.
> - * @devdata: device private data.
> - * @ops: standard thermal cooling devices callbacks.
> - *
> - * This function will register a cooling device with device tree node reference.
> - * This interface function adds a new thermal cooling device (fan/processor/...)
> - * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
> - * to all the thermal zone devices registered at the same time.
> - *
> - * Return: a pointer to the created struct thermal_cooling_device or an
> - * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
> - */
> -struct thermal_cooling_device *
> -devm_thermal_of_cooling_device_register(struct device *dev,
> - struct device_node *np,
> - const char *type, void *devdata,
> - const struct thermal_cooling_device_ops *ops)
> -{
> - struct thermal_cooling_device **ptr, *tcd;
> -
> - ptr = devres_alloc(thermal_cooling_device_release, sizeof(*ptr),
> - GFP_KERNEL);
> - if (!ptr)
> - return ERR_PTR(-ENOMEM);
> -
> - tcd = __thermal_cooling_device_register(np, type, devdata, ops);
> - if (IS_ERR(tcd)) {
> - devres_free(ptr);
> - return tcd;
> - }
> -
> - *ptr = tcd;
> - devres_add(dev, ptr);
> -
> - return tcd;
> -}
> -EXPORT_SYMBOL_GPL(devm_thermal_of_cooling_device_register);
> -
> static bool thermal_cooling_device_present(struct thermal_cooling_device *cdev)
> {
> struct thermal_cooling_device *pos = NULL;
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index d3acff602f9c..bdd59947b24f 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -269,6 +269,11 @@ void thermal_zone_device_critical_shutdown(struct thermal_zone_device *tz);
> void thermal_governor_update_tz(struct thermal_zone_device *tz,
> enum thermal_notify_event reason);
>
> +struct thermal_cooling_device *
> +__thermal_cooling_device_register(struct device_node *np,
> + const char *type, void *devdata,
> + const struct thermal_cooling_device_ops *ops);
> +
> /* Helpers */
> #define for_each_trip_desc(__tz, __td) \
> for (__td = __tz->trips; __td - __tz->trips < __tz->num_trips; __td++)
> diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
> index 99085c806a1f..398157e740fc 100644
> --- a/drivers/thermal/thermal_of.c
> +++ b/drivers/thermal/thermal_of.c
> @@ -510,3 +510,75 @@ void devm_thermal_of_zone_unregister(struct device *dev, struct thermal_zone_dev
> devm_thermal_of_zone_match, tz));
> }
> EXPORT_SYMBOL_GPL(devm_thermal_of_zone_unregister);
> +
> +/**
> + * thermal_of_cooling_device_register() - register an OF thermal cooling device
> + * @np: a pointer to a device tree node.
> + * @type: the thermal cooling device type.
> + * @devdata: device private data.
> + * @ops: standard thermal cooling devices callbacks.
> + *
> + * This function will register a cooling device with device tree node reference.
> + * This interface function adds a new thermal cooling device (fan/processor/...)
> + * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
> + * to all the thermal zone devices registered at the same time.
> + *
> + * Return: a pointer to the created struct thermal_cooling_device or an
> + * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
> + */
> +struct thermal_cooling_device *
> +thermal_of_cooling_device_register(struct device_node *np,
> + const char *type, void *devdata,
> + const struct thermal_cooling_device_ops *ops)
> +{
> + return __thermal_cooling_device_register(np, type, devdata, ops);
> +}
> +EXPORT_SYMBOL_GPL(thermal_of_cooling_device_register);
> +
> +static void thermal_cooling_device_release(struct device *dev, void *res)
> +{
> + thermal_cooling_device_unregister(*(struct thermal_cooling_device **)res);
> +}
> +
> +/**
> + * devm_thermal_of_cooling_device_register() - register an OF thermal cooling
> + * device
> + * @dev: a valid struct device pointer of a sensor device.
> + * @np: a pointer to a device tree node.
> + * @type: the thermal cooling device type.
> + * @devdata: device private data.
> + * @ops: standard thermal cooling devices callbacks.
> + *
> + * This function will register a cooling device with device tree node reference.
> + * This interface function adds a new thermal cooling device (fan/processor/...)
> + * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
> + * to all the thermal zone devices registered at the same time.
> + *
> + * Return: a pointer to the created struct thermal_cooling_device or an
> + * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
> + */
> +struct thermal_cooling_device *
> +devm_thermal_of_cooling_device_register(struct device *dev,
> + struct device_node *np,
> + const char *type, void *devdata,
> + const struct thermal_cooling_device_ops *ops)
> +{
> + struct thermal_cooling_device **ptr, *tcd;
> +
> + ptr = devres_alloc(thermal_cooling_device_release, sizeof(*ptr),
> + GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + tcd = __thermal_cooling_device_register(np, type, devdata, ops);
> + if (IS_ERR(tcd)) {
> + devres_free(ptr);
> + return tcd;
> + }
> +
> + *ptr = tcd;
> + devres_add(dev, ptr);
> +
> + return tcd;
> +}
> +EXPORT_SYMBOL_GPL(devm_thermal_of_cooling_device_register);
> --
Applied as 7.1 material, thanks!
^ 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