linux-stable.git/drivers/pmdomain, branch v6.15

pmdomain: core: Fix error checking in genpd_dev_pm_attach_by_id()

2025-05-08T11:29:30+00:00

The error checking for of_count_phandle_with_args() does not handle
negative error codes correctly.  The problem is that "index" is a u32 so
in the condition "if (index >= num_domains)" negative error codes stored
in "num_domains" are type promoted to very high positive values and
"index" is always going to be valid.

Test for negative error codes first and then test if "index" is valid.

Fixes: 3ccf3f0cd197 ("PM / Domains: Enable genpd_dev_pm_attach_by_id|name() for single PM domain")
Signed-off-by: Dan Carpenter 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/aBxPQ8AI8N5v-7rL@stanley.mountain
Signed-off-by: Ulf Hansson

pmdomain: renesas: rcar: Remove obsolete nullify checks

2025-04-29T09:22:27+00:00

All nullify users and helpers were removed, but the R-Car SYSC drivers
still checked for nullified domains.  Remove the obsolete checks.

Fixes: c8d87704444a8ac7 ("pmdomain: renesas: rcar-sysc: Remove rcar_sysc_nullify() helper")
Signed-off-by: Geert Uytterhoeven 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/107f2bf9f13b29f0f623d2959a5347ec151fb089.1745840768.git.geert+renesas@glider.be
Signed-off-by: Ulf Hansson

pmdomain: arm: scmi_pm_domain: Remove redundant state verification

2025-03-17T10:12:01+00:00

Currently, scmi_pd_power() explicitly verifies whether the requested
power state was applied by calling state_get(). While this check could
detect failures where the state was not properly updated, ensuring
correctness is the responsibility of the SCMI firmware.

Removing this redundant state_get() call eliminates an unnecessary
round-trip to the firmware, improving efficiency. Any mismatches
between the requested and actual states should be handled by the SCMI
firmware, which must return a failure if state_set() is unsuccessful.

Additionally, in some cases, checking the state after powering off a
domain may be unreliable or unsafe, depending on the firmware
implementation.

This patch removes the redundant verification, simplifying the function
without compromising correctness.

Reported-and-tested-by: Ranjani Vaidyanathan 
Signed-off-by: Sudeep Holla 
Reviewed-by: Peng Fan 
Reviewed-by: Cristian Marussi 
Link: https://lore.kernel.org/r/20250314095851.443979-1-sudeep.holla@arm.com
Signed-off-by: Ulf Hansson

pmdomain: thead: fix TH1520_AON_PROTOCOL dependency

2025-03-17T10:09:50+00:00

Kconfig treats the dependency as optional, but the header file only provides
normal declarations and no empty API stubs:

