Documentation/devicetree/bindings/opp/opp-v2.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
Example 3 is a dual-cluster example, meaning that the CPU nodes should
have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses
decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct
hexadecimal values.
Even though the value doesn't change for the first two CPUs, 0 and 1 in
example 3 are changed to 0x0 and 0x1 respectively for consistency. Other
examples all have reg less than 10, so they have not been changed.
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
---
Found while trying to figure out if cpu@* unit addresses are supposed to
be decimal or hexadecimal. This is AFAICT the only place in-tree where
an arm/arm64 DTS uses multi-digit decimal. See also:
- https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
- https://github.com/devicetree-org/devicetree-specification/issues/86
---
Documentation/devicetree/bindings/opp/opp-v2.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp-v2.yaml b/Documentation/devicetree/bindings/opp/opp-v2.yaml
index 6972d76233aa..10000a758572 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2.yaml
@@ -172,7 +172,7 @@ examples:
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
- reg = <0>;
+ reg = <0x0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
@@ -183,7 +183,7 @@ examples:
cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
- reg = <1>;
+ reg = <0x1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
@@ -194,7 +194,7 @@ examples:
cpu@100 {
compatible = "arm,cortex-a15";
device_type = "cpu";
- reg = <100>;
+ reg = <0x100>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
@@ -205,7 +205,7 @@ examples:
cpu@101 {
compatible = "arm,cortex-a15";
device_type = "cpu";
- reg = <101>;
+ reg = <0x101>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260403-dt-bindings-opp-v2-hex-cpu-reg-2d2dbec0bb15
Best regards,
--
Vivian "dramforever" Wang
On Fri, 03 Apr 2026 18:34:29 +0800, Vivian Wang wrote: > Example 3 is a dual-cluster example, meaning that the CPU nodes should > have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses > decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct > hexadecimal values. > > Even though the value doesn't change for the first two CPUs, 0 and 1 in > example 3 are changed to 0x0 and 0x1 respectively for consistency. Other > examples all have reg less than 10, so they have not been changed. > > Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> > --- > Found while trying to figure out if cpu@* unit addresses are supposed to > be decimal or hexadecimal. This is AFAICT the only place in-tree where > an arm/arm64 DTS uses multi-digit decimal. See also: > > - https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/ > - https://github.com/devicetree-org/devicetree-specification/issues/86 > --- > Documentation/devicetree/bindings/opp/opp-v2.yaml | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > Applied, thanks!
On 03-04-26, 18:34, Vivian Wang wrote:
> Example 3 is a dual-cluster example, meaning that the CPU nodes should
> have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses
> decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct
> hexadecimal values.
>
> Even though the value doesn't change for the first two CPUs, 0 and 1 in
> example 3 are changed to 0x0 and 0x1 respectively for consistency. Other
> examples all have reg less than 10, so they have not been changed.
>
> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
> ---
> Found while trying to figure out if cpu@* unit addresses are supposed to
> be decimal or hexadecimal. This is AFAICT the only place in-tree where
> an arm/arm64 DTS uses multi-digit decimal. See also:
>
> - https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
> - https://github.com/devicetree-org/devicetree-specification/issues/86
> ---
> Documentation/devicetree/bindings/opp/opp-v2.yaml | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp-v2.yaml b/Documentation/devicetree/bindings/opp/opp-v2.yaml
> index 6972d76233aa..10000a758572 100644
> --- a/Documentation/devicetree/bindings/opp/opp-v2.yaml
> +++ b/Documentation/devicetree/bindings/opp/opp-v2.yaml
> @@ -172,7 +172,7 @@ examples:
> cpu@0 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> - reg = <0>;
> + reg = <0x0>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 0>;
> clock-names = "cpu";
> @@ -183,7 +183,7 @@ examples:
> cpu@1 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> - reg = <1>;
> + reg = <0x1>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 0>;
> clock-names = "cpu";
> @@ -194,7 +194,7 @@ examples:
> cpu@100 {
> compatible = "arm,cortex-a15";
> device_type = "cpu";
> - reg = <100>;
> + reg = <0x100>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 1>;
> clock-names = "cpu";
> @@ -205,7 +205,7 @@ examples:
> cpu@101 {
> compatible = "arm,cortex-a15";
> device_type = "cpu";
> - reg = <101>;
> + reg = <0x101>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 1>;
> clock-names = "cpu";
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
On Fri, Apr 03, 2026 at 06:34:29PM +0800, Vivian Wang wrote: > Example 3 is a dual-cluster example, meaning that the CPU nodes should > have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses > decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct > hexadecimal values. > > Even though the value doesn't change for the first two CPUs, 0 and 1 in > example 3 are changed to 0x0 and 0x1 respectively for consistency. Other > examples all have reg less than 10, so they have not been changed. > > Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.