[PATCH 0/2] Add support for K3 BIST

[PATCH 0/2] Add support for K3 BIST

[Neha Malcom Francis]

BIST (Built-In Self Test) is an IP responsible for triggering hardware
circuitry tests on both logic as well as memory blocks. This driver is
currently being upstreamed in U-Boot [1] and triggers these tests on
cores. This patch series adds the dt-binding as well as a node for BIST
on J784S4.

[1] https://lore.kernel.org/all/613efa0b-f785-444c-8769-ea40ac94d6f9@ti.com/T/

Neha Malcom Francis (2):
  dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices
  arm64: dts: ti: k3-j784s4-main: Add PBIST_14 node

 .../bindings/misc/ti,j784s4-bist.yaml         | 66 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi    | 11 ++++
 2 files changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml

-- 
2.34.1

[PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Neha Malcom Francis]

Document the binding for TI K3 BIST (Built-In Self Test) block.

Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
 .../bindings/misc/ti,j784s4-bist.yaml         | 66 +++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml

diff --git a/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
new file mode 100644
index 000000000000..bd1b42734b3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/ti,j784s4-bist.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 BIST
+
+maintainers:
+  - Neha Malcom Francis <n-francis@ti.com>
+
+description:
+  The BIST (Built-In Self Test) module is an IP block present in K3 devices
+  that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
+  (Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
+  is executed by hardware for the MCU domain automatically as part of HW POST.
+
+properties:
+  compatible:
+    const: ti,j784s4-bist
+
+  reg:
+    minItems: 2
+    maxItems: 2
+
+  reg-names:
+    items:
+      - const: cfg
+      - const: ctrl_mmr
+
+  clocks:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+  ti,bist-instance:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      the BIST instance in the SoC represented as an integer
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - ti,bist-instance
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/soc/ti,sci_pm_domain.h>
+    bus {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        bist@33c0000 {
+            compatible = "ti,j784s4-bist";
+            reg = <0x00 0x033c0000 0x00 0x400>,
+            <0x00 0x0010c1a0 0x00 0x01c>;
+            reg-names = "cfg", "ctrl_mmr";
+            clocks = <&k3_clks 237 7>;
+            power-domains = <&k3_pds 237 TI_SCI_PD_EXCLUSIVE>;
+            ti,bist-instance = <14>;
+        };
+    };
-- 
2.34.1

[PATCH 2/2] arm64: dts: ti: k3-j784s4-main: Add PBIST_14 node

[Neha Malcom Francis]

Add DT node for PBIST_14 that is responsible for triggering the PBIST
self-tests for the MAIN_R5_2_x cores.

Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 0160fe0da983..f96113d8db22 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -113,6 +113,17 @@ serdes2: serdes@5020000 {
 			status = "disabled";
 		};
 	};
+
+	bist_main14: bist@33c0000 {
+		compatible = "ti,j784s4-bist";
+		reg = <0x00 0x033c0000 0x00 0x400>,
+		      <0x00 0x0010c1a0 0x00 0x01c>;
+		reg-names = "cfg", "ctrl_mmr";
+		clocks = <&k3_clks 237 7>;
+		power-domains = <&k3_pds 237 TI_SCI_PD_EXCLUSIVE>;
+		bootph-pre-ram;
+		ti,bist-instance = <14>;
+	};
 };
 
 &scm_conf {
-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Krzysztof Kozlowski]

On Thu, Nov 28, 2024 at 07:38:24PM +0530, Neha Malcom Francis wrote:
> Document the binding for TI K3 BIST (Built-In Self Test) block.
> 

A nit, subject: drop second/last, redundant "dt-binding". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
>  .../bindings/misc/ti,j784s4-bist.yaml         | 66 +++++++++++++++++++
>  1 file changed, 66 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml

soc directory, not misc.

