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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <09b0768a-4534-420f-9774-50e250795dd7@amd.com>
Date: Thu, 15 Feb 2024 10:45:21 -0600
From: Tanmay Shah <tanmay.shah@....com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 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 2/15/24 3:06 AM, Krzysztof Kozlowski wrote:
> 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.

Ack. I will send new revision fixing the warning.

Thanks.


>
> Best regards,
> Krzysztof