The ROCK 4D's actual DC input is 5V, and the schematic names it as being
5V as well.
Rename the regulator, and change the voltage it claims to be at.
Furthermore, fix vcc_1v1_nldo_s3's vin-supply as coming from
vcc_5v0_sys, and not the DCIN, as per the schematic. This makes no
functional change; both regulators are always on, and one feeds into the
other.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
index 6756403111e704cad42f6674d5ab55eb0306f1e3..352e3df165688219bfedc19734d9eb32c547ec44 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
@@ -57,13 +57,13 @@ user-led {
};
};
- vcc_12v0_dcin: regulator-vcc-12v0-dcin {
+ vcc_5v0_dcin: regulator-vcc-5v0-dcin {
compatible = "regulator-fixed";
regulator-always-on;
regulator-boot-on;
- regulator-min-microvolt = <12000000>;
- regulator-max-microvolt = <12000000>;
- regulator-name = "vcc_12v0_dcin";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-name = "vcc_5v0_dcin";
};
vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
@@ -166,7 +166,7 @@ vcc_5v0_device: regulator-vcc-5v0-device {
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
regulator-name = "vcc_5v0_device";
- vin-supply = <&vcc_12v0_dcin>;
+ vin-supply = <&vcc_5v0_sys>;
};
vcc_5v0_host: regulator-vcc-5v0-host {
@@ -190,7 +190,7 @@ vcc_5v0_sys: regulator-vcc-5v0-sys {
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
regulator-name = "vcc_5v0_sys";
- vin-supply = <&vcc_12v0_dcin>;
+ vin-supply = <&vcc_5v0_dcin>;
};
};
--
2.50.0Hi Nicolas,
On Mon Jun 30, 2025 at 5:36 PM CEST, Nicolas Frattaroli wrote:
> The ROCK 4D's actual DC input is 5V, and the schematic names it as being
> 5V as well.
>
> Rename the regulator, and change the voltage it claims to be at.
Shouldn't it have a fixes tag then? Providing 12V where 5V is expected
sounds problematic ;-)
> Furthermore, fix vcc_1v1_nldo_s3's vin-supply as coming from
> vcc_5v0_sys, and not the DCIN, as per the schematic. This makes no
> functional change; both regulators are always on, and one feeds into the
> other.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> index 6756403111e704cad42f6674d5ab55eb0306f1e3..352e3df165688219bfedc19734d9eb32c547ec44 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> @@ -57,13 +57,13 @@ user-led {
> };
> };
>
> - vcc_12v0_dcin: regulator-vcc-12v0-dcin {
> + vcc_5v0_dcin: regulator-vcc-5v0-dcin {
> compatible = "regulator-fixed";
> regulator-always-on;
> regulator-boot-on;
> - regulator-min-microvolt = <12000000>;
> - regulator-max-microvolt = <12000000>;
> - regulator-name = "vcc_12v0_dcin";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-name = "vcc_5v0_dcin";
> };
With the name change, this block needs to be moved down.
Cheers,
Diederik
>
> vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
> @@ -166,7 +166,7 @@ vcc_5v0_device: regulator-vcc-5v0-device {
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> regulator-name = "vcc_5v0_device";
> - vin-supply = <&vcc_12v0_dcin>;
> + vin-supply = <&vcc_5v0_sys>;
> };
>
> vcc_5v0_host: regulator-vcc-5v0-host {
> @@ -190,7 +190,7 @@ vcc_5v0_sys: regulator-vcc-5v0-sys {
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> regulator-name = "vcc_5v0_sys";
> - vin-supply = <&vcc_12v0_dcin>;
> + vin-supply = <&vcc_5v0_dcin>;
> };
> };
>
Hi,
On Mon, Jun 30, 2025 at 08:12:27PM +0200, Diederik de Haas wrote:
> Hi Nicolas,
>
> On Mon Jun 30, 2025 at 5:36 PM CEST, Nicolas Frattaroli wrote:
> > The ROCK 4D's actual DC input is 5V, and the schematic names it as being
> > 5V as well.
> >
> > Rename the regulator, and change the voltage it claims to be at.
>
> Shouldn't it have a fixes tag then? Providing 12V where 5V is expected
> sounds problematic ;-)
This is basically "just" documentation, as the DT just describes
a fixed regulator (i.e. nothing software controllable). This just
changes a number in sysfs :)
Note, that the 5V DCIN is a USB-C port, which does not do any PD
negotiation, but has the 5K1 resistors on the CC lines to "request"
5V. If for whatever reason a higher voltage is applied (which does
not happen as long as the power is provided by anything remotely
following the USB specifications) there also is an over-voltage
protection chip. So it's not problematic :)
OTOH adding a Fixes tag does not hurt ;)
-- Sebastian
> > Furthermore, fix vcc_1v1_nldo_s3's vin-supply as coming from
> > vcc_5v0_sys, and not the DCIN, as per the schematic. This makes no
> > functional change; both regulators are always on, and one feeds into the
> > other.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> > index 6756403111e704cad42f6674d5ab55eb0306f1e3..352e3df165688219bfedc19734d9eb32c547ec44 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> > @@ -57,13 +57,13 @@ user-led {
> > };
> > };
> >
> > - vcc_12v0_dcin: regulator-vcc-12v0-dcin {
> > + vcc_5v0_dcin: regulator-vcc-5v0-dcin {
> > compatible = "regulator-fixed";
> > regulator-always-on;
> > regulator-boot-on;
> > - regulator-min-microvolt = <12000000>;
> > - regulator-max-microvolt = <12000000>;
> > - regulator-name = "vcc_12v0_dcin";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-name = "vcc_5v0_dcin";
> > };
>
> With the name change, this block needs to be moved down.
>
> Cheers,
> Diederik
> >
> > vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
> > @@ -166,7 +166,7 @@ vcc_5v0_device: regulator-vcc-5v0-device {
> > regulator-min-microvolt = <5000000>;
> > regulator-max-microvolt = <5000000>;
> > regulator-name = "vcc_5v0_device";
> > - vin-supply = <&vcc_12v0_dcin>;
> > + vin-supply = <&vcc_5v0_sys>;
> > };
> >
> > vcc_5v0_host: regulator-vcc-5v0-host {
> > @@ -190,7 +190,7 @@ vcc_5v0_sys: regulator-vcc-5v0-sys {
> > regulator-min-microvolt = <5000000>;
> > regulator-max-microvolt = <5000000>;
> > regulator-name = "vcc_5v0_sys";
> > - vin-supply = <&vcc_12v0_dcin>;
> > + vin-supply = <&vcc_5v0_dcin>;
> > };
> > };
> >
>
Hi, On Tue Jul 1, 2025 at 1:10 AM CEST, Sebastian Reichel wrote: > On Mon, Jun 30, 2025 at 08:12:27PM +0200, Diederik de Haas wrote: >> On Mon Jun 30, 2025 at 5:36 PM CEST, Nicolas Frattaroli wrote: >> > The ROCK 4D's actual DC input is 5V, and the schematic names it as being >> > 5V as well. >> > >> > Rename the regulator, and change the voltage it claims to be at. >> >> Shouldn't it have a fixes tag then? Providing 12V where 5V is expected >> sounds problematic ;-) > > This is basically "just" documentation, as the DT just describes > a fixed regulator (i.e. nothing software controllable). This just > changes a number in sysfs :) > > Note, that the 5V DCIN is a USB-C port, which does not do any PD > negotiation, but has the 5K1 resistors on the CC lines to "request" > 5V. If for whatever reason a higher voltage is applied (which does > not happen as long as the power is provided by anything remotely > following the USB specifications) there also is an over-voltage > protection chip. So it's not problematic :) I was worried about and wondered why I/we did NOT receive reports about boards being fried. Good to know, thanks! > OTOH adding a Fixes tag does not hurt ;) Cheers, Diederik
Hello, On Tuesday, 1 July 2025 10:19:33 Central European Summer Time Diederik de Haas wrote: > Hi, > > On Tue Jul 1, 2025 at 1:10 AM CEST, Sebastian Reichel wrote: > > On Mon, Jun 30, 2025 at 08:12:27PM +0200, Diederik de Haas wrote: > >> On Mon Jun 30, 2025 at 5:36 PM CEST, Nicolas Frattaroli wrote: > >> > The ROCK 4D's actual DC input is 5V, and the schematic names it as being > >> > 5V as well. > >> > > >> > Rename the regulator, and change the voltage it claims to be at. > >> > >> Shouldn't it have a fixes tag then? Providing 12V where 5V is expected > >> sounds problematic ;-) > > > > This is basically "just" documentation, as the DT just describes > > a fixed regulator (i.e. nothing software controllable). This just > > changes a number in sysfs :) > > > > Note, that the 5V DCIN is a USB-C port, which does not do any PD > > negotiation, but has the 5K1 resistors on the CC lines to "request" > > 5V. If for whatever reason a higher voltage is applied (which does > > not happen as long as the power is provided by anything remotely > > following the USB specifications) there also is an over-voltage > > protection chip. So it's not problematic :) > > I was worried about and wondered why I/we did NOT receive reports about > boards being fried. Good to know, thanks! > > > OTOH adding a Fixes tag does not hurt ;) > > Cheers, > Diederik > to add to what Sebastian already said: I purposefully didn't include the Fixes: tag because there is no functional change here. I don't think cosmetic fixes are worth pulling into stable kernels unless they're a dependency of a follow-up functional fix patch, which isn't the case right now. If such a functional fix patch does emerge, it can explicitly declare its dependence on this patch, or even have our robot overlords figure it out itself. In that sense, I do think a Fixes tag hurts, because it needlessly adds to the patch queue of the stable kernel people, and it's worth pointing out that while I claim this patch has no functional change, that's always predicated on the understanding that it does not unintentionally break anything. In this case the chance is essentially zero though, but I won't bother re-rolling this for that tag alone. Regards, Nicolas Frattaroli
On Tue Jul 1, 2025 at 10:55 AM CEST, Nicolas Frattaroli wrote: > On Tuesday, 1 July 2025 10:19:33 Central European Summer Time Diederik de Haas wrote: >> On Tue Jul 1, 2025 at 1:10 AM CEST, Sebastian Reichel wrote: >> > On Mon, Jun 30, 2025 at 08:12:27PM +0200, Diederik de Haas wrote: >> >> On Mon Jun 30, 2025 at 5:36 PM CEST, Nicolas Frattaroli wrote: >> >> > The ROCK 4D's actual DC input is 5V, and the schematic names it as being >> >> > 5V as well. >> >> > >> >> > Rename the regulator, and change the voltage it claims to be at. >> >> >> >> Shouldn't it have a fixes tag then? Providing 12V where 5V is expected >> >> sounds problematic ;-) >> > >> > This is basically "just" documentation, as the DT just describes >> > a fixed regulator (i.e. nothing software controllable). This just >> > changes a number in sysfs :) >> > >> > Note, that the 5V DCIN is a USB-C port, which does not do any PD >> > negotiation, but has the 5K1 resistors on the CC lines to "request" >> > 5V. If for whatever reason a higher voltage is applied (which does >> > not happen as long as the power is provided by anything remotely >> > following the USB specifications) there also is an over-voltage >> > protection chip. So it's not problematic :) >> >> I was worried about and wondered why I/we did NOT receive reports about >> boards being fried. Good to know, thanks! >> >> > OTOH adding a Fixes tag does not hurt ;) > > to add to what Sebastian already said: I purposefully didn't include the > Fixes: tag because there is no functional change here. I don't think > cosmetic fixes are worth pulling into stable kernels unless they're a Then I agree with you. I didn't realize it was not a functional change. I guess I didn't (fully) understand the "just documentation" remark. Cheers, Diederik > dependency of a follow-up functional fix patch, which isn't the case > right now. If such a functional fix patch does emerge, it can explicitly > declare its dependence on this patch, or even have our robot overlords > figure it out itself. > > In that sense, I do think a Fixes tag hurts, because it needlessly > adds to the patch queue of the stable kernel people, and it's worth > pointing out that while I claim this patch has no functional change, > that's always predicated on the understanding that it does not > unintentionally break anything. In this case the chance is essentially > zero though, but I won't bother re-rolling this for that tag alone. > > Regards, > Nicolas Frattaroli
© 2016 - 2025 Red Hat, Inc.