linux-kernel - Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8e58b093-1c64-45b9-a9d3-9835a3bbc4fd@ti.com>
Date: Thu, 13 Mar 2025 16:44:06 +0530
From: Neha Malcom Francis <n-francis@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: <nm@...com>, <vigneshr@...com>, <kristo@...nel.org>, <robh@...nel.org>,
        <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <u-kumar1@...com>
Subject: Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI
 K3 devices

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