ld: fs/btrfs/extent_io.o: in function `writepage_delalloc':
extent_io.c:(.text+0x2b42): undefined reference to `__udivdi3'
ld: drivers/pmdomain/thead/th1520-pm-domains.o: in function `th1520_pd_power_off':
th1520-pm-domains.c:(.text+0x57): undefined reference to `th1520_aon_power_update'
ld: drivers/pmdomain/thead/th1520-pm-domains.o: in function `th1520_pd_power_on':
th1520-pm-domains.c:(.text+0x8a): undefined reference to `th1520_aon_power_update'
ld: drivers/pmdomain/thead/th1520-pm-domains.o: in function `th1520_pd_probe':
th1520-pm-domains.c:(.text+0xb8): undefined reference to `th1520_aon_init'
ld: th1520-pm-domains.c:(.text+0x1c6): undefined reference to `th1520_aon_power_update'

Since the firmware code can easily be enabled for compile testing, there
is no need to add stubs either, so just make it a hard dependency.

Fixes: dc9a897dbb03 ("pmdomain: thead: Add power-domain driver for TH1520")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Michal Wilczynski 
Link: https://lore.kernel.org/r/20250314154834.4053416-1-arnd@kernel.org
Signed-off-by: Ulf Hansson

pmdomain: thead: Add power-domain driver for TH1520

2025-03-13T13:42:06+00:00

The T-Head TH1520 SoC contains multiple power islands that can be
programmatically turned on and off using the AON (Always-On) protocol
and a hardware mailbox [1]. The relevant mailbox driver has already been
merged into the mainline kernel in commit 5d4d263e1c6b ("mailbox:
Introduce support for T-head TH1520 Mailbox driver");

Introduce a power-domain driver for the TH1520 SoC, which is using AON
firmware protocol to communicate with E902 core through the hardware
mailbox. This way it can send power on/off commands to the E902 core.

The interaction with AUDIO power island e.g trying to turn it OFF proved
to crash the firmware running on the E902 core. Introduce the workaround
to disable interacting with the power island.

[1]
Link: https://openbeagle.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20System%20User%20Manual.pdf

Signed-off-by: Michal Wilczynski 
Acked-by: Drew Fustini 
Link: https://lore.kernel.org/r/20250311171900.1549916-5-m.wilczynski@samsung.com
Signed-off-by: Ulf Hansson

pmdomain: Merge branch fixes into next

2025-03-05T14:52:15+00:00

Merge the pmdomain fixes for v6.14-rc[n] into the next branch, to allow them
to get tested together with the new changes that are targeted for v6.15.

Signed-off-by: Ulf Hansson

pmdomain: amlogic: fix T7 ISP secpower

2025-03-05T14:51:04+00:00

ISP and MIPI_ISP, these two have a parent-child relationship,
ISP depends on MIPI_ISP.

Fixes: ca75e4b214c6 ("pmdomain: amlogic: Add support for T7 power domains controller")
Signed-off-by: Xianwei Zhao 
Reviewed-by: Neil Armstrong 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250303-fix-t7-pwrc-v1-1-b563612bcd86@amlogic.com
Signed-off-by: Ulf Hansson

pmdomain: rockchip: add regulator dependency

2025-03-05T14:46:33+00:00

When CONFIG_REGULATOR is disabled, this pmdomain driver fails to build:

drivers/pmdomain/rockchip/pm-domains.c:653:30: error: implicit declaration of function 'devm_of_regulator_get'; did you mean 'devm_regulator_get'? [-Wimplicit-function-declaration]
  653 |                 pd->supply = devm_of_regulator_get(pmu->dev, pd->node, "domain");
      |                              ^~~~~~~~~~~~~~~~~~~~~
      |                              devm_regulator_get
drivers/pmdomain/rockchip/pm-domains.c:653:28: error: assignment to 'struct regulator *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  653 |                 pd->supply = devm_of_regulator_get(pmu->dev, pd->node, "domain");
      |                            ^

Add a Kconfig dependency.

Fixes: db6df2e3fc16 ("pmdomain: rockchip: add regulator support")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Sebastian Reichel 
Reviewed-by: Dragan Simic 
Reviewed-by: Heiko Stuebner 
Link: https://lore.kernel.org/r/20250304142803.689201-1-arnd@kernel.org
Signed-off-by: Ulf Hansson

pmdomain: rockchip: add regulator support

2025-02-28T12:10:28+00:00

Some power domains require extra voltages to be applied. For example
trying to enable the GPU power domain on RK3588 fails when the SoC
does not have VDD GPU enabled. The same is expected to happen for
the NPU, which also has a dedicated supply line.

We get the regulator using devm_of_regulator_get(), so a missing
dependency in the devicetree is handled gracefully by printing a warning
and creating a dummy regulator. This is necessary, since existing DTs do
not have the regulator described. They might still work if the regulator
is marked as always-on. It is also working if the regulator is enabled
at boot time and the GPU driver is probed before the kernel disables
unused regulators.

The regulator itself is not acquired at driver probe time, since that
creates an unsolvable circular dependency. The power domain driver must
be probed early, since SoC peripherals need it. Regulators on the other
hand depend on SoC peripherals like SPI, I2C or GPIO. MediaTek does not
run into this, since they have two power domain drivers.

Tested-by: Heiko Stuebner 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Sebastian Reichel 
Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-7-a4f9c24e5b81@kernel.org
[Ulf: Fixed conflict when applying]
Signed-off-by: Ulf Hansson

pmdomain: rockchip: fix rockchip_pd_power error handling

2025-02-28T12:07:04+00:00

The calls rockchip_pd_power makes to rockchip_pmu_set_idle_request lack
any return error handling, causing device drivers to incorrectly believe
the hardware idle requests succeed when they may have failed. This leads
to software possibly accessing hardware that is powered off and the
subsequent SError panic that follows.

Add error checking and return errors to the calling function to prevent
such crashes.

gst-launch-1.0 videotestsrc num-buffers=2000 ! v4l2jpegenc ! fakesink
Setting pipeline to PAUSED ...er-x64
Pipeline is PREROLLING ...
Redistribute latency...
rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'hevc', val=0x98260
SError Interrupt on CPU2, code 0x00000000bf000002 -- SError

Signed-off-by: Peter Geis 
Link: https://lore.kernel.org/r/20241214215802.23989-1-pgwipeout@gmail.com
Signed-off-by: Sebastian Reichel 
Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-5-a4f9c24e5b81@kernel.org
Signed-off-by: Ulf Hansson