linux-stable.git/arch, branch v6.3.8 Linux kernel stable tree riscv: fix kprobe __user string arg print fault issue 2023-06-14T09:17:03+00:00 Ruan Jinjie ruanjinjie@huawei.com 2023-05-04T07:29:10+00:00 ddfc58117c6f16524acbf22bbb8b7ccbb5ad34f5 [ Upstream commit 99a670b2069c725a7b50318aa681d9cae8f89325 ] On riscv qemu platform, when add kprobe event on do_sys_open() to show filename string arg, it just print fault as follow: echo 'p:myprobe do_sys_open dfd=$arg1 filename=+0($arg2):string flags=$arg3 mode=$arg4' > kprobe_events bash-166 [000] ...1. 360.195367: myprobe: (do_sys_open+0x0/0x84) dfd=0xffffffffffffff9c filename=(fault) flags=0x8241 mode=0x1b6 bash-166 [000] ...1. 360.219369: myprobe: (do_sys_open+0x0/0x84) dfd=0xffffffffffffff9c filename=(fault) flags=0x8241 mode=0x1b6 bash-191 [000] ...1. 360.378827: myprobe: (do_sys_open+0x0/0x84) dfd=0xffffffffffffff9c filename=(fault) flags=0x98800 mode=0x0 As riscv do not select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE, the +0($arg2) addr is processed as a kernel address though it is a userspace address, cause the above filename=(fault) print. So select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE to avoid the issue, after that the kprobe trace is ok as below: bash-166 [000] ...1. 96.767641: myprobe: (do_sys_open+0x0/0x84) dfd=0xffffffffffffff9c filename="/dev/null" flags=0x8241 mode=0x1b6 bash-166 [000] ...1. 96.793751: myprobe: (do_sys_open+0x0/0x84) dfd=0xffffffffffffff9c filename="/dev/null" flags=0x8241 mode=0x1b6 bash-177 [000] ...1. 96.962354: myprobe: (do_sys_open+0x0/0x84) dfd=0xffffffffffffff9c filename="/sys/kernel/debug/tracing/events/kprobes/" flags=0x98800 mode=0x0 Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Acked-by: Björn Töpel <bjorn@rivosinc.com> Fixes: 0ebeea8ca8a4 ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work") Link: https://lore.kernel.org/r/20230504072910.3742842-1-ruanjinjie@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 99a670b2069c725a7b50318aa681d9cae8f89325 ]

On riscv qemu platform, when add kprobe event on do_sys_open() to show
filename string arg, it just print fault as follow:

echo 'p:myprobe do_sys_open dfd=$arg1 filename=+0($arg2):string flags=$arg3
mode=$arg4' > kprobe_events

bash-166     [000] ...1.   360.195367: myprobe: (do_sys_open+0x0/0x84)
dfd=0xffffffffffffff9c filename=(fault) flags=0x8241 mode=0x1b6

bash-166     [000] ...1.   360.219369: myprobe: (do_sys_open+0x0/0x84)
dfd=0xffffffffffffff9c filename=(fault) flags=0x8241 mode=0x1b6

bash-191     [000] ...1.   360.378827: myprobe: (do_sys_open+0x0/0x84)
dfd=0xffffffffffffff9c filename=(fault) flags=0x98800 mode=0x0

As riscv do not select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE,
the +0($arg2) addr is processed as a kernel address though it is a
userspace address, cause the above filename=(fault) print. So select
ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE to avoid the issue, after that the
kprobe trace is ok as below:

bash-166     [000] ...1.    96.767641: myprobe: (do_sys_open+0x0/0x84)
dfd=0xffffffffffffff9c filename="/dev/null" flags=0x8241 mode=0x1b6

bash-166     [000] ...1.    96.793751: myprobe: (do_sys_open+0x0/0x84)
dfd=0xffffffffffffff9c filename="/dev/null" flags=0x8241 mode=0x1b6

