linux-kernel - Re: [PATCH v10 2/4] dt-bindings: remoteproc: add 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: <135e3154-2a55-40ac-9ba9-2de00833b903@linaro.org>
Date: Thu, 15 Feb 2024 10:06:55 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Tanmay Shah <tanmay.shah@....com>, Rob Herring <robh@...nel.org>
Cc: andersson@...nel.org, robh+dt@...nel.org, devicetree@...r.kernel.org,
 krzysztof.kozlowski+dt@...aro.org, linux-remoteproc@...r.kernel.org,
 michal.simek@....com, Radhey Shyam Pandey <radhey.shyam.pandey@....com>,
 ben.levinsky@....com, linux-kernel@...r.kernel.org,
 mathieu.poirier@...aro.org, conor+dt@...nel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v10 2/4] dt-bindings: remoteproc: add Tightly Coupled
 Memory (TCM) bindings

On 13/02/2024 21:37, Tanmay Shah wrote:
> Hello,
> 
> Thanks for reviews please find my comments below.
> 
> On 2/13/24 1:20 PM, Rob Herring wrote:
>> On Tue, 13 Feb 2024 09:54:48 -0800, Tanmay Shah wrote:
>>> From: Radhey Shyam Pandey <radhey.shyam.pandey@....com>
>>>
>>> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
>>> UltraScale+ platform. It will help in defining TCM in device-tree
>>> and make it's access platform agnostic and data-driven.
>>>
>>> Tightly-coupled memories(TCMs) are low-latency memory that provides
>>> predictable instruction execution and predictable data load/store
>>> timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
>>> banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
>>>
>>> The TCM resources(reg, reg-names and power-domain) are documented for
>>> each TCM in the R5 node. The reg and reg-names are made as required
>>> properties as we don't want to hardcode TCM addresses for future
>>> platforms and for zu+ legacy implementation will ensure that the
>>> old dts w/o reg/reg-names works and stable ABI is maintained.
>>>
>>> It also extends the examples for TCM split and lockstep modes.
>>>
>>> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@....com>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@....com>
>>> ---
>>>
>>> Changes in v10:
>>>   - modify number of "reg", "reg-names" and "power-domains" entries
>>>     based on cluster mode
>>>   - Add extra optional atcm and btcm in "reg" property for lockstep mode
>>>   - Add "reg-names" for extra optional atcm and btcm for lockstep mode
>>>   - Drop previous Ack as bindings has new change
>>>
>>> Changes in v9:
>>>   - None
>>> Changes in v8:
>>>   - None
>>> Changes in v7:
>>>   - None
>>> Changes in v6:
>>>   - None
>>> Changes in v5:
>>>   - None
>>>
>>> Changes in v4:
>>>   - Use address-cells and size-cells value 2
>>>   - Modify ranges property as per new value of address-cells
>>>     and size-cells
>>>   - Modify child node "reg" property accordingly
>>>   - Remove previous ack for further review
>>>
>>> v4 link: https://lore.kernel.org/all/20230829181900.2561194-2-tanmay.shah@amd.com/
>>>
>>>  .../remoteproc/xlnx,zynqmp-r5fss.yaml         | 192 ++++++++++++++++--
>>>  1 file changed, 170 insertions(+), 22 deletions(-)
>>>
>>
>> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
>> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>>
>> yamllint warnings/errors:
>> ./Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml:118:13: [warning] wrong indentation: expected 10 but found 12 (indentation)
> Ack. I will fix this.
> 
> However, can I still get reviews on patch itself so if something else needs to be fixed I can fix in next revision as well.

Sorry, I have too many patches to review to provide feedback on work
which does not build/compile/test. First use automated tooling, like
building a C code, to detect as many issues as possible then ask for
reviewing. Not the other way around.

Best regards,
Krzysztof