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 <djakov@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJmBWPGAAoJEIDQzArG2BZj5EIP/im57/L6BX3IfvoS+2y3xrxD
p8AzJnFxuiqPH1azaN9jvqH0iMNfb6ysjYklweCRbxPG0PuODeZq44SLTRbl8eF7
YR31G/AYTftM7AZcVRiJZ+CCqFruE4g91wVTKMhnmUKH8VhQDz0bwP7S94ym5Ps2
CUsnXa7fjoFp/Qp/uxWvr+cLD3foKj6EdSNuDYuv+ClmDOU7lUZ3jE6khDe4FioS
9KjRVaaEO+kBC8nMOFUk/JEyxKOPpD8GItqrppkeC917gAO/2D5FL7/uO4BsU10n
4a2X+CEr44k4KN6BXpGh/lc3PRhFjEiNYUdTLJMBCytfNALhnO58LGfkWdENiBEn
yPpXLalJOz9wgAENS06LI52rF0LyU8kS2/QO2k9oC7WvTW8uttaCgEzUeSyxq2CO
FUAeA0+y9uYIg7l6Zotpcl4i5CAV4A1w3zloIAGpFolnZ/YiGb0xNNp7OXu8pb86
Kgz16jiH+HecO8RMlHkT4r7SnSKOaDtOscF5SKP7/6afhWYa5K4c4ECQXlCaAndj
m0h70+rCAQ8GP77GGMtQQgMaycFnr2G67kvalAe7DYuI9OVg8XZMBWLWVUpb5Hch
Kdm4bIyjHWPz79df7JweErj64hZeXsY55ggwjho5SPCPcxyZvjSDGDo9h/0RB/lq
Jyl1o3DyBb/0ZDdTJrTg
=FkyX
-----END PGP SIGNATURE-----
Merge tag 'icc-6.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-work-linus
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 <djakov@kernel.org>
* 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 <quic_mdtipton@quicinc.com>
Fixes: af42269c35 ("interconnect: Fix locking for runpm vs reclaim")
Reviewed-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20240305225652.22872-1-quic_mdtipton@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Booting the kernel on X1E results in a message like:
[ 2.561524] qnoc-x1e80100 interconnect-0: ACV_PERF could not find RPMh address
And indeed, taking a look at cmd-db, no such BCM exists. Remove it.
Fixes: 9f19677284 ("interconnect: qcom: Add X1E80100 interconnect provider driver")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Mike Tipton <quic_mdtipton@quicinc.com>
Link: https://lore.kernel.org/r/20240302-topic-faux_bcm_x1e-v1-1-c40fab7c4bc5@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This pull request contains the interconnect changes for the 6.9-rc1 merge
window. The highlights are below:
Core changes:
- Constify the of_phandle_args in xlate functions.
Driver changes:
- New interconnect driver for the MSM8909 platform.
- New interconnect driver for the SM7150 platform.
- Clean-up and removal of unused resources in drivers.
- Constify some pointers to structs.
Signed-off-by: Georgi Djakov <djakov@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJl6G4mAAoJEIDQzArG2BZjOQUQAMFME5pN7vAPFIYRdQSseax0
2Ncjr5LCWbXHd1mfKutSkx/aABu3t7ywYC0y0EUDkQoqNXBXw+awHCQLVH9K9Apr
QbhU6a7H0ZKSRpRVx2ZAgz5EO/OMcq8rXnPtuSeG8QLjo52DBNUNFBwxKrNJiMV9
cW6qzfP7KE8rznmpYbpOdS2Y6P/aAjH6RHBiMcBeCJBdXHzVYBuKwB3JGxYhqUrR
jykPMWCsjT5PARaHHXfKbt6HXx1vZi5CJogcOJ6asGWoxOTTZpldO/CLk/zdTies
wqOYIZ6c3TJs6k8qerHo+2Cn0ghRjKUyreEnzWlzrRrg6gzwRrny70VEPHY5Sy7D
0m2QzTehhcZsN4X1bJ+96XFiYl6WW6NLsKy1Onbqo/trcwIGMip5ZR9Q6IF014Kp
kdVGZFLE93HZuQMNp14hF2nFLS+L+JTllS2caO92ddJz7aPnDRlBYHROyD4iCC5a
L8eoAFgBZQU6lLqeMrff5RBDVCV1s+roBHk6G2CzXcpDM8ZAAtnbwDYE4hX7CwxK
nbTSagYyW8/tIXgCJZc2RyhpUKmLTi4ruNQY3TxjJHSnZIwlx1KIflqtp9iSSwd8
JYSCxCS+rmnloARMK6rJM5jP7hcObLluPACsBxVnXsoCiwriZU4PbTFAnvOLEKtH
Ianlhvr3v36OXcCOM90J
=ZOoD
-----END PGP SIGNATURE-----
Merge tag 'icc-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next
Georgi writes:
interconnect changes for 6.9
This pull request contains the interconnect changes for the 6.9-rc1 merge
window. The highlights are below:
Core changes:
- Constify the of_phandle_args in xlate functions.
Driver changes:
- New interconnect driver for the MSM8909 platform.
- New interconnect driver for the SM7150 platform.
- Clean-up and removal of unused resources in drivers.
- Constify some pointers to structs.
Signed-off-by: Georgi Djakov <djakov@kernel.org>
* tag 'icc-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc:
interconnect: qcom: Add SM7150 driver support
dt-bindings: interconnect: Add Qualcomm SM7150 DT bindings
interconnect: constify of_phandle_args in xlate
dt-bindings: interconnect: qcom,rpmh: Fix bouncing @codeaurora address
interconnect: qcom: x1e80100: constify pointer to qcom_icc_bcm
interconnect: qcom: sa8775p: constify pointer to qcom_icc_bcm
interconnect: qcom: sm6115: constify pointer to qcom_icc_node
interconnect: qcom: sm8250: constify pointer to qcom_icc_node
interconnect: qcom: sa8775p: constify pointer to qcom_icc_node
interconnect: qcom: msm8909: constify pointer to qcom_icc_node
interconnect: qcom: x1e80100: Remove bogus per-RSC BCMs and nodes
dt-bindings: interconnect: Remove bogus interconnect nodes
interconnect: qcom: sm8550: Remove bogus per-RSC BCMs and nodes
interconnect: qcom: Add MSM8909 interconnect provider driver
dt-bindings: interconnect: Add Qualcomm MSM8909 DT bindings
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 <konrad.dybcio@linaro.org>
Acked-by: Thierry Reding <treding@nvidia.com> # Tegra
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Alim Akhtar <alim.akhtar@samsung.com> # Samsung
Link: https://lore.kernel.org/r/20240220072213.35779-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Pointers to struct qcom_icc_bcm are const.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240208105056.128448-7-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Pointers to struct qcom_icc_bcm are const.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240208105056.128448-6-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Pointers to struct qcom_icc_node are const.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240208105056.128448-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Pointers to struct qcom_icc_node are const.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240208105056.128448-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Pointers to struct qcom_icc_node are const.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240208105056.128448-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Pointers to struct qcom_icc_node are const.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240208105056.128448-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The ACV BCM is voted using bitmasks. Add the proper mask for this
target.
Fixes: 9f19677284 ("interconnect: qcom: Add X1E80100 interconnect provider driver")
Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20240202014806.7876-3-quic_mdtipton@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The ACV enable_mask is historically BIT(3), but it's BIT(0) on this
target. Fix it.
Fixes: c062bcab59 ("interconnect: qcom: introduce RPMh Network-On-Chip Interconnect on SM8650 SoC")
Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240202014806.7876-2-quic_mdtipton@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The downstream kernel has infrastructure for passing votes from different
interconnect nodes onto different RPMh RSCs. This neither implemented, not
is going to be implemented upstream (in favor of a different solution
using ICC tags through the same node).
Unfortunately, as it happens, meaningless (in the upstream context) parts
of the vendor driver were copied, ending up causing havoc - since all
"per-RSC" (in quotes because they all point to the main APPS one) BCMs
defined within the driver overwrite the value in RPMh on every
aggregation.
To both avoid keeping bogus code around and possibly introducing
impossible-to-track-down bugs (busses shutting down for no reason), get
rid of the duplicated BCMs and their associated ICC nodes.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Link: https://lore.kernel.org/r/20240102-topic-x1e_fixes-v1-1-70723e08d5f6@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The downstream kernel has infrastructure for passing votes from different
interconnect nodes onto different RPMh RSCs. This neither implemented, not
is going to be implemented upstream (in favor of a different solution
using ICC tags through the same node).
Unfortunately, as it happens, meaningless (in the upstream context) parts
of the vendor driver were copied, ending up causing havoc - since all
"per-RSC" (in quotes because they all point to the main APPS one) BCMs
defined within the driver overwrite the value in RPMh on every
aggregation.
To both avoid keeping bogus code around and possibly introducing
impossible-to-track-down bugs (busses shutting down for no reason), get
rid of the duplicated BCMs and their associated ICC nodes.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20231218-topic-8550_fixes-v1-1-ce1272d77540@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Add driver for interconnect busses found in MSM8909 based platforms.
The topology consists of three NoCs that are partially controlled by
a RPM processor.
In the downstream/vendor kernel from Qualcomm there is an additional
"mm-snoc". However, it actually ends up using the same RPM "snoc_clk"
as the normal "snoc". It looks like this is actually the same NoC
in hardware and the "mm-snoc" was only defined to assign a different
"qcom,util-fact" to increase bandwidth requests by a static margin.
In mainline we can represent this by assigning the equivalent "ab_coeff"
to all the nodes that are part of "mm-snoc" downstream.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
[Stephan: Drop separate mm-snoc that exists downstream since it's
actually the same NoC as SNoC in hardware, add qos_offset for BIMC,
add ab_coeff for mm-snoc nodes and BIMC]
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231220-icc-msm8909-v2-2-3b68bbed2891@kernkonzept.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Here is the big set of char/misc and other driver subsystem changes for
6.8-rc1. Lots of stuff in here, but first off, you will get a merge
conflict in drivers/android/binder_alloc.c when merging this tree due to
changing coming in through the -mm tree.
The resolution of the merge issue can be found here:
https://lore.kernel.org/r/20231207134213.25631ae9@canb.auug.org.au
or in a simpler patch form in that thread:
https://lore.kernel.org/r/ZXHzooF07LfQQYiE@google.com
If there are issues with the merge of this file, please let me know.
Other than lots of binder driver changes (as you can see by the merge
conflicts) included in here are:
- lots of iio driver updates and additions
- spmi driver updates
- eeprom driver updates
- firmware driver updates
- ocxl driver updates
- mhi driver updates
- w1 driver updates
- nvmem driver updates
- coresight driver updates
- platform driver remove callback api changes
- tags.sh script updates
- bus_type constant marking cleanups
- lots of other small driver updates
All of these have been in linux-next for a while with no reported issues
(other than the binder merge conflict.)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZaeMMQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynWNgCfQ/Yz7QO6EMLDwHO5LRsb3YMhjL4AoNVdanjP
YoI7f1I4GBcC0GKNfK6s
=+Kyv
-----END PGP SIGNATURE-----
Merge tag 'char-misc-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc and other driver updates from Greg KH:
"Here is the big set of char/misc and other driver subsystem changes
for 6.8-rc1.
Other than lots of binder driver changes (as you can see by the merge
conflicts) included in here are:
- lots of iio driver updates and additions
- spmi driver updates
- eeprom driver updates
- firmware driver updates
- ocxl driver updates
- mhi driver updates
- w1 driver updates
- nvmem driver updates
- coresight driver updates
- platform driver remove callback api changes
- tags.sh script updates
- bus_type constant marking cleanups
- lots of other small driver updates
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (341 commits)
android: removed duplicate linux/errno
uio: Fix use-after-free in uio_open
drivers: soc: xilinx: add check for platform
firmware: xilinx: Export function to use in other module
scripts/tags.sh: remove find_sources
scripts/tags.sh: use -n to test archinclude
scripts/tags.sh: add local annotation
scripts/tags.sh: use more portable -path instead of -wholename
scripts/tags.sh: Update comment (addition of gtags)
firmware: zynqmp: Convert to platform remove callback returning void
firmware: turris-mox-rwtm: Convert to platform remove callback returning void
firmware: stratix10-svc: Convert to platform remove callback returning void
firmware: stratix10-rsu: Convert to platform remove callback returning void
firmware: raspberrypi: Convert to platform remove callback returning void
firmware: qemu_fw_cfg: Convert to platform remove callback returning void
firmware: mtk-adsp-ipc: Convert to platform remove callback returning void
firmware: imx-dsp: Convert to platform remove callback returning void
firmware: coreboot_table: Convert to platform remove callback returning void
firmware: arm_scpi: Convert to platform remove callback returning void
firmware: arm_scmi: Convert to platform remove callback returning void
...
To ensure the interconnect votes are actually meaningful and in order to
prevent holding all buses at FMAX, introduce the sync state callback.
Fixes: e6f0d6a30f ("interconnect: qcom: Add SM8550 interconnect provider driver")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20231218-topic-8550_fixes-v1-2-ce1272d77540@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The CO0 BCM needs to be up at all times, otherwise some hardware (like
the UFS controller) loses its connection to the rest of the SoC,
resulting in a hang of the platform, accompanied by a spectacular
logspam.
Mark it as keepalive to prevent such cases.
Fixes: 9c8c6bac1a ("interconnect: qcom: Add SC8180x providers")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231214-topic-sc8180_fixes-v1-1-421904863006@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Remove some unnecessary includes and get rid of the abusive of_platform
in favor of the correct headers.
Reported-by: Rob Herring <robh+dt@kernel.org>
Reported-by: Georgi Djakov <djakov@kernel.org>
Fixes: 2eab57b131 ("interconnect: qcom: Add SM6115 interconnect provider driver")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231214-topic-6115iccfix-v1-1-9ad999683a7d@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Per the commit message of commit 'dd014803f260 ("interconnect: qcom:
icc-rpm: Add AB/IB calculations coefficients")', the peak rate should be
100/ib_percent. But, in what looks like a typical typo, the numerator
value is discarded in the calculation.
Update the implementation to match the described intention.
Fixes: dd014803f2 ("interconnect: qcom: icc-rpm: Add AB/IB calculations coefficients")
Cc: stable@vger.kernel.org
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231205-qcom_icc_calc_rate-typo-v1-1-9d4378dcf53e@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Add the generic icc sync_state callback to ensure interconnect votes
are taken into account, instead of being pegged at maximum values.
Fixes: b95b668eaa ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231130-topic-8250icc_syncstate-v1-1-7ce78ba6e04c@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
* icc-x1e80100
dt-bindings: interconnect: document the RPMh Network-On-Chip Interconnect in Qualcomm SM8650 SoC
interconnect: qcom: introduce RPMh Network-On-Chip Interconnect on SM8650 SoC
dt-bindings: interconnect: qcom-bwmon: document SM8650 BWMONs
This series adds interconnect support for the Qualcomm X1E80100 platform,
aka Snapdragon X Elite.
Our v1 post of the patchsets adding support for Snapdragon X Elite SoC had
the part number sc8380xp which is now updated to the new part number x1e80100
based on the new branding scheme and refers to the exact same SoC.
Release Link: https://www.qualcomm.com/news/releases/2023/10/qualcomm-unleashes-snapdragon-x-elite--the-ai-super-charged-plat
Link: https://lore.kernel.org/r/20231123135028.29433-1-quic_sibis@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Add driver for the Qualcomm interconnect buses found in X1E80100 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: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Link: https://lore.kernel.org/r/20231123135028.29433-3-quic_sibis@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
* icc-platform-remove
interconnect: qcom: Make qnoc_remove return void
interconnect: imx8mm: Convert to platform remove callback returning void
interconnect: imx8mn: Convert to platform remove callback returning void
interconnect: imx8mp: Convert to platform remove callback returning void
interconnect: imx8mq: Convert to platform remove callback returning void
interconnect: qcom/msm8974: Convert to platform remove callback returning void
interconnect: qcom/osm-l3: Convert to platform remove callback returning void
interconnect: qcom/smd-rpm: Convert to platform remove callback returning void
interconnect: exynos: Convert to platform remove callback returning void
This series converts all platform drivers below drivers/interconnect to
use .remove_new(). Compared to the traditional .remove() callback
.remove_new() returns no value. This is a good thing because the driver
core doesn't (and cannot) cope for errors during remove. The only effect
of a non-zero return value in .remove() is that the driver core emits a
warning. The device is removed anyhow and an early return from .remove()
usually yields resource leaks and/or use-after-free bugs.
See commit 5c5a7680e6 ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
All drivers converted here already returned zero unconditionally in
.remove(), so they are converted here trivially. The imx drivers could
be slightly simplified, because the remove callback only called a single
function with the same prototype as .remove_new().
Link: https://lore.kernel.org/r/20231031222851.3126434-11-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231031222851.3126434-20-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231031222851.3126434-19-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231031222851.3126434-18-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231031222851.3126434-17-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231031222851.3126434-16-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231031222851.3126434-15-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231031222851.3126434-14-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231031222851.3126434-13-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Several interconnect/qcom drivers use qnoc_remove() as remove callback.
Make this function return void (instead of unconditionally zero) and
adapt the drivers using this function accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231031222851.3126434-12-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
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 <quic_mdtipton@quicinc.com>
Link: https://lore.kernel.org/r/20231025145829.11603-1-quic_mdtipton@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Several drivers use qcom_icc_rpmh_remove() as remove callback which
returns zero unconditionally. Make it return void and use .remove_new in
the drivers. There is no change in behaviour.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231015135955.1537751-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
* icc-misc
interconnect: imx: Replace custom implementation of COUNT_ARGS()
interconnect: msm8974: Replace custom implementation of COUNT_ARGS()
interconnect: qcom: osm-l3: Replace custom implementation of COUNT_ARGS()
interconnect: fix error handling in qnoc_probe()
interconnect: imx: Replace inclusion of kernel.h in the header
dt-bindings: interconnect: qcom,rpmh: do not require reg on SDX65 MC virt
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Add missing clk_disable_unprepare() and clk_bulk_disable_unprepare()
in the error path in qnoc_probe(). And when qcom_icc_qos_set() fails,
it needs remove nodes and disable clks.
Fixes: 2e2113c8a6 ("interconnect: qcom: rpm: Handle interface clocks")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20230803130521.959487-1-yangyingliang@huawei.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Add interconnect driver support for SDX75 platform.
* icc-sdx75
dt-bindings: interconnect: Add compatibles for SDX75
interconnect: qcom: Add SDX75 interconnect provider driver
Link: https://lore.kernel.org/r/1694614256-24109-1-git-send-email-quic_rohiagar@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>anter a commit message to explain why this merge is necessary,