bash-177     [000] ...1.    96.962354: myprobe: (do_sys_open+0x0/0x84)
dfd=0xffffffffffffff9c filename="/sys/kernel/debug/tracing/events/kprobes/"
flags=0x98800 mode=0x0

Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Acked-by: Björn Töpel <bjorn@rivosinc.com>
Fixes: 0ebeea8ca8a4 ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work")
Link: https://lore.kernel.org/r/20230504072910.3742842-1-ruanjinjie@huawei.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
riscv: mm: Ensure prot of VM_WRITE and VM_EXEC must be readable 2023-06-14T09:17:03+00:00 Hsieh-Tseng Shen woodrow.shen@sifive.com 2023-04-25T10:28:28+00:00 ea035a20a461e7bf632ae5e5167662d3459ba215 [ Upstream commit 6569fc12e442ea973d96db39e542aa19a7bc3a79 ] Commit 8aeb7b17f04e ("RISC-V: Make mmap() with PROT_WRITE imply PROT_READ") allows riscv to use mmap with PROT_WRITE only, and meanwhile mmap with w+x is also permitted. However, when userspace tries to access this page with PROT_WRITE|PROT_EXEC, which causes infinite loop at load page fault as well as it triggers soft lockup. According to riscv privileged spec, "Writable pages must also be marked readable". The fix to drop the `PAGE_COPY_READ_EXEC` and then `PAGE_COPY_EXEC` would be just used instead. This aligns the other arches (i.e arm64) for protection_map. Fixes: 8aeb7b17f04e ("RISC-V: Make mmap() with PROT_WRITE imply PROT_READ") Signed-off-by: Hsieh-Tseng Shen <woodrow.shen@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230425102828.1616812-1-woodrow.shen@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6569fc12e442ea973d96db39e542aa19a7bc3a79 ]

Commit 8aeb7b17f04e ("RISC-V: Make mmap() with PROT_WRITE imply PROT_READ")
allows riscv to use mmap with PROT_WRITE only, and meanwhile mmap with w+x
is also permitted. However, when userspace tries to access this page with
PROT_WRITE|PROT_EXEC, which causes infinite loop at load page fault as
well as it triggers soft lockup. According to riscv privileged spec,
"Writable pages must also be marked readable". The fix to drop the
`PAGE_COPY_READ_EXEC` and then `PAGE_COPY_EXEC` would be just used instead.
This aligns the other arches (i.e arm64) for protection_map.

Fixes: 8aeb7b17f04e ("RISC-V: Make mmap() with PROT_WRITE imply PROT_READ")
Signed-off-by: Hsieh-Tseng Shen <woodrow.shen@sifive.com>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20230425102828.1616812-1-woodrow.shen@sifive.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arm64: dts: imx8mn-beacon: Fix SPI CS pinmux 2023-06-14T09:17:02+00:00 Adam Ford aford173@gmail.com 2023-05-28T11:22:54+00:00 bf37668af4174d694c513be07fd617f0dcced800 [ Upstream commit 9bf2e534313fcf420367668cc1f30e10469901dc ] The final production baseboard had a different chip select than earlier prototype boards. When the newer board was released, the SPI stopped working because the wrong pin was used in the device tree and conflicted with the UART RTS. Fix the pinmux for production boards. Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9bf2e534313fcf420367668cc1f30e10469901dc ]

The final production baseboard had a different chip select than
earlier prototype boards.  When the newer board was released,
the SPI stopped working because the wrong pin was used in the device
tree and conflicted with the UART RTS. Fix the pinmux for
production boards.

Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit")
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arm64: dts: imx8-ss-dma: assign default clock rate for lpuarts 2023-06-14T09:17:01+00:00 Shenwei Wang shenwei.wang@nxp.com 2023-05-26T15:38:54+00:00 4fd0ca9f8348ce3934c7c6c1ff576fb4f49f8d98 [ Upstream commit ca50d7765587fe0a8351a6e8d9742cfd4811d925 ] Add the assigned-clocks and assigned-clock-rates properties for the LPUARTx nodes. Without these properties, the default clock rate used would be 0, which can cause the UART ports to fail when open. Fixes: 35f4e9d7530f ("arm64: dts: imx8: split adma ss into dma and audio ss") Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ca50d7765587fe0a8351a6e8d9742cfd4811d925 ]

