linux-kernel - Re: [PATCH v2 1/2] dt-bindings: soc: ti: bist: Add BIST for K3 devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <26ab079e-9178-4936-9dd9-6aa66916a59a@kernel.org>
Date: Sat, 29 Mar 2025 05:38:38 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Neha Malcom Francis <n-francis@...com>, nm@...com, vigneshr@...com,
 kristo@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org
Cc: linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, u-kumar1@...com
Subject: Re: [PATCH v2 1/2] dt-bindings: soc: ti: bist: Add BIST for K3
 devices

On 28/03/2025 13:42, Neha Malcom Francis wrote:
> On 28/03/25 17:18, Krzysztof Kozlowski wrote:
>> On 28/03/2025 12:14, Neha Malcom Francis wrote:
>>> +properties:
>>> +  compatible:
>>> +    const: ti,j784s4-bist
>>> +
>>> +  reg:
>>> +    maxItems: 2
>>> +
>>> +  reg-names:
>>> +    items:
>>> +      - const: cfg
>>> +      - const: ctrl_mmr
>>> +
>>> +  clocks:
>>> +    maxItems: 1
>>> +
>>> +  power-domains:
>>> +    maxItems: 1
>>> +
>>> +  ti,bist-under-test:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +    description:
>>> +      the device IDs of the devices under test control of the BIST device, the
>>
>> Still not phandle... What is a "device ID"?
> 
> I took a shot at working with the phandle, however the test devices may
> or may not be present in the devicetree at bootloader stage which is the

If the nodes are not in DT, then you should not reference them here.
Bootloader is supposed to receive all the nodes it is expected to work on.

> only place this BIST driver can execute (I know I shouldn't be bringing
> up the driver here but it's crucial to how I can model this property).
> HW mandates you run it as early as possible before any other software
> executes on the test device.
> 
> So now thinking of other possible ways to define the test devices, we
> have unique HW identifiers [1] for each of the device which is what I've
> used here...
> 
> [1]
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/arm/keystone/ti%2Ck3-sci-common.yaml#L31

Then do not redefine properties, but use one common definition.


Best regards,
Krzysztof