> 
> diff --git a/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
> new file mode 100644
> index 000000000000..bd1b42734b3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2024 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/misc/ti,j784s4-bist.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments K3 BIST
> +
> +maintainers:
> +  - Neha Malcom Francis <n-francis@ti.com>
> +
> +description:
> +  The BIST (Built-In Self Test) module is an IP block present in K3 devices
> +  that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
> +  (Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
> +  is executed by hardware for the MCU domain automatically as part of HW POST.
> +
> +properties:
> +  compatible:
> +    const: ti,j784s4-bist
> +
> +  reg:
> +    minItems: 2

Drop minItems

> +    maxItems: 2
> +
> +  reg-names:
> +    items:
> +      - const: cfg
> +      - const: ctrl_mmr
> +
> +  clocks:
> +    maxItems: 1
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  ti,bist-instance:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      the BIST instance in the SoC represented as an integer

No instance indices are allowed. Drop.

> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - ti,bist-instance
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/soc/ti,sci_pm_domain.h>
> +    bus {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        bist@33c0000 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation

Come with something, don't just use device name.

> +            compatible = "ti,j784s4-bist";
> +            reg = <0x00 0x033c0000 0x00 0x400>,
> +            <0x00 0x0010c1a0 0x00 0x01c>;

Misaligned code.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Neha Malcom Francis]

Hi Krzysztof,

On 29/11/24 12:50, Krzysztof Kozlowski wrote:
> On Thu, Nov 28, 2024 at 07:38:24PM +0530, Neha Malcom Francis wrote:
>> Document the binding for TI K3 BIST (Built-In Self Test) block.
>>
> 
> A nit, subject: drop second/last, redundant "dt-binding". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> 
>> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
>> ---
>>   .../bindings/misc/ti,j784s4-bist.yaml         | 66 +++++++++++++++++++
>>   1 file changed, 66 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
> 
> soc directory, not misc.
> 
>>
>> diff --git a/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
>> new file mode 100644
>> index 000000000000..bd1b42734b3d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
>> @@ -0,0 +1,66 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2024 Texas Instruments Incorporated
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/misc/ti,j784s4-bist.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Texas Instruments K3 BIST
>> +
>> +maintainers:
>> +  - Neha Malcom Francis <n-francis@ti.com>
>> +
>> +description:
>> +  The BIST (Built-In Self Test) module is an IP block present in K3 devices
>> +  that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
>> +  (Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
>> +  is executed by hardware for the MCU domain automatically as part of HW POST.
>> +
>> +properties:
>> +  compatible:
>> +    const: ti,j784s4-bist
>> +
>> +  reg:
>> +    minItems: 2
> 
> Drop minItems
> 
>> +    maxItems: 2
>> +
>> +  reg-names:
>> +    items:
>> +      - const: cfg
>> +      - const: ctrl_mmr
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +  ti,bist-instance:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      the BIST instance in the SoC represented as an integer
> 
> No instance indices are allowed. Drop.
> 

Question on this, this is not a property that is driven by software but rather 
indicates which register sequences have to be picked up for triggering this test 
from this instance. So I don't see how I can workaround this without getting 
this number. Or maybe call it ID rather than instance?

>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - reg-names
>> +  - ti,bist-instance
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/soc/ti,sci_pm_domain.h>
>> +    bus {
>> +        #address-cells = <2>;
>> +        #size-cells = <2>;
>> +        bist@33c0000 {
> 
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> 
> Come with something, don't just use device name.
> 
>> +            compatible = "ti,j784s4-bist";
>> +            reg = <0x00 0x033c0000 0x00 0x400>,
>> +            <0x00 0x0010c1a0 0x00 0x01c>;
> 
> Misaligned code.
> 
> Best regards,
> Krzysztof
> 

For the rest of the comments, got it! thanks for the review!

-- 
Thanking You
Neha Malcom Francis

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Krzysztof Kozlowski]

On 29/11/2024 08:43, Neha Malcom Francis wrote:
>>> +
>>> +  power-domains:
>>> +    maxItems: 1
>>> +
>>> +  ti,bist-instance:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description:
>>> +      the BIST instance in the SoC represented as an integer
>>
>> No instance indices are allowed. Drop.
>>
> 
> Question on this, this is not a property that is driven by software but rather 
> indicates which register sequences have to be picked up for triggering this test 
> from this instance. So I don't see how I can workaround this without getting 
> this number. Or maybe call it ID rather than instance?

I don't understand how the device operates, so what is exactly behind
some sequences of registers for triggering this test. You described
property as index or ID of one instance of the block. That's not what we
want in the binding. That's said maybe other, different hardware
characteristic is behind, who knows. Or maybe it's about callers... or
maybe that's not hardware property at all, but runtime OS, who knows.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Neha Malcom Francis]

Hi Krzysztof

On 29/11/24 14:45, Krzysztof Kozlowski wrote:
> On 29/11/2024 08:43, Neha Malcom Francis wrote:
>>>> +
>>>> +  power-domains:
>>>> +    maxItems: 1
>>>> +
>>>> +  ti,bist-instance:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>> +    description:
>>>> +      the BIST instance in the SoC represented as an integer
>>>
>>> No instance indices are allowed. Drop.
>>>
>>
>> Question on this, this is not a property that is driven by software but rather 
>> indicates which register sequences have to be picked up for triggering this test 
>> from this instance. So I don't see how I can workaround this without getting 
>> this number. Or maybe call it ID rather than instance?
> 
> I don't understand how the device operates, so what is exactly behind
> some sequences of registers for triggering this test. You described
> property as index or ID of one instance of the block. That's not what we
> want in the binding. That's said maybe other, different hardware
> characteristic is behind, who knows. Or maybe it's about callers... or
> maybe that's not hardware property at all, but runtime OS, who knows.
> 

Sorry for such a late reply, but I was hoping to get more details on
this "ID" and never got back to the thread...

The best way I can describe is this device (BIST) runs a safety
diagnostic test on a bunch of processors/blocks (let's call them
targets). There's a mapping between the instance of this device and the
targets it will run the test. This ID was essentially letting the BIST
driver know which are these targets.

Should I perhaps trigger it the other way around; a target driver asks
for it's safety test to be run by pointing to the BIST instance? However
the issue with this approach is, the architecture of this safety test
device is that once triggered, it will run the test on all the targets
it controls and that should be reflected in the software arch as well right?

Yet another way would be the BIST points out the targets it controls via
their phandles in its node... but this approach would trigger the probe
of these targets before the test runs on them. And in hardware, the test
must run only one before the device is used, else we see indefinite
behavior.


> Best regards,
> Krzysztof

-- 
Thanking You
Neha Malcom Francis

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Krzysztof Kozlowski]

On 13/03/2025 12:14, Neha Malcom Francis wrote:
> Hi Krzysztof
> 
> On 29/11/24 14:45, Krzysztof Kozlowski wrote:
>> On 29/11/2024 08:43, Neha Malcom Francis wrote:
>>>>> +
>>>>> +  power-domains:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  ti,bist-instance:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>> +    description:
>>>>> +      the BIST instance in the SoC represented as an integer
>>>>
>>>> No instance indices are allowed. Drop.
>>>>
>>>
>>> Question on this, this is not a property that is driven by software but rather 
>>> indicates which register sequences have to be picked up for triggering this test 
>>> from this instance. So I don't see how I can workaround this without getting 
>>> this number. Or maybe call it ID rather than instance?
>>
>> I don't understand how the device operates, so what is exactly behind
>> some sequences of registers for triggering this test. You described
>> property as index or ID of one instance of the block. That's not what we
>> want in the binding. That's said maybe other, different hardware
>> characteristic is behind, who knows. Or maybe it's about callers... or
>> maybe that's not hardware property at all, but runtime OS, who knows.
>>
> 
> Sorry for such a late reply, but I was hoping to get more details on
> this "ID" and never got back to the thread...
> 
> The best way I can describe is this device (BIST) runs a safety
> diagnostic test on a bunch of processors/blocks (let's call them
> targets). There's a mapping between the instance of this device and the
> targets it will run the test. This ID was essentially letting the BIST
> driver know which are these targets.


So you want to configure some target? Then this is your property. If you
want to configure 'foo' difference in DT, you do not write 'bar'...

Anyway, no clue, original emails are long time not in my inbox. Context
disappeared also long time ago.


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Neha Malcom Francis]

Hi Krzysztof,

On 19/03/25 13:16, Krzysztof Kozlowski wrote:
> On 13/03/2025 12:14, Neha Malcom Francis wrote:
>> Hi Krzysztof
>>
>> On 29/11/24 14:45, Krzysztof Kozlowski wrote:
>>> On 29/11/2024 08:43, Neha Malcom Francis wrote:
>>>>>> +
>>>>>> +  power-domains:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  ti,bist-instance:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> +    description:
>>>>>> +      the BIST instance in the SoC represented as an integer
>>>>>
>>>>> No instance indices are allowed. Drop.
>>>>>
>>>>
>>>> Question on this, this is not a property that is driven by software but rather 
>>>> indicates which register sequences have to be picked up for triggering this test 
>>>> from this instance. So I don't see how I can workaround this without getting 
>>>> this number. Or maybe call it ID rather than instance?
>>>
>>> I don't understand how the device operates, so what is exactly behind
>>> some sequences of registers for triggering this test. You described
>>> property as index or ID of one instance of the block. That's not what we
>>> want in the binding. That's said maybe other, different hardware
>>> characteristic is behind, who knows. Or maybe it's about callers... or
>>> maybe that's not hardware property at all, but runtime OS, who knows.
>>>
>>
>> Sorry for such a late reply, but I was hoping to get more details on
>> this "ID" and never got back to the thread...
>>
>> The best way I can describe is this device (BIST) runs a safety
>> diagnostic test on a bunch of processors/blocks (let's call them
>> targets). There's a mapping between the instance of this device and the
>> targets it will run the test. This ID was essentially letting the BIST
>> driver know which are these targets.
> 
> 
> So you want to configure some target? Then this is your property. If you
> want to configure 'foo' difference in DT, you do not write 'bar'...
> 

So the difficulty in doing this is, what I mentioned in the earlier
email just copying it over again:

"Yet another way would be the BIST points out the targets it controls via
their phandles in its node... but this approach would trigger the probe
of these targets before the test runs on them. And in hardware, the test
must run only one before the device is used, else we see indefinite
behavior."

Property that has a list of strings (targets) instead of phandles maybe?
Would that be acceptable?

> Anyway, no clue, original emails are long time not in my inbox. Context
> disappeared also long time ago.
> 

Completely understand, delay from my end, sorry!

> 
> Best regards,
> Krzysztof

-- 
Thanking You
Neha Malcom Francis

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Krzysztof Kozlowski]

