Pull clk updates from Stephen Boyd:
"This is all clk driver updates. Mostly new SoC support for various
Qualcomm chips and Canaan K230. Otherwise there's non-critical fixes
and updates to clk data such as adding missing clks to existing
drivers or marking clks critical. Nothing looks especially exciting"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (106 commits)
clk: qcom: regmap-phy-mux: Rework the implementation
clk: qcom: a53: Corrected frequency multiplier for 1152MHz
clk: qcom: camcc-milos: Declare icc path dependency for CAMSS_TOP_GDSC
clk: qcom: gdsc: Support enabling interconnect path for power domain
dt-bindings: clock: qcom,milos-camcc: Document interconnect path
interconnect: Add devm_of_icc_get_by_index() as exported API for users
clk: qcom: camcc-x1p42100: Add support for camera clock controller
clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks
clk: qcom: videocc-x1p42100: Add support for video clock controller
dt-bindings: clock: qcom: Add X1P42100 camera clock controller
dt-bindings: clock: qcom: Add X1P42100 video clock controller
clk: keystone: sci-clk: fix application of sizeof to pointer
clk: keystone: don't cache clock rate
clk: spacemit: k3: Add PCIe DBI clock
dt-bindings: soc: spacemit: k3: Add PCIe DBI clock IDs
clk: spacemit: k3: Fix PCIe clock register offset
clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock
clk: at91: keep securam node alive while mapping it
clk: samsung: exynos990: Fix PERIC0/1 USI clock types
clk: renesas: r9a08g045: Drop unused pm_domain header file
...
This is the exact same thing as the 'alloc_obj()' version, only much
smaller because there are a lot fewer users of the *alloc_flex()
interface.
As with alloc_obj() version, this was done entirely with mindless brute
force, using the same script, except using 'flex' in the pattern rather
than 'objs*'.
Signed-off-by: Linus Torvalds <[email protected]>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <[email protected]>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <[email protected]>
The 'icc_bw_lock' mutex is introduced in commit af42269c35
("interconnect: Fix locking for runpm vs reclaim") in order to decouple
serialization of bw aggregation from codepaths that require memory
allocation.
However commit d30f83d278 ("interconnect: core: Add dynamic id
allocation support") added a devm_kasprintf() call into a path protected
by the 'icc_bw_lock' which causes the following lockdep warning on
machines like the Lenovo ThinkPad X13s:
======================================================
WARNING: possible circular locking dependency detected
6.16.0-rc3 #15 Not tainted
------------------------------------------------------
(udev-worker)/342 is trying to acquire lock:
ffffb973f7ec4638 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_node_track_caller_noprof+0xa0/0x3e0
but task is already holding lock:
ffffb973f7f7f0e8 (icc_bw_lock){+.+.}-{4:4}, at: icc_node_add+0x44/0x154
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (icc_bw_lock){+.+.}-{4:4}:
icc_init+0x48/0x108
do_one_initcall+0x64/0x30c
kernel_init_freeable+0x27c/0x500
kernel_init+0x20/0x1d8
ret_from_fork+0x10/0x20
-> #0 (fs_reclaim){+.+.}-{0:0}:
__lock_acquire+0x136c/0x2114
lock_acquire+0x1c8/0x354
fs_reclaim_acquire+0x74/0xa8
__kmalloc_node_track_caller_noprof+0xa0/0x3e0
devm_kmalloc+0x54/0x124
devm_kvasprintf+0x74/0xd4
devm_kasprintf+0x58/0x80
icc_node_add+0xb4/0x154
qcom_osm_l3_probe+0x20c/0x314 [icc_osm_l3]
platform_probe+0x68/0xd8
really_probe+0xc0/0x38c
__driver_probe_device+0x7c/0x160
driver_probe_device+0x40/0x110
__driver_attach+0xfc/0x208
bus_for_each_dev+0x74/0xd0
driver_attach+0x24/0x30
bus_add_driver+0x110/0x234
driver_register+0x60/0x128
__platform_driver_register+0x24/0x30
osm_l3_driver_init+0x20/0x1000 [icc_osm_l3]
do_one_initcall+0x64/0x30c
do_init_module+0x58/0x23c
load_module+0x1df8/0x1f70
init_module_from_file+0x88/0xc4
idempotent_init_module+0x188/0x280
__arm64_sys_finit_module+0x6c/0xd8
invoke_syscall+0x48/0x110
el0_svc_common.constprop.0+0xc0/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x4c/0x158
el0t_64_sync_handler+0xc8/0xcc
el0t_64_sync+0x198/0x19c
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(icc_bw_lock);
lock(fs_reclaim);
lock(icc_bw_lock);
lock(fs_reclaim);
*** DEADLOCK ***
The icc_node_add() functions is not designed to fail, and as such it
should not do any memory allocation. In order to avoid this, add a new
helper function for the name generation to be called by drivers which
are using the new dynamic id feature.
Fixes: d30f83d278 ("interconnect: core: Add dynamic id allocation support")
Signed-off-by: Gabor Juhos <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Co-developed-by: Johan Hovold <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Since commit d30f83d278 ("interconnect: core: Add dynamic id allocation
support"), interconnect node ids greater than or equal to ICC_DYN_ID_START
are reserved for dynamic id allocation. Yet the icc_node_create_nolock()
function allows to directly use such ids for creating nodes. This can
cause problems by executing dynamic id related codepaths even for nodes
intended to use static ids.
For example, the 'nsscc-ipq9574' driver creates interconnect nodes with
static ids starting from 19148. Because these ids belongs to the dynamic
id range, the icc_node_add() function replaces the node names
unexpectedly.
The node names looked like this before the change:
# grep nss_cc /sys/kernel/debug/interconnect/interconnect_summary
nss_cc_nssnoc_ppe_clk_master 0 0
nss_cc_nssnoc_ppe_clk_slave 0 0
nss_cc_nssnoc_ppe_cfg_clk_master 0 0
...
And those have an unexpected suffix now:
# grep nss_cc /sys/kernel/debug/interconnect/interconnect_summary
[email protected] 0 0
[email protected] 0 0
[email protected] 0 0
...
Increase the value of ICC_DYN_ID_START to avoid this.
Also, add sanity check to the icc_node_create_nolock() function to prevent
directly creating nodes with ids reserved for dynamic allocation in order
to detect these kind of problems.
Fixes: d30f83d278 ("interconnect: core: Add dynamic id allocation support")
Signed-off-by: Gabor Juhos <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
The current interconnect framework relies on static IDs for node
creation and registration, which limits topologies with multiple
instances of the same interconnect provider. To address this,
introduce icc_node_create_dyn() and icc_link_nodes() APIs to
dynamically allocate IDs for interconnect nodes during creation
and link. This change removes the dependency on static IDs,
allowing multiple instances of the same hardware, such as EPSS L3.
Signed-off-by: Raviteja Laggyshetty <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Georgi writes:
interconnect fixes for v6.9-rc
Here are fixes for two reported issues. One of them is a fix for
a driver that tries to access a non-existent resource which prints
a warning message during boot. The other one is fixing a race
condition in the core framework where one struct member has been
left unprotected by mutex.
- interconnect: qcom: x1e80100: Remove inexistent ACV_PERF BCM
- interconnect: Don't access req_list while it's being manipulated
Signed-off-by: Georgi Djakov <[email protected]>
* tag 'icc-6.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc:
interconnect: Don't access req_list while it's being manipulated
interconnect: qcom: x1e80100: Remove inexistent ACV_PERF BCM
The icc_lock mutex was split into separate icc_lock and icc_bw_lock
mutexes in [1] to avoid lockdep splats. However, this didn't adequately
protect access to icc_node::req_list.
The icc_set_bw() function will eventually iterate over req_list while
only holding icc_bw_lock, but req_list can be modified while only
holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),
and icc_put().
Example A:
CPU0 CPU1
---- ----
icc_set_bw(path_a)
mutex_lock(&icc_bw_lock);
icc_put(path_b)
mutex_lock(&icc_lock);
aggregate_requests()
hlist_for_each_entry(r, ...
hlist_del(...
<r = invalid pointer>
Example B:
CPU0 CPU1
---- ----
icc_set_bw(path_a)
mutex_lock(&icc_bw_lock);
path_b = of_icc_get()
of_icc_get_by_index()
mutex_lock(&icc_lock);
path_find()
path_init()
aggregate_requests()
hlist_for_each_entry(r, ...
hlist_add_head(...
<r = invalid pointer>
Fix this by ensuring icc_bw_lock is always held before manipulating
icc_node::req_list. The additional places icc_bw_lock is held don't
perform any memory allocations, so we should still be safe from the
original lockdep splats that motivated the separate locks.
[1] commit af42269c35 ("interconnect: Fix locking for runpm vs reclaim")
Signed-off-by: Mike Tipton <[email protected]>
Fixes: af42269c35 ("interconnect: Fix locking for runpm vs reclaim")
Reviewed-by: Rob Clark <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Currently, if provider->xlate() or provider->xlate_extended()
"successfully" return a NULL node, then of_icc_get_from_provider() won't
consider that an error and will successfully return the NULL node. This
bypasses error handling in of_icc_get_by_index() and leads to NULL
dereferences in path_find().
This could be avoided by ensuring provider callbacks always return an
error for NULL nodes, but it's better to explicitly protect against this
in the common framework.
Fixes: 87e3031b6f ("interconnect: Allow endpoints translation via DT")
Signed-off-by: Mike Tipton <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
This series introduces interconnect debugfs files that support voting
for any interconnect path the framework supports. It is useful for debug,
test and verification.
* icc-debugfs
debugfs: Add write support to debugfs_create_str()
interconnect: Reintroduce icc_get()
interconnect: Add debugfs test client
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
It's often useful during test, debug, and development to issue path
votes from shell. Add a debugfs client for this purpose.
Example usage:
cd /sys/kernel/debug/interconnect/test-client/
# Configure node endpoints for the path from CPU to DDR on
# qcom/sm8550.
echo chm_apps > src_node
echo ebi > dst_node
# Get path between src_node and dst_node. This is only
# necessary after updating the node endpoints.
echo 1 > get
# Set desired BW to 1GBps avg and 2GBps peak.
echo 1000000 > avg_bw
echo 2000000 > peak_bw
# Vote for avg_bw and peak_bw on the latest path from "get".
# Voting for multiple paths is possible by repeating this
# process for different nodes endpoints.
echo 1 > commit
Allowing userspace to directly enable and set bus rates can be dangerous
So, following in the footsteps of the regmap [0] and clk [1] frameworks,
keep these userspace controls compile-time disabled without Kconfig
options to enable them. Enabling this will require code changes to
define INTERCONNECT_ALLOW_WRITE_DEBUGFS.
[0] commit 09c6ecd394 ("regmap: Add support for writing to regmap registers via debugfs")
[1] commit 37215da555 ("clk: Add support for setting clk_rate via debugfs")
Signed-off-by: Mike Tipton <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
The original icc_get() that took integer node IDs was removed due to
lack of users. Reintroduce a new version that takes string node names,
which is needed for the debugfs client.
Signed-off-by: Mike Tipton <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
The icc_get() interface can be used to lookup an interconnect path based
on global node ids. There has never been any users of this interface and
all lookups are currently done from the devicetree.
Remove the unused icc_get() interface.
Reviewed-by: Konrad Dybcio <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Pull module updates from Luis Chamberlain:
"The summary of the changes for this pull requests is:
- Song Liu's new struct module_memory replacement
- Nick Alcock's MODULE_LICENSE() removal for non-modules
- My cleanups and enhancements to reduce the areas where we vmalloc
module memory for duplicates, and the respective debug code which
proves the remaining vmalloc pressure comes from userspace.
Most of the changes have been in linux-next for quite some time except
the minor fixes I made to check if a module was already loaded prior
to allocating the final module memory with vmalloc and the respective
debug code it introduces to help clarify the issue. Although the
functional change is small it is rather safe as it can only *help*
reduce vmalloc space for duplicates and is confirmed to fix a bootup
issue with over 400 CPUs with KASAN enabled. I don't expect stable
kernels to pick up that fix as the cleanups would have also had to
have been picked up. Folks on larger CPU systems with modules will
want to just upgrade if vmalloc space has been an issue on bootup.
Given the size of this request, here's some more elaborate details:
The functional change change in this pull request is the very first
patch from Song Liu which replaces the 'struct module_layout' with a
new 'struct module_memory'. The old data structure tried to put
together all types of supported module memory types in one data
structure, the new one abstracts the differences in memory types in a
module to allow each one to provide their own set of details. This
paves the way in the future so we can deal with them in a cleaner way.
If you look at changes they also provide a nice cleanup of how we
handle these different memory areas in a module. This change has been
in linux-next since before the merge window opened for v6.3 so to
provide more than a full kernel cycle of testing. It's a good thing as
quite a bit of fixes have been found for it.
Jason Baron then made dynamic debug a first class citizen module user
by using module notifier callbacks to allocate / remove module
specific dynamic debug information.
Nick Alcock has done quite a bit of work cross-tree to remove module
license tags from things which cannot possibly be module at my request
so to:
a) help him with his longer term tooling goals which require a
deterministic evaluation if a piece a symbol code could ever be
part of a module or not. But quite recently it is has been made
clear that tooling is not the only one that would benefit.
Disambiguating symbols also helps efforts such as live patching,
kprobes and BPF, but for other reasons and R&D on this area is
active with no clear solution in sight.
b) help us inch closer to the now generally accepted long term goal
of automating all the MODULE_LICENSE() tags from SPDX license tags
In so far as a) is concerned, although module license tags are a no-op
for non-modules, tools which would want create a mapping of possible
modules can only rely on the module license tag after the commit
8b41fc4454 ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf").
Nick has been working on this *for years* and AFAICT I was the only
one to suggest two alternatives to this approach for tooling. The
complexity in one of my suggested approaches lies in that we'd need a
possible-obj-m and a could-be-module which would check if the object
being built is part of any kconfig build which could ever lead to it
being part of a module, and if so define a new define
-DPOSSIBLE_MODULE [0].
A more obvious yet theoretical approach I've suggested would be to
have a tristate in kconfig imply the same new -DPOSSIBLE_MODULE as
well but that means getting kconfig symbol names mapping to modules
always, and I don't think that's the case today. I am not aware of
Nick or anyone exploring either of these options. Quite recently Josh
Poimboeuf has pointed out that live patching, kprobes and BPF would
benefit from resolving some part of the disambiguation as well but for
other reasons. The function granularity KASLR (fgkaslr) patches were
mentioned but Joe Lawrence has clarified this effort has been dropped
with no clear solution in sight [1].
In the meantime removing module license tags from code which could
never be modules is welcomed for both objectives mentioned above. Some
developers have also welcomed these changes as it has helped clarify
when a module was never possible and they forgot to clean this up, and
so you'll see quite a bit of Nick's patches in other pull requests for
this merge window. I just picked up the stragglers after rc3. LWN has
good coverage on the motivation behind this work [2] and the typical
cross-tree issues he ran into along the way. The only concrete blocker
issue he ran into was that we should not remove the MODULE_LICENSE()
tags from files which have no SPDX tags yet, even if they can never be
modules. Nick ended up giving up on his efforts due to having to do
this vetting and backlash he ran into from folks who really did *not
understand* the core of the issue nor were providing any alternative /
guidance. I've gone through his changes and dropped the patches which
dropped the module license tags where an SPDX license tag was missing,
it only consisted of 11 drivers. To see if a pull request deals with a
file which lacks SPDX tags you can just use:
./scripts/spdxcheck.py -f \
$(git diff --name-only commid-id | xargs echo)
You'll see a core module file in this pull request for the above, but
that's not related to his changes. WE just need to add the SPDX
license tag for the kernel/module/kmod.c file in the future but it
demonstrates the effectiveness of the script.
Most of Nick's changes were spread out through different trees, and I
just picked up the slack after rc3 for the last kernel was out. Those
changes have been in linux-next for over two weeks.
The cleanups, debug code I added and final fix I added for modules
were motivated by David Hildenbrand's report of boot failing on a
systems with over 400 CPUs when KASAN was enabled due to running out
of virtual memory space. Although the functional change only consists
of 3 lines in the patch "module: avoid allocation if module is already
present and ready", proving that this was the best we can do on the
modules side took quite a bit of effort and new debug code.
The initial cleanups I did on the modules side of things has been in
linux-next since around rc3 of the last kernel, the actual final fix
for and debug code however have only been in linux-next for about a
week or so but I think it is worth getting that code in for this merge
window as it does help fix / prove / evaluate the issues reported with
larger number of CPUs. Userspace is not yet fixed as it is taking a
bit of time for folks to understand the crux of the issue and find a
proper resolution. Worst come to worst, I have a kludge-of-concept [3]
of how to make kernel_read*() calls for modules unique / converge
them, but I'm currently inclined to just see if userspace can fix this
instead"
Link: https://lore.kernel.org/all/Y/[email protected]/ [0]
Link: https://lkml.kernel.org/r/[email protected] [1]
Link: https://lwn.net/Articles/927569/ [2]
Link: https://lkml.kernel.org/r/[email protected] [3]
* tag 'modules-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: (121 commits)
module: add debugging auto-load duplicate module support
module: stats: fix invalid_mod_bytes typo
module: remove use of uninitialized variable len
module: fix building stats for 32-bit targets
module: stats: include uapi/linux/module.h
module: avoid allocation if module is already present and ready
module: add debug stats to help identify memory pressure
module: extract patient module check into helper
modules/kmod: replace implementation with a semaphore
Change DEFINE_SEMAPHORE() to take a number argument
module: fix kmemleak annotations for non init ELF sections
module: Ignore L0 and rename is_arm_mapping_symbol()
module: Move is_arm_mapping_symbol() to module_symbol.h
module: Sync code of is_arm_mapping_symbol()
scripts/gdb: use mem instead of core_layout to get the module address
interconnect: remove module-related code
interconnect: remove MODULE_LICENSE in non-modules
zswap: remove MODULE_LICENSE in non-modules
zpool: remove MODULE_LICENSE in non-modules
x86/mm/dump_pagetables: remove MODULE_LICENSE in non-modules
...
Since commit 8b41fc4454 ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock <[email protected]>
Suggested-by: Luis Chamberlain <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Hitomi Hasegawa <[email protected]>
Cc: Georgi Djakov <[email protected]>
Cc: [email protected]
Signed-off-by: Luis Chamberlain <[email protected]>
Now that the link array is deallocated when destroying nodes and the
explicit link removal has been dropped from the exynos driver there are
no further users of and no need for the icc_link_destroy() interface.
Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.
Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Currently framework sets bw even when init bw requirements are zero during
provider registration, thus resulting bulk of set bw to hw.
Avoid this behaviour by skipping provider set bw calls if init bw is zero.
Signed-off-by: Vivek Aknurwar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
The current interconnect provider interface is inherently racy as
providers are expected to be added before being fully initialised.
Specifically, nodes are currently not added and the provider data is not
initialised until after registering the provider which can cause racing
DT lookups to fail.
Add a new provider API which will be used to fix up the interconnect
drivers.
The old API is reimplemented using the new interface and will be removed
once all drivers have been fixed.
Fixes: 11f1ceca70 ("interconnect: Add generic on-chip interconnect API")
Fixes: 87e3031b6f ("interconnect: Allow endpoints translation via DT")
Cc: [email protected] # 5.1
Reviewed-by: Konrad Dybcio <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Tested-by: Luca Ceresoli <[email protected]> # i.MX8MP MSC SM2-MB-EP1 Board
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
The interconnect framework currently expects that providers are only
removed when there are no users and after all nodes have been removed.
There is currently nothing that guarantees this to be the case and the
framework does not do any reference counting, but refusing to remove the
provider is never correct as that would leave a dangling pointer to a
resource that is about to be released in the global provider list (e.g.
accessible through debugfs).
Replace the current sanity checks with WARN_ON() so that the provider is
always removed.
Fixes: 11f1ceca70 ("interconnect: Add generic on-chip interconnect API")
Cc: [email protected] # 5.1: 680f8666ba: interconnect: Make icc_provider_del() return void
Reviewed-by: Konrad Dybcio <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Tested-by: Luca Ceresoli <[email protected]> # i.MX8MP MSC SM2-MB-EP1 Board
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Similar to the sdx55 and sc7180, let's drop the MASTER_IPA_CORE and
SLAVE_IPA_CORE interconnects for this platofm. There are no actual users
of this intercoonect. The IP0 resource will be handled by clk-rpmh
driver.
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Similar to the sdx55 and sc7180, let's drop the MASTER_IPA_CORE and
SLAVE_IPA_CORE interconnects for this platform. There are no actual users
of this interconnect. The IP0 resource will be handled by clk-rpmh
driver.
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Similar to the sdx55 and sc7180, let's drop the MASTER_IPA_CORE and
SLAVE_IPA_CORE interconnects for this platform. There are no actual users
of this interconnect. The IP0 resource will be handled by clk-rpmh
driver.
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Move the const ignore_list definition out of the
of_count_icc_providers() function. This prevents the following stack
frame size warnings if the list is expanded:
drivers/interconnect/core.c:1082:12: warning: stack frame size (1216) exceeds limit (1024) in 'of_count_icc_providers' [-Wframe-larger-than]
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Ignore compatible strings for the IPA virt drivers that were removed in
commits 2fb251c265 ("interconnect: qcom: sdx55: Drop IP0
interconnects") and 2f3724930e ("interconnect: qcom: sc7180: Drop IP0
interconnects") so that the sync state logic can kick in again.
Otherwise all the interconnects in the system will stay pegged at max
speeds because 'providers_count' is always going to be one larger than
the number of drivers that will ever probe on sc7180 or sdx55. This
fixes suspend on sc7180 and sdx55 devices when you don't have a
devicetree patch to remove the ipa-virt compatible node.
Cc: Bjorn Andersson <[email protected]>
Cc: Doug Anderson <[email protected]>
Cc: Alex Elder <[email protected]>
Cc: Taniya Das <[email protected]>
Cc: Mike Tipton <[email protected]>
Fixes: 2fb251c265 ("interconnect: qcom: sdx55: Drop IP0 interconnects")
Fixes: 2f3724930e ("interconnect: qcom: sc7180: Drop IP0 interconnects")
Signed-off-by: Stephen Boyd <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Georgi writes:
interconnect changes for 5.15
Here are changes for the 5.15-rc1 merge window consisting of interconnect
core and driver updates.
Framework change:
- Add sanity check to detect if node is already added to provider.
Driver changes:
- RPMh drivers probe function consolidation
- Add driver for SC8180x platforms
- Add support for SC8180x OSM L3
- Use driver-specific naming in OSM L3
Signed-off-by: Georgi Djakov <[email protected]>
* tag 'icc-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc:
interconnect: qcom: osm-l3: Use driver-specific naming
interconnect: qcom: osm-l3: Add sc8180x support
dt-bindings: interconnect: Add SC8180x to OSM L3 DT binding
interconnect: qcom: Add SC8180x providers
dt-bindings: interconnect: Add Qualcomm SC8180x DT bindings
interconnect: Sanity check that node isn't already on list
interconnect: qcom: icc-rpmh: Consolidate probe functions
The expression sizeof(**ptr) for the void **ptr is just 1 rather than
the size of a pointer. Fix this by using sizeof(*ptr).
Addresses-Coverity: ("Wrong sizeof argument")
Fixes: e145d9a184 ("interconnect: Add devm_of_icc_get() as exported API for users")
Signed-off-by: Colin Ian King <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
The pre_aggregate callback isn't called in all cases before calling
aggregate. Add the missing calls so providers can rely on consistent
framework behavior.
Fixes: d3703b3e25 ("interconnect: Aggregate before setting initial bandwidth")
Signed-off-by: Mike Tipton <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
The initial BW values may be used by providers to enforce floors. Zero
these values after sync-state so that providers know when to stop
enforcing them.
Fixes: b1d681d8d3 ("interconnect: Add sync state support")
Signed-off-by: Mike Tipton <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Broken interconnect providers might add the same node multiple times or
in multiple providers, which causes strange errors as the provider's
node list is later traversed.
Detect that a node already has an associated provider, complain and
reject the addition of the node, to aid the developer.
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
of_count_icc_providers() function uses for_each_available_child_of_node()
helper to recursively check all the available nodes. This helper already
properly handles child nodes' reference count, so there is no need to do
it explicitly. Remove the excessive call to of_node_put(). This fixes
memory trashing when CONFIG_OF_DYNAMIC is enabled (for example
arm/multi_v7_defconfig).
Fixes: b1d681d8d3 ("interconnect: Add sync state support")
Signed-off-by: Marek Szyprowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
When setting the initial bandwidth, make sure to call the aggregate()
function (if such is implemented for the current provider), to handle
cases when data needs to be aggregated first.
Fixes: b1d681d8d3 ("interconnect: Add sync state support")
Acked-by: Saravana Kannan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
* icc-syncstate:
interconnect: Add get_bw() callback
interconnect: Add sync state support
interconnect: qcom: Use icc_sync_state
Signed-off-by: Georgi Djakov <[email protected]>
The bootloaders often do some initial configuration of the interconnects
in the system and we want to keep this configuration until all consumers
have probed and expressed their bandwidth needs. This is because we don't
want to change the configuration by starting to disable unused paths until
every user had a chance to request the amount of bandwidth it needs.
To accomplish this we will implement an interconnect specific sync_state
callback which will synchronize (aggregate and set) the current bandwidth
settings when all consumers have been probed.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Saravana Kannan <[email protected]>
Signed-off-by: Georgi Djakov <[email protected]>
Currently there is the xlate() callback, which is used by providers for
mapping the nodes from phandle arguments. That's fine for simple mappings,
but the phandle arguments could contain an additional data, such as tag
information. Let's create another callback xlate_extended() for the cases
where providers want also populate the path tag data.
Tested-by: Sibi Sankar <[email protected]>
Reviewed-by: Sibi Sankar <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
Tested-by: Matthias Kaehlcke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Georgi Djakov <[email protected]>
Linus Torvalds