Add the assigned-clocks and assigned-clock-rates properties for the
LPUARTx nodes. Without these properties, the default clock rate
used would be 0, which can cause the UART ports to fail when open.

Fixes: 35f4e9d7530f ("arm64: dts: imx8: split adma ss into dma and audio ss")
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arm64: dts: imx8qm-mek: correct GPIOs for USDHC2 CD and WP signals 2023-06-14T09:17:01+00:00 Shenwei Wang shenwei.wang@nxp.com 2023-05-18T13:54:21+00:00 636516f2377d1c8568d817fb74778f44de377adf [ Upstream commit 2b28fc688cdff225c41cdd22857500e187453ed7 ] The USDHC2 CD and WP sginal should be on LSIO_GPIO5. Fixes: 307fd14d4b14 ("arm64: dts: imx: add imx8qm mek support") Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2b28fc688cdff225c41cdd22857500e187453ed7 ]

The USDHC2 CD and WP sginal should be on LSIO_GPIO5.

Fixes: 307fd14d4b14 ("arm64: dts: imx: add imx8qm mek support")
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arm64: dts: qcom: sc7180-lite: Fix SDRAM freq for misidentified sc7180-lite boards 2023-06-14T09:17:01+00:00 Douglas Anderson dianders@chromium.org 2023-05-16T00:19:29+00:00 4a88286579ed4a3508b92155deb60a8c7f45d087 [ Upstream commit 3a735530c159b75e1402c08abe1ba4eb99a1f7a3 ] In general, the three SKUs of sc7180 (lite, normal, and pro) are handled dynamically. The cpufreq table in sc7180.dtsi includes the superset of all CPU frequencies. The "qcom-cpufreq-hw" driver in Linux shows that we can dynamically detect which frequencies are actually available on the currently running CPU and then we can just enable those ones. The GPU is similarly dynamic. The nvmem has a fuse in it (see "gpu_speed_bin" in sc7180.dtsi) that the GPU driver can use to figure out which frequencies to enable. There is one part, however, that is not so dynamic. The way SDRAM frequency works in sc7180 is that it's tied to cpufreq. At the busiest cpufreq operating points we'll pick the top supported SDRAM frequency. They ramp down together. For the "pro" SKU of sc7180, we only enable one extra cpufreq step. That extra cpufreq step runs SDRAM at the same speed as the step below. Thus, for normal and pro things are OK. There is no sc7180-pro device tree snippet. For the "lite" SKU if sc7180, however, things aren't so easy. The "lite" SKU drops 3 cpufreq entries but can still run SDRAM at max frequency. That messed things up with the whole scheme. This is why we added the "sc7180-lite" fragment in commit 8fd01e01fd6f ("arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite"). When the lite scheme came about, it was agreed that the WiFi SKUs of lazor would _always_ be "lite" and would, in fact, be the only "lite" devices. Unfortunately, this decision changed and folks didn't realize that it would be a problem. Specifically, some later lazor WiFi-only devices were built with "pro" CPUs. Building WiFi-only lazor with "pro" CPUs isn't the end of the world. The SDRAM will ramp up a little sooner than it otherwise would, but aside from a small power hit things work OK. One problem, though, is that the SDRAM scaling becomes a bit quirky. Specifically, with the current tables we'll max out SDRAM frequency at 2.1GHz but then _lower_ it at 2.2GHz / 2.3GHz only to raise it back to max for 2.4GHz and 2.55GHz. Let's at least fix this so that the SDRAM frequency doesn't go down in that quirky way. On true "lite" SKUs this change will be a no-op because the operating points we're touching are disabled. This change is only useful when a board that thinks it has a "lite" CPU actually has a "normal" or "pro" one stuffed. Fixes: 8fd01e01fd6f ("arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230515171929.1.Ic8dee2cb79ce39ffc04eab2a344dde47b2f9459f@changeid Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3a735530c159b75e1402c08abe1ba4eb99a1f7a3 ]

