linux-stable.git/drivers/opp, branch v6.18.33

OPP: Move break out of scoped_guard in dev_pm_opp_xlate_required_opp()

2026-05-23T11:06:23+00:00

[ Upstream commit 3d2398f44a2d48fb1c575a6e0bc6b38f3e689e22 ]

The commit ff9c512041f2 ("OPP: Use mutex locking guards")
unintentionally made the for loop run longer than required.

scoped_guard() is implemented as a for loop. The break statement now
breaks out out the scoped_guard() and not out of the outer for loop.
The outer loop always iterates to completion.

Fix it.

Fixes: ff9c512041f2 ("OPP: Use mutex locking guards")
Reported-by: David Lechner 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

OPP: debugfs: Use performance level if available to distinguish between rates

2026-05-23T11:06:23+00:00

[ Upstream commit e560083c0467f86b72aecac377b27bd1e7d16c49 ]

Some OPP tables have entries with same rate and different performance
level. For these entries, using only the rate as the debugfs directory name
causes below error:

debugfs: 'opp:5000000' already exists in 'soc@0-1c00000.pci'

Fix it by appending the performance level to the dir name if available.

Reported-by: Bjorn Andersson 
Closes: https://lore.kernel.org/linux-arm-msm/75lzykd37zdvrks5i2bb4zb2yzjtm25kv3hegmikndkbr772mz@w2ykff3ny45u/
Fixes: 05db35963eef ("OPP: Add support to find OPP for a set of keys")
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

OPP: Return correct value in dev_pm_opp_get_level

2026-02-26T22:59:00+00:00

[ Upstream commit 0b7277e02dabba2a9921a7f4761ae6e627e7297a ]

Commit 073d3d2ca7d4 ("OPP: Level zero is valid") modified the
documentation for this function to indicate that errors should return a
non-zero value to avoid colliding with the OPP level zero, however
forgot to actually update the return.

No in-tree kernel code depends on the error value being 0.

Fixes: 073d3d2ca7d4 ("OPP: Level zero is valid")
Signed-off-by: Aleks Todorov 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

OPP: Add support to find OPP for a set of keys

2025-08-26T05:10:58+00:00

Some clients, such as PCIe, may operate at the same clock frequency
across different data rates by varying link width. In such cases,
frequency alone is not sufficient to uniquely identify an OPP.

To support these scenarios, introduce a new API
dev_pm_opp_find_key_exact() that allows OPP lookup with different
set of keys like freq, level & bandwidth.

Signed-off-by: Krishna Chaitanya Chundru 
[ Viresh: Minor cleanups ]
Signed-off-by: Viresh Kumar

OPP: switch to use kmemdup_array()

2025-05-19T10:07:53+00:00

Use kmemdup_array() to avoid multiplication and possible overflows.

Signed-off-by: Zhang Enpei 
Signed-off-by: Viresh Kumar

OPP: Use mutex locking guards

2025-05-02T05:25:52+00:00

Use mutex locking guard in the OPP core.

No intentional functional impact.

Signed-off-by: Viresh Kumar

OPP: Define and use scope-based cleanup helpers

2025-05-02T05:25:40+00:00

Define and use scope-based cleanup helpers for `struct opp` and `struct
opp_table`.

No intentional functional impact.

Signed-off-by: Viresh Kumar

OPP: Use scope-based OF cleanup helpers

2025-04-24T10:35:59+00:00

Use the OF scope-based cleanup helpers for the OPP core.

No intentional functional impact.

Signed-off-by: Viresh Kumar

OPP: Return opp_table from dev_pm_opp_get_opp_table_ref()

2025-04-24T10:35:56+00:00

For convenience of users, return back the pointer to the opp_table from
dev_pm_opp_get_opp_table_ref(), so they can do:

	opp_table = dev_pm_opp_get_opp_table_ref(tmp_table);

No intentional functional impact.

Signed-off-by: Viresh Kumar

OPP: Return opp from dev_pm_opp_get()

2025-04-24T10:35:53+00:00

For convenience of users, return back the pointer to the opp from
dev_pm_opp_get(), so they can do:

	opp = dev_pm_opp_get(tmp_opp);

No intentional functional impact.

Signed-off-by: Viresh Kumar