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

interconnect: mediatek: Aggregate bandwidth with saturating add

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

[ Upstream commit 6ffd02b82243d9907b5f5d2c7a2fc6a62669eece ]

By using a regular non-overflow-checking add, the MediaTek icc-emi
driver will happy wrap at U32_MAX + 1 to 0. As it's common for the
interconnect core to fill in INT_MAX values, this is not a hypothetical
situation, but something that actually happens in regular use. This
would be pretty disasterous if anything used this driver.

Replace the addition with an overflow-checked addition from overflow.h,
and saturate to U32_MAX if an overflow is detected.

Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver")
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Nicolas Frattaroli 
Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-13-d9c1334db9f3@collabora.com
Signed-off-by: Georgi Djakov 
Signed-off-by: Sasha Levin

interconnect: mediatek: Don't hijack parent device

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

[ Upstream commit 510f8214440c553e81774c5822437ccf154e9e38 ]

If the intention is that users of the interconnect declare their
relationship to the child icc_emi node of the dvfsrc controller, then
this code never worked. That's because it uses the parent dvfsrc device
as the device it passes to the interconnect core framework, which means
all the OF parsing is broken.

Use the actual device instead, and pass the dvfsrc parent into the
dvfsrc calls.

Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver")
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Nicolas Frattaroli 
Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-12-d9c1334db9f3@collabora.com
Signed-off-by: Georgi Djakov 
Signed-off-by: Sasha Levin

interconnect: debugfs: initialize src_node and dst_node to empty strings

2026-01-30T09:32:16+00:00

[ Upstream commit 8cc27f5c6dd17dd090f3a696683f04336c162ff5 ]

The debugfs_create_str() API assumes that the string pointer is either NULL
or points to valid kmalloc() memory. Leaving the pointer uninitialized can
cause problems.

Initialize src_node and dst_node to empty strings before creating the
debugfs entries to guarantee that reads and writes are safe.

Fixes: 770c69f037c1 ("interconnect: Add debugfs test client")
Signed-off-by: Georgi Djakov 
Reviewed-by: Kuan-Wei Chiu 
Tested-by: Kuan-Wei Chiu 
Link: https://lore.kernel.org/r/20260109122523.125843-1-djakov@kernel.org
Signed-off-by: Georgi Djakov 
Signed-off-by: Sasha Levin

interconnect: qcom: sdx75: Drop QPIC interconnect and BCM nodes

2026-01-02T11:57:30+00:00

commit 295f58fdccd05b2d6da1f4a4f81952ccb565c4dc upstream.

As like other SDX SoCs, SDX75 SoC's QPIC BCM resource was modeled as a
RPMh clock in clk-rpmh driver. However, for SDX75, this resource was also
described as an interconnect and BCM node mistakenly. It is incorrect to
describe the same resource in two different providers, as it will lead to
votes from clients overriding each other.

Hence, drop the QPIC interconnect and BCM nodes and let the clients use
clk-rpmh driver to vote for this resource.

Without this change, the NAND driver fails to probe on SDX75, as the
interconnect sync state disables the QPIC nodes as there were no clients
voting for this ICC resource. However, the NAND driver had already voted
for this BCM resource through the clk-rpmh driver. Since both votes come
from Linux, RPMh was unable to distinguish between these two and ends up
disabling the QPIC resource during sync state.

Cc: stable@vger.kernel.org
Fixes: 3642b4e5cbfe ("interconnect: qcom: Add SDX75 interconnect provider driver")
Signed-off-by: Raviteja Laggyshetty 
[mani: dropped the reference to bcm_qp0, reworded description]
Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Konrad Dybcio 
Tested-by: Lakshmi Sowjanya D   # on SDX75
Link: https://lore.kernel.org/r/20250926-sdx75-icc-v2-1-20d6820e455c@oss.qualcomm.com
Signed-off-by: Georgi Djakov 
Signed-off-by: Greg Kroah-Hartman

interconnect: debugfs: Fix incorrect error handling for NULL path

2025-12-18T13:02:46+00:00

[ Upstream commit 6bfe104fd0f94d0248af22c256ce725ee087157b ]

The icc_commit_set() function, used by the debugfs interface, checks
the validity of the global cur_path pointer using IS_ERR_OR_NULL().
However, in the specific case where cur_path is NULL, while
IS_ERR_OR_NULL(NULL) correctly evaluates to true, the subsequent call
to PTR_ERR(NULL) returns 0.

This causes the function to return a success code (0) instead of an
error, misleading the user into believing their bandwidth request was
successfully committed when, in fact, no operation was performed.

Fix this by adding an explicit check to return -EINVAL if cur_path is
NULL. This prevents silent failures and ensures that an invalid
operational sequence is immediately and clearly reported as an error.

Fixes: 770c69f037c1 ("interconnect: Add debugfs test client")
Signed-off-by: Kuan-Wei Chiu 
Link: https://lore.kernel.org/r/20251010151447.2289779-1-visitorckw@gmail.com
Signed-off-by: Georgi Djakov 
Signed-off-by: Sasha Levin

interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS

2025-12-18T13:02:45+00:00

[ Upstream commit 8cf9b43f6b4d90e19a9341edefdd46842d4adb55 ]

>From the initial submission the interconnect driver missed the link from
SNOC_PNOC to the USB 2 configuration space. Add missing link in order to
let the platform configure and utilize this path.

Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver")
Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Link: https://lore.kernel.org/r/20251002-fix-msm8996-icc-v1-1-a36a05d1f869@oss.qualcomm.com
Signed-off-by: Georgi Djakov 
Signed-off-by: Sasha Levin

Merge branch 'icc-glymur' into icc-next

2025-09-12T10:54:17+00:00

Add interconnect dt-bindings and driver support for
Qualcomm's next gen compute SoC - Glymur.

* icc-glymur
  dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Glymur SoC
  interconnect: qcom: icc-rpmh: increase MAX_PORTS to support four QoS ports
  interconnect: qcom: add glymur interconnect provider driver

Link: https://lore.kernel.org/r/20250814-glymur-icc-v2-0-596cca6b6015@oss.qualcomm.com
Signed-off-by: Georgi Djakov

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: qcom: add glymur interconnect provider driver

2025-08-18T10:43:18+00:00

Add driver for the Qualcomm interconnect buses found in glymur
based platforms. The topology consists of several NoCs that are
controlled by a remote processor that collects the aggregated
bandwidth for each master-slave pairs.

Co-developed-by: Odelu Kukatla 
Signed-off-by: Odelu Kukatla 
Signed-off-by: Raviteja Laggyshetty 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20250814-glymur-icc-v2-3-596cca6b6015@oss.qualcomm.com
Signed-off-by: Georgi Djakov

interconnect: qcom: icc-rpmh: increase MAX_PORTS to support four QoS ports

2025-08-18T10:43:13+00:00

Update the MAX_PORTS value to 4 to program four QoS ports
available on the Glymur SoC's interconnect master node.

Co-developed-by: Odelu Kukatla 
Signed-off-by: Odelu Kukatla 
Signed-off-by: Raviteja Laggyshetty 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20250814-glymur-icc-v2-2-596cca6b6015@oss.qualcomm.com
Signed-off-by: Georgi Djakov