In general, the three SKUs of sc7180 (lite, normal, and pro) are
handled dynamically.

The cpufreq table in sc7180.dtsi includes the superset of all CPU
frequencies. The "qcom-cpufreq-hw" driver in Linux shows that we can
dynamically detect which frequencies are actually available on the
currently running CPU and then we can just enable those ones.

The GPU is similarly dynamic. The nvmem has a fuse in it (see
"gpu_speed_bin" in sc7180.dtsi) that the GPU driver can use to figure
out which frequencies to enable.

There is one part, however, that is not so dynamic. The way SDRAM
frequency works in sc7180 is that it's tied to cpufreq. At the busiest
cpufreq operating points we'll pick the top supported SDRAM frequency.
They ramp down together.

For the "pro" SKU of sc7180, we only enable one extra cpufreq step.
That extra cpufreq step runs SDRAM at the same speed as the step
below. Thus, for normal and pro things are OK. There is no sc7180-pro
device tree snippet.

For the "lite" SKU if sc7180, however, things aren't so easy. The
"lite" SKU drops 3 cpufreq entries but can still run SDRAM at max
frequency. That messed things up with the whole scheme. This is why we
added the "sc7180-lite" fragment in commit 8fd01e01fd6f ("arm64: dts:
qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite").

When the lite scheme came about, it was agreed that the WiFi SKUs of
lazor would _always_ be "lite" and would, in fact, be the only "lite"
devices. Unfortunately, this decision changed and folks didn't realize
that it would be a problem. Specifically, some later lazor WiFi-only
devices were built with "pro" CPUs.

Building WiFi-only lazor with "pro" CPUs isn't the end of the world.
The SDRAM will ramp up a little sooner than it otherwise would, but
aside from a small power hit things work OK. One problem, though, is
that the SDRAM scaling becomes a bit quirky. Specifically, with the
current tables we'll max out SDRAM frequency at 2.1GHz but then
_lower_ it at 2.2GHz / 2.3GHz only to raise it back to max for 2.4GHz
and 2.55GHz.

Let's at least fix this so that the SDRAM frequency doesn't go down in
that quirky way. On true "lite" SKUs this change will be a no-op
because the operating points we're touching are disabled. This change
is only useful when a board that thinks it has a "lite" CPU actually
has a "normal" or "pro" one stuffed.

Fixes: 8fd01e01fd6f ("arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230515171929.1.Ic8dee2cb79ce39ffc04eab2a344dde47b2f9459f@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: dts: at91: sama7g5ek: fix debounce delay property for shdwc 2023-06-14T09:17:00+00:00 Claudiu Beznea claudiu.beznea@microchip.com 2023-05-23T05:27:50+00:00 b8cd81c74af99f350f2a24864fd2cda84217d014 [ Upstream commit 6b0db163ff9200a55dc77a652dad1d4b0a853f63 ] There is no atmel,shdwc-debouncer property for SHDWC. The right DT property is debounce-delay-us. Use it. Fixes: 16b161bcf5d4 ("ARM: dts: at91: sama7g5: add shdwc node") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20230523052750.184223-1-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6b0db163ff9200a55dc77a652dad1d4b0a853f63 ]

There is no atmel,shdwc-debouncer property for SHDWC. The right DT property
is debounce-delay-us. Use it.

Fixes: 16b161bcf5d4 ("ARM: dts: at91: sama7g5: add shdwc node")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20230523052750.184223-1-claudiu.beznea@microchip.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: at91: pm: fix imbalanced reference counter for ethernet devices 2023-06-14T09:17:00+00:00 Claudiu Beznea claudiu.beznea@microchip.com 2023-05-18T06:25:11+00:00 427d4a73efce3d817da17878b8502e9646b41e4c [ Upstream commit ccd4923d18d5698a5910d516646ce125b9155d47 ] The of_find_device_by_node() function is returning a struct platform_device object with the embedded struct device member's reference counter incremented. This needs to be dropped when done with the platform device returned by of_find_device_by_node(). at91_pm_eth_quirk_is_valid() calls of_find_device_by_node() on suspend and resume path. On suspend it calls of_find_device_by_node() and on resume and failure paths it drops the counter of struct platform_device::dev. In case ethernet device may not wakeup there is a put_device() on at91_pm_eth_quirk_is_valid() which is wrong as it colides with put_device() on resume path leading to the reference counter of struct device embedded in struct platform_device to be messed, stack trace to be displayed (after 5 consecutive suspend/resume cycles) and execution to hang. Along with this the error path of at91_pm_config_quirks() had been also adapted to decrement propertly the reference counter of struct device embedded in struct platform_device. Fixes: b7fc72c63399 ("ARM: at91: pm: add quirks for pm") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20230518062511.2988500-1-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ccd4923d18d5698a5910d516646ce125b9155d47 ]

The of_find_device_by_node() function is returning a struct platform_device
object with the embedded struct device member's reference counter
incremented. This needs to be dropped when done with the platform device
returned by of_find_device_by_node().

at91_pm_eth_quirk_is_valid() calls of_find_device_by_node() on
suspend and resume path. On suspend it calls of_find_device_by_node() and
on resume and failure paths it drops the counter of
struct platform_device::dev.

In case ethernet device may not wakeup there is a put_device() on
at91_pm_eth_quirk_is_valid() which is wrong as it colides with
put_device() on resume path leading to the reference counter of struct
device embedded in struct platform_device to be messed, stack trace to be
displayed (after 5 consecutive suspend/resume cycles) and execution to
hang.

Along with this the error path of at91_pm_config_quirks() had been also
adapted to decrement propertly the reference counter of struct device
embedded in struct platform_device.

Fixes: b7fc72c63399 ("ARM: at91: pm: add quirks for pm")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20230518062511.2988500-1-claudiu.beznea@microchip.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
arm64: dts: qcom: sm6375-pdx225: Fix remoteproc firmware paths 2023-06-14T09:17:00+00:00 Konrad Dybcio konrad.dybcio@linaro.org 2023-05-17T17:06:13+00:00 1d6e542fb823afdca696bac3182104622d623d90 [ Upstream commit a14da6144d16ef27e3022835fa282a3740b8ad7b ] They were previously missing the SoC name. Fix it. Fixes: a2ad207c412b ("arm64: dts: qcom: sm6375-pdx225: Enable ADSP & CDSP") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230517-topic-murray-fwname-v1-1-923e87312249@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a14da6144d16ef27e3022835fa282a3740b8ad7b ]

They were previously missing the SoC name. Fix it.

Fixes: a2ad207c412b ("arm64: dts: qcom: sm6375-pdx225: Enable ADSP & CDSP")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230517-topic-murray-fwname-v1-1-923e87312249@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
arm64: dts: qcom: sc8280xp: Flush RSC sleep & wake votes 2023-06-14T09:16:59+00:00 Bjorn Andersson quic_bjorande@quicinc.com 2023-05-12T15:04:25+00:00 eed41b6475eb31b32f4eeeed8f6eac09326ae2fc [ Upstream commit ce7c014937c442be677963848c7db62eccd94eac ] The rpmh driver will cache sleep and wake votes until the cluster power-domain is about to enter idle, to avoid unnecessary writes. So associate the apps_rsc with the cluster pd, so that it can be notified about this event. Without this, only AMC votes are being commited. Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230512150425.3171122-1-quic_bjorande@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ce7c014937c442be677963848c7db62eccd94eac ]

The rpmh driver will cache sleep and wake votes until the cluster
power-domain is about to enter idle, to avoid unnecessary writes. So
associate the apps_rsc with the cluster pd, so that it can be notified
about this event.

Without this, only AMC votes are being commited.

Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230512150425.3171122-1-quic_bjorande@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>