linux-kernel - Re: [PATCH] dt-bindings: sram: Tightly Coupled Memory (TCM) bindings

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: <96081a96-e74c-8165-c0e6-212a670c9074@linaro.org>
Date:   Tue, 17 Jan 2023 09:16:09 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Tanmay Shah <tanmays@....com>, Tanmay Shah <tanmay.shah@....com>,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: sram: Tightly Coupled Memory (TCM) bindings

On 16/01/2023 18:43, Tanmay Shah wrote:
> 
> On 1/15/23 6:38 AM, Krzysztof Kozlowski wrote:
>> On 13/01/2023 19:08, Tanmay Shah wrote:
>>> On 1/12/23 11:52 PM, Krzysztof Kozlowski wrote:
>>>> On 13/01/2023 08:30, Tanmay Shah wrote:
>>>>> This patch introduces bindings for TCM memory address space on AMD-xilinx
>>>>> platforms. As of now TCM addresses are hardcoded in xilinx remoteproc
>>>>> driver. This bindings will help in defining TCM in device-tree and
>>>>> make it's access platform agnostic and data-driven from the driver.
>>>>>
>>>> Subject: drop second/last, redundant "bindings". The "dt-bindings"
>>>> prefix is already stating that these are bindings.
>>> Ack.
>>>
>>>
>>>> Where is driver or DTS? Are you now adding a dead binding without users?
>>>
>>> TCM is used by drivers/remoteproc/xlnx_r5_remoteproc.c driver. Howerver,
>>> we have hardcode addresses in TCM as bindings are not available yet.
>> I don't see usage of these compatibles there. You also did not supply
>> DTS here. Please provide users of bindings within the same patchset.
> 
> 
> ACK. I will supply dts as well.
> 
> However, Is it ok if I convert this patch to RFC patch, and once 
> bindings are fixed I will send actual patch with driver support.
> 
> If bindings design is not correct then I might have to change 
> corresponding driver design lot.

First, why this driver is particularly special? Why should have other
treatment then all other cases?

Second, so think about bindings and do not submit something for "driver"
but something describing hardware.

Best regards,
Krzysztof