[PATCH v2 0/5] power: reset: syscon-reboot-mode: Add support for Rockchip RK3576 reboot modes

[PATCH v2 0/5] power: reset: syscon-reboot-mode: Add support for Rockchip RK3576 reboot modes

[Alexey Charkov]

Rockchip RK3576 supports reboots with a specified boot device priority
mode, allowing one to override the board-defined strapping config and the
OTP programmed priority setting.

Supporting it requires several changes though:
- The boot mode request needs to be forwarded via TF-A to the boot ROM
  (upstream since TF-A commit 2a97ba20e901 ("feat(rk3576): forward any
  boot ROM boot mode request on reset"))
- Some power supplies need to be kept active across the reboot to prevent
  early boot code from running into a synchronous abort
- The magic values for each of the supported boot modes need to be defined
  for the OS to use

This series enables the above with the RK3576 EVB1 board as the example
user. Other boards will likely need a close to identical change to make
use of this functionality, but need testing.

Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Changes in v2:
- Fixed a leak of the dynamically allocated syscon_rbm->supplies (Sashiko)
- Uninitialized access to supplies[].supply (Sashiko) is fixed separately in:
  https://lore.kernel.org/all/20260929-regulator-get-all-v1-1-e887c66a47f1@flipper.net/
- Link to v1: https://patch.msgid.link/20260928-b4-rk3576-reboot-mode-v1-0-65486b03bd41@flipper.net

To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>
To: Sebastian Reichel <sre@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org

---
Alexey Charkov (5):
      dt-bindings: soc: rockchip: add boot ROM download boot mode
      dt-bindings: power: reset: syscon-reboot-mode: allow supplies
      power: reset: syscon-reboot-mode: enable supplies for the next stage
      arm64: dts: rockchip: add reboot-mode node to RK3576
      arm64: dts: rockchip: name the reboot mode supplies on RK3576 EVB1

 .../bindings/power/reset/syscon-reboot-mode.yaml   |  8 +++++
 arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts   | 16 +++++++++
 arch/arm64/boot/dts/rockchip/rk3576.dtsi           | 36 +++++++++++++++++++
 drivers/power/reset/syscon-reboot-mode.c           | 41 ++++++++++++++++++++++
 include/dt-bindings/soc/rockchip,boot-mode.h       |  2 ++
 5 files changed, 103 insertions(+)
---
base-commit: 6375e61c01e93e35ee7acd336a689ac1fae4b509
change-id: 20260928-b4-rk3576-reboot-mode-d3804e39df04

Best regards,
--  
Alexey Charkov <alchark@flipper.net>

[PATCH v2 1/5] dt-bindings: soc: rockchip: add boot ROM download boot mode

[Alexey Charkov]

Rockchip boot ROMs enter USB download mode, commonly known as maskrom,
when they find 0xef08a53c in the register they take the boot mode from.
Add the magic under the name U-Boot already uses for it, so that boards
able to request it can do so symbolically.

Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 include/dt-bindings/soc/rockchip,boot-mode.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/soc/rockchip,boot-mode.h b/include/dt-bindings/soc/rockchip,boot-mode.h
index 4b0914c0989d..88684f4184df 100644
--- a/include/dt-bindings/soc/rockchip,boot-mode.h
+++ b/include/dt-bindings/soc/rockchip,boot-mode.h
@@ -12,5 +12,7 @@
 #define BOOT_RECOVERY		(REBOOT_FLAG + 3)
  /* enter fastboot mode */
 #define BOOT_FASTBOOT		(REBOOT_FLAG + 9)
+/* enter boot ROM usb download (maskrom) mode */
+#define BOOT_BROM_DOWNLOAD	0xEF08A53C
 
 #endif

-- 
2.55.0

[PATCH v2 2/5] dt-bindings: power: reset: syscon-reboot-mode: allow supplies

[Alexey Charkov]

Whatever program that acts on a reboot mode runs before a full OS, so it
may lack the capability to enable the regulators it depends on, and a
reset that preserves the mode register generally leaves the regulators as
the previously running system left them.

Allow a reboot mode node to name such supplies, so that they can be
turned on while the mode is being requested.

Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 .../devicetree/bindings/power/reset/syscon-reboot-mode.yaml       | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
index 79ffc78b23ea..5ed70c87269e 100644
--- a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
@@ -36,6 +36,14 @@ patternProperties:
   "^mode-.*$":
     maxItems: 1
 
+  "^[a-z0-9]+(-[a-z0-9]+)*-supply$":
+    description:
+      Supply that has to be powered for whatever program acts on the mode.
+      That could be a boot ROM with no access to regulators, and a warm reset
+      leaves them as the previously running system left them and not necessarily
+      what their expected out-of-reboot state is. Any supply described here is
+      enabled when a mode is requested, and stays enabled.
+
 unevaluatedProperties: false
 
 required:

-- 
2.55.0

[PATCH v2 3/5] power: reset: syscon-reboot-mode: enable supplies for the next stage

[Alexey Charkov]

Requesting a boot mode on some SoCs such as the Rockchip RK3576 hands the
request to the boot ROM in a register that a full reset would clear, so
any reset that carries it has to leave the PMIC untouched. This means that
the regulators stay in whichever power state the running OS left them,
which may be unsuitable for the early boot code. E.g. on RK3576 the DDR
initialization blob runs on the way back and accesses registers which
Linux normally leaves powered down, resulting in an unrecoverable abort.

Get every supply named in the reboot mode node and enable it when a mode
is written, which is when a mode is being requested. The supplies are
deliberately left enabled afterwards: the system is on its way down, and
what runs next cannot turn them on.

Signed-off-by: Alexey Charkov <alchark@flipper.net>

------

Current implementation of of_regulator_bulk_get_all() never writes the
supply names, instead leaving them uninitialized, while the regulator
core uses the field in error paths to provide meaningful error messages
to the user. This has been highlighted by Sashiko on v1, and is addressed
separately in [1]

[1] https://lore.kernel.org/all/20260929-regulator-get-all-v1-1-e887c66a47f1@flipper.net/
---
 drivers/power/reset/syscon-reboot-mode.c | 41 ++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/drivers/power/reset/syscon-reboot-mode.c b/drivers/power/reset/syscon-reboot-mode.c
index e0772c9f70f7..5ef882d81816 100644
--- a/drivers/power/reset/syscon-reboot-mode.c
+++ b/drivers/power/reset/syscon-reboot-mode.c
@@ -10,6 +10,8 @@
 #include <linux/platform_device.h>
 #include <linux/reboot.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
 #include <linux/mfd/syscon.h>
 #include <linux/reboot-mode.h>
 
@@ -18,6 +20,8 @@ struct syscon_reboot_mode {
 	struct reboot_mode_driver reboot;
 	u32 offset;
 	u32 mask;
+	struct regulator_bulk_data *supplies;
+	int num_supplies;
 };
 
 static int syscon_reboot_mode_write(struct reboot_mode_driver *reboot,
@@ -28,6 +32,20 @@ static int syscon_reboot_mode_write(struct reboot_mode_driver *reboot,
 
 	syscon_rbm = container_of(reboot, struct syscon_reboot_mode, reboot);
 
+	/*
+	 * Whatever acts on the mode (e.g. boot ROM) runs before the operating
+	 * system, and may need supplies that the running system had powered
+	 * down. Enable them here, and deliberately leave them enabled: the
+	 * system is on its way down, and what runs next may not know how to
+	 * turn them on.
+	 */
+	if (syscon_rbm->num_supplies) {
+		ret = regulator_bulk_enable(syscon_rbm->num_supplies,
+					    syscon_rbm->supplies);
+		if (ret < 0)
+			dev_err(reboot->dev, "enabling reboot mode supplies failed\n");
+	}
+
 	ret = regmap_update_bits(syscon_rbm->map, syscon_rbm->offset,
 				 syscon_rbm->mask, magic);
 	if (ret < 0)
@@ -36,6 +54,14 @@ static int syscon_reboot_mode_write(struct reboot_mode_driver *reboot,
 	return ret;
 }
 
+static void syscon_reboot_mode_put_supplies(void *data)
+{
+	struct syscon_reboot_mode *syscon_rbm = data;
+
+	regulator_bulk_free(syscon_rbm->num_supplies, syscon_rbm->supplies);
+	kfree(syscon_rbm->supplies);
+}
+
 static int syscon_reboot_mode_probe(struct platform_device *pdev)
 {
 	int ret;
@@ -59,6 +85,21 @@ static int syscon_reboot_mode_probe(struct platform_device *pdev)
 
 	of_property_read_u32(pdev->dev.of_node, "mask", &syscon_rbm->mask);
 
+	ret = of_regulator_bulk_get_all(&pdev->dev, pdev->dev.of_node,
+					&syscon_rbm->supplies);
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret,
+				     "can't get reboot mode supplies\n");
+
+	syscon_rbm->num_supplies = ret;
+	if (syscon_rbm->num_supplies) {
+		ret = devm_add_action_or_reset(&pdev->dev,
+					       syscon_reboot_mode_put_supplies,
+					       syscon_rbm);
+		if (ret)
+			return ret;
+	}
+
 	ret = devm_reboot_mode_register(&pdev->dev, &syscon_rbm->reboot);
 	if (ret)
 		dev_err(&pdev->dev, "can't register reboot mode\n");

-- 
2.55.0

[PATCH v2 4/5] arm64: dts: rockchip: add reboot-mode node to RK3576

[Alexey Charkov]

The RK3576 boot ROM chooses its boot device order from PMU1_GRF OS_REG0
when that register holds one of its magic values: 0xef08a53c selects USB
download (maskrom) mode, 0xef085a3X selects boot mode X, overriding what
OTP or the SARADC strap would otherwise give.

OS_REG0 cannot be written ahead of a reset, as it is cleared by NPOR.
Instead TF-A takes a request from PMU0_GRF OS_REG16, forwards it to
OS_REG0 and masks the reset outputs so that it reaches the boot ROM.
That register is the one U-Boot uses for its own boot modes as well.

Describe it as a syscon-reboot-mode node, so that a reboot can carry a
request for maskrom or for a particular boot device. Under Linux, for
example:

	systemctl reboot --reboot-argument=maskrom

Requesting anything other than maskrom needs a TF-A containing commit
2a97ba20e901 ("feat(rk3576): forward any boot ROM boot mode request on
reset"); older builds ignore those requests and boot normally.

Link: https://docs.flipper.net/one/hardware/rk3576/boot-rom
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 arch/arm64/boot/dts/rockchip/rk3576.dtsi | 36 ++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index e87ace5d05e6..c938dbcad712 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -881,6 +881,42 @@ php_grf: syscon@26020000 {
 		pmu0_grf: syscon@26024000 {
 			compatible = "rockchip,rk3576-pmu0-grf", "syscon", "simple-mfd";
 			reg = <0x0 0x26024000 0x0 0x1000>;
+
+			/*
+			 * OS_REG16 carries a boot mode request across a reset.
+			 * TF-A picks it up while resetting the system, forwards
+			 * it to the boot ROM through PMU1_GRF OS_REG0 and masks
+			 * the reset outputs, so that the request survives NPOR.
+			 * The modes below are listed in boot mode order, each
+			 * naming the devices the boot ROM tries in turn.
+			 */
+			reboot_mode: reboot-mode {
+				compatible = "syscon-reboot-mode";
+				offset = <0x40>;
+				mode-normal = <BOOT_NORMAL>;
+				/* 1: USB */
+				mode-maskrom = <BOOT_BROM_DOWNLOAD>;
+				/* 2: SPI NOR, SPI NAND, USB */
+				mode-spi = <0xef085a32>;
+				/* 3: SPI NOR/NAND M1, eMMC, USB */
+				mode-spi-m1 = <0xef085a33>;
+				/* 4: SPI NOR/NAND M2, eMMC, USB */
+				mode-spi-m2 = <0xef085a34>;
+				/* 5: SPI NOR, SPI NAND, UFS, USB */
+				mode-spi-ufs = <0xef085a35>;
+				/* 6: SPI NOR/NAND M1, UFS, USB */
+				mode-spi-m1-ufs = <0xef085a36>;
+				/* 7: UFS, USB */
+				mode-ufs = <0xef085a37>;
+				/* 8: UFS, SD, USB */
+				mode-ufs-sd = <0xef085a38>;
+				/* 9: every SPI iomux, eMMC, SD, USB */
+				mode-spi-all = <0xef085a39>;
+				/* 10: eMMC, SD, USB */
+				mode-emmc-sd = <0xef085a3a>;
+				/* 11: eMMC, USB */
+				mode-emmc = <0xef085a3b>;
+			};
 		};
 
 		pmu1_grf: syscon@26026000 {

-- 
2.55.0

[PATCH v2 5/5] arm64: dts: rockchip: name the reboot mode supplies on RK3576 EVB1

[Alexey Charkov]

A reset that carries a boot mode request has to leave the mode register
intact, so it also leaves the regulators as the running system left
them. The DDR firmware that runs next configures bus QoS in the
interconnect, in CCI_GRF, DDR_GRF and NPU_GRF, and faults if a supply
behind any of those is down. The NPU rail is the one most easily left
unpowered, as nothing else on the board needs it.

Name every supply those blocks sit behind, so that requesting a boot
mode powers them regardless of what the running system happened to keep
enabled.

Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
index 4c82980a9f63..55951f290906 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
@@ -957,6 +957,22 @@ wifi_wake_host: wifi-wake-host {
 	};
 };
 
+&reboot_mode {
+	/*
+	 * A reset that carries a boot mode request leaves the regulators as
+	 * the running system left them, while the DDR firmware that runs next
+	 * configures bus QoS in the interconnect, CCI_GRF, DDR_GRF and
+	 * NPU_GRF, and it runs into a synchronous abort if any of the blocks
+	 * is unpowered when it accesses them.
+	 */
+	ddr-supply = <&vdd_ddr_s0>;
+	ddr2-supply = <&vdd2_ddr_s3>;
+	ddr-pll-supply = <&vdda_ddr_pll_s0>;
+	ddrq-supply = <&vddq_ddr_s0>;
+	logic-supply = <&vdd_logic_s0>;
+	npu-supply = <&vdd_npu_s0>;
+};
+
 &sai1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&sai1m0_lrck

-- 
2.55.0

Re: [PATCH v2 1/5] dt-bindings: soc: rockchip: add boot ROM download boot mode

[Krzysztof Kozlowski]

On Tue, Sep 29, 2026 at 02:28:18PM +0400, Alexey Charkov wrote:
> Rockchip boot ROMs enter USB download mode, commonly known as maskrom,
> when they find 0xef08a53c in the register they take the boot mode from.
> Add the magic under the name U-Boot already uses for it, so that boards
> able to request it can do so symbolically.
> 
> Tested-by: Shawn Lin <shawn.lin@rock-chips.com>

Drop, you cannot test it.

What is the point of such blanket tags which are not even applicable to
50% of patches here?

Best regards,
Krzysztof

Re: [PATCH v2 2/5] dt-bindings: power: reset: syscon-reboot-mode: allow supplies

[Krzysztof Kozlowski]

On Tue, Sep 29, 2026 at 02:28:19PM +0400, Alexey Charkov wrote:
> Whatever program that acts on a reboot mode runs before a full OS, so it
> may lack the capability to enable the regulators it depends on, and a
> reset that preserves the mode register generally leaves the regulators as
> the previously running system left them.
> 
> Allow a reboot mode node to name such supplies, so that they can be
> turned on while the mode is being requested.
> 
> Tested-by: Shawn Lin <shawn.lin@rock-chips.com>

Again fake tag.

> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
>  .../devicetree/bindings/power/reset/syscon-reboot-mode.yaml       | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> index 79ffc78b23ea..5ed70c87269e 100644
> --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> @@ -36,6 +36,14 @@ patternProperties:
>    "^mode-.*$":
>      maxItems: 1
>  
> +  "^[a-z0-9]+(-[a-z0-9]+)*-supply$":
> +    description:
> +      Supply that has to be powered for whatever program acts on the mode.
> +      That could be a boot ROM with no access to regulators, and a warm reset
> +      leaves them as the previously running system left them and not necessarily
> +      what their expected out-of-reboot state is. Any supply described here is
> +      enabled when a mode is requested, and stays enabled.

This looks like workaround for missing supply handling in actual
consumers. Fix your devices instead.

Best regards,
Krzysztof

Re: [PATCH v2 2/5] dt-bindings: power: reset: syscon-reboot-mode: allow supplies

[Krzysztof Kozlowski]

On 30/09/2026 13:47, Krzysztof Kozlowski wrote:
> On Tue, Sep 29, 2026 at 02:28:19PM +0400, Alexey Charkov wrote:
>> Whatever program that acts on a reboot mode runs before a full OS, so it
>> may lack the capability to enable the regulators it depends on, and a
>> reset that preserves the mode register generally leaves the regulators as
>> the previously running system left them.
>>
>> Allow a reboot mode node to name such supplies, so that they can be
>> turned on while the mode is being requested.
>>
>> Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
> 
> Again fake tag.
> 
>> Signed-off-by: Alexey Charkov <alchark@flipper.net>
>> ---
>>  .../devicetree/bindings/power/reset/syscon-reboot-mode.yaml       | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
>> index 79ffc78b23ea..5ed70c87269e 100644
>> --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
>> +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
>> @@ -36,6 +36,14 @@ patternProperties:
>>    "^mode-.*$":
>>      maxItems: 1
>>  
>> +  "^[a-z0-9]+(-[a-z0-9]+)*-supply$":
>> +    description:
>> +      Supply that has to be powered for whatever program acts on the mode.
>> +      That could be a boot ROM with no access to regulators, and a warm reset
>> +      leaves them as the previously running system left them and not necessarily
>> +      what their expected out-of-reboot state is. Any supply described here is
>> +      enabled when a mode is requested, and stays enabled.
> 
> This looks like workaround for missing supply handling in actual
> consumers. Fix your devices instead.

Heh, I misread - you need to power this on? Then how does your board
powers itself in the first place? And how do you even solve the
incorrect - e.g. too low - voltage on these regulators?

Best regards,
Krzysztof

Re: [PATCH v2 2/5] dt-bindings: power: reset: syscon-reboot-mode: allow supplies

[Alexey Charkov]

On Wed, Sep 30, 2026 at 3:50 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/09/2026 13:47, Krzysztof Kozlowski wrote:
> > On Tue, Sep 29, 2026 at 02:28:19PM +0400, Alexey Charkov wrote:
> >> Whatever program that acts on a reboot mode runs before a full OS, so it
> >> may lack the capability to enable the regulators it depends on, and a
> >> reset that preserves the mode register generally leaves the regulators as
> >> the previously running system left them.
> >>
> >> Allow a reboot mode node to name such supplies, so that they can be
> >> turned on while the mode is being requested.
> >>
> >> Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
> >
> > Again fake tag.
> >
> >> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> >> ---
> >>  .../devicetree/bindings/power/reset/syscon-reboot-mode.yaml       | 8 ++++++++
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> >> index 79ffc78b23ea..5ed70c87269e 100644
> >> --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> >> +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> >> @@ -36,6 +36,14 @@ patternProperties:
> >>    "^mode-.*$":
> >>      maxItems: 1
> >>
> >> +  "^[a-z0-9]+(-[a-z0-9]+)*-supply$":
> >> +    description:
> >> +      Supply that has to be powered for whatever program acts on the mode.
> >> +      That could be a boot ROM with no access to regulators, and a warm reset
> >> +      leaves them as the previously running system left them and not necessarily
> >> +      what their expected out-of-reboot state is. Any supply described here is
> >> +      enabled when a mode is requested, and stays enabled.
> >
> > This looks like workaround for missing supply handling in actual
> > consumers. Fix your devices instead.
>
> Heh, I misread - you need to power this on? Then how does your board
> powers itself in the first place? And how do you even solve the
> incorrect - e.g. too low - voltage on these regulators?

When the PMIC comes out of a cold reset it has all the needed rails
enabled by its power-on default state, which the DDR trainer relies
on. But the OS will normally disable the rails it knows it doesn't use
itself, so a _warm_ reset which keeps the boot mode argument live and
keeps the PMIC running would leave those rails disabled, unless the OS
put them back as it found them.

So to make warm resets work one would have to either ignore unused
regulators in the OS to keep it from powering them down (ugly), or
mark them "always-on" in DT (also ugly), or state that they are needed
for the reboot mode feature, as done here (which is least ugly IMO).

The DDR trainer unfortunately cannot access the PMIC at all, so it
won't be able to enable the supplies it needs.

Best regards,
Alexey

Re: [PATCH v2 1/5] dt-bindings: soc: rockchip: add boot ROM download boot mode

[Alexey Charkov]

On Wed, Sep 30, 2026 at 3:46 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Sep 29, 2026 at 02:28:18PM +0400, Alexey Charkov wrote:
> > Rockchip boot ROMs enter USB download mode, commonly known as maskrom,
> > when they find 0xef08a53c in the register they take the boot mode from.
> > Add the magic under the name U-Boot already uses for it, so that boards
> > able to request it can do so symbolically.
> >
> > Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> Drop, you cannot test it.
>
> What is the point of such blanket tags which are not even applicable to
> 50% of patches here?

I'd argue for 40% :-D

Anyway, I get your point. I'll drop the tag from the bindings patches,
because Shawn tested a driver implementing the binding and a DTS
implementing the binding, but it's perhaps far fetched to imply that
the test covered the binding change itself.

Best regards,
Alexey