On 19/03/2025 10:02, Neha Malcom Francis wrote:
> Hi Krzysztof,
> 
> On 19/03/25 13:16, Krzysztof Kozlowski wrote:
>> On 13/03/2025 12:14, Neha Malcom Francis wrote:
>>> Hi Krzysztof
>>>
>>> On 29/11/24 14:45, Krzysztof Kozlowski wrote:
>>>> On 29/11/2024 08:43, Neha Malcom Francis wrote:
>>>>>>> +
>>>>>>> +  power-domains:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  ti,bist-instance:
>>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>> +    description:
>>>>>>> +      the BIST instance in the SoC represented as an integer
>>>>>>
>>>>>> No instance indices are allowed. Drop.
>>>>>>
>>>>>
>>>>> Question on this, this is not a property that is driven by software but rather 
>>>>> indicates which register sequences have to be picked up for triggering this test 
>>>>> from this instance. So I don't see how I can workaround this without getting 
>>>>> this number. Or maybe call it ID rather than instance?
>>>>
>>>> I don't understand how the device operates, so what is exactly behind
>>>> some sequences of registers for triggering this test. You described
>>>> property as index or ID of one instance of the block. That's not what we
>>>> want in the binding. That's said maybe other, different hardware
>>>> characteristic is behind, who knows. Or maybe it's about callers... or
>>>> maybe that's not hardware property at all, but runtime OS, who knows.
>>>>
>>>
>>> Sorry for such a late reply, but I was hoping to get more details on
>>> this "ID" and never got back to the thread...
>>>
>>> The best way I can describe is this device (BIST) runs a safety
>>> diagnostic test on a bunch of processors/blocks (let's call them
>>> targets). There's a mapping between the instance of this device and the
>>> targets it will run the test. This ID was essentially letting the BIST
>>> driver know which are these targets.
>>
>>
>> So you want to configure some target? Then this is your property. If you
>> want to configure 'foo' difference in DT, you do not write 'bar'...
>>
> 
> So the difficulty in doing this is, what I mentioned in the earlier
> email just copying it over again:
> 
> "Yet another way would be the BIST points out the targets it controls via
> their phandles in its node... but this approach would trigger the probe

