This adds a second register range in ti,k3-socinfo. This register
range can also be used to detect silicon revisions.

AM62px SR1.0, SR1.1, and SR1.2 can only be distinguished with GP_SW
registers, so increase maximum items to 2 for reg property and update
the example.

Signed-off-by: Judith Mendez <jm@ti.com>
---
 .../devicetree/bindings/hwinfo/ti,k3-socinfo.yaml        | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
index dada28b47ea0..3b656fc0cb5a 100644
--- a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
+++ b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
@@ -24,7 +24,8 @@ properties:
       - const: ti,am654-chipid
 
   reg:
-    maxItems: 1
+    maxItems: 2
+    minItems: 1
 
 required:
   - compatible
@@ -34,7 +35,9 @@ additionalProperties: false
 
 examples:
   - |
-    chipid@43000014 {
+    chipid@14 {
         compatible = "ti,am654-chipid";
-        reg = <0x43000014 0x4>;
+        reg = <0x43000014 0x4>,
+              <0x43000230 0x10>;
+        bootph-all;
     };
-- 
2.49.0

On 06/08/2025 01:49, Judith Mendez wrote:
> This adds a second register range in ti,k3-socinfo. This register

Please do not use "This commit/patch/change", but imperative mood. See
longer explanation here:
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95


> range can also be used to detect silicon revisions.
> 
> AM62px SR1.0, SR1.1, and SR1.2 can only be distinguished with GP_SW
> registers, so increase maximum items to 2 for reg property and update
> the example.
> 
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
>  .../devicetree/bindings/hwinfo/ti,k3-socinfo.yaml        | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
> index dada28b47ea0..3b656fc0cb5a 100644
> --- a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
> +++ b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
> @@ -24,7 +24,8 @@ properties:
>        - const: ti,am654-chipid
>  
>    reg:
> -    maxItems: 1
> +    maxItems: 2
> +    minItems: 1

They always come with reversed order... but anyway, you instead must
list the items with minItems.

another problem is that this is not supposed to be per register. I
already complained more than once about some of TI bindings: stop
creating device nodes or address spaces per register.

That's one address space.

>  
>  required:
>    - compatible
> @@ -34,7 +35,9 @@ additionalProperties: false
>  
>  examples:
>    - |
> -    chipid@43000014 {
> +    chipid@14 {

And this was never even checked :/ You have clear warnings here.

Best regards,
Krzysztof

Hi Krystoff,

On 8/6/25 1:40 AM, Krzysztof Kozlowski wrote:
> On 06/08/2025 01:49, Judith Mendez wrote:
>> This adds a second register range in ti,k3-socinfo. This register
> 
> Please do not use "This commit/patch/change", but imperative mood. See
> longer explanation here:
> https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95

I can reword this.

> 
> 
>> range can also be used to detect silicon revisions.
>>
>> AM62px SR1.0, SR1.1, and SR1.2 can only be distinguished with GP_SW
>> registers, so increase maximum items to 2 for reg property and update
>> the example.
>>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> ---
>>   .../devicetree/bindings/hwinfo/ti,k3-socinfo.yaml        | 9 ++++++---
>>   1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>> index dada28b47ea0..3b656fc0cb5a 100644
>> --- a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>> +++ b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>> @@ -24,7 +24,8 @@ properties:
>>         - const: ti,am654-chipid
>>   
>>     reg:
>> -    maxItems: 1
>> +    maxItems: 2
>> +    minItems: 1
> 
> They always come with reversed order... but anyway, you instead must
> list the items with minItems.
> 
> another problem is that this is not supposed to be per register. I
> already complained more than once about some of TI bindings: stop
> creating device nodes or address spaces per register.
> 
> That's one address space.

That does not really make sense. Registers jtag vs gp_sw have a
different back-end, one from silicon and another from efuse. Not even
sure if the memory map will always be the same across processors.

> 
>>   
>>   required:
>>     - compatible
>> @@ -34,7 +35,9 @@ additionalProperties: false
>>   
>>   examples:
>>     - |
>> -    chipid@43000014 {
>> +    chipid@14 {
> 
> And this was never even checked :/ You have clear warnings here.

I will double check this.


~ Judith

On 06/08/2025 17:24, Judith Mendez wrote:
> Hi Krystoff,

That's not really my name. I know it is tricky to type, so it's enough
to say Hi.

>>>   
>>>     reg:
>>> -    maxItems: 1
>>> +    maxItems: 2
>>> +    minItems: 1
>>
>> They always come with reversed order... but anyway, you instead must
>> list the items with minItems.
>>
>> another problem is that this is not supposed to be per register. I
>> already complained more than once about some of TI bindings: stop
>> creating device nodes or address spaces per register.
>>
>> That's one address space.
> 
> That does not really make sense. Registers jtag vs gp_sw have a
> different back-end, one from silicon and another from efuse. Not even

How does the datasheet describe this address space(s) (not registers,
address space)?

> sure if the memory map will always be the same across processors.
> 
>>
Best regards,
Krzysztof