linux.git/drivers/devfreq, branch v6.18.21

PM / devfreq: hisi: Fix potential UAF in OPP handling

2025-12-18T13:03:11+00:00

[ Upstream commit 26dd44a40096468396b6438985d8e44e0743f64c ]

Ensure all required data is acquired before calling dev_pm_opp_put(opp)
to maintain correct resource acquisition and release order.

Fixes: 7da2fdaaa1e6 ("PM / devfreq: Add HiSilicon uncore frequency scaling driver")
Signed-off-by: Pengjie Zhang 
Reviewed-by: Jie Zhan 
Acked-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Link: https://patchwork.kernel.org/project/linux-pm/patch/20250915062135.748653-1-zhangpengjie2@huawei.com/
Signed-off-by: Sasha Levin

PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro

2025-10-15T14:39:54+00:00

The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.

Like many other Rockchip drivers, rockchip-dfi brings with it its own
HIWORD_UPDATE macro. This variant doesn't shift the value (and like the
others, doesn't do any checking).

Remove it, and replace instances of it with hw_bitfield.h's
FIELD_PREP_WM16.  Since FIELD_PREP_WM16 requires contiguous masks and
shifts the value for us, some reshuffling of definitions needs to
happen.

This gives us better compile-time error checking, and in my opinion,
nicer code.