No, it would not. Which part of OF kernel code causes probe ordering
(device links) if some random phandle appears?

> of these targets before the test runs on them. And in hardware, the test
> must run only one before the device is used, else we see indefinite
> behavior."
> 
> Property that has a list of strings (targets) instead of phandles maybe?
> Would that be acceptable?



Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Neha Malcom Francis]

On 24/03/25 12:53, Krzysztof Kozlowski wrote:
> On 19/03/2025 10:02, Neha Malcom Francis wrote:
>> Hi Krzysztof,
>>
>> On 19/03/25 13:16, Krzysztof Kozlowski wrote:
>>> On 13/03/2025 12:14, Neha Malcom Francis wrote:
>>>> Hi Krzysztof
>>>>
>>>> On 29/11/24 14:45, Krzysztof Kozlowski wrote:
>>>>> On 29/11/2024 08:43, Neha Malcom Francis wrote:
>>>>>>>> +
>>>>>>>> +  power-domains:
>>>>>>>> +    maxItems: 1
>>>>>>>> +
>>>>>>>> +  ti,bist-instance:
>>>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>>> +    description:
>>>>>>>> +      the BIST instance in the SoC represented as an integer
>>>>>>>
>>>>>>> No instance indices are allowed. Drop.
>>>>>>>
>>>>>>
>>>>>> Question on this, this is not a property that is driven by software but rather 
>>>>>> indicates which register sequences have to be picked up for triggering this test 
>>>>>> from this instance. So I don't see how I can workaround this without getting 
>>>>>> this number. Or maybe call it ID rather than instance?
>>>>>
>>>>> I don't understand how the device operates, so what is exactly behind
>>>>> some sequences of registers for triggering this test. You described
>>>>> property as index or ID of one instance of the block. That's not what we
>>>>> want in the binding. That's said maybe other, different hardware
>>>>> characteristic is behind, who knows. Or maybe it's about callers... or
>>>>> maybe that's not hardware property at all, but runtime OS, who knows.
>>>>>
>>>>
>>>> Sorry for such a late reply, but I was hoping to get more details on
>>>> this "ID" and never got back to the thread...
>>>>
>>>> The best way I can describe is this device (BIST) runs a safety
>>>> diagnostic test on a bunch of processors/blocks (let's call them
>>>> targets). There's a mapping between the instance of this device and the
>>>> targets it will run the test. This ID was essentially letting the BIST
>>>> driver know which are these targets.
>>>
>>>
>>> So you want to configure some target? Then this is your property. If you
>>> want to configure 'foo' difference in DT, you do not write 'bar'...
>>>
>>
>> So the difficulty in doing this is, what I mentioned in the earlier
>> email just copying it over again:
>>
>> "Yet another way would be the BIST points out the targets it controls via
>> their phandles in its node... but this approach would trigger the probe
> 
> No, it would not. Which part of OF kernel code causes probe ordering
> (device links) if some random phandle appears?

Going through device links now, I realize I may have come to the wrong
conclusion while writing the driver. Let me try to respin the driver
using this approach then post which I will resume this series.

> 
>> of these targets before the test runs on them. And in hardware, the test
>> must run only one before the device is used, else we see indefinite
>> behavior."
>>
>> Property that has a list of strings (targets) instead of phandles maybe?
>> Would that be acceptable?
> 
> 
> 
> Best regards,
> Krzysztof

-- 
Thanking You
Neha Malcom Francis