* Re: [PATCH] interconnect: Do not create empty devres on missing interconnects
From: Kuan-Wei Chiu @ 2026-04-16 16:37 UTC (permalink / raw)
To: Krzysztof Kozlowski; +Cc: Georgi Djakov, linux-pm, linux-kernel
In-Reply-To: <20260416130912.375013-2-krzysztof.kozlowski@oss.qualcomm.com>
On Thu, Apr 16, 2026 at 03:09:13PM +0200, Krzysztof Kozlowski wrote:
> of_icc_get() returns NULL on valid case - no interconnects - but no
> need to create devres for that, because it just wastes memory without
> any use/benefits.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Regards,
Kuan-Wei
> ---
> drivers/interconnect/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 8569b78a1851..ce572c62f58f 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -432,7 +432,7 @@ struct icc_path *devm_of_icc_get(struct device *dev, const char *name)
> return ERR_PTR(-ENOMEM);
>
> path = of_icc_get(dev, name);
> - if (!IS_ERR(path)) {
> + if (!IS_ERR_OR_NULL(path)) {
> *ptr = path;
> devres_add(dev, ptr);
> } else {
> --
> 2.51.0
>
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Petr Mladek @ 2026-04-16 14:54 UTC (permalink / raw)
To: David Laight
Cc: chensong_2000, rafael, lenb, mturquette, sboyd, viresh.kumar, agk,
snitzer, mpatocka, bmarzins, song, yukuai, linan122, jason.wessel,
danielt, dianders, horms, davem, edumazet, kuba, pabeni, paulmck,
frederic, mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin,
jpoimboe, jikos, mbenes, joe.lawrence, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260416133004.07bd2886@pumpkin>
On Thu 2026-04-16 13:30:04, David Laight wrote:
> On Wed, 15 Apr 2026 15:01:37 +0800
> chensong_2000@189.cn wrote:
>
> > From: Song Chen <chensong_2000@189.cn>
> >
> > The current notifier chain implementation uses a single-linked list
> > (struct notifier_block *next), which only supports forward traversal
> > in priority order. This makes it difficult to handle cleanup/teardown
> > scenarios that require notifiers to be called in reverse priority order.
>
> If it is only cleanup/teardown then the list can be order-reversed
> as part of that process at the same time as the list is deleted.
Interesting idea. But it won't work in all situations.
Note that the motivation for this update are the module loader
notifiers which are called several times for each loaded/removed module.
Best Regards,
Petr
^ permalink raw reply
* Re: [RFC PATCH 2/2] kernel/module: Decouple klp and ftrace from load_module
From: Petr Mladek @ 2026-04-16 14:49 UTC (permalink / raw)
To: Petr Pavlu
Cc: Song Chen, rafael, lenb, mturquette, sboyd, viresh.kumar, agk,
snitzer, mpatocka, bmarzins, song, yukuai, linan122, jason.wessel,
danielt, dianders, horms, davem, edumazet, kuba, pabeni, paulmck,
frederic, mcgrof, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, joe.lawrence, rostedt, mhiramat, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <1db425bf-58a9-4768-8c38-3ae25d7662a5@suse.com>
On Thu 2026-04-16 13:18:30, Petr Pavlu wrote:
> On 4/15/26 8:43 AM, Song Chen wrote:
> > On 4/14/26 22:33, Petr Pavlu wrote:
> >> On 4/13/26 10:07 AM, chensong_2000@189.cn wrote:
> >>> diff --git a/include/linux/module.h b/include/linux/module.h
> >>> index 14f391b186c6..0bdd56f9defd 100644
> >>> --- a/include/linux/module.h
> >>> +++ b/include/linux/module.h
> >>> @@ -308,6 +308,14 @@ enum module_state {
> >>> MODULE_STATE_COMING, /* Full formed, running module_init. */
> >>> MODULE_STATE_GOING, /* Going away. */
> >>> MODULE_STATE_UNFORMED, /* Still setting it up. */
> >>> + MODULE_STATE_FORMED,
> >>
> >> I don't see a reason to add a new module state. Why is it necessary and
> >> how does it fit with the existing states?
> >>
> > because once notifier fails in state MODULE_STATE_UNFORMED (now only ftrace has someting to do in this state), notifier chain will roll back by calling blocking_notifier_call_chain_robust, i'm afraid MODULE_STATE_GOING is going to jeopardise the notifers which don't handle it appropriately, like:
> >
> > case MODULE_STATE_COMING:
> > kmalloc();
> > case MODULE_STATE_GOING:
> > kfree();
>
> My understanding is that the current module "state machine" operates as
> follows. Transitions marked with an asterisk (*) are announced via the
> module notifier.
>
> ---> UNFORMED --*> COMING --*> LIVE --*> GOING -.
> ^ | ^ |
> | '---------------------* |
> '---------------------------------------'
>
> The new code aims to replace the current ftrace_module_init() call in
> load_module(). To achieve this, it adds a notification for the UNFORMED
> state (only when loading a module) and introduces a new FORMED state for
> rollback. FORMED is purely a fake state because it never appears in
> module::state. The new structure is as follows:
>
> ,--*> (FORMED)
> |
> --*> UNFORMED --*> COMING --*> LIVE --*> GOING -.
> ^ | ^ |
> | '---------------------* |
> '---------------------------------------'
>
> I'm afraid this is quite complex and inconsistent. Unless it can be kept
> simple, we would be just replacing one special handling with a different
> complexity, which is not worth it.
> >>
> >>> + if (err)
> >>> + goto ddebug_cleanup;
> >>> /* Finally it's fully formed, ready to start executing. */
> >>> err = complete_formation(mod, info);
> >>> - if (err)
> >>> + if (err) {
> >>> + blocking_notifier_call_chain_reverse(&module_notify_list,
> >>> + MODULE_STATE_FORMED, mod);
> >>> goto ddebug_cleanup;
> >>> + }
> >>> - err = prepare_coming_module(mod);
> >>> + err = prepare_module_state_transaction(mod,
> >>> + MODULE_STATE_COMING, MODULE_STATE_GOING);
> >>> if (err)
> >>> goto bug_cleanup;
> >>> @@ -3522,7 +3519,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
> >>> destroy_params(mod->kp, mod->num_kp);
> >>> blocking_notifier_call_chain(&module_notify_list,
> >>> MODULE_STATE_GOING, mod);
> >>
> >> My understanding is that all notifier chains for MODULE_STATE_GOING
> >> should be reversed.
> > yes, all, from lowest priority notifier to highest.
> > I will resend patch 1 which was failed due to my proxy setting.
>
> What I meant here is that the call:
>
> blocking_notifier_call_chain(&module_notify_list, MODULE_STATE_GOING, mod);
>
> should be replaced with:
>
> blocking_notifier_call_chain_reverse(&module_notify_list, MODULE_STATE_GOING, mod);
>
> >
> >>
> >>> - klp_module_going(mod);
> >>> bug_cleanup:
> >>> mod->state = MODULE_STATE_GOING;
> >>> /* module_bug_cleanup needs module_mutex protection */
> >>
> >> The patch removes the klp_module_going() cleanup call in load_module().
> >> Similarly, the ftrace_release_mod() call under the ddebug_cleanup label
> >> should be removed and appropriately replaced with a cleanup via
> >> a notifier.
> >>
> > err = prepare_module_state_transaction(mod,
> > MODULE_STATE_UNFORMED, MODULE_STATE_FORMED);
> > if (err)
> > goto ddebug_cleanup;
> >
> > ftrace will be cleanup in blocking_notifier_call_chain_robust rolling back.
> >
> > err = prepare_module_state_transaction(mod,
> > MODULE_STATE_COMING, MODULE_STATE_GOING);
> >
> > each notifier including ftrace and klp will be cleanup in blocking_notifier_call_chain_robust rolling back.
> >
> > if all notifiers are successful in MODULE_STATE_COMING, they all will be clean up in
> > coming_cleanup:
> > mod->state = MODULE_STATE_GOING;
> > destroy_params(mod->kp, mod->num_kp);
> > blocking_notifier_call_chain(&module_notify_list,
> > MODULE_STATE_GOING, mod);
> >
> > if something wrong underneath.
>
> My point is that the patch leaves a call to ftrace_release_mod() in
> load_module(), which I expected to be handled via a notifier.
I think that I have got it. The ftrace code needs two notifiers when
the module is being loaded and two when it is going.
This is why Sond added the new state. But I think that we would
need two new states to call:
+ ftrace_module_init() in MODULE_STATE_UNFORMED
+ ftrace_module_enable() in MODULE_STATE_FORMED
and
+ ftrace_free_mem() in MODULE_STATE_PRE_GOING
+ ftrace_free_mem() in MODULE_STATE_GOING
By using the ascii art:
-*> UNFORMED -*> FORMED -> COMING -*> LIVE -*> PRE_GOING -*> GOING -.
| | | ^ ^ ^
| | '----------------' | |
| '--------------------------------------' |
'------------------------------------------------------'
But I think that this is not worth it.
Best Regards,
Petr
^ permalink raw reply
* [PATCH v2] cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
From: Yuho Choi @ 2026-04-16 14:46 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar; +Cc: linux-pm, linux-kernel, Yuho Choi
pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the
two-phase _OSC negotiation. Between the two calls it freed
output.pointer but left output.length unchanged. Since
acpi_evaluate_object() treats a non-zero length with a non-NULL
pointer as an existing buffer to write into, the second call wrote
into freed memory (use-after-free). The subsequent kfree(output.pointer)
at out_free then freed the same pointer a second time (double free).
Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER
after freeing the first result, so ACPICA allocates a fresh buffer for
each phase independently.
Fixes: 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
Changes in v1:
- Drop spurious #include "acpi/actypes.h" (Zhongqiu Han)
- Keep kfree() between the two calls and reset output.pointer = NULL
and output.length = ACPI_ALLOCATE_BUFFER
drivers/cpufreq/pcc-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index ac2e90a65f0c4..a355ec4f3dd4c 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -352,6 +352,8 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
}
kfree(output.pointer);
+ output.pointer = NULL;
+ output.length = ACPI_ALLOCATE_BUFFER;
capabilities[0] = 0x0;
capabilities[1] = 0x1;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v1] cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
From: 최유호 @ 2026-04-16 14:30 UTC (permalink / raw)
To: Zhongqiu Han; +Cc: Rafael J . Wysocki, Viresh Kumar, linux-pm, linux-kernel
In-Reply-To: <952b0192-4ba8-45ae-a71a-79854d558702@oss.qualcomm.com>
Dear Zhongqiu Han,
> 1. I don't see why this header is needed for this change. Even if it is,
> it's already included by <linux/acpi.h>, right?
You are right, it is unnecessary. I will drop it in v2.
> 2. Would it be cleaner to reset the pointer and output.length, and let
> acpi_evaluate_object() reallocate the buffer?
Agreed, that is cleaner and makes the intent explicit. I will adopt
your suggestion in v2.
> 3. The sashiko.dev pointed out a few pre-existing boundary checking
> issues that are outside the scope of this patch.
Noted. I will address those in a separate patch.
Thanks for the review.
Best regards,
Yuho Choi
On Thu, 16 Apr 2026 at 02:04, Zhongqiu Han
<zhongqiu.han@oss.qualcomm.com> wrote:
>
> On 4/16/2026 12:51 AM, Yuho Choi wrote:
> > pcc_cpufreq_do_osc() evaluates _OSC twice with the same output buffer.
> > The first acpi_evaluate_object() allocates the buffer because output is
> > initialized with ACPI_ALLOCATE_BUFFER. Freeing output.pointer before the
> > second evaluation leaves output.length stale, so the next call treats
> > output as a caller-supplied buffer and performs a use-after-free write
> > into the freed memory. The final cleanup path then frees the same
> > pointer again, causing a double free.
> >
> > Keep the first _OSC result alive until the shared cleanup path and route
> > the early error exits through out_free. This avoids both the use-after-
> > free on the second evaluation and the final double free.
> >
> > Fixes: 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
> > Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> > ---
> > drivers/cpufreq/pcc-cpufreq.c | 14 +++++++++-----
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
> > index ac2e90a65f0c4..165826b5d6844 100644
> > --- a/drivers/cpufreq/pcc-cpufreq.c
> > +++ b/drivers/cpufreq/pcc-cpufreq.c
> > @@ -23,6 +23,7 @@
> > * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > */
>
> Hi Yuho Choi,
> Thanks for the patch.
>
> >
> > +#include "acpi/actypes.h"
>
> 1.I don't see why this header is needed for this change. Even if it is,
> it’s already included by <linux/acpi.h>, right?
>
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/init.h>
> > @@ -351,16 +352,19 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
> > goto out_free;
> > }
> >
> > - kfree(output.pointer);
>
> 2.Would it be cleaner to reset the pointer and output.length, and let
> acpi_evaluate_object() reallocate the buffer? For example:
>
> kfree(output.pointer);
> + output.pointer = NULL;
> + output.length = ACPI_ALLOCATE_BUFFER;
>
>
>
> 3.The sashiko.dev pointed out a few pre-existing boundary checking
> issues that are outside the scope of this patch.
>
> https://sashiko.dev/#/patchset/20260415165139.14113-1-dbgh9129%40gmail.com
>
> > capabilities[0] = 0x0;
> > capabilities[1] = 0x1;
> >
> > status = acpi_evaluate_object(*handle, "_OSC", &input, &output);
> > - if (ACPI_FAILURE(status))
> > - return -ENODEV;
> > + if (ACPI_FAILURE(status)) {
> > + ret = -ENODEV;
> > + goto out_free;
> > + }
> >
> > - if (!output.length)
> > - return -ENODEV;
> > + if (!output.length) {
> > + ret = -ENODEV;
> > + goto out_free;
> > + }
> >
> > out_obj = output.pointer;
> > if (out_obj->type != ACPI_TYPE_BUFFER) {
>
>
> --
> Thx and BRs,
> Zhongqiu Han
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sdm632: Correct power domains
From: Konrad Dybcio @ 2026-04-16 13:34 UTC (permalink / raw)
To: Barnabás Czémán, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Ulf Hansson, Mathieu Poirier,
Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <20260327-sdm632-rpmpd-v1-7-6098dc997d66@mainlining.org>
On 3/27/26 9:11 PM, Barnabás Czémán wrote:
> SDM632 is using different pm domains from MSM8953 override them
> where it is needed.
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
> arch/arm64/boot/dts/qcom/sdm632.dtsi | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm632.dtsi b/arch/arm64/boot/dts/qcom/sdm632.dtsi
> index 40d86d91b67f..b1dbcffd51b6 100644
> --- a/arch/arm64/boot/dts/qcom/sdm632.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm632.dtsi
> @@ -87,3 +87,34 @@ opp-725000000 {
> required-opps = <&rpmpd_opp_turbo>;
> };
> };
> +
> +&lpass {
> + power-domains = <&rpmpd SDM632_VDDCX>;
> + power-domain-names = "cx";
> +};
> +
> +&mpss {
> + compatible = "qcom,sdm632-mss-pil";
> + power-domains = <&rpmpd SDM632_VDDCX>,
> + <&rpmpd SDM632_VDDMX>,
> + <&rpmpd SDM632_VDDMD>;
> + power-domain-names = "cx", "mx", "mss";
nit: one a line would be perfect
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Herve Codina @ 2026-04-16 13:34 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Chen-Yu Tsai, Andy Shevchenko, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <4yockfx5rjcvfh2n2excrgsknnhi72rv2w7wf7onks2ryt33sm@w7zkcxuc6vem>
Hi Manivannan,
On Thu, 16 Apr 2026 14:25:39 +0530
Manivannan Sadhasivam <mani@kernel.org> wrote:
> On Wed, Apr 15, 2026 at 04:56:51PM +0200, Herve Codina wrote:
> > Hi Chen, all,
> >
> > ...
> >
> > >
> > > I'm not arguing for a even more generic "M.2" connector. The "key" is
> > > already described in the compatible. I'm saying we should have some way
> > > of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> > > on the connector so further nodes or properties can be attached to them,
> > > either with overlays or dynamically within the kernel. Right now the
> > > are only described as individual ports, but we can't actually tie a
> > > device to a OF graph port.
> > >
> > > But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> > > UART-based BT bit part, Mani just had the driver create a device node
> > > under the UART (by traversing the OF graph to find the UART). If that's
> > > the desired way then the connector binding should mention it. And that
> > > works for me. But I think it's messier and also we're missing an
> > > opportunity to make the M.2 connector a standardized attachment point
> > > for overlays.
> > >
> > > Mani, could you also chime in a bit on what you envisioned?
> > >
> > > (Added Luca from Bootlin to CC, as I think there are parallels to the
> > > "Hotplug of Non-discoverable Hardware" work)
> > >
> >
> > Related to "Hotplug of Non-discoverable Hardware",
> >
> > I would add entries for busses in the connector without using an OF graph.
> >
>
> I don't think this is a correct representation. It is non-standard to describe
> the device nodes in some other connectors. While it may work with your series in
> the future, not something I would bet-on at this point.
>
> Using OF graph to link the connector nodes look like the cleaner solution to me.
In your DT binding, there is the i2c-parent property at connector level.
How it is used or planned to be used in order to handle devices available on the
board connected to the M2 connector ?
>
> > For I2C and later SPI, this was is done.
> >
> > You already have an i2c-parent property but no node where an i2c device
> > can be added.
> >
> > The last discussion related to hotplug, connectors and DT led to the RFC
> > series [1].
> >
> > It is a huge series. The last patch give a real example of representation:
> > https://lore.kernel.org/all/20260112142009.1006236-78-herve.codina@bootlin.com/
> >
> > In your case I would see some thing like:
> >
> > connector {
> > compatible = "pcie-m2-e-connector";
> > vpcie3v3-supply = <&vreg_wcn_3p3>;
> > vpcie1v8-supply = <&vreg_l15b_1p8>;
> >
> > /*
> > * If those GPIOs have to be used by components available in
> > * the connected board, a Nexus node should be used.
> > */
> > w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>;
> > w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
> > viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
> > uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
> > sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
> > sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>;
> >
> > conn-i2c {
> > i2c-parent = <&i2c0>;
> >
> > /*
> > * Here i2c devices available on the board
> > * connected to the connector can be described.
> > */
> > };
> >
> > /* Same kind to description for other busses */
> > conn-pcie {
> > pci-parent = <&xxxxx>;
> >
> > /*
> > * The PCIe bus has abilities to discover devices.
> > * Not sure this node is needed.
> > *
> > * If a PCI device need a DT description to describe
> > * stuffs behind the device, what has been done for LAN966x
> > * could be re-used [2] and [3]
> > */
>
> I don't think anyone would connect something like LAN966x to the M.2 connector.
> M.2 cards have a defined purpose, like NVMe, WLAN etc... If anyone wants to
> connect another SoC like LAN966x, they would use non-M.2 connectors.
Hum, maybe yes, maybe not. I don't know what kind of hardware could be available
on a M2 connector.
One think sure is that a PCIe bus is available on the connector and so, potentially
all PCI devices could be wired on a M2 form factor.
LAN966x in PCI version is just a PCI device.
Anyway, Is it allowed to have sub-nodes in a port node ?
I mean, can we describe devices connected to a bus described by the port node ?
For USB and PCI it is probably not needed for common use cases but having a DT
description for devices on PCI and/or USB exists and is supported in the current
kernel
On SDIO, wireless devices can be described:
Documentation/devicetree/bindings/net/wireless/
and so, sub-nodes will be needed.
As those devices need an address (reg property), #address-cells and
#size-cells will be needed.
This will end in a mix of sub-nodes describing devices and a sub-node
describing the endpoint connection.
#address-cells and #size-cells will conflict at some points.
Is a reg value for endpoints has the same characteristics as a reg value
for a SDIO device ?
How a BT devices is described under the UART available in the M2
connector ?
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 4/7] arm64: dts: qcom: msm8953: fix modem pm domains
From: Konrad Dybcio @ 2026-04-16 13:33 UTC (permalink / raw)
To: Dmitry Baryshkov, Barnabás Czémán
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <i6lymgal5c62ud3aas3qvzv6fjnjrzuncguwechraahmflr45l@5t5qli3k7npu>
On 3/27/26 9:35 PM, Dmitry Baryshkov wrote:
> On Fri, Mar 27, 2026 at 09:11:46PM +0100, Barnabás Czémán wrote:
>> MSM8953 MSS is using mss-supply as regulator.
>
> "On MSM8953 MSS regulators is controlled using the voltages rather than
> performance levels. Correct DT definition and model the MSS as a
> regulator rather than a power domain".
>
> Also please squash with the changes actually making use of the
> regulator.
+1
Konrad
^ permalink raw reply
* Re: [PATCH 6/7] remoteproc: qcom_q6v5_mss: Add SDM632 MSS
From: Konrad Dybcio @ 2026-04-16 13:32 UTC (permalink / raw)
To: Barnabás Czémán, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Ulf Hansson, Mathieu Poirier,
Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <20260327-sdm632-rpmpd-v1-6-6098dc997d66@mainlining.org>
On 3/27/26 9:11 PM, Barnabás Czémán wrote:
> Add support for SDM632 mss, it is very similar to MSM8953 mss only
> difference SDM632 is using mss-supply as pm domain.
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 3/7] remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953
From: Konrad Dybcio @ 2026-04-16 13:32 UTC (permalink / raw)
To: Barnabás Czémán, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Ulf Hansson, Mathieu Poirier,
Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <20260327-sdm632-rpmpd-v1-3-6098dc997d66@mainlining.org>
On 3/27/26 9:11 PM, Barnabás Czémán wrote:
> MSM8953 MSS is using mss-supply as regulator what is usually pm8953_s1.
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
> drivers/remoteproc/qcom_q6v5_mss.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 4e9eb5bd11fa..86edd826ede8 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -2705,6 +2705,14 @@ static const struct rproc_hexagon_res msm8953_mss = {
> },
> {}
> },
> + .active_supply = (struct qcom_mss_reg_res[]) {
> + {
> + .supply = "mss",
> + .uV = 1050000,
> + .uA = 100000,
I don't know if it's a typo, but msm8953-regulator.dtsi on msm-3.18
suggests one more zero
Konrad
^ permalink raw reply
* [PATCH] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Thierry Reding @ 2026-04-16 13:18 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-tegra, linux-arm-kernel, linux-pm, linux-omap, linux-kernel,
Paul Walmsley
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while back. Paul did a much better job at
finding the right words to mourn this loss than I ever could, so I will
leave this link here:
https://lore.kernel.org/lkml/alpine.DEB.2.21.999.2407240345480.11116@utopia.booyaka.com/T/#u
Co-developed-by: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
CREDITS | 6 ++++++
MAINTAINERS | 1 -
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/CREDITS b/CREDITS
index 885fb05d8816..29fcfa679430 100644
--- a/CREDITS
+++ b/CREDITS
@@ -3645,7 +3645,13 @@ D: Macintosh IDE Driver
N: Peter De Schrijver
E: stud11@cc4.kuleuven.ac.be
+E: p2@mind.be
+E: peter.de-schrijver@nokia.com
+E: pdeschrijver@nvidia.com
+E: p2@psychaos.be
D: Mitsumi CD-ROM driver patches March version
+D: OMAP power management
+D: NVIDIA Tegra clock and BPMP drivers, among many other things
S: Molenbaan 29
S: B2240 Zandhoven
S: Belgium
diff --git a/MAINTAINERS b/MAINTAINERS
index ef978bfca514..ffe20d770249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26145,7 +26145,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
N: [^a-z]tegra
TEGRA CLOCK DRIVER
-M: Peter De Schrijver <pdeschrijver@nvidia.com>
M: Prashant Gaikwad <pgaikwad@nvidia.com>
S: Supported
F: drivers/clk/tegra/
--
2.52.0
^ permalink raw reply related
* Re: [RFC PATCH 2/2] kernel/module: Decouple klp and ftrace from load_module
From: Petr Mladek @ 2026-04-16 13:09 UTC (permalink / raw)
To: Song Chen
Cc: Petr Pavlu, rafael, lenb, mturquette, sboyd, viresh.kumar, agk,
snitzer, mpatocka, bmarzins, song, yukuai, linan122, jason.wessel,
danielt, dianders, horms, davem, edumazet, kuba, pabeni, paulmck,
frederic, mcgrof, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, joe.lawrence, rostedt, mhiramat, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <a35f5f94-7d5a-4347-974b-b270c89ef241@189.cn>
On Wed 2026-04-15 14:43:53, Song Chen wrote:
> Hi,
>
> On 4/14/26 22:33, Petr Pavlu wrote:
> > On 4/13/26 10:07 AM, chensong_2000@189.cn wrote:
> > > From: Song Chen <chensong_2000@189.cn>
> > >
> > > ftrace and livepatch currently have their module load/unload callbacks
> > > hard-coded in the module loader as direct function calls to
> > > ftrace_module_enable(), klp_module_coming(), klp_module_going()
> > > and ftrace_release_mod(). This tight coupling was originally introduced
> > > to enforce strict call ordering that could not be guaranteed by the
> > > module notifier chain, which only supported forward traversal. Their
> > > notifiers were moved in and out back and forth. see [1] and [2].
> >
> > I'm unclear about what is meant by the notifiers being moved back and
> > forth. The links point to patches that converted ftrace+klp from using
> > module notifiers to explicit callbacks due to ordering issues, but this
> > switch occurred only once. Have there been other attempts to use
> > notifiers again?
> >
> > > diff --git a/include/linux/module.h b/include/linux/module.h
> > > index 14f391b186c6..0bdd56f9defd 100644
> > > --- a/include/linux/module.h
> > > +++ b/include/linux/module.h
> > > @@ -308,6 +308,14 @@ enum module_state {
> > > MODULE_STATE_COMING, /* Full formed, running module_init. */
> > > MODULE_STATE_GOING, /* Going away. */
> > > MODULE_STATE_UNFORMED, /* Still setting it up. */
> > > + MODULE_STATE_FORMED,
> >
> > I don't see a reason to add a new module state. Why is it necessary and
> > how does it fit with the existing states?
> >
> because once notifier fails in state MODULE_STATE_UNFORMED (now only ftrace
> has someting to do in this state), notifier chain will roll back by calling
> blocking_notifier_call_chain_robust, i'm afraid MODULE_STATE_GOING is going
> to jeopardise the notifers which don't handle it appropriately, like:
>
> case MODULE_STATE_COMING:
> kmalloc();
> case MODULE_STATE_GOING:
> kfree();
>
>
> > > +};
> > > +
> > > +enum module_notifier_prio {
> > > + MODULE_NOTIFIER_PRIO_LOW = INT_MIN, /* Low prioroty, coming last, going first */
> > > + MODULE_NOTIFIER_PRIO_MID = 0, /* Normal priority. */
> > > + MODULE_NOTIFIER_PRIO_SECOND_HIGH = INT_MAX - 1, /* Second high priorigy, coming second*/
> > > + MODULE_NOTIFIER_PRIO_HIGH = INT_MAX, /* High priorigy, coming first, going late. */
> >
> > I suggest being explicit about how the notifiers are ordered. For
> > example:
> >
> > enum module_notifier_prio {
> > MODULE_NOTIFIER_PRIO_NORMAL, /* Normal priority, coming last, going first. */
> > MODULE_NOTIFIER_PRIO_LIVEPATCH,
> > MODULE_NOTIFIER_PRIO_FTRACE, /* High priority, coming first, going late. */
> > };
> >
I like the explicit PRIO_LIVEPATCH/FTRACE names.
But I would keep the INT_MAX - 1 and INT_MAX priorities. I believe
that ftrace/livepatching will always be the first/last to call.
And INT_MAX would help to preserve kABI when PRIO_NORMAL is not
enough for the rest of notifiers.
That said, I am not sure whether this is worth the effort.
This patch tries to move the explicit callbacks in a generic
notifiers API. But it will still need to use some explictly
defined (reserved) priorities. And it will
not guarantee a misuse. Also it requires the double linked
list which complicates the notifiers code.
> > > };
> > > struct mod_tree_node {
> > > --- a/kernel/module/main.c
> > > +++ b/kernel/module/main.c
> > > @@ -3281,20 +3277,14 @@ static int complete_formation(struct module *mod, struct load_info *info)
> > > return err;
> > > }
> > > -static int prepare_coming_module(struct module *mod)
> > > +static int prepare_module_state_transaction(struct module *mod,
> > > + unsigned long val_up, unsigned long val_down)
> > > {
> > > int err;
> > > - ftrace_module_enable(mod);
> > > - err = klp_module_coming(mod);
> > > - if (err)
> > > - return err;
> > > -
> > > err = blocking_notifier_call_chain_robust(&module_notify_list,
> > > - MODULE_STATE_COMING, MODULE_STATE_GOING, mod);
> > > + val_up, val_down, mod);
> > > err = notifier_to_errno(err);
> > > - if (err)
> > > - klp_module_going(mod);
> > > return err;
> > > }
I personally find the name "prepare_module_state_transaction"
misleading. What is the "transaction" here? If this was a "preparation"
step then where is the transaction done/finished?
It might be better to just opencode the
blocking_notifier_call_chain_robust() instead.
> > > @@ -3468,14 +3458,21 @@ static int load_module(struct load_info *info, const char __user *uargs,
> > > init_build_id(mod, info);
> > > /* Ftrace init must be called in the MODULE_STATE_UNFORMED state */
> > > - ftrace_module_init(mod);
> > > + err = prepare_module_state_transaction(mod,
> > > + MODULE_STATE_UNFORMED, MODULE_STATE_FORMED);
> >
> > I believe val_down should be MODULE_STATE_GOING to reverse the
> > operation. Why is the new state MODULE_STATE_FORMED needed here?
> to avoid this:
>
> case MODULE_STATE_COMING:
> kmalloc();
> case MODULE_STATE_GOING:
> kfree();
Hmm, the module is in "FORMED" state here.
> > > + if (err)
> > > + goto ddebug_cleanup;
> > > /* Finally it's fully formed, ready to start executing. */
> > > err = complete_formation(mod, info);
And we call "complete_formation()" function. This sounds like
it was not really "FORMED" before. => It is confusing and nono.
Please, try to avoid the new state if possible. My experience
with reading the module loader code is that any new state
brings a lot of complexity. You need to take it into account
when checking correctness of other changes, features, ...
Something tells me that if the state was not needed before
then we could avoid it.
> > > - if (err)
> > > + if (err) {
> > > + blocking_notifier_call_chain_reverse(&module_notify_list,
> > > + MODULE_STATE_FORMED, mod);
> > > goto ddebug_cleanup;
> > > + }
> > > - err = prepare_coming_module(mod);
> > > + err = prepare_module_state_transaction(mod,
> > > + MODULE_STATE_COMING, MODULE_STATE_GOING);
> > > if (err)
> > > goto bug_cleanup;
> > > --- a/kernel/trace/ftrace.c
> > > +++ b/kernel/trace/ftrace.c
> > > @@ -5241,6 +5241,44 @@ static int __init ftrace_mod_cmd_init(void)
> > > }
> > > core_initcall(ftrace_mod_cmd_init);
> > > +static int ftrace_module_callback(struct notifier_block *nb, unsigned long op,
> > > + void *module)
> > > +{
> > > + struct module *mod = module;
> > > +
> > > + switch (op) {
> > > + case MODULE_STATE_UNFORMED:
> > > + ftrace_module_init(mod);
> > > + break;
> > > + case MODULE_STATE_COMING:
> > > + ftrace_module_enable(mod);
> > > + break;
> > > + case MODULE_STATE_LIVE:
> > > + ftrace_free_mem(mod, mod->mem[MOD_INIT_TEXT].base,
> > > + mod->mem[MOD_INIT_TEXT].base + mod->mem[MOD_INIT_TEXT].size);
> > > + break;
> > > + case MODULE_STATE_GOING:
> > > + case MODULE_STATE_FORMED:
> > > + ftrace_release_mod(mod);
This calls "release" in a "FORMED" state. It does not make any
sense. Something looks fishy, either the code or the naming.
> > > + break;
> > > + default:
> > > + break;
> > > + }
> >
I am sorry for being so picky about names. I believe that good names
help to prevent bugs and reduce headaches.
Best Regards,
Petr
^ permalink raw reply
* [PATCH] interconnect: Do not create empty devres on missing interconnects
From: Krzysztof Kozlowski @ 2026-04-16 13:09 UTC (permalink / raw)
To: Georgi Djakov, linux-pm, linux-kernel; +Cc: Krzysztof Kozlowski
of_icc_get() returns NULL on valid case - no interconnects - but no
need to create devres for that, because it just wastes memory without
any use/benefits.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/interconnect/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 8569b78a1851..ce572c62f58f 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -432,7 +432,7 @@ struct icc_path *devm_of_icc_get(struct device *dev, const char *name)
return ERR_PTR(-ENOMEM);
path = of_icc_get(dev, name);
- if (!IS_ERR(path)) {
+ if (!IS_ERR_OR_NULL(path)) {
*ptr = path;
devres_add(dev, ptr);
} else {
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Felix Gu @ 2026-04-16 13:04 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260415-imx-v2-1-aeacff9e72b2@gmail.com>
On Wed, Apr 15, 2026 at 9:10 PM Felix Gu <ustc.gu@gmail.com> wrote:
>
> If pm_runtime_resume_and_get() fails after the thermal zone has been
> registered, the probe error path cleans up runtime PM but skips
> thermal_zone_device_unregister(), leaking the thermal zone device.
>
> Switch to use devm_thermal_of_zone_register() to fix the problem.
>
> Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/thermal/imx_thermal.c | 35 +++++++++++++++++++----------------
> 1 file changed, 19 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index 38c993d1bcb3..3729c3eac748 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -216,6 +216,20 @@ struct imx_thermal_data {
> const char *temp_grade;
> };
>
> +static int imx_thermal_sync_zone_trip(struct thermal_trip *trip, void *arg)
> +{
> + struct imx_thermal_data *data = arg;
> + int temp;
> +
> + if (trip->type != THERMAL_TRIP_PASSIVE && trip->type != THERMAL_TRIP_CRITICAL)
> + return 0;
> +
> + temp = trips[trip->type].temperature;
> + thermal_zone_set_trip_temp(data->tz, trip, temp);
> +
> + return 0;
> +}
> +
> static void imx_set_panic_temp(struct imx_thermal_data *data,
> int panic_temp)
> {
> @@ -679,13 +693,8 @@ static int imx_thermal_probe(struct platform_device *pdev)
> goto legacy_cleanup;
> }
>
> - data->tz = thermal_zone_device_register_with_trips("imx_thermal_zone",
> - trips,
> - ARRAY_SIZE(trips),
> - data,
> - &imx_tz_ops, NULL,
> - IMX_PASSIVE_DELAY,
> - IMX_POLLING_DELAY);
> + data->irq_enabled = true;
> + data->tz = devm_thermal_of_zone_register(dev, 0, data, &imx_tz_ops);
> if (IS_ERR(data->tz)) {
> ret = PTR_ERR(data->tz);
> dev_err(dev, "failed to register thermal zone device %d\n",
> @@ -693,6 +702,8 @@ static int imx_thermal_probe(struct platform_device *pdev)
> goto clk_disable;
> }
>
> + thermal_zone_for_each_trip(data->tz, imx_thermal_sync_zone_trip, data);
> +
> dev_info(dev, "%s CPU temperature grade - max:%dC"
> " critical:%dC passive:%dC\n", data->temp_grade,
> data->temp_max / 1000, trips[IMX_TRIP_CRITICAL].temperature / 1000,
> @@ -724,25 +735,18 @@ static int imx_thermal_probe(struct platform_device *pdev)
> if (ret < 0)
> goto disable_runtime_pm;
>
> - data->irq_enabled = true;
> - ret = thermal_zone_device_enable(data->tz);
> - if (ret)
> - goto thermal_zone_unregister;
> -
> ret = devm_request_threaded_irq(dev, data->irq,
> imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
> 0, "imx_thermal", data);
> if (ret < 0) {
> dev_err(dev, "failed to request alarm irq: %d\n", ret);
> - goto thermal_zone_unregister;
> + goto disable_runtime_pm;
> }
>
> pm_runtime_put(data->dev);
>
> return 0;
>
> -thermal_zone_unregister:
> - thermal_zone_device_unregister(data->tz);
> disable_runtime_pm:
> pm_runtime_put_noidle(data->dev);
> pm_runtime_disable(data->dev);
> @@ -761,7 +765,6 @@ static void imx_thermal_remove(struct platform_device *pdev)
> pm_runtime_put_noidle(data->dev);
> pm_runtime_disable(data->dev);
>
> - thermal_zone_device_unregister(data->tz);
> imx_thermal_unregister_legacy_cooling(data);
> }
>
>
> --
> 2.43.0
>
Hi all,
This patch has a problem, I will fix it and send v3.
Best regards,
Felix
^ permalink raw reply
* Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Krzysztof Kozlowski @ 2026-04-16 12:30 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Julia Lawall, Nicolas Palix
In-Reply-To: <20260310-b4-is_err_or_null-v1-1-bd63b656022d@avm.de>
On 10/03/2026 12:48, Philipp Hahn wrote:
> Find and convert uses of IS_ERR() plus NULL check to IS_ERR_OR_NULL().
>
> There are several cases where `!ptr && WARN_ON[_ONCE](IS_ERR(ptr))` is
> used:
> - arch/x86/kernel/callthunks.c:215 WARN_ON_ONCE
> - drivers/clk/clk.c:4561 WARN_ON_ONCE
> - drivers/interconnect/core.c:793 WARN_ON
> - drivers/reset/core.c:718 WARN_ON
> The change is not 100% semantical equivalent as the warning will now
> also happen when the pointer is NULL.
>
> To: Julia Lawall <Julia.Lawall@inria.fr>
> To: Nicolas Palix <nicolas.palix@imag.fr>
> Cc: cocci@inria.fr
> Cc: linux-kernel@vger.kernel.org
>
> ---
> drivers/clocksource/mips-gic-timer.c:283 looks suspicious: ret != clk,
> but Daniel Lezcano verified it as cottect.
>
> There are some cases where the checks are part of a larger expression:
> - mm/kmemleak.c:1095
> - mm/kmemleak.c:1155
> - mm/kmemleak.c:1173
> - mm/kmemleak.c:1290
> - mm/kmemleak.c:1328
> - mm/kmemleak.c:1241
> - mm/kmemleak.c:1310
> - mm/kmemleak.c:1258
> - net/netlink/af_netlink.c:2670
> Thanks to Julia Lawall for the help to also handle them.
>
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> scripts/coccinelle/api/is_err_or_null.cocci | 125 ++++++++++++++++++++++++++++
> 1 file changed, 125 insertions(+)
>
Neither this, nor try from 2011, nor any future try should be accepted,
because it creates impression IS_ERR_OR_NULL is somehow okay. No, it is
not okay, it is a discouraged pattern leading to less readable and
maintainable code. We should not have therefore any tools suggesting
usage of IS_ERR_OR_NULL, because people will be converting poor code
into that, instead of fixing that poor code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: David Laight @ 2026-04-16 12:30 UTC (permalink / raw)
To: chensong_2000
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, pmladek, joe.lawrence, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260415070137.17860-1-chensong_2000@189.cn>
On Wed, 15 Apr 2026 15:01:37 +0800
chensong_2000@189.cn wrote:
> From: Song Chen <chensong_2000@189.cn>
>
> The current notifier chain implementation uses a single-linked list
> (struct notifier_block *next), which only supports forward traversal
> in priority order. This makes it difficult to handle cleanup/teardown
> scenarios that require notifiers to be called in reverse priority order.
If it is only cleanup/teardown then the list can be order-reversed
as part of that process at the same time as the list is deleted.
David
^ permalink raw reply
* Re: [PATCH 55/61] interconnect: Prefer IS_ERR_OR_NULL over manual NULL check
From: Krzysztof Kozlowski @ 2026-04-16 12:24 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Georgi Djakov
In-Reply-To: <20260310-b4-is_err_or_null-v1-55-bd63b656022d@avm.de>
On 10/03/2026 12:49, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Semantich change: Previously the code only printed the warning on error,
> but not when the pointer was NULL. Now the warning is printed in both
> cases!
NAK, read the code
>
> Change found with coccinelle.
>
> To: Georgi Djakov <djakov@kernel.org>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/interconnect/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 8569b78a18517b33abeafac091978b25cbc1acc7..22e92b30f73853d5bd2e05b4f52cb5aa22556468 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -790,7 +790,7 @@ void icc_put(struct icc_path *path)
> size_t i;
> int ret;
>
> - if (!path || WARN_ON(IS_ERR(path)))
> + if (WARN_ON(IS_ERR_OR_NULL(path)))
IS_ERR_OR_NULL is simply discouraged, but beside of code preference, you
just added bug here. This is clearly not equivalent and you emit warn on
perfectly valid case!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 02/13] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-04-16 12:15 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260416-upbeat-archetypal-mantis-1ede48@quoll>
On 2026-04-16 10:23 +02:00, Krzysztof Kozlowski wrote:
> On Wed, Apr 15, 2026 at 11:00:16PM +0530, Kaustabh Chakraborty wrote:
>> On 2026-04-15 09:03 +02:00, Krzysztof Kozlowski wrote:
>> > On Tue, Apr 14, 2026 at 12:02:54PM +0530, Kaustabh Chakraborty wrote:
>> >> +description: |
>> >> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>> >> + 8-bit brightness control for each channel, typically used as status
>> >> + indicators in mobile phones.
>> >> +
>> >> + This is a part of device tree bindings for S2M and S5M family of Power
>> >> + Management IC (PMIC).
>> >> +
>> >> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> >> + additional information and example.
>> >> +
>> >> +allOf:
>> >> + - $ref: common.yaml#
>> >
>> > Rob's comment is still valid:
>> > 1. How do you address one of three LEDs in non-RGB case?
>> > 2. Where is multi-color?
>>
>> Yes, multi-color should have been added here.
>>
>> >
>> > And based on this alone without other properties, I say this should be
>> > part of top-level schema. Separate node is fine, but no need for
>> > separate binding.
>>
>> BTW, for loading the sub-device driver via platform (as it won't be a
>> separate binding) the driver *must* be built-in. Although not related to
>> bindings, this seems counter-intuitive. I see the same problem with the
>
> I don't understand that comment. If it has nothing to do with the
> binding, what is the problem?
It was an unrelated user-space issue, so ignore.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Rob Herring (Arm) @ 2026-04-16 12:03 UTC (permalink / raw)
To: Kevin Hilman (TI)
Cc: devicetree, Ulf Hansson, linux-arm-kernel, linux-pm, linux-kernel,
arm-scmi, Geert Uytterhoeven
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-1-83396e4b5f8b@baylibre.com>
On Fri, 10 Apr 2026 16:44:36 -0700, Kevin Hilman (TI) wrote:
> Add binding documentation for the new power-domains-child-ids property,
> which works in conjunction with the existing power-domains property to
> establish parent-child relationships between a multi-domain power domain
> provider and external parent domains.
>
> Each element in the uint32 array identifies the child domain
> ID (index) within the provider that should be made a child domain of
> the corresponding phandle entry in power-domains. The two arrays must
> have the same number of elements.
>
> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
> ---
> Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: thermal: Fix false warning with 'phandle' in trips nodes
From: Rob Herring (Arm) @ 2026-04-16 12:03 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Daniel Lezcano, Zhang Rui, Krzysztof Kozlowski, Lukasz Luba,
Rafael J. Wysocki, linux-pm, Conor Dooley, linux-kernel,
devicetree
In-Reply-To: <20260410223601.1487473-2-robh@kernel.org>
On Fri, 10 Apr 2026 17:36:00 -0500, Rob Herring (Arm) wrote:
> A pattern property matching essentially anything doesn't work if there
> are implicit properties such as 'phandle' which can occur on any node.
> One such example popped up recently:
>
> arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: thermal-zones: gpuss0-thermal:trips:phandle: 531 is not of type 'object'
> from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml
>
> Instead of a pattern property, use an "additionalProperties" schema
> instead which is the fallback in case of no matching property.
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> Daniel, Please pick this up for v7.1 as the above warning is in next. Or
> if you prefer, I can take it.
>
> .../bindings/thermal/thermal-zones.yaml | 111 +++++++++---------
> 1 file changed, 54 insertions(+), 57 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Anand Moon @ 2026-04-16 11:37 UTC (permalink / raw)
To: Shuwei Wu
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, linux-pm, linux-kernel, linux-riscv,
spacemit, devicetree
In-Reply-To: <DHUCL24GMX7D.369IWK9DLPZPX@mailbox.org>
Hi Shuwei,
Thanks for sharing the details.
On Thu, 16 Apr 2026 at 11:29, Shuwei Wu <shuwei.wu@mailbox.org> wrote:
>
> On Tue Apr 14, 2026 at 9:25 PM CST, Anand Moon wrote:
> > Hi Shuwei,
> >
> > On Fri, 10 Apr 2026 at 13:30, Shuwei Wu <shuwei.wu@mailbox.org> wrote:
> >>
> >> Add Operating Performance Points (OPP) tables and CPU clock properties
> >> for the two clusters in the SpacemiT K1 SoC.
> >>
> >> Also assign the CPU power supply (cpu-supply) for the Banana Pi BPI-F3
> >> board to fully enable CPU DVFS.
> >>
> >> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
> >>
> >> ---
> >> Changes in v2:
> >> - Add k1-opp.dtsi with OPP tables for both CPU clusters
> >> - Assign CPU supplies and include OPP table for Banana Pi BPI-F3
> >> ---
> >> arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
> >> arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
> >> arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
> >> 3 files changed, 147 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> >> index 444c3b1e6f44..3780593f610d 100644
> >> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> >> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> >> @@ -5,6 +5,7 @@
> >>
> >> #include "k1.dtsi"
> >> #include "k1-pinctrl.dtsi"
> >> +#include "k1-opp.dtsi"
> >>
> >> / {
> >> model = "Banana Pi BPI-F3";
> >> @@ -86,6 +87,38 @@ &combo_phy {
> >> status = "okay";
> >> };
> >>
> >> +&cpu_0 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_1 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_2 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_3 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_4 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_5 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_6 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> +&cpu_7 {
> >> + cpu-supply = <&buck1_3v45>;
> >> +};
> >> +
> >> &emmc {
> >> bus-width = <8>;
> >> mmc-hs400-1_8v;
> >> @@ -201,7 +234,7 @@ pmic@41 {
> >> dldoin2-supply = <&buck5>;
> >>
> >> regulators {
> >> - buck1 {
> >> + buck1_3v45: buck1 {
> >> regulator-min-microvolt = <500000>;
> >> regulator-max-microvolt = <3450000>;
> >> regulator-ramp-delay = <5000>;
> >> diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> >> new file mode 100644
> >> index 000000000000..768ae390686d
> >> --- /dev/null
> >> +++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
> >> @@ -0,0 +1,105 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +
> >> +/ {
> >> + cluster0_opp_table: opp-table-cluster0 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp-614400000 {
> >> + opp-hz = /bits/ 64 <614400000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-819000000 {
> >> + opp-hz = /bits/ 64 <819000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1000000000 {
> >> + opp-hz = /bits/ 64 <1000000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1228800000 {
> >> + opp-hz = /bits/ 64 <1228800000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1600000000 {
> >> + opp-hz = /bits/ 64 <1600000000>;
> >> + opp-microvolt = <1050000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> + };
> >> +
> >> + cluster1_opp_table: opp-table-cluster1 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp-614400000 {
> >> + opp-hz = /bits/ 64 <614400000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-819000000 {
> >> + opp-hz = /bits/ 64 <819000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1000000000 {
> >> + opp-hz = /bits/ 64 <1000000000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1228800000 {
> >> + opp-hz = /bits/ 64 <1228800000>;
> >> + opp-microvolt = <950000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> +
> >> + opp-1600000000 {
> >> + opp-hz = /bits/ 64 <1600000000>;
> >> + opp-microvolt = <1050000>;
> >> + clock-latency-ns = <200000>;
> >> + };
> >> + };
> >> +};
> >> +
> >> +&cpu_0 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_1 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_2 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_3 {
> >> + operating-points-v2 = <&cluster0_opp_table>;
> >> +};
> >> +
> >> +&cpu_4 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> +
> >> +&cpu_5 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> +
> >> +&cpu_6 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> +
> >> +&cpu_7 {
> >> + operating-points-v2 = <&cluster1_opp_table>;
> >> +};
> >> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> >> index 529ec68e9c23..bdd109b81730 100644
> >> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> >> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> >> @@ -54,6 +54,7 @@ cpu_0: cpu@0 {
> >> compatible = "spacemit,x60", "riscv";
> >> device_type = "cpu";
> >> reg = <0>;
> >> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> >> riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> >> riscv,isa-base = "rv64i";
> >> riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
> >> @@ -84,6 +85,7 @@ cpu_1: cpu@1 {
> >> compatible = "spacemit,x60", "riscv";
> >> device_type = "cpu";
> >> reg = <1>;
> >> + clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
> >
> > Based on the Spacemit kernel source, the k1-x_opp_table.dtsi file
> > defines several additional clocks for the Operating Performance Points
> > (OPP) table:
> >
> > clocks = <&ccu CLK_CPU_C0_ACE>, <&ccu CLK_CPU_C1_ACE>, <&ccu CLK_CPU_C0_TCM>,
> > <&ccu CLK_CCI550>, <&ccu CLK_PLL3>, <&ccu
> > CLK_CPU_C0_HI>, <&ccu CLK_CPU_C1_HI>;
> > clock-names = "ace0","ace1","tcm","cci","pll3", "c0hi", "c1hi";
> >
> > These hardware clocks are also explicitly registered in the APMU clock driver
> > via the k1_ccu_apmu_hws array, confirming their availability for frequency
> > and voltage scaling on the K1-X SoC.
> >
> > static struct clk_hw *k1_ccu_apmu_hws[] = {
> > [CLK_CCI550] = &cci550_clk.common.hw,
> > [CLK_CPU_C0_HI] = &cpu_c0_hi_clk.common.hw,
> > [CLK_CPU_C0_CORE] = &cpu_c0_core_clk.common.hw,
> > [CLK_CPU_C0_ACE] = &cpu_c0_ace_clk.common.hw,
> > [CLK_CPU_C0_TCM] = &cpu_c0_tcm_clk.common.hw,
> > [CLK_CPU_C1_HI] = &cpu_c1_hi_clk.common.hw,
> > [CLK_CPU_C1_CORE] = &cpu_c1_core_clk.common.hw,
> > [CLK_CPU_C1_ACE] = &cpu_c1_ace_clk.common.hw,
> >
> > Yes, it is possible to add these clocks for DVFS to work correctly,
> > provided they are managed by the appropriate driver and declared in
> > the Device Tree (DT).
> >
> > Thanks
> > -Anand
>
> Thanks for your review and for pointing this out.
>
> Regarding the clocks you mentioned, I'd like to clarify their roles based on
> the K1 datasheet. Taking Cluster 0 as an example, c0_core_clk is the primary
> clock for the cluster. c0_ace_clk and c0_tcm_clk are children derived from it,
> defaulting to half the frequency of their parent core clock, while c0_hi_clk
> represents the high-speed path selection.
> Cluster 1 follows the same structure.
>
> Based on the official SpacemiT Bianbu OS source, the spacemit-cpufreq.c driver
> mainly performs the following tasks:
> 1. Sets the CCI550 clock frequency to 614MHz.
> 2. Sets the clock frequencies of c0_ace_clk, c1_ace1_clk, and c0_tcm_clk to half
> the frequency of their parent clock.
> 3. For the 1.6GHz OPP, it sets the PLL3 frequency to 3.2GHz and the
> c0_hi_clk/c1_hi_clk frequencies to 1.6GHz.
>
> I booted with the manufacturer's OpenWRT image and used debugfs to confirm that
> the clock states are exactly as described above.
>
> At 1.6GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> │ └─ cpu_c1_pclk 1,600,000,000 Y cpu0
> │ └─ cpu_c1_ace_clk 800,000,000 Y deviceless
> └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c0_core_clk 1,600,000,000 Y cpu0
> ├─ cpu_c0_tcm_clk 800,000,000 Y deviceless
> └─ cpu_c0_ace_clk 800,000,000 Y deviceless
>
> pll1_2457p6_vco 2,457,600,000 Y deviceless
> └─ pll1_d4 614,400,000 Y deviceless
> └─ pll1_d4_614p4 614,400,000 Y deviceless
> └─ cci550_clk 614,400,000 Y deviceless
>
> At 1.228GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll1_2457p6_vco 2,457,600,000 Y deviceless
> └─ pll1_d2 1,228,800,000 Y deviceless
> └─ pll1_d2_1228p8 1,228,800,000 Y deviceless
> ├─ cpu_c0_core_clk 1,228,800,000 Y cpu0
> │ ├─ cpu_c0_tcm_clk 614,400,000 Y deviceless
> │ └─ cpu_c0_ace_clk 614,400,000 Y deviceless
> └─ cpu_c1_pclk 1,228,800,000 Y cpu0
> └─ cpu_c1_ace_clk 614,400,000 Y deviceless
> └─ pll1_d4 614,400,000 Y deviceless
> └─ pll1_d4_614p4 614,400,000 Y deviceless
> └─ cci550_clk 614,400,000 Y deviceless
>
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> └─ pll3_d3 1,066,666,666 Y deviceless
>
> Regarding the necessity of listing these clocks in the DT, my analysis is as follows:
> 1. For CCI550, I did not find a clear definition of this clock's specific role
> in the SoC datasheet. Although the vendor kernel increases its frequency,
> my benchmarks show that maintaining the mainline default (245.76MHz) has a
> negligible impact on CPU performance.
> 2. For ACE and TCM clocks, they function as synchronous children of the core
> clock with a default divide-by-2 ratio. Since they scale automatically relative
> to c0_core_clk/c1_core_clk and no other peripherals depend on them, they do not
> require manual management in the OPP table.
> 3. For the high-speed path, the underlying clock controller logic already handles
> the parent MUX switching and PLL3 scaling automatically when clk_set_rate()
> is called on the core clock.
>
> I have verified this by checking the hardware state in the mainline kernel.
> The clock tree matches the vendor kernel's configuration:
>
> At 1.6GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> ├─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> │ └─ cpu_c1_core_clk 1,600,000,000 Y cpu4
> │ └─ cpu_c1_ace_clk 800,000,000 Y deviceless
> └─ cpu_c0_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c0_core_clk 1,600,000,000 Y cpu0
> ├─ cpu_c0_tcm_clk 800,000,000 Y deviceless
> └─ cpu_c0_ace_clk 800,000,000 Y deviceless
>
> pll1 2,457,600,000 Y deviceless
> └─ pll1_d5 491,520,000 Y deviceless
> └─ pll1_d5_491p52 491,520,000 Y deviceless
> └─ cci550_clk 245,760,000 Y deviceless
>
> At 1.228GHz:
> Clock Source & Tree Rate (Hz) HW Enable Consumer
> ---------------------------------------------------------------------------
> pll1 2,457,600,000 Y deviceless
> ├─ pll1_d5 491,520,000 Y deviceless
> │ └─ pll1_d5_491p52 491,520,000 Y deviceless
> │ └─ cci550_clk 245,760,000 Y deviceless
> └─ pll1_d2 1,228,800,000 Y deviceless
> └─ pll1_d2_1228p8 1,228,800,000 Y deviceless
> └─ cpu_c0_core_clk 1,228,800,000 Y cpu0
> ├─ cpu_c0_tcm_clk 614,400,000 Y deviceless
> └─ cpu_c0_ace_clk 614,400,000 Y deviceless
>
> pll3 3,200,000,000 Y deviceless
> └─ pll3_d2 1,600,000,000 Y deviceless
> └─ cpu_c1_hi_clk 1,600,000,000 Y deviceless
> └─ cpu_c1_core_clk 1,600,000,000 Y cpu4
> └─ cpu_c1_ace_clk 800,000,000 Y deviceless
>
Thanks, I have verified the clocks are set to Y in
/sys/kernel/debug/clk/clk_summary
> Performance benchmarks also confirm that the current configuration is sufficient:
> Benchmark (AWK computation): time awk 'BEGIN{for(i=0;i<10000000;i++) sum+=i}'
> ----------------------------------------------------------------------------
> Frequency | Mainline Linux (s) | OpenWrt (s)
> (kHz) | Real (Total) | User (CPU) | Real (Total) | User (CPU) )
> -------------+---------------+---------------+---------------+--------------
> 1,600,000 | 1.82s | 1.81s | 1.73s | 1.73s
> 1,228,800 | 2.34s | 2.33s | 2.26s | 2.26s
> 1,000,000 | 2.94s | 2.86s | 2.78s | 2.78s
> 819,000 | 3.54s | 3.53s | 3.39s | 3.39s
> 614,400 | 4.73s | 4.71s | 4.51s | 4.51s
> ----------------------------------------------------------------------------
>
> In summary, because the clock controller correctly handles the internal dividers
> and parent switching, declaring only the primary core clock for each CPU node is
> sufficient for functional DVFS.
>
I have just tested this patch against next-20260415
But, I have observed this log on the Banana Pi F3 dev board with the
Banana PI - R4 heat sink and fan.
[ 5.803445][ T1] In-situ OAM (IOAM) with IPv6
[ 5.809605][ T1] NET: Registered PF_PACKET protocol family
[ 5.819098][ T1] Key type dns_resolver registered
[ 5.853430][ C2] cpu2: scalar unaligned word access speed is
1.60x byte access speed (fast)
[ 5.853431][ C3] cpu3: scalar unaligned word access speed is
1.67x byte access speed (fast)
[ 5.853440][ C7] cpu7: scalar unaligned word access speed is
8.10x byte access speed (fast)
[ 5.853432][ C1] cpu1: scalar unaligned word access speed is
3.98x byte access speed (fast)
[ 5.853431][ T1] cpu0: scalar unaligned word access speed is
2.33x byte access speed (fast)
[ 5.853436][ C5] cpu5: scalar unaligned word access speed is
2.29x byte access speed (fast)
[ 5.853436][ C6] cpu6: scalar unaligned word access speed is
2.58x byte access speed (fast)
[ 5.853431][ C4] cpu4: scalar unaligned word access speed is
2.07x byte access speed (fast)
[ 5.936544][ T92] mmcblk0boot0: mmc0:0001 AJTD4R 4.00 MiB
[ 6.003120][ T92] mmcblk0boot1: mmc0:0001 AJTD4R 4.00 MiB
[ 6.070909][ T92] mmcblk0rpmb: mmc0:0001 AJTD4R 4.00 MiB, chardev (244:0)
[ 6.380324][ T1] registered taskstats version 1
[ 6.407337][ T1] Loading compiled-in X.509 certificates
[ 6.594206][ T1] Loaded X.509 cert 'Build time autogenerated
kernel key: 19b81ec48e45e6ee983623417bad5096df8bbcf1'
[ 7.600343][ T1] Demotion targets for Node 0: null
[ 7.608583][ T1] kmemleak: Kernel memory leak detector
initialized (mem pool available: 1309)
[ 7.608646][ T120] kmemleak: Automatic memory scanning thread started
[ 7.624663][ T1] debug_vm_pgtable: [debug_vm_pgtable ]:
Validating architecture page table helpers
[ 7.636721][ T1] page_owner is disabled
[ 8.213648][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
in 'domains'
[ 8.233502][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
in 'domains'
[ 8.254012][ T74] debugfs: ':soc:gpio@d4019000-1' already exists
in 'domains'
[ 8.319431][ T74] printk: legacy console [ttyS0] disabled
[ 8.345811][ T74] d4017000.serial: ttyS0 at MMIO 0xd4017000 (irq
= 16, base_baud = 921600) is a XScale
[ 8.357331][ T74] printk: legacy console [ttyS0] enabled
[ 8.357331][ T74] printk: legacy console [ttyS0] enabled
[ 8.369971][ T74] printk: legacy bootconsole [uart0] disabled
[ 8.369971][ T74] printk: legacy bootconsole [uart0] disabled
[ 8.427040][ T74] /soc/i2c@d401d800/pmic@41: Fixed dependency
cycle(s) with /soc/i2c@d401d800/pmic@41/regulators/buck5
[ 8.634595][ T74] spacemit-p1-rtc spacemit-p1-rtc.1.auto:
registered as rtc0
[ 8.642732][ T74] spacemit-p1-rtc spacemit-p1-rtc.1.auto: setting
system clock to 2026-04-10T00:03:42 UTC (1775779422)
[ 8.766081][ T74] sdhci-spacemit d4280000.mmc: Got CD GPIO
[ 8.801855][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.806411][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.813413][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.818261][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.818307][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.827239][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.833161][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 8.842546][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 8.848941][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 8.855273][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 8.893720][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.904437][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 8.908515][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.918057][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 8.924402][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 8.945668][ T74] mmc1: SDHCI controller on d4280000.mmc
[d4280000.mmc] using ADMA
[ 8.976207][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.980156][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 8.986169][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 8.995473][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.001603][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.020028][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.024051][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.030122][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.036004][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.036059][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.045003][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.045077][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.058079][ T57] spacemit-k1-pcie ca800000.pcie: host bridge
/soc/pcie-bus/pcie@ca800000 ranges:
[ 9.064716][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.064745][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.064825][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 9.064889][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.065762][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.069924][ T60] spacemit-k1-pcie ca400000.pcie: host bridge
/soc/pcie-bus/pcie@ca400000 ranges:
[ 9.071122][ T60] spacemit-k1-pcie ca400000.pcie: IO
0x009f002000..0x009f101fff -> 0x0000000000
[ 9.073304][ T60] spacemit-k1-pcie ca400000.pcie: MEM
0x0090000000..0x009effffff -> 0x0090000000
[ 9.081407][ T74] at24 2-0050: 256 byte 24c02 EEPROM, read-only
[ 9.083047][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.083509][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.083614][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.083686][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.083845][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 9.083885][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.089945][ T57] spacemit-k1-pcie ca800000.pcie: IO
0x00b7002000..0x00b7101fff -> 0x0000000000
[ 9.092728][ T1] clk: Disabling unused clocks
[ 9.095269][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.096981][ T1] PM: genpd: Disabling unused power domains
[ 9.104949][ T57] spacemit-k1-pcie ca800000.pcie: MEM
0x00a0000000..0x00afffffff -> 0x00a0000000
[ 9.107986][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.108166][ T129] buck1: Restricting voltage, 1050000-950000uV
[ 9.108246][ T129] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.108311][ T129] cpu cpu0: Failed to set regulator voltages: -22
[ 9.108356][ T129] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.108582][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
[ 9.113366][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.118144][ T57] spacemit-k1-pcie ca800000.pcie: MEM
0x00b0000000..0x00b6ffffff -> 0x00b0000000
[ 9.130386][ T130] buck1: Restricting voltage, 1050000-950000uV
[ 9.196246][ T130] cpu cpu4: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 9.202562][ T60] spacemit-k1-pcie ca400000.pcie: iATU: unroll T,
8 ob, 8 ib, align 4K, limit 4G
[ 9.206998][ T130] cpu cpu4: Failed to set regulator voltages: -22
[ 9.257180][ T130] cpufreq: __target_index: Failed to change cpu
frequency: -22
After reviewing the Banana Pi F3 schematics, I confirmed that Buck1 and Buck2
Both supply the CORE_0V9 with 0.9V±1% rail. To resolve the restriction errors,
I expanded the voltage range in the DTS to 500,000–950,000 µV.
Additionally, I updated the DTS to map the second CPU cluster (cores 4–7)
to Buck2 to better align with the hardware's power distribution.
[1] https://drive.google.com/file/d/19iLJ5xnCB_oK8VeQjkPGjzAn39WYyylv/view
(page 4)
Can you share your thoughts on the changes below?
$ git diff
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 7e300cca50d8..be53645ba0c6 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -102,19 +102,19 @@ &cpu_3 {
};
&cpu_4 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&cpu_5 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&cpu_6 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&cpu_7 {
- cpu-supply = <&buck1_3v45>;
+ cpu-supply = <&buck2_3v45>;
};
&emmc {
@@ -234,14 +234,14 @@ pmic@41 {
regulators {
buck1_3v45: buck1 {
regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
+ regulator-max-microvolt = <950000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
- buck2 {
+ buck2_3v45: buck2 {
regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3450000>;
+ regulator-max-microvolt = <950000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
> --
> Best regards,
> Shuwei Wu
Thanks
-Anand
^ permalink raw reply related
* Re: [RFC PATCH 2/2] kernel/module: Decouple klp and ftrace from load_module
From: Petr Pavlu @ 2026-04-16 11:18 UTC (permalink / raw)
To: Song Chen
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, da.gomez, samitolvanen, atomlin, jpoimboe, jikos, mbenes,
pmladek, joe.lawrence, rostedt, mhiramat, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <a35f5f94-7d5a-4347-974b-b270c89ef241@189.cn>
On 4/15/26 8:43 AM, Song Chen wrote:
> On 4/14/26 22:33, Petr Pavlu wrote:
>> On 4/13/26 10:07 AM, chensong_2000@189.cn wrote:
>>> diff --git a/include/linux/module.h b/include/linux/module.h
>>> index 14f391b186c6..0bdd56f9defd 100644
>>> --- a/include/linux/module.h
>>> +++ b/include/linux/module.h
>>> @@ -308,6 +308,14 @@ enum module_state {
>>> MODULE_STATE_COMING, /* Full formed, running module_init. */
>>> MODULE_STATE_GOING, /* Going away. */
>>> MODULE_STATE_UNFORMED, /* Still setting it up. */
>>> + MODULE_STATE_FORMED,
>>
>> I don't see a reason to add a new module state. Why is it necessary and
>> how does it fit with the existing states?
>>
> because once notifier fails in state MODULE_STATE_UNFORMED (now only ftrace has someting to do in this state), notifier chain will roll back by calling blocking_notifier_call_chain_robust, i'm afraid MODULE_STATE_GOING is going to jeopardise the notifers which don't handle it appropriately, like:
>
> case MODULE_STATE_COMING:
> kmalloc();
> case MODULE_STATE_GOING:
> kfree();
My understanding is that the current module "state machine" operates as
follows. Transitions marked with an asterisk (*) are announced via the
module notifier.
---> UNFORMED --*> COMING --*> LIVE --*> GOING -.
^ | ^ |
| '---------------------* |
'---------------------------------------'
The new code aims to replace the current ftrace_module_init() call in
load_module(). To achieve this, it adds a notification for the UNFORMED
state (only when loading a module) and introduces a new FORMED state for
rollback. FORMED is purely a fake state because it never appears in
module::state. The new structure is as follows:
,--*> (FORMED)
|
--*> UNFORMED --*> COMING --*> LIVE --*> GOING -.
^ | ^ |
| '---------------------* |
'---------------------------------------'
I'm afraid this is quite complex and inconsistent. Unless it can be kept
simple, we would be just replacing one special handling with a different
complexity, which is not worth it.
>>
>>> + if (err)
>>> + goto ddebug_cleanup;
>>> /* Finally it's fully formed, ready to start executing. */
>>> err = complete_formation(mod, info);
>>> - if (err)
>>> + if (err) {
>>> + blocking_notifier_call_chain_reverse(&module_notify_list,
>>> + MODULE_STATE_FORMED, mod);
>>> goto ddebug_cleanup;
>>> + }
>>> - err = prepare_coming_module(mod);
>>> + err = prepare_module_state_transaction(mod,
>>> + MODULE_STATE_COMING, MODULE_STATE_GOING);
>>> if (err)
>>> goto bug_cleanup;
>>> @@ -3522,7 +3519,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
>>> destroy_params(mod->kp, mod->num_kp);
>>> blocking_notifier_call_chain(&module_notify_list,
>>> MODULE_STATE_GOING, mod);
>>
>> My understanding is that all notifier chains for MODULE_STATE_GOING
>> should be reversed.
> yes, all, from lowest priority notifier to highest.
> I will resend patch 1 which was failed due to my proxy setting.
What I meant here is that the call:
blocking_notifier_call_chain(&module_notify_list, MODULE_STATE_GOING, mod);
should be replaced with:
blocking_notifier_call_chain_reverse(&module_notify_list, MODULE_STATE_GOING, mod);
>
>>
>>> - klp_module_going(mod);
>>> bug_cleanup:
>>> mod->state = MODULE_STATE_GOING;
>>> /* module_bug_cleanup needs module_mutex protection */
>>
>> The patch removes the klp_module_going() cleanup call in load_module().
>> Similarly, the ftrace_release_mod() call under the ddebug_cleanup label
>> should be removed and appropriately replaced with a cleanup via
>> a notifier.
>>
> err = prepare_module_state_transaction(mod,
> MODULE_STATE_UNFORMED, MODULE_STATE_FORMED);
> if (err)
> goto ddebug_cleanup;
>
> ftrace will be cleanup in blocking_notifier_call_chain_robust rolling back.
>
> err = prepare_module_state_transaction(mod,
> MODULE_STATE_COMING, MODULE_STATE_GOING);
>
> each notifier including ftrace and klp will be cleanup in blocking_notifier_call_chain_robust rolling back.
>
> if all notifiers are successful in MODULE_STATE_COMING, they all will be clean up in
> coming_cleanup:
> mod->state = MODULE_STATE_GOING;
> destroy_params(mod->kp, mod->num_kp);
> blocking_notifier_call_chain(&module_notify_list,
> MODULE_STATE_GOING, mod);
>
> if something wrong underneath.
My point is that the patch leaves a call to ftrace_release_mod() in
load_module(), which I expected to be handled via a notifier.
--
Thanks,
Petr
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Petr Mladek @ 2026-04-16 10:33 UTC (permalink / raw)
To: chensong_2000
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, joe.lawrence, rostedt, mhiramat, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260415070137.17860-1-chensong_2000@189.cn>
On Wed 2026-04-15 15:01:37, chensong_2000@189.cn wrote:
> From: Song Chen <chensong_2000@189.cn>
>
> The current notifier chain implementation uses a single-linked list
> (struct notifier_block *next), which only supports forward traversal
> in priority order. This makes it difficult to handle cleanup/teardown
> scenarios that require notifiers to be called in reverse priority order.
>
> A concrete example is the ordering dependency between ftrace and
> livepatch during module load/unload. see the detail here [1].
>
> This patch replaces the single-linked list in struct notifier_block
> with a struct list_head, converting the notifier chain into a
> doubly-linked list sorted in descending priority order. Based on
> this, a new function notifier_call_chain_reverse() is introduced,
> which traverses the chain in reverse (ascending priority order).
> The corresponding blocking_notifier_call_chain_reverse() is also
> added as the locking wrapper for blocking notifier chains.
>
> The internal notifier_call_chain_robust() is updated to use
> notifier_call_chain_reverse() for rollback: on error, it records
> the failing notifier (last_nb) and the count of successfully called
> notifiers (nr), then rolls back exactly those nr-1 notifiers in
> reverse order starting from last_nb's predecessor, without needing
> to know the total length of the chain.
>
> With this change, subsystems with symmetric setup/teardown ordering
> requirements can register a single notifier_block with one priority
> value, and rely on blocking_notifier_call_chain() for forward
> traversal and blocking_notifier_call_chain_reverse() for reverse
> traversal, without needing hard-coded call sequences or separate
> notifier registrations for each direction.
>
> [1]:https://lore.kernel.org/all
> /alpine.LNX.2.00.1602172216491.22700@cbobk.fhfr.pm/
>
> --- a/include/linux/notifier.h
> +++ b/include/linux/notifier.h
> @@ -53,41 +53,41 @@ typedef int (*notifier_fn_t)(struct notifier_block *nb,
[...]
> struct notifier_block {
> notifier_fn_t notifier_call;
> - struct notifier_block __rcu *next;
> + struct list_head __rcu entry;
> int priority;
> };
[...]
> #define ATOMIC_INIT_NOTIFIER_HEAD(name) do { \
> spin_lock_init(&(name)->lock); \
> - (name)->head = NULL; \
> + INIT_LIST_HEAD(&(name)->head); \
I would expect the RCU variant here, aka INIT_LIST_HEAD_RCU().
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
> @@ -14,39 +14,47 @@
> * are layered on top of these, with appropriate locking added.
> */
>
> -static int notifier_chain_register(struct notifier_block **nl,
> +static int notifier_chain_register(struct list_head *nl,
> struct notifier_block *n,
> bool unique_priority)
> {
> - while ((*nl) != NULL) {
> - if (unlikely((*nl) == n)) {
> + struct notifier_block *cur;
> +
> + list_for_each_entry(cur, nl, entry) {
> + if (unlikely(cur == n)) {
> WARN(1, "notifier callback %ps already registered",
> n->notifier_call);
> return -EEXIST;
> }
> - if (n->priority > (*nl)->priority)
> - break;
> - if (n->priority == (*nl)->priority && unique_priority)
> +
> + if (n->priority == cur->priority && unique_priority)
> return -EBUSY;
> - nl = &((*nl)->next);
> +
> + if (n->priority > cur->priority) {
> + list_add_tail(&n->entry, &cur->entry);
> + goto out;
> + }
> }
> - n->next = *nl;
> - rcu_assign_pointer(*nl, n);
> +
> + list_add_tail(&n->entry, nl);
I would expect list_add_tail_rcu() here.
> @@ -59,25 +67,25 @@ static int notifier_chain_unregister(struct notifier_block **nl,
> * value of this parameter is -1.
> * @nr_calls: Records the number of notifications sent. Don't care
> * value of this field is NULL.
> + * @last_nb: Records the last called notifier block for rolling back
> * Return: notifier_call_chain returns the value returned by the
> * last notifier function called.
> */
> -static int notifier_call_chain(struct notifier_block **nl,
> +static int notifier_call_chain(struct list_head *nl,
> unsigned long val, void *v,
> - int nr_to_call, int *nr_calls)
> + int nr_to_call, int *nr_calls,
> + struct notifier_block **last_nb)
> {
> int ret = NOTIFY_DONE;
> - struct notifier_block *nb, *next_nb;
> -
> - nb = rcu_dereference_raw(*nl);
> + struct notifier_block *nb;
>
> - while (nb && nr_to_call) {
> - next_nb = rcu_dereference_raw(nb->next);
> + if (!nr_to_call)
> + return ret;
>
> + list_for_each_entry(nb, nl, entry) {
I would expect the RCU variant here, aka list_for_each_rcu()
These are just two random examples which I found by a quick look.
I guess that the notifier API is very old and it does not use all
the RCU API features which allow to track safety when
CONFIG_PROVE_RCU and CONFIG_PROVE_RCU_LIST are enabled.
It actually might be worth to audit the code and make it right.
> #ifdef CONFIG_DEBUG_NOTIFIERS
> if (unlikely(!func_ptr_is_kernel_text(nb->notifier_call))) {
> WARN(1, "Invalid notifier called!");
> - nb = next_nb;
> continue;
> }
> #endif
That said, I am not sure if the ftrace/livepatching handlers are
the right motivation for this. Especially when I see the
complexity of the 2nd patch [*]
After thinking more about it. I am not even sure that the ftrace and
livepatching callbacks are good candidates for generic notifiers.
They are too special. It is not only about ordering them against
each other. But it is also about ordering them against other
notifiers. The ftrace/livepatching callbacks must be the first/last
during module load/release.
[*] The 2nd patch is not archived by lore for some reason.
I have found only a review but it gives a good picture, see
https://lore.kernel.org/all/1191caf5-6a61-4622-a15e-854d3701f4fc@suse.com/
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 4/5] clk: qcom: camcc-milos: Declare icc path dependency for CAMSS_TOP_GDSC
From: Konrad Dybcio @ 2026-04-16 10:22 UTC (permalink / raw)
To: Luca Weiss, Georgi Djakov, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-pm, linux-kernel,
linux-arm-msm, linux-clk, devicetree
In-Reply-To: <20260116-milos-camcc-icc-v1-4-400b7fcd156a@fairphone.com>
On 1/16/26 2:17 PM, Luca Weiss wrote:
> This GDSC requires an interconnect path to be enabled, otherwise the
> GDSC will be stuck on 'off' and can't be enabled.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 3/8] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Luca Weiss @ 2026-04-16 10:06 UTC (permalink / raw)
To: Dmitry Baryshkov, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Jeff Johnson,
Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Krzysztof Kozlowski,
Bartosz Golaszewski
In-Reply-To: <20260119-wcn3990-pwrctl-v3-3-948df19f5ec2@oss.qualcomm.com>
Hi Dmitry,
On Mon Jan 19, 2026 at 6:07 PM CET, Dmitry Baryshkov wrote:
> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
> voltages over internal rails. Implement support for using powersequencer
> for this family of ATH10k devices in addition to using regulators.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/snoc.c | 53 ++++++++++++++++++++++++++++++++--
> drivers/net/wireless/ath/ath10k/snoc.h | 3 ++
> 2 files changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
> index b3f6424c17d3..f72f236fb9eb 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: ISC
> /*
> * Copyright (c) 2018 The Linux Foundation. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> #include <linux/bits.h>
> @@ -11,6 +12,7 @@
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/property.h>
> +#include <linux/pwrseq/consumer.h>
> #include <linux/regulator/consumer.h>
> #include <linux/remoteproc/qcom_rproc.h>
> #include <linux/of_reserved_mem.h>
> @@ -1023,10 +1025,14 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power on\n");
>
> - ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> + ret = pwrseq_power_on(ar_snoc->pwrseq);
> if (ret)
> return ret;
>
> + ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> + if (ret)
> + goto pwrseq_off;
> +
> ret = clk_bulk_prepare_enable(ar_snoc->num_clks, ar_snoc->clks);
> if (ret)
> goto vreg_off;
> @@ -1035,18 +1041,28 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> vreg_off:
> regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +pwrseq_off:
> + pwrseq_power_off(ar_snoc->pwrseq);
> +
> return ret;
> }
>
> static int ath10k_hw_power_off(struct ath10k *ar)
> {
> struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> + int ret_seq = 0;
> + int ret_vreg;
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power off\n");
>
> clk_bulk_disable_unprepare(ar_snoc->num_clks, ar_snoc->clks);
>
> - return regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> + ret_vreg = regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +
> + if (ar_snoc->pwrseq)
> + ret_seq = pwrseq_power_off(ar_snoc->pwrseq);
> +
> + return ret_vreg ? : ret_seq;
> }
>
> static void ath10k_snoc_wlan_disable(struct ath10k *ar)
> @@ -1762,7 +1778,38 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
> goto err_release_resource;
> }
>
> - ar_snoc->num_vregs = ARRAY_SIZE(ath10k_regulators);
> + /*
> + * devm_pwrseq_get() can return -EPROBE_DEFER in two cases:
> + * - it is not supposed to be used
> + * - it is supposed to be used, but the driver hasn't probed yet.
> + *
> + * There is no simple way to distinguish between these two cases, but:
> + * - if it is not supposed to be used, then regulator_bulk_get() will
> + * return all regulators as expected, continuing the probe
> + * - if it is supposed to be used, but wasn't probed yet, we will get
> + * -EPROBE_DEFER from regulator_bulk_get() too.
> + *
> + * For backwards compatibility with DTs specifying regulators directly
> + * rather than using the PMU device, ignore the defer error from
> + * pwrseq.
> + */
> + ar_snoc->pwrseq = devm_pwrseq_get(&pdev->dev, "wlan");
> + if (IS_ERR(ar_snoc->pwrseq)) {
> + ret = PTR_ERR(ar_snoc->pwrseq);
> + ar_snoc->pwrseq = NULL;
> + if (ret != -EPROBE_DEFER)
> + goto err_free_irq;
I'm fairly sure this is now broken with CONFIG_POWER_SEQUENCING=n since
then pwrseq_get() is returning ERR_PTR(-ENOSYS) which is not handled
here.
I'm observing my ath10k_snoc is now failing to probe "with error -38"
which definitely seems to be related, but I haven't debugged it further
yet.
Regards
Luca
^ 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