Tested on an RK3568 ODROID-M1 board (LPDDR4X at 1560 MHz, an RK3588
Radxa ROCK 5B board (LPDDR4X at 2112 MHz) and an RK3588 Radxa ROCK 5T
board (LPDDR5 at 2400 MHz). perf measurements were consistent with the
measurements of stress-ng --stream in all cases.

Signed-off-by: Nicolas Frattaroli 
Signed-off-by: Yury Norov (NVIDIA)

PM / devfreq: rockchip-dfi: add support for LPDDR5

2025-09-09T14:37:39+00:00

The Rockchip RK3588 SoC can also support LPDDR5 memory. This type of
memory needs some special case handling in the rockchip-dfi driver.

Add support for it in rockchip-dfi, as well as the needed GRF register
definitions.

This has been tested as returning both the right cycle count and
bandwidth on a LPDDR5 board where the CKR bit is 1. I couldn't test
whether the values are correct on a system where CKR is 0, as I'm not
savvy enough with the Rockchip tooling to know whether this can be set
in the DDR init blob.

Downstream has some special case handling for a hardware version where
not just the control bits differ, but also the register. Since I don't
know whether that hardware version is in any production silicon, it's
left unimplemented for now, with an error message urging users to report
if they have such a system.

There is a slight change of behaviour for non-LPDDR5 systems: instead of
writing 0 as the control flags to the control register and pretending
everything is alright if the memory type is unknown, we now explicitly
return an error.

Signed-off-by: Nicolas Frattaroli 
Reviewed-by: Sascha Hauer 
Acked-by: Heiko Stuebner 
Signed-off-by: Chanwoo Choi 
Link: https://patchwork.kernel.org/project/linux-pm/patch/20250530-rk3588-dfi-improvements-v1-2-6e077c243a95@collabora.com/

PM / devfreq: rockchip-dfi: double count on RK3588

2025-09-09T14:37:39+00:00

On RK3588 with LPDDR4X memory, the cycle count as returned by

perf stat -a -e rockchip_ddr/cycles/ sleep 1

consistently reads half as much as what the actual DDR frequency is at.
For a LPDDR4X module running at 2112MHz, I get more like 1056059916
cycles per second, which is almost bang-on half what it should be. No,
I'm not mixing up megatransfers and megahertz.

Consulting the downstream driver, this appears to be because the RK3588
hardware specifically (and RK3528 as well, for future reference) needs a
multiplier of 2 to get to the correct frequency with everything but
LPDDR5.

The RK3588's actual memory bandwidth measurements in MB/s are correct
however, as confirmed with stress-ng --stream. This makes me think the
access counters are not affected in the same way. This tracks with the
vendor kernel not multiplying the access counts either.

Solve this by adding a new member to the dfi struct, which each SoC can
set to whatever they want, but defaults to 1 if left unset by the SoC
init functions. The event_get_count op can then use this multiplier if
the cycle count is requested.

The cycle multiplier is not used in rockchip_dfi_get_event because the
vendor driver doesn't use it there either, and we don't do other actual
bandwidth unit conversion stuff in there anyway.

Fixes: 481d97ba61e1 ("PM / devfreq: rockchip-dfi: add support for RK3588")
Signed-off-by: Nicolas Frattaroli
Signed-off-by: Chanwoo Choi
Link: https://lore.kernel.org/lkml/20250530-rk3588-dfi-improvements-v1-1-6e077c243a95@collabora.com/

PM / devfreq: mtk-cci: avoid redundant conditions

2025-09-08T08:19:25+00:00

While 'if (i <= 0) ... else if (i > 0) ...' is technically equivalent to
'if (i <= 0) ... else ...', the latter is vastly easier to read because
it avoids writing out a condition that is unnecessary. Let's drop such
unnecessary conditions.

Signed-off-by: Liao Yuanhong 
Signed-off-by: Chanwoo Choi 
Link: https://patchwork.kernel.org/project/linux-pm/patch/20250903121452.387023-1-liaoyuanhong@vivo.com/

PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()

2025-09-06T16:15:17+00:00

The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which
would lead to a error pointer dereference.  Use IS_ERR_OR_NULL() to check
that the pointer is valid.

Fixes: e09bd5757b52 ("PM / devfreq: mtk-cci: Handle sram regulator probe deferral")
Signed-off-by: Dan Carpenter 
Signed-off-by: Chanwoo Choi 
Link: https://patchwork.kernel.org/project/linux-pm/patch/aJTNHz8kk8s6Q2os@stanley.mountain/

PM / devfreq: Add HiSilicon uncore frequency scaling driver

2025-07-14T11:23:57+00:00

Add the HiSilicon uncore frequency scaling driver for Kunpeng SoCs based on
the devfreq framework.  The uncore domain contains shared computing
resources, including system interconnects and L3 cache.  The uncore
frequency significantly impacts the system-wide performance as well as
power consumption.  This driver adds support for runtime management of
uncore frequency from kernel and userspace.  The main function includes
setting and getting frequencies, changing frequency scaling policies, and
querying the list of CPUs whose performance is significantly related to
this uncore frequency domain, etc.  The driver communicates with a platform
controller through an ACPI PCC mailbox to take the actual actions of
frequency scaling.

Co-developed-by: Lifeng Zheng 
Signed-off-by: Lifeng Zheng 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Huisong Li 
Signed-off-by: Jie Zhan 
Signed-off-by: Chanwoo Choi 
Link: https://patchwork.kernel.org/project/linux-pm/patch/20250623143401.4095045-3-zhanjie9@hisilicon.com/

PM / devfreq: Allow devfreq driver to add custom sysfs ABIs

2025-07-14T11:22:59+00:00

Extend the devfreq_dev_profile to allow drivers optionally create
device-specific sysfs ABIs together with other common devfreq ABIs under
the devfreq device path.

Reviewed-by: Jonathan Cameron 
Reviewed-by: Huisong Li 
Signed-off-by: Jie Zhan 
Signed-off-by: Chanwoo Choi 
Link: https://patchwork.kernel.org/project/linux-pm/patch/20250623143401.4095045-2-zhanjie9@hisilicon.com/

PM / devfreq: sun8i-a33-mbus: Simplify by using more devm functions

2025-07-14T11:04:17+00:00

Use devm allocators for enabling the bus clock and
clk_rate_exclusive_get(). This simplifies error handling and the remove
callback.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Uwe Kleine-König 
Tested-by: Corentin LABBE 
Link: https://patchwork.kernel.org/project/linux-pm/patch/20250513203908.205060-2-u.kleine-koenig@baylibre.com/
Signed-off-by: Chanwoo Choi

PM / devfreq: Fix a index typo in trans_stat

2025-07-14T11:04:17+00:00

Fixes: 4920ee6dcfaf ("PM / devfreq: Convert to use sysfs_emit_at() API")
Signed-off-by: pls 
Link: https://patchwork.kernel.org/project/linux-pm/patch/20250515143100.17849-1-chanwoo@kernel.org/
Signed-off-by: Chanwoo Choi