The SC8280XP currently shows depressing results in memory benchmarks.
Fix this by introducing support for the platform in the OSM (and EPSS)
L3 driver and support for the platform in the bwmon binding.
Link: https://lore.kernel.org/r/20221111032515.3460-1-quic_bjorande@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220924015043.25130-1-shangxiaojing@huawei.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The aggregation over votes for all nodes in the provider will always
only find the bandwidth votes for the destination side of the path.
Further more, the average kBps value will always be 0.
Simplify the logic by directly looking at the destination node's peak
bandwidth request.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Tested-by: Steev Klimaszewski <steev@kali.org>
Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com>
Link: https://lore.kernel.org/r/20221111032515.3460-5-quic_bjorande@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The EPSS instance in e.g. SM8350 and SC8280XP has per-core L3 voting
enabled. In this configuration, the "shared" vote is done using the
REG_L3_VOTE register instead of PERF_STATE.
Rename epss_l3 to clarify that it's affecting the PERF_STATE register
and add a new L3_VOTE description. Given platform lineage it's assumed
that the L3_VOTE-based case will be the predominant one, so use this for
a new generic qcom,epss-l3 compatible.
While adding the EPSS generic, also add qcom,osm-l3.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Tested-by: Steev Klimaszewski <steev@kali.org>
Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com>
Link: https://lore.kernel.org/r/20221111032515.3460-4-quic_bjorande@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Each platform defines their own OSM L3 descriptor, but in practice
there's only two: one for OSM and one for EPSS. Remove the duplicated
definitions.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Tested-by: Steev Klimaszewski <steev@kali.org>
Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com>
Link: https://lore.kernel.org/r/20221111032515.3460-3-quic_bjorande@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The identifiers used for nodes needs to be unique in the running system,
but defining them per platform results in a lot of duplicated
definitions and prevents us from using generic compatibles.
As these identifiers are not exposed outside the kernel, change to use
driver-local numbers, picked completely at random.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Tested-by: Steev Klimaszewski <steev@kali.org>
Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com>
Link: https://lore.kernel.org/r/20221111032515.3460-2-quic_bjorande@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Today remove callbacks of platform devices return an int. This is unfortunate
because the device core ignores the return value and so the platform code only
emits a warning (and still removes the device).
The longterm quest is to make these remove callbacks return void instead.
This series is a preparation for that, with the goal to make the remove
callbacks obviously always return 0. This way when the prototype of
these functions is changed to return void, the change is straight
forward and easy to review.
Link: https://lore.kernel.org/r/20220718121409.171773-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Make INTERCONNECT_QCOM tristate so that icc-common.c can be
compiled as a module.
Signed-off-by: Huang Yiwei <quic_hyiwei@quicinc.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220914064122.16222-1-quic_hyiwei@quicinc.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The function imx_icc_unregister() returns zero unconditionally. Make it
return void.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220718121409.171773-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220718121409.171773-7-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220718121409.171773-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220718121409.171773-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220718121409.171773-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220718121409.171773-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
icc_provider_del() already emits an error message on failure. In this
case letting .remove() return the corresponding error code results in
another error message and the device is removed anyhow. (See
platform_remove().)
So ignore the return value of icc_provider_del() and return 0
unconditionally.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220718121409.171773-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This patch set is to support bucket in icc-rpm driver, so it implements
the similar mechanism in the icc-rpmh driver.
It uses interconnect path tag to indicate the bandwidth voting is for
which buckets, and there have three kinds of buckets: AWC, WAKE and
SLEEP, finally the wake and sleep bucket values are used to set the
corresponding clock (active and sleep clocks). So far, we keep the AWC
bucket but doesn't really use it.
Link: https://lore.kernel.org/r/20220712015929.2789881-1-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This patchset is to support i.MX8MP NoC settings, i.MX8MP NoC initial
value after power up is invalid, need set a valid value after related
power domain up.
This patchset also includes two patch[1,2] during my development to enable
the ICC feature for i.MX8MP.
I not include ddrc DVFS in this patchset, ths patchset is only to
support NoC value mode/priority/ext_control being set to a valid value
that suggested by i.MX Chip Design Team. The value is same as NXP
downstream one inside Arm Trusted Firmware:
https://source.codeaurora.org/external/imx/imx-atf/tree/plat/imx/imx8m/i/gpc.c?h=lf_v2.4#n97
Link: https://lore.kernel.org/r/20220703091132.1412063-1-peng.fan@oss.nxp.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Introduce imx_icc_noc_setting structure to describe a master port setting
Pass imx_icc_noc_setting as a parameter from specific driver
Set priority level, mode, ext control in imx_icc_node_set
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20220703091132.1412063-8-peng.fan@oss.nxp.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
max_node_id not equal to the ARRAY_SIZE of node array, need increase 1,
otherwise xlate will fail for the last entry. And rename max_node_id
to num_nodes to reflect the reality.
Fixes: f0d8048525 ("interconnect: Add imx core driver")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20220703091132.1412063-5-peng.fan@oss.nxp.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This commit uses buckets for support bandwidth and clock rates. It
introduces a new function qcom_icc_bus_aggregate() to calculate the
aggregate average and peak bandwidths for every bucket, and also it
calculates the maximum value of aggregated average bandwidth across all
buckets.
The maximum aggregated average is used to calculate the final bandwidth
requests. And we can set the clock rate per bucket, we use SLEEP bucket
as default bucket if a platform doesn't enable the interconnect path
tags in DT binding; otherwise, we use WAKE bucket to set active clock
and use SLEEP bucket for other clocks. So far we don't use AMC bucket.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Link: https://lore.kernel.org/r/20220712015929.2789881-6-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The current interconnect rpm driver uses a single aggregate bandwidth to
calculate the clock rates for both active and sleep clocks; therefore,
it has no chance to separate bandwidth requests for these two kinds of
clocks.
This patch studies the implementation from interconnect rpmh driver to
support multiple buckets. The rpmh driver provides three buckets for
AMC, WAKE, and SLEEP; this driver only needs to use WAKE and SLEEP
buckets, but we keep the same way with rpmh driver, this can allow us to
reuse the DT binding and avoid to define duplicated data structures.
This patch introduces two callbacks: qcom_icc_pre_bw_aggregate() is used
to clean up bucket values before aggregate bandwidth requests, and
qcom_icc_bw_aggregate() is to aggregate bandwidth for buckets.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Link: https://lore.kernel.org/r/20220712015929.2789881-5-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This commit changes to use callback qcom_icc_xlate_extended(). This
is a preparation for population path tags from the interconnect DT
binding, it doesn't introduce functionality change for the existed DT
binding without path tags.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220712015929.2789881-4-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
since there have conflict between two headers icc-rpmh.h and icc-rpm.h,
the function qcom_icc_xlate_extended() is declared in icc-rpmh.h thus
it cannot be used by icc-rpm driver.
Move the function to a new common file icc-common.c so that allow it to
be called by multiple drivers.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220712015929.2789881-3-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Make it possible to set destination as well as source bandwidth. If the
*dst pointer is non-NULL. Right now it appears that we never make the
destination bw allocation call, which is inconsistent with the downstream
way of doing this.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20220707093823.1691870-1-bryan.odonoghue@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
It's fashion to use the icc_sync_state callback to notify the framework
when all consumers are probed, so that the bandwidth request doesn't
need to stay on maximum value.
Do the same thing for msm8939 driver.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Link: https://lore.kernel.org/r/20220416012634.479617-1-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Here is the large set of char, misc, and other driver subsystem updates
for 5.19-rc1. The merge request for this has been delayed as I wanted
to get lots of linux-next testing due to some late arrivals of changes
for the habannalabs driver.
Highlights of this merge are:
- habanalabs driver updates for new hardware types and fixes and
other updates
- IIO driver tree merge which includes loads of new IIO drivers
and cleanups and additions
- PHY driver tree merge with new drivers and small updates to
existing ones
- interconnect driver tree merge with fixes and updates
- soundwire driver tree merge with some small fixes
- coresight driver tree merge with small fixes and updates
- mhi bus driver tree merge with lots of updates and new device
support
- firmware driver updates
- fpga driver updates
- lkdtm driver updates (with a merge conflict, more on that
below)
- extcon driver tree merge with small updates
- lots of other tiny driver updates and fixes and cleanups, full
details in the shortlog.
All of these have been in linux-next for almost 2 weeks with no reported
problems.
Note, there are 3 merge conflicts when merging this with your tree:
- MAINTAINERS, should be easy to resolve
- drivers/slimbus/qcom-ctrl.c, should be straightforward
resolution
- drivers/misc/lkdtm/stackleak.c, not an easy resolution. This
has been noted in the linux-next tree for a while, and
resolved there, here's a link to the resolution that Stephen
came up with and that Kees says is correct:
https://lore.kernel.org/r/20220509185344.3fe1a354@canb.auug.org.au
I will be glad to provide a merge point that contains these resolutions
if that makes things any easier for you.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYpnkbA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylOrgCggbbAFwESBY9o2YfpG+2VOLpc0GAAoJgY1XN8
P/gumbLEpFvoBZ5xLIW8
=KCgk
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char / misc / other smaller driver subsystem updates from Greg KH:
"Here is the large set of char, misc, and other driver subsystem
updates for 5.19-rc1. The merge request for this has been delayed as I
wanted to get lots of linux-next testing due to some late arrivals of
changes for the habannalabs driver.
Highlights of this merge are:
- habanalabs driver updates for new hardware types and fixes and
other updates
- IIO driver tree merge which includes loads of new IIO drivers and
cleanups and additions
- PHY driver tree merge with new drivers and small updates to
existing ones
- interconnect driver tree merge with fixes and updates
- soundwire driver tree merge with some small fixes
- coresight driver tree merge with small fixes and updates
- mhi bus driver tree merge with lots of updates and new device
support
- firmware driver updates
- fpga driver updates
- lkdtm driver updates (with a merge conflict, more on that below)
- extcon driver tree merge with small updates
- lots of other tiny driver updates and fixes and cleanups, full
details in the shortlog.
All of these have been in linux-next for almost 2 weeks with no
reported problems"
* tag 'char-misc-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (387 commits)
habanalabs: use separate structure info for each error collect data
habanalabs: fix missing handle shift during mmap
habanalabs: remove hdev from hl_ctx_get args
habanalabs: do MMU prefetch as deferred work
habanalabs: order memory manager messages
habanalabs: return -EFAULT on copy_to_user error
habanalabs: use NULL for eventfd
habanalabs: update firmware header
habanalabs: add support for notification via eventfd
habanalabs: add topic to memory manager buffer
habanalabs: handle race in driver fini
habanalabs: add device memory scrub ability through debugfs
habanalabs: use unified memory manager for CB flow
habanalabs: unified memory manager new code for CB flow
habanalabs/gaudi: set arbitration timeout to a high value
habanalabs: add put by handle method to memory manager
habanalabs: hide memory manager page shift
habanalabs: Add separate poll interval value for protocol
habanalabs: use get_task_pid() to take PID
habanalabs: add prefetch flag to the MAP operation
...
This patch set is to address two clock rate setting issues.
The first patch is to fix a potential cached clock rate mismatching
issue, the issue can lead to the clock rate is missed to be set. Note,
since this potential issue requires specific time window and certain
condition (consumers need to request the same bandwidth) to produce,
the patch is based on analysis but not a real trace log.
The second patch is an extension to cache clock rates for active and
sleep clocks separately, with this change it gives us possibility to set
active and sleep clock with different clock rates.
* icc-rpm
interconnect: qcom: icc-rpm: Fix for cached clock rate
interconnect: qcom: icc-rpm: Cache every clock rate
Link: https://lore.kernel.org/r/20220416031029.693211-1-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This contains a few fixes for the sc8180x interconnect provider driver to make
it functional.
* icc-sc8180x
dt-bindings: interconnect: Add SC8180X QUP0 virt provider
interconnect: qcom: sc8180x: Modernize sc8180x probe
interconnect: qcom: sc8180x: Fix QUP0 nodes
interconnect: qcom: sc8180x: Mark some BCMs keepalive
Link: https://lore.kernel.org/r/20220503211925.1022169-1-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The Qualcomm interconnect providers started off defining nodes and BCMs
using the DEFINE_QNODE() and DEFINE_QBCM() macros. Unfortunately this
results in a block of long lines that are hard to read, a transition to
explicitly stated definition has been made for newly introduced
platforms.
Transition the SC8180X interconnect provider driver to this style as
well, to make it easier to read while debugging interconnect related
issues.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220503225300.1141814-1-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The QUP0 BCM relates to some internal property of the QUPs, and should
be configured independently of the path to the QUP. In line with other
platforms expose QUP_CORE endpoints in order allow this configuration.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220503211925.1022169-4-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The introduction of the Qualcomm SC8180X provider raced with the
refactoring of the RPMh common code and SC8180X was left with the old
style of duplicating the probe function in each provider driver.
Transition the driver to the "new" design.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220503211925.1022169-3-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The cached clock rate is used for all bus clocks, thus it has the
assumption that all interconnect clock rates are always same, this
causes trouble if we want to set different clock rates separately.
This patch is to allocate a clock rate array to cache every clock
rate.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Link: https://lore.kernel.org/r/20220416031029.693211-3-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
All nodes within an interconnect bus share interconnect bus clocks, but
every node has its own cached clock rate values, this can lead to
unexpected clock rate setting.
Let's see an example shown in below, in this case, a bus have two nodes
A and B, and its buswidth is 8:
step1: vote bandwidth 1600M for node(A):
aggregated(bw) = 1600M
qcom_icc_node(A)->rate = 1600M / 8 = 200MHz
step2: vote bandwidth 1600M for node(B):
aggregated(bw) = 1600M + 1600M = 3200M
qcom_icc_node(B)->rate = 3200M / 8 = 400MHz
step3: unvote bandwidth 1600M for node(A)
aggregated(bw) = 3200M - 1600M = 1600M
target_clock = 1600M / 8 = 200MHz
The problem is in step 3, the calculated target clock rate is 200MHz,
which equals to the cached clock rate in node(A) (See step 1),
unfortunately, qcom_icc_set() skips to set the new clock rate 200MHz in
this case, so the bus clock rate will continue to stay at 400MHz.
To resolve the issue, one possible solution is to invoke clk_get_rate()
to retrieve the clock rates on the fly, thus we can totally remove the
cached clock rates. But after review the code, many bus clock has set
the flag CLK_GET_RATE_NOCACHE, this results in the retrieving bus clock
rate is time cost for iterating parent clock nodes, and even challenges
bus clock drivers to provide recalc_rate() callbacks.
So this patch moves the cached rates into structure qcom_icc_provider,
we use it as a central place to maintain bus clock handlers and cached
clock rate, therefore, it can smoothly dismiss the mismatching problem.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Link: https://lore.kernel.org/r/20220416031029.693211-2-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
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 <bjorn.andersson@linaro.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Alex Elder <elder@linaro.org>
Cc: Taniya Das <quic_tdas@quicinc.com>
Cc: Mike Tipton <quic_mdtipton@quicinc.com>
Fixes: 2fb251c265 ("interconnect: qcom: sdx55: Drop IP0 interconnects")
Fixes: 2f3724930e ("interconnect: qcom: sc7180: Drop IP0 interconnects")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220427013226.341209-1-swboyd@chromium.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Pointers to struct qcom_icc_bcm are not modified, so they can be made
const for safety. The contents of struct qcom_icc_bcm must stay
non-const.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220427131154.302581-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Georgi Djakov