* Re: [PATCH v2 1/7] dt-bindings: thermal: Add Google GS101 TMU
From: Tudor Ambarus @ 2026-04-17 13:28 UTC (permalink / raw)
To: Alexey Klimov, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik
Cc: willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <DGUJIFLIOK7Y.1Q4PZQU3MOWTT@linaro.org>
On 3/5/26 5:48 AM, Alexey Klimov wrote:
> Hi Tudor,
>
> On Mon Jan 19, 2026 at 12:08 PM GMT, Tudor Ambarus wrote:
>> Document the Thermal Management Unit (TMU) found on the Google GS101 SoC.
>>
>> The GS101 TMU utilizes a hybrid control model shared between the
>> Application Processor (AP) and the ACPM (Alive Clock and Power Manager)
>> firmware.
>>
>> While the TMU is a standard memory-mapped IP block, on this platform
>
> this ^^
>
okay
cut
> Is it Google TMU hardware block or Exynos/Samsung TMU block?
>
> My understanding at this point is that ACPM interface, ACPM protocols, etc
> appeared on Samsung SoCs before gs101 (maybe even before initial SCMI
> prototyping). It looks like ACPM firmware, communication via mailboxes,
> TMU channel, dealing with TMU behing ACPM, etc are actually a standard
> Samsung Exynos architectural feature, rather than a Google-specific
> implementation. I can't say though what was the first chipset where it
> was implemented.
autov920, exynos850 too can use the hybrid ACPM TMU approach.
I'll generalize the description.
>
> Given that this is a Samsung design that predates the gs101, would it
> make sense to use more generic name for this binding to reflect that
> it is Exynos-derived? That would save us from generalizing things later
The name has to match the compatible. We can rename it when other Samsung
compatibles are added.
Cheers,
ta
^ permalink raw reply
* [PATCH v2 3/3] dt-bindings: reserved-memory: Change maintainer for BPMP SHMEM
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while ago, so change the maintainers for BPMP
SHMEM to Jon and myself.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
index 4380f622f9a9..6efadc5f8078 100644
--- a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Tegra CPU-NS - BPMP IPC reserved memory
maintainers:
- - Peter De Schrijver <pdeschrijver@nvidia.com>
+ - Thierry Reding <thierry.reding@kernel.org>
+ - Jonathan Hunter <jonathanh@nvidia.com>
description: |
Define a memory region used for communication between CPU-NS and BPMP.
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/3] Documentation: ABI: Take over as contact for sysfs-driver-tegra-fuse
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while ago, so I'll be taking over as contact
for this ABI documentation.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Documentation/ABI/testing/sysfs-driver-tegra-fuse | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
index b8936fad2ccf..47d5513100f6 100644
--- a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
+++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
@@ -1,6 +1,6 @@
What: /sys/devices/*/<our-device>/fuse
Date: February 2014
-Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
+Contact: Thierry Reding <thierry.reding@kernel.org>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
data programmed at the factory. The data is laid out in 32bit
--
2.52.0
^ permalink raw reply related
* [PATCH v2 1/3] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, 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>
Co-developed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Co-developed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v2:
- add more missing entries
CREDITS | 10 ++++++++++
MAINTAINERS | 1 -
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/CREDITS b/CREDITS
index 885fb05d8816..afd1f70b41cf 100644
--- a/CREDITS
+++ b/CREDITS
@@ -3645,7 +3645,17 @@ 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: Apollo Domain workstations
+D: Ariadne and Hydra Amiga Ethernet drivers
+D: IBM PS/2, Microchannel, and Token Ring support
D: Mitsumi CD-ROM driver patches March version
+D: TWL4030 power management and audio codec driver
+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: [PATCH v2 0/7] thermal: samsung: Add support for Google GS101 TMU
From: Tudor Ambarus @ 2026-04-17 13:06 UTC (permalink / raw)
To: Alexey Klimov, daniel.lezcano
Cc: Rafael J. Wysocki, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alim Akhtar, Bartlomiej Zolnierkiewicz, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <63087cad-a8d1-4ff0-870a-6e1a738ff8b8@linaro.org>
On 4/9/26 3:22 PM, Tudor Ambarus wrote:
> No, it's more than that. When I talked with Daniel about this driver, he
> suggested I shall really focus on using the .set_trips callback instead of
> .set_trip_temp. I'm not sure if it's possible given the static nature of
> the ACPM interface. So it needs a bit of investigation, which I couldn't
> do lately.
FYI, I switched to .set_trips and testing went fine. I'll recheck the
review feedback and resubmit.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v2 0/9] driver core / pmdomain: Add support for fined grained sync_state
From: Ulf Hansson @ 2026-04-17 11:27 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman,
Danilo Krummrich, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
+ Danilo (for the driver core changes)
On Fri, 10 Apr 2026 at 12:41, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> Since the introduction [1] of the common sync_state support for pmdomains
> (genpd), we have encountered a lot of various interesting problems. In most
> cases the new behaviour of genpd triggered some weird platform specific bugs.
>
> That said, in LPC in Tokyo me and Saravana hosted a session to walk through the
> remaining limitations that we have found for genpd's sync state support. In
> particular, we discussed the problems we have for the so-called onecell power
> domain providers, where a single provider typically provides multiple
> independent power domains, all with their own set of consumers.
>
> Note that, onecell power domain providers are very common. It's being used by
> many SoCs/platforms/technologies. To name a few:
> SCMI, Qualcomm, NXP, Mediatek, Renesas, TI, etc.
>
> Anyway, in these cases, the generic sync_state mechanism with fw_devlink isn't
> fine grained enough, as we end up waiting for all consumers for all power
> domains before the ->sync_callback gets called for the supplier/provider. In
> other words, we may end up keeping unused power domains powered-on, for no good
> reasons.
>
> The series intends to fix this problem. Please have a look at the commit
> messages for more details and help review/test!
>
> Kind regards
> Ulf Hansson
>
> [1]
> https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
>
> Ulf Hansson (9):
> driver core: Enable suppliers to implement fine grained sync_state
> support
> driver core: Add dev_set_drv_queue_sync_state()
> pmdomain: core: Move genpd_get_from_provider()
> pmdomain: core: Add initial fine grained sync_state support
> pmdomain: core: Extend fine grained sync_state to more onecell
> providers
> pmdomain: core: Export a common function for ->queue_sync_state()
> pmdomain: renesas: rcar-gen4-sysc: Drop GENPD_FLAG_NO_STAY_ON
> pmdomain: renesas: rcar-sysc: Drop GENPD_FLAG_NO_STAY_ON
> pmdomain: renesas: rmobile-sysc: Drop GENPD_FLAG_NO_STAY_ON
>
> drivers/base/core.c | 7 +-
> drivers/pmdomain/core.c | 205 ++++++++++++++++++----
> drivers/pmdomain/renesas/rcar-gen4-sysc.c | 1 -
> drivers/pmdomain/renesas/rcar-sysc.c | 1 -
> drivers/pmdomain/renesas/rmobile-sysc.c | 3 +-
> include/linux/device.h | 12 ++
> include/linux/device/driver.h | 7 +
> include/linux/pm_domain.h | 3 +
> 8 files changed, 197 insertions(+), 42 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH] pmdomain: core: Fix detach procedure for virtual devices in genpd
From: Ulf Hansson @ 2026-04-17 11:13 UTC (permalink / raw)
To: Geert Uytterhoeven, Ulf Hansson, linux-pm
Cc: Geert Uytterhoeven, Frank Binns, Matt Coster, Marek Vasut,
Rafael J . Wysocki, linux-arm-kernel, linux-kernel, Ulf Hansson,
stable
If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(),
genpd calls pm_runtime_enable() for the corresponding virtual device that
it registers. While this avoids boilerplate code in drivers, there is no
corresponding call to pm_runtime_disable() in genpd_dev_pm_detach().
This means these virtual devices are typically detached from its genpd,
while runtime PM remains enabled for them, which is not how things are
designed to work. In worst cases it may lead to critical errors, like a
NULL pointer dereference bug in genpd_runtime_suspend(), which was recently
reported. For another case, we may end up keeping an unnecessary vote for a
performance state for the device.
To fix these problems, let's add this missing call to pm_runtime_disable()
in genpd_dev_pm_detach().
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: 3c095f32a92b ("PM / Domains: Add support for multi PM domains per device to genpd")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/CAMuHMdWapT40hV3c+CSBqFOW05aWcV1a6v_NiJYgoYi0i9_PDQ@mail.gmail.com/
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/core.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 4d32fc676aaf..71e930e80178 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -3089,6 +3089,7 @@ static const struct bus_type genpd_bus_type = {
static void genpd_dev_pm_detach(struct device *dev, bool power_off)
{
struct generic_pm_domain *pd;
+ bool is_virt_dev;
unsigned int i;
int ret = 0;
@@ -3098,6 +3099,13 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
dev_dbg(dev, "removing from PM domain %s\n", pd->name);
+ /* Check if the device was created by genpd at attach. */
+ is_virt_dev = dev->bus == &genpd_bus_type;
+
+ /* Disable runtime PM if we enabled it at attach. */
+ if (is_virt_dev)
+ pm_runtime_disable(dev);
+
/* Drop the default performance state */
if (dev_gpd_data(dev)->default_pstate) {
dev_pm_genpd_set_performance_state(dev, 0);
@@ -3123,7 +3131,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
genpd_queue_power_off_work(pd);
/* Unregister the device if it was created by genpd. */
- if (dev->bus == &genpd_bus_type)
+ if (is_virt_dev)
device_unregister(dev);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-17 9:31 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring
Cc: Lee Jones, Krzysztof Kozlowski, Conor Dooley, Andi Shyti,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <6758aaa2-ac1a-4751-aece-2b445b84f2bc@linaro.org>
On 4/17/26 9:53 AM, Neil Armstrong wrote:
> On 4/16/26 10:25, Ronald Claveau wrote:
>> On 4/15/26 11:48 PM, Rob Herring wrote:
>>> On Fri, Apr 03, 2026 at 06:08:34PM +0200, Ronald Claveau wrote:
>>>> The Khadas VIM4 MCU register is slightly different
>>>> from previous boards' MCU.
>>>> This board also features a switchable power source for its fan.
>>>>
>>>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>>>> ---
>>>> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> index 084960fd5a1fd..67769ef5d58b1 100644
>>>> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> @@ -18,6 +18,7 @@ properties:
>>>> compatible:
>>>> enum:
>>>> - khadas,mcu # MCU revision is discoverable
>>>
>>> The revision is no longer discoverable as was claimed?
>>>
>>
>> The firmware revision is still discoverable, and via the same register,
>> but the VIM4 MCU has a different register layout (eg: no DEVICE_NO
>> register). The new compatible is needed to describe a different MCU
>> variant, not a different revision of the same MCU.
>> I will remove the comment as it is confusing with new boards.
>
> Yes basically it was discoverable for earlier MCU version, but is not
> for this particular board version.
>
> Keep the comment, but add a comment on the vim4 entry saying this variant
> is not discoverable.
>
> Neil
>
Ok make sense, I will do that.
>>
>>>> + - khadas,vim4-mcu
>>>> "#cooling-cells": # Only needed for boards having FAN control
>>>> feature
>>>> const: 2
>>>> @@ -25,6 +26,10 @@ properties:
>>>> reg:
>>>> maxItems: 1
>>>> + fan-supply:
>>>> + description: Phandle to the regulator that powers the fan.
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>> +
>>>> required:
>>>> - compatible
>>>> - reg
>>>>
>>>> --
>>>> 2.49.0
>>>>
>>
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v2 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Frank Li @ 2026-04-17 8:16 UTC (permalink / raw)
To: Felix Gu
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel, linux-pm, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <CAN4SLj3rH1q-jd6ccdo2qVNuNUoqfpsiS0KXJ3b=b7m_bh2QBw@mail.gmail.com>
On Thu, Apr 16, 2026 at 09:04:38PM +0800, Felix Gu wrote:
> On Wed, Apr 15, 2026 at 9:10 PM Felix Gu <ustc.gu@gmail.com> wrote:
...
> > 2.43.0
> >
>
> Hi all,
> This patch has a problem, I will fix it and send v3.
Next time trim context to let reviewer see important information before
scoll down email.
Frank
>
> Best regards,
> Felix
^ permalink raw reply
* [PATCH] dt-bindings: cpufreq: add mt8189 cpufreq hw dt-bindings
From: Binbin Shi @ 2026-04-17 8:06 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Hector Yuan
Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group,
vince-wl.liu, Binbin Shi
Add mt8189 cpufreq hw compatible in dt-bindings.
Signed-off-by: Binbin Shi <binbin.shi@mediatek.com>
---
.../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
index d0aecde2b89b..cff52fffc6b8 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
@@ -16,7 +16,9 @@ description:
properties:
compatible:
- const: mediatek,cpufreq-hw
+ enum:
+ - mediatek,cpufreq-hw
+ - mediatek,mt8189-cpufreq-hw
reg:
minItems: 1
--
2.45.2
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Geert Uytterhoeven @ 2026-04-17 7:55 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Thierry Reding, linux-tegra, linux-arm-kernel, linux-pm,
linux-omap, linux-kernel, Paul Walmsley
In-Reply-To: <aeEm5DavehkPmSgl@darkstar.musicnaut.iki.fi>
On Thu, 16 Apr 2026 at 20:14, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> On Thu, Apr 16, 2026 at 03:18:10PM +0200, Thierry Reding wrote:
> > 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>
>
> Thanks for doing this. I think also the m68k work should be mentioned?
Indeed: Apollo Domain workstations, and Ariadne and Hydra Amiga
Ethernet.
Also: IBM PS/2, Microchannel, and Token Ring support.
Peter is also still listed as the contact info in
Documentation/ABI/testing/sysfs-driver-tegra-fuse
and as DT bindings maintainer in
Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
Thanks!
> > --- 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/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Neil Armstrong @ 2026-04-17 7:53 UTC (permalink / raw)
To: Ronald Claveau, Rob Herring
Cc: Lee Jones, Krzysztof Kozlowski, Conor Dooley, Andi Shyti,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <6fc8ddeb-d54d-473d-94d2-49dc78a07154@aliel.fr>
On 4/16/26 10:25, Ronald Claveau wrote:
> On 4/15/26 11:48 PM, Rob Herring wrote:
>> On Fri, Apr 03, 2026 at 06:08:34PM +0200, Ronald Claveau wrote:
>>> The Khadas VIM4 MCU register is slightly different
>>> from previous boards' MCU.
>>> This board also features a switchable power source for its fan.
>>>
>>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>>> ---
>>> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>> index 084960fd5a1fd..67769ef5d58b1 100644
>>> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>> @@ -18,6 +18,7 @@ properties:
>>> compatible:
>>> enum:
>>> - khadas,mcu # MCU revision is discoverable
>>
>> The revision is no longer discoverable as was claimed?
>>
>
> The firmware revision is still discoverable, and via the same register,
> but the VIM4 MCU has a different register layout (eg: no DEVICE_NO
> register). The new compatible is needed to describe a different MCU
> variant, not a different revision of the same MCU.
> I will remove the comment as it is confusing with new boards.
Yes basically it was discoverable for earlier MCU version, but is not
for this particular board version.
Keep the comment, but add a comment on the vim4 entry saying this variant
is not discoverable.
Neil
>
>>> + - khadas,vim4-mcu
>>>
>>> "#cooling-cells": # Only needed for boards having FAN control feature
>>> const: 2
>>> @@ -25,6 +26,10 @@ properties:
>>> reg:
>>> maxItems: 1
>>>
>>> + fan-supply:
>>> + description: Phandle to the regulator that powers the fan.
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> +
>>> required:
>>> - compatible
>>> - reg
>>>
>>> --
>>> 2.49.0
>>>
>
>
^ permalink raw reply
* Re: [PATCH] power: supply: bd71828: add input current limit property
From: Matti Vaittinen @ 2026-04-17 7:33 UTC (permalink / raw)
To: Andreas Kemnade; +Cc: Sebastian Reichel, linux-pm, linux-kernel
In-Reply-To: <20260415221358.59574987@kemnade.info>
On 15/04/2026 23:13, Andreas Kemnade wrote:
> On Tue, 7 Apr 2026 09:33:25 +0300
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>
>> I am afraid I don't know your use-case for the control of the DCIN input
>> limit well enough to decide, if the BD72720 would need something similar
>> - or if the VBUS_INLIM should be tied to the same knob. If you have the
>> enthusiasm to write some more words ... I am keen on learning! :)
>
> Justification for this patch is mostly: there is a standard interface
> for this functionality and the chip has that functionality.
I wasn't doubting the justification for this patch. I was more like
wondering if the use-case of the functionality, toggled by the
interface, is such that BD72720 VBUS_INLIM should be tied to this same knob.
> The bigger picture: Attach a power source with changing properties causes
> mess. To repreduce issues at my desk, I have played around with a labor power
> supply with changeable current limitation, turining it down to zero (so
> power is off) then turning it on slowly again, no charging will happen. My
> usual way around such a problem is to clear DCIN_ILIM_EN (will add a sysfs
> attribute for that) and set some conservative current.
Right. I suppose deciding if the BD72720 should support changing the
VBUS_INLIM would require me to have the hardware to do some testing so I
could see how it behaves with variable charging currents. I don't
currently have that, and I haven't heard of any complaints. Furthermore,
AFAIR, there are some differences between the logic of BD71828 and
BD72720 (battery assisted mode in BD72720) - so they're not 100% same.
Hence, I won't touch the BD72720 for now.
Thanks for sharing the details!
Yours,
-- Matti
--
---
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Anand Moon @ 2026-04-17 6:08 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: <CANAwSgRt5-t_ah=phGc+CQYHG-CdWJuOX-2VTW6xE7n7EnVsFw@mail.gmail.com>
Hi Shuwei,
On Thu, 16 Apr 2026 at 17:07, Anand Moon <linux.amoon@gmail.com> wrote:
>
> 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
>
I also made some modifications to the k1-opp.dtsi to fix the warning,
add over clock to 18000
[ 8.712035][ T80] core: _opp_supported_by_regulators: OPP minuV:
1050000 maxuV: 1050000, not supported by regulator
[ 8.720556][ T80] cpu cpu0: _opp_add: OPP not supported by
regulators (1600000000)
[ 8.752494][ T80] core: _opp_supported_by_regulators: OPP minuV:
1050000 maxuV: 1050000, not supported by regulator
[ 8.760906][ T80] cpu cpu4: _opp_add: OPP not supported by
regulators (1600000000)
[ 8.780195][ T80] cpufreq: cpufreq_policy_online: CPU0: Running
at unlisted initial frequency: 1600000 kHz, changing to: 1228800 kHz
[ 8.809572][ T80] cpufreq: cpufreq_policy_online: CPU4: Running
at unlisted initial frequency: 1600000 kHz, changing to: 1228800 kHz
$ git diff .
diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
index 768ae390686d..bec565947ba3 100644
--- a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
@@ -31,7 +31,13 @@ opp-1228800000 {
opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
- opp-microvolt = <1050000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1800000000 {
+ opp-hz = /bits/ 64 <1800000000>;
+ opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
};
@@ -66,7 +72,13 @@ opp-1228800000 {
opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
- opp-microvolt = <1050000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1800000000 {
+ opp-hz = /bits/ 64 <1800000000>;
+ opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
};
> Thanks
> -Anand
Thanks
-Anand
^ permalink raw reply related
* Re: [PATCH v2] cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
From: 최유호 @ 2026-04-17 4:35 UTC (permalink / raw)
To: Zhongqiu Han
Cc: Rafael J . Wysocki, Viresh Kumar, linux-pm, linux-kernel,
Kim, Taegyu
In-Reply-To: <203f2e52-bf9d-4055-88bd-d911bfecf082@oss.qualcomm.com>
Dear Zhongqiu,
I appreciate your review.
Best regards,
Yuho Choi
On Thu, 16 Apr 2026 at 23:29, Zhongqiu Han
<zhongqiu.han@oss.qualcomm.com> wrote:
>
> On 4/16/2026 10:46 PM, Yuho Choi wrote:
> > 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>
>
>
> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.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;
> >
>
>
> --
> Thx and BRs,
> Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v2] cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
From: Zhongqiu Han @ 2026-04-17 3:29 UTC (permalink / raw)
To: Yuho Choi, Rafael J . Wysocki, Viresh Kumar
Cc: linux-pm, linux-kernel, zhongqiu.han
In-Reply-To: <20260416144621.93964-1-dbgh9129@gmail.com>
On 4/16/2026 10:46 PM, Yuho Choi wrote:
> 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>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.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;
>
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v8 0/9] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL and HMEM
From: Tomasz Wolski @ 2026-04-16 23:44 UTC (permalink / raw)
To: tomasz.wolski
Cc: alison.schofield, ardb, benjamin.cheatham, bp, dan.j.williams,
dave.jiang, dave, gregkh, huang.ying.caritas, ira.weiny, jack,
jeff.johnson, jonathan.cameron, len.brown, linux-cxl,
linux-fsdevel, linux-kernel, linux-pm, lizhijian, ming.li,
nathan.fontenot, nvdimm, pavel, peterz, rafael, rrichter,
smita.koralahallichannabasappa, terry.bowman, vishal.l.verma,
willy, yaoxt.fnst, yazen.ghannam
In-Reply-To: <20260416224618.12987-1-tomasz.wolski@fujitsu.com>
One additional remark:
I observed one isue unrelated to this patch during tests
on our AMD machine with two CXL physical cards installed.
Region teardown with "destroy-region" fails with "Operation not permitted":
cxl region: destroy_region: region1: failed to reset decode: Operation not permitted
cxl region: decoder_region_action: region1: failed: Operation not permitted
cxl region: region_action: one or more failures, last failure: Operation not permitted
cxl region: cmd_destroy_region: destroyed 0 regions
Region lock is now correctly set by a fix "cxl: Test decoder flags as bitmasks"
(commit 0a70b7cd397e545e926c93715ff6366b67c716f6) but I cannot see any option
how it can be unlocked to proceed with the teardown?
Without the lock I'm able to destroy regions:
>static void cxl_region_setup_flags(struct cxl_region *cxlr,
> struct cxl_decoder *cxld)
>{
> if (cxld->flags & CXL_DECODER_F_LOCK) {
> dev_err(&cxlr->dev, "cxl_region_setup_flags: would lock, flags: %04lx\n", cxld->flags);
> }
> if (test_bit(CXL_DECODER_F_LOCK, &cxld->flags)) {
> dev_err(&cxlr->dev, "cxl_region_setup_flags: setting CXL_DECODER_F_LOCK, flags: %04lx\n", cxld->flags);
> set_bit(CXL_REGION_F_LOCK, &cxlr->flags);
> clear_bit(CXL_REGION_F_NEEDS_RESET, &cxlr->flags);
> }
>
> if (cxld->flags & CXL_DECODER_F_NORMALIZED_ADDRESSING)
> set_bit(CXL_REGION_F_NORMALIZED_ADDRESSING, &cxlr->flags);
>}
[ 5.155997] [ T12] cxl region0: cxl_region_setup_flags: would lock, flags: 0030
..
[ 5.130070] [ T12] cxl region1: cxl_region_setup_flags: would lock, flags: 0030
^ permalink raw reply
* [PATCH v8 0/9] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL and HMEM
From: Tomasz Wolski @ 2026-04-16 22:46 UTC (permalink / raw)
To: smita.koralahallichannabasappa
Cc: alison.schofield, ardb, benjamin.cheatham, bp, dan.j.williams,
dave.jiang, dave, gregkh, huang.ying.caritas, ira.weiny, jack,
jeff.johnson, jonathan.cameron, len.brown, linux-cxl,
linux-fsdevel, linux-kernel, linux-pm, lizhijian, ming.li,
nathan.fontenot, nvdimm, pavel, peterz, rafael, rrichter,
terry.bowman, tomasz.wolski, vishal.l.verma, willy, yaoxt.fnst,
yazen.ghannam
In-Reply-To: <20260322195343.206900-1-Smita.KoralahalliChannabasappa@amd.com>
Hi Smita,
Tested on QEMU and physical setups - it worked as expected
(had to disable ACPI_PRMT/CONFIG_CXL_ATL on our physical system though)
Best regards,
Tomasz
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
^ permalink raw reply
* Re: [PATCH V10 4/4] thermal: qcom: add support for PMIC5 Gen3 ADC thermal monitoring
From: Daniel Lezcano @ 2026-04-16 21:12 UTC (permalink / raw)
To: Jishnu Prakash
Cc: jic23, robh, krzk+dt, conor+dt, agross, andersson, lumag,
dmitry.baryshkov, konradybcio, daniel.lezcano, sboyd, amitk,
thara.gopinath, lee, rafael, subbaraman.narayanamurthy,
david.collins, anjelique.melendez, kamal.wadhwa, rui.zhang,
lukasz.luba, devicetree, linux-arm-msm, linux-iio, linux-kernel,
linux-pm, cros-qcom-dts-watchers, quic_kotarake, neil.armstrong,
stephan.gerhold
In-Reply-To: <12d683aa-44c2-4e2d-8459-78ba9f2ab61e@oss.qualcomm.com>
On 4/16/26 10:05, Jishnu Prakash wrote:
> Hi Daniel,
>
> On 4/9/2026 11:42 AM, Daniel Lezcano wrote:
>> On Fri, Jan 30, 2026 at 05:24:21PM +0530, Jishnu Prakash wrote:
>>> Add support for ADC_TM part of PMIC5 Gen3.
>>>
>>> This is an auxiliary driver under the Gen3 ADC driver, which implements the
>>> threshold setting and interrupt generating functionalities of QCOM ADC_TM
>>> drivers, used to support thermal trip points.
>>>
>>> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
>
> ...
>
>>> +
>>> +static irqreturn_t adctm5_gen3_isr(int irq, void *dev_id)
>>> +{
>>> + struct adc_tm5_gen3_chip *adc_tm5 = dev_id;
>>> + int ret, sdam_num;
>>> + u8 tm_status[2];
>>> + u8 status, val;
>>> +
>>> + sdam_num = get_sdam_from_irq(adc_tm5, irq);
>>> + if (sdam_num < 0) {
>>> + dev_err(adc_tm5->dev, "adc irq %d not associated with an sdam\n",
>>> + irq);
>>> + return IRQ_HANDLED;
>>> + }
>>> +
>>> + ret = adc5_gen3_read(adc_tm5->dev_data, sdam_num, ADC5_GEN3_STATUS1,
>>> + &status, sizeof(status));
>>> + if (ret) {
>>> + dev_err(adc_tm5->dev, "adc read status1 failed with %d\n", ret);
>>> + return IRQ_HANDLED;
>>> + }
>>> +
>>> + if (status & ADC5_GEN3_STATUS1_CONV_FAULT) {
>>> + dev_err_ratelimited(adc_tm5->dev,
>>> + "Unexpected conversion fault, status:%#x\n",
>>> + status);
>>> + val = ADC5_GEN3_CONV_ERR_CLR_REQ;
>>> + adc5_gen3_status_clear(adc_tm5->dev_data, sdam_num,
>>> + ADC5_GEN3_CONV_ERR_CLR, &val, 1);
>>> + return IRQ_HANDLED;
>>> + }
>>> +
>>> + ret = adc5_gen3_read(adc_tm5->dev_data, sdam_num, ADC5_GEN3_TM_HIGH_STS,
>>> + tm_status, sizeof(tm_status));
>>> + if (ret) {
>>> + dev_err(adc_tm5->dev, "adc read TM status failed with %d\n", ret);
>>> + return IRQ_HANDLED;
>>> + }
>>> +
>>> + if (tm_status[0] || tm_status[1])
>>> + schedule_work(&adc_tm5->tm_handler_work);
>>> +
>>> + dev_dbg(adc_tm5->dev, "Interrupt status:%#x, high:%#x, low:%#x\n",
>>> + status, tm_status[0], tm_status[1]);
>>> +
>>> + return IRQ_HANDLED;
>>
>> This ISR routine should be revisited:
>>
>> - no error message inside
>
> I'll drop all the error messages, but does that also include the debug print at the end?
> In addition, the print for conversion fault is ratelimited and may be useful as it
> indicates a possible HW issue, can I keep that?
It is not a good practice to put an error message in the ISR. If the
conversion fails, then the thread blocked on the read will timeout and
then show a message.
>> - use a shared interrupt to split what is handled by the ADC and the
>> TM drivers
>
> I'll make the required updates in the main ADC driver and this driver to share the first
> SDAM's interrupt.
>
>>
>> - do not return IRQ_HANDLED in case of error (cf. irqreturn.h doc)
>>
>
> I'll replace IRQ_HANDLED with IRQ_NONE at places where errors are returned.
> But in the case of conversion fault, I think returning IRQ_HANDLED may be
> more appropriate because we do handle it by clearing the status, to
> allow subsequent conversion requests to be sent.
>
> What do you think, is this fine?
It is a good point.
Actually, if get_sdam_from_irq() or adc5_gen3_read() fail, they will
return without clearing the interrupt flag, so we should potentially end
up in an infinite loop.
So the status should be cleared at the end with IRQ_HANDLED. IRQ_NONE
returned if it is for another subsystem.
If you think there can be a significant number of errors in the handler
may be you should add statistics but later in an additional series if it
makes sense.
[ ... ]
>>> + adc_tm5 = prop->chip;
>>> +
>>> + if (prop->last_temp_set) {
>>> + pr_debug("last_temp: %d\n", prop->last_temp);
>>> + prop->last_temp_set = false;
>>> + *temp = prop->last_temp;
>>> + return 0;
>>> + }
>>
>> Why do you need to do that?
>>
>> The temperature should reflect the current situation even if the
>> reading was triggered by a thermal trip violation.
>>
>
> This logic is needed to handle a corner case issue we have seen earlier.
> In this case, the ADC_TM threshold violation interrupt gets triggered ,
> but when get_temp() is subsequently called by the thermal framework, the
> temperature has fluctuated and the value read now lies within the thresholds,
> so the thresholds do not get updated by the thermal framework and the violation
> interrupts get repeated several times, until there is a get_temp() call
> which returns a temperature outside the threshold range.
Oh, that's clearly an issue with the thermal framework, not the driver.
> In order to avoid this issue, when the interrupt handler runs, we find the actual
> temperature read in ADC_TM that led to threshold violation by reading the ADC_TM
> data registers and we cache it and return it when get_temp() is called in the flow
> of thermal_zone_device_update(). Any subsequent calls to get_temp() would
> return the actual channel temperature at the time.
>
> This is only done to avoid delaying thermal mitigation due to temperature
> fluctuations. Do you think this needs to be changed?
I think it is an interesting problem certainly impacting all thermal
sensors. It should be fixed in the thermal framework itself if possible.
Just drop this portion of code and let's handle that correctly in the
thermal framework.
[ ... ]
>>> + dev_dbg(adc_tm5->dev, "channel:%s, low_temp(mdegC):%d, high_temp(mdegC):%d\n",
>>> + prop->common_props.label, low_temp, high_temp);
>>> +
>>> + guard(adc5_gen3)(adc_tm5);
>>> + if (high_temp == INT_MAX && low_temp == -INT_MAX)
>>> + return adc_tm5_gen3_disable_channel(prop);
>>
>> Why disable the channel instead of returning an errno ?
>>
>
> This is the convention we follow in our existing ADC_TM driver at
> drivers/thermal/qcom/qcom-spmi-adc-tm5.c. If both upper and lower
> thresholds are meant to be disabled, we disable the channel fully
> in HW to save some power and it can be enabled later if this API
> is called for it with valid thresholds.
>
> Is it considered invalid in the thermal framework to try to disable
> both thresholds? Should I both disable the channel and return some
> error from here?
Well, if the channel is disabled, then the temperature sensor of the
thermal zone is disabled, consequently the thermal zone is disabled from
a HW POV but enabled from the kernel POV.
Why not add the 'change_mode' ops and then disable the thermal zone (+
pm_runtime) ?
[ ... ]
>>> + /*
>>> + * Skipping first SDAM IRQ as it is requested in parent driver.
>>> + * If there is a TM violation on that IRQ, the parent driver calls
>>> + * the notifier (adctm_event_handler) exposed from this driver to handle it.
>>> + */
>>> + for (i = 1; i < adc_tm5->dev_data->num_sdams; i++) {
>>> + ret = devm_request_threaded_irq(dev,
>>> + adc_tm5->dev_data->base[i].irq,
>>> + NULL, adctm5_gen3_isr, IRQF_ONESHOT,
>>> + adc_tm5->dev_data->base[i].irq_name,
>>> + adc_tm5);
>>
>> The threaded interrupts set the isr in a thread and from the thread
>> handling the event, there is a work queue scheduled. Why not use the
>> top and bottom halves of the threaded interrupt ? Hopefully you should
>> be able to remove the lock.
>
> Yes, I can use the top and bottom halves of the threaded interrupt as you
> suggested. But what exactly do you mean by removing the lock?
>
> If you meant the mutex lock used in this driver, we cannot remove that.
> This is because the ADC_TM driver needs to write into several registers
> shared with the main ADC driver for setting new thresholds, so we
> have to share a mutex between the drivers to prevent concurrency issues.
When using a workqueue tampering with registers while an interrupt
handler is doing the same, the lock is needed.
But if the workqueue is replaced by threaded interrupt, the lock *may*
not be needed because the design may prevent race conditions.
That may be not true in this case, I did not investigate deeper in the
code to figure it out. Let's see the next version
> I'll address all your other comments too in the next version of this patch.
Thanks
-- Daniel
^ 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 19:15 UTC (permalink / raw)
To: Petr Mladek
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: <aeD4H8P1DiPQoM8V@pathway.suse.cz>
On Thu, 16 Apr 2026 16:54:23 +0200
Petr Mladek <pmladek@suse.com> wrote:
> 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.
It is useful for things like locklessy queuing a request to be processed later.
Items can be added with a cmpxchg and the list grabbed by xchg of NULL.
The only downside is that reversing a list isn't cache friendly.
Thinks... although that may not be any worse than accessing the current 'tail'
to add to the end of a doubly linked (or singly linked with a tail ptr) list.
David
>
> 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
* [PATCH] interconnect: Fix use after free in icc_get() and of_icc_get_by_index()
From: Kuan-Wei Chiu @ 2026-04-16 19:08 UTC (permalink / raw)
To: djakov
Cc: gregkh, marscheng, wllee, aarontian, jserv, eleanor15x, linux-pm,
linux-kernel, Kuan-Wei Chiu, stable
In of_icc_get_by_index() and icc_get(), if the dynamic allocation for
path->name fails via kasprintf(), the error handling path directly
calls kfree(path) to free the path object and returns an error.
However, prior to this point, path_find() calls path_init(), which
already links the path's requests into the req_list of the respective
interconnect nodes via hlist_add_head(). Directly invoking kfree(path)
leaves dangling pointers in the hlist. A subsequent call to icc_get()
or icc_set_bw() will traverse or modify these corrupted lists, triggering
a slab use afterfree.
KASAN report showing the vulnerability when reproducing via debugfs:
BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc
Write of size 8 at addr fff000000d43f748 by task sh/1
...
Call trace:
kasan_report+0xac/0xfc
path_find+0x6f8/0xcfc
icc_get+0x148/0x380
icc_get_set+0xf8/0x2d0
...
Freed by task 1:
kfree+0x1a0/0x4a4
icc_get+0x2cc/0x380
icc_get_set+0xf8/0x2d0
Fix this by replacing kfree(path) with the proper teardown function,
icc_put(path), which safely removes the requests from the req_list using
hlist_del() and drops the provider usage references before freeing the
memory.
Additionally, in icc_get(), ensure that the icc_lock mutex is released
prior to calling icc_put(path) to avoid a deadlock, as icc_put()
internally acquires the same lock.
Fixes: 3791163602f7 ("interconnect: Handle memory allocation errors")
Cc: stable@vger.kernel.org
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
I discovered this bug while reviewing Krzysztof's patch [1].
To verify my hypothesis, I injected an artificial kasprintf() failure
into the source code and wrote a minimal dummy icc provider module.
This allowed me to successfully trigger the use after free via the
debugfs client and catch it with KASAN, confirming the issue.
[1]: https://lore.kernel.org/lkml/20260416130912.375013-2-krzysztof.kozlowski@oss.qualcomm.com/
drivers/interconnect/core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 8569b78a1851..e14280ced381 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -528,7 +528,7 @@ struct icc_path *of_icc_get_by_index(struct device *dev, int idx)
path->name = kasprintf(GFP_KERNEL, "%s-%s",
src_data->node->name, dst_data->node->name);
if (!path->name) {
- kfree(path);
+ icc_put(path);
path = ERR_PTR(-ENOMEM);
}
@@ -626,8 +626,9 @@ struct icc_path *icc_get(struct device *dev, const char *src, const char *dst)
path->name = kasprintf(GFP_KERNEL, "%s-%s", src_node->name, dst_node->name);
if (!path->name) {
- kfree(path);
- path = ERR_PTR(-ENOMEM);
+ mutex_unlock(&icc_lock);
+ icc_put(path);
+ return ERR_PTR(-ENOMEM);
}
out:
mutex_unlock(&icc_lock);
--
2.54.0.rc1.555.g9c883467ad-goog
^ permalink raw reply related
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Kairui Song @ 2026-04-16 18:46 UTC (permalink / raw)
To: Nhat Pham
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <CAKEwX=NrUhUrAFx+8BYJEfaVKpCm-H9JhBzYSrqOQb-NW7QRug@mail.gmail.com>
On Wed, Apr 15, 2026 at 1:23 AM Nhat Pham <nphamcs@gmail.com> wrote:
> Hi Kairui,
>
> My apologies if I missed your response, but could you share with me
> your full benchmark suite? It would be hugely useful, not just for
> this series, but for all swap contributions in the future :) We should
> do as much homework ourselves as possible :P
>
> And apologies for the delayed response. I kept having to back and
> forth between regression investigating, and figuring out what was
> going on with the build setups (I missed some of the CONFIGs you had
> originally), reducing variance on hosts, etc.
>
Hello Nhat!
No worries, I was also thinking about submitting some in tree test for
that so testing will be easier, but got really busy with some other
issues, series and the incommong LSFMM, will find some time to do
that.
>
> 1. Kswapd is slower on the vswap side, which shifts work towards
> direct reclaim, and makes compaction have to run harder (which has a
> weird contention through zsmalloc - I can expand further, but this is
> not vswap-specific, just exacerbated by slower kswapd).
It might be related, e.g. could the dynamic alloc and RCU free of
vswap data cause more fragmentation hence more pressure?
> 2. Higher swap readahead (albeit with higher hit rate) - this is more
> of an artifact of the fact that zero swap pages are no longer backed
> by zram swapfile, which skipped readahead in certain paths. We can
> ignore this for now, but worth assessing this for fast swap backends
> in general (zero swap pages, zswap, so on and so forth).
Hmm... That just brought up another question, you can't tell the
backend type or properly do readahead until you look down through the
virtual layer I guess?
> I spent sometimes perf-ing kswapd, and hack the usemem binary a bit so
> that I can perf the free stage of usemem separately. Most of the
> vswap-specific overhead lies in the xarray lookups. Some big offenders
> on top of my mind:
>
> 1. Right now, in the physical swap allocator, whenever we have an
> allocated slot in the range we're checking, we check if that slot is
> swap-cache-only (i.e no swap count), and if so we try to free it (if
> swapfile is almost full etc.). This check is cheap if all swap entry
> metadata live in physical swap layer only, but more expensive when you
> have to go through another layer of indirection :)
>
> I fixed that by just taking one bit in the reverse map to track
> swap-cache-only state, which eliminates this without extra space
> overhead (on top of the existing design).
Isn't that HAS_CACHE :) ?
> 2. On the free path, in swap_pte_batch(), we check cgroup to make sure
> that the range we pass to free_swap_and_cache_nr() belongs to the same
> cgroup, which has a per-PTE overhead for going to the vswap layer. We
This might be helpful:
https://lore.kernel.org/linux-mm/20260417-swap-table-p4-v2-8-17f5d1015428@tencent.com/
I observed a similar but much smaller issue with the current swap too.
Deferring the cgroup lookup to the swap-cache layer, where we already
grab the cluster (in a later commit), should reduce a lot of overhead.
It requires some unification of allocation though as shown in that
series, things will be much easier after that :)
> Anyway, still a small gap. The next idea that I have is inspired by
> TLB, which cache virtual->physical memory address translation. I added
I think this is getting over complex... You got a mandatory virtual
layer, which already comes with some cluster cache inside, and the
lower physical allocator has its own cluster cache, and then a new set
of cache on top of the virtual layer?
>
> Some final remarks:
> * I still think there's a good chance we can *significantly* close the
> gap overall between a design with virtual swap and a design without.
> It's a bit premature to commit to a vswap-optional route (which to be
> completely honest I'm still not confident is possible to satisfy all
> of our requirements).
>
> * Regardless of the direction we take, these are all pitfalls that
> will be problematic for virtual swap design, and more generally some
> of them will affect any dynamic swap design (which has to go through
> some sort of indirection or a dynamic data structure like xarray that
> will induce some amount of lookup overhead). I hope my work here can
> be useful in this sense too, outside of this specific vswap direction
> :)
Glad to know things are getting better! We can definitely work
something out. But besides the problem above, I think there are some
other concerns that need to be solved too. Good part is I think
everyone agrees that some kind of intermediate layer is needed.
^ permalink raw reply
* Re: [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Yao Zi @ 2026-04-16 18:28 UTC (permalink / raw)
To: Shuwei Wu, Anand Moon
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>
On Thu, Apr 16, 2026 at 01:59:05PM +0800, Shuwei Wu 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(-)
> >>
...
> 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.
FYI, CCI550 is used for naming an ARM interconnect IP[1], which matches
your observation.
...
> Best regards,
> Shuwei Wu
Regards,
Yao Zi.
[1]: https://developer.arm.com/Processors/CoreLink%20CCI-550
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Aaro Koskinen @ 2026-04-16 18:13 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-tegra, linux-arm-kernel, linux-pm, linux-omap, linux-kernel,
Paul Walmsley, Geert Uytterhoeven
In-Reply-To: <20260416131810.3116408-1-thierry.reding@kernel.org>
Hello,
On Thu, Apr 16, 2026 at 03:18:10PM +0200, Thierry Reding wrote:
> 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>
Thanks for doing this. I think also the m68k work should be mentioned?
A.
> ---
> 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
* 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
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