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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bd7bee62-38fd-412b-a2d4-611890238e9e@ti.com>
Date: Thu, 27 Mar 2025 09:42:38 +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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