Devicetree
 help / color / mirror / Atom feed
* [PATCH v3 0/2] interconnect: qcom: add MSM8x60 NoC driver
@ 2026-06-06 12:34 Herman van Hazendonk
  2026-06-06 12:34 ` [PATCH v3 1/2] dt-bindings: interconnect: qcom: add msm8660 NoC Herman van Hazendonk
  2026-06-06 12:34 ` [PATCH v3 2/2] interconnect: qcom: add MSM8x60 NoC driver Herman van Hazendonk
  0 siblings, 2 replies; 7+ messages in thread
From: Herman van Hazendonk @ 2026-06-06 12:34 UTC (permalink / raw)
  To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
  Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel,
	Herman van Hazendonk

Add an interconnect provider for the MSM8x60 family (MSM8260 / MSM8660
/ APQ8060). The driver describes the four NoC fabrics (System, Apps,
MMSS, Daytona) and the RPM-managed fabric arbitration tables that
program per-master / per-tiered-slave bandwidth budgets via
QCOM_RPM_*_FABRIC_ARB resources.

v3 folds one High Sashiko finding (msm8660_rpm_commit() concurrent
access on shared per-fabric scratch buffers) on top of the v2 patchset
that addressed the maintainer / LKP feedback from v1.

Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
---
Changes in v3:

  - [High Sashiko] msm8660_rpm_commit() ran with no synchronisation.
    The shared per-fabric scratch buffers (qp->arb, qp->bwsum,
    qp->rpm_buf) are allocated once at probe and reused across all
    ICC set operations. The ICC core can dispatch provider->set
    concurrently from different CPUs, so two msm8660_rpm_commit()
    instances could interleave their memset()s and overlapping
    per-node writes, producing a corrupted packet on the
    qcom_rpm_write() to RPM firmware. Added a 'struct mutex
    commit_lock' to msm8660_icc_provider, initialised via
    devm_mutex_init() in probe, taken across the entire
    memset -> iterate -> pack -> qcom_rpm_write sequence with a
    scoped guard(mutex)().

Changes in v2 (already sent 2026-06-04):

Maintainer / LKP feedback on v1:

  - [Medium] dt-bindings: add explicit '#interconnect-cells: const: 1'.
    The common rpm-common.yaml permits both 1- and 2-cell phandles for
    historical reasons; without an explicit const here a 2-cell consumer
    would pass schema validation but then fail of_icc_xlate_onecell()
    at runtime.

  - [High] msm8660_get_rpm(): drop the manual device_link_remove()
    before the EPROBE_DEFER return path. The link is added with
    DL_FLAG_AUTOREMOVE_CONSUMER, so the driver core releases its kref
    when our probe ultimately fails. The manual remove dropped an
    extra kref -> potential UAF on the supplier device.

  - [Low] devm_clk_bulk_get_optional(): drop the dead ret == -ENOENT
    branch. The helper internally masks per-clock ENOENT to NULL
    handles before returning, so the branch is unreachable.

  - [High] static msm8660_qnode .node cache pointers: on probe
    failure icc_nodes_remove() frees the dynamic icc_node but the
    cache field still points at freed memory. A subsequent
    probe-retry (or unbind/rebind) would then dereference the stale
    pointer. Added msm8660_clear_node_cache() helper, called from
    both err_remove_nodes: and msm8660_icc_remove(). Same latent bug
    exists in the icc-rpmh.c template; we keep it local for now.

  - [High] icc_link_nodes(): check the return value. Failure
    (-ENOMEM from krealloc) was silently ignored -> partially-linked
    topology with no error path. Now goto err_remove_nodes on
    failure.

Test results (v3, HP TouchPad APQ8060, kernel 7.1.0-rc1):

  - All four fabrics probe clean at boot
    (4096000.qnoc, 4400000.qnoc, 4500000.qnoc, 4540000.qnoc).
    Real bandwidth votes flow through slv_ebi_ch0 (DDR), MDP,
    video-codec, camss.

  - 120s concurrent multi-subsystem load
    (camera stream loop + dd to eMMC + /dev/urandom + filesystem
    walk + USB I/O): zero qcom_rpm errors, zero icc warnings,
    USB stayed up, MDP stayed active, no display glitches or
    USB stalls.

  - dmesg post-load: 0 WARN, 0 BUG, 0 Oops. Specifically no
    "qcom_rpm: ARB write failed" and no "interconnect: ... failed"
    messages.

  - Kernel build clean (ARCH=arm, CONFIG_INTERCONNECT_QCOM_MSM8660=y).

- Link to v1: https://lore.kernel.org/r/20260603163410.2312712-1-github.com@herrie.org
- Link to v2: https://lore.kernel.org/r/20260604184400.801543-1-github.com@herrie.org

---
Herman van Hazendonk (2):
      dt-bindings: interconnect: qcom: add msm8660 NoC
      interconnect: qcom: add MSM8x60 NoC driver

 .../bindings/interconnect/qcom,msm8660.yaml        |  166 ++
 drivers/interconnect/qcom/Kconfig                  |   14 +
 drivers/interconnect/qcom/Makefile                 |    2 +
 drivers/interconnect/qcom/msm8660.c                | 1663 ++++++++++++++++++++
 include/dt-bindings/interconnect/qcom,msm8660.h    |  156 ++
 5 files changed, 2001 insertions(+)
---
base-commit: 944125b4c454b58d2fe6e35f1087a932b2050dff
change-id: 20260606-submit-interconnect-msm8660-62420c194b6a

Best regards,
-- 
Herman van Hazendonk <github.com@herrie.org>


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-06-06 14:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-06 12:34 [PATCH v3 0/2] interconnect: qcom: add MSM8x60 NoC driver Herman van Hazendonk
2026-06-06 12:34 ` [PATCH v3 1/2] dt-bindings: interconnect: qcom: add msm8660 NoC Herman van Hazendonk
2026-06-06 12:46   ` sashiko-bot
2026-06-06 13:23   ` Dmitry Baryshkov
2026-06-06 14:32     ` me
2026-06-06 12:34 ` [PATCH v3 2/2] interconnect: qcom: add MSM8x60 NoC driver Herman van Hazendonk
2026-06-06 12:48   ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox