linux.git/drivers/interconnect/core.c, branch v6.18.21

interconnect: core: Use device_match_of_node()

2025-09-12T10:53:12+00:00

Make use of device_match_of_node() instead of open coding its
functionality.

Signed-off-by: Zhang Enpei 
Link: https://lore.kernel.org/r/20250807141833927wb2idY1sZi1OpUKkrXk44@zte.com.cn
Signed-off-by: Georgi Djakov

interconnect: avoid memory allocation when 'icc_bw_lock' is held

2025-06-27T18:43:40+00:00

The 'icc_bw_lock' mutex is introduced in commit af42269c3523
("interconnect: Fix locking for runpm vs reclaim") in order to decouple
serialization of bw aggregation from codepaths that require memory
allocation.

However commit d30f83d278a9 ("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: d30f83d278a9 ("interconnect: core: Add dynamic id allocation support")
Signed-off-by: Gabor Juhos 
Link: https://lore.kernel.org/r/20250625-icc-bw-lockdep-v3-1-2b8f8b8987c4@gmail.com
Co-developed-by: Johan Hovold 
Signed-off-by: Johan Hovold 
Link: https://lore.kernel.org/r/20250627075854.26943-1-johan+linaro@kernel.org
Signed-off-by: Georgi Djakov

interconnect: increase ICC_DYN_ID_START

2025-06-26T16:17:19+00:00

Since commit d30f83d278a9 ("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
  nss_cc_nssnoc_ppe_clk_master@39b00000.clock-controller            0            0
  nss_cc_nssnoc_ppe_clk_slave@39b00000.clock-controller            0            0
  nss_cc_nssnoc_ppe_cfg_clk_master@39b00000.clock-controller            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: d30f83d278a9 ("interconnect: core: Add dynamic id allocation support")
Signed-off-by: Gabor Juhos 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20250625-icc-dyn-id-fix-v1-1-127cb5498449@gmail.com
Signed-off-by: Georgi Djakov

interconnect: core: Add dynamic id allocation support

2025-04-15T11:13:36+00:00

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 
Link: https://lore.kernel.org/r/20250415095343.32125-3-quic_rlaggysh@quicinc.com
Signed-off-by: Georgi Djakov

interconnect: Use of_property_present() for non-boolean properties

2024-11-04T23:27:39+00:00

The use of of_property_read_bool() for non-boolean properties is
deprecated in favor of of_property_present() when testing for property
presence.

Signed-off-by: "Rob Herring (Arm)" 
Link: https://lore.kernel.org/r/20241104190650.275278-1-robh@kernel.org
Signed-off-by: Georgi Djakov

interconnect: Remove a useless kfree_const() usage

2024-10-22T08:17:24+00:00

"path->name" is allocated in of_icc_get_by_index() using kasprintf(), so
there is no point in using kfree_const() to free it.

Switch to the more standard kfree() to free this.

Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/06630f9ec3e153d0e7773b8d97a17e7c53e0d606.1727375615.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Georgi Djakov

Merge tag 'icc-6.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-work-linus

2024-04-11T12:44:49+00:00

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 

* 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

interconnect: Don't access req_list while it's being manipulated

2024-03-14T11:51:44+00:00

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(...
        

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(...
        

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 af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

Signed-off-by: Mike Tipton 
Fixes: af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
Reviewed-by: Rob Clark 
Link: https://lore.kernel.org/r/20240305225652.22872-1-quic_mdtipton@quicinc.com
Signed-off-by: Georgi Djakov

interconnect: constify of_phandle_args in xlate

2024-02-25T22:38:17+00:00

The xlate callbacks are supposed to translate of_phandle_args to proper
provider without modifying the of_phandle_args.  Make the argument
pointer to const for code safety and readability.

Acked-by: Konrad Dybcio 
Acked-by: Thierry Reding  # Tegra
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Alim Akhtar  # Samsung
Link: https://lore.kernel.org/r/20240220072213.35779-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov

interconnect: Treat xlate() returning NULL node as an error

2023-11-22T12:36:03+00:00

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: 87e3031b6fbd ("interconnect: Allow endpoints translation via DT")
Signed-off-by: Mike Tipton 
Link: https://lore.kernel.org/r/20231025145829.11603-1-quic_mdtipton@quicinc.com
Signed-off-by: Georgi Djakov