linux-kernel - Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET reset driver

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: <22e7dc73-2411-5cb1-6cef-daa5f2af8297@linaro.org>
Date:   Tue, 18 Jul 2023 15:20:24 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Michal Simek <michal.simek@....com>,
        Conor Dooley <conor@...nel.org>,
        Piyush Mehta <piyush.mehta@....com>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, p.zabel@...gutronix.de,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        git@....com
Subject: Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET
 reset driver

On 18/07/2023 15:11, Michal Simek wrote:
>>>
>>> That numbers in DT are virtual no matter if you use ID from 0 to max or random
>>> values it is up to code to handle them. Checking nr_pins against ID is done in
>>> core but it is up to drivers.
>>
>> No, you confuse "virtual" and "ID". IDs are not virtual. IDs are real
>> and have representation in Linux driver. You do not need to define
>> anything virtual in the bindings.
> 
> Not sure how you define ID itself. But HW doesn't know ID. HW knows only 
> register which you can use to perform the reset. It is not really 128bit 
> register where every bit targets to different IP.
> 
> And this is SW-firmware interface like SCMI reset driver.
> 
> Firmware is saying that ID 0 is QSPI, ID 1 is MMC.
> Their Linux driver is asking for nr_reset via firmware call which can be 
> different for different SOC and that's fine and I have no problem with it.
> But only SCMI server is dictating that ID 0 is QSPI and ID 1 is MMC. Different 
> SCMI server implementation can map it differently.

Sure, and all this points to: no need for bindings.

> 
> 
>>> In our case that IDs are coming from firmware and driver itself is just matching
>>> them.
>>
>> So they are the same as if coming from hardware - no need for IDs.
> 
> It is hard to say what hardware here exactly is. From my perspective and I am 
> not advocating not using IDs from 0 to max, it is just a number.
> 
> If my firmware knows that QSPI reset is 0xc10402dU then I will just pass it to 
> reach my goal which is reset QSPI IP.
> 
> If you think that we should use IDs from 0 to max NR I am happy to pass this 
> message to PM team and we should extend any SW to do translation between.

When we talk about IDs and bindings, we mean IDs meaningful to Linux.
Whatever is ignored by Linux and passed to anyone else - hardware or
firmware - is not a ID anymore from bindings point of view. It's just
some value.

Best regards,
Krzysztof