linux-kernel - Re: [PATCH v4 0/4] TI K3 R5F remoteproc support

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] [day] [month] [year] [list]

Date:   Tue, 22 Sep 2020 15:26:05 -0500
From:   Suman Anna <s-anna@...com>
To:     Rob Herring <robh@...nel.org>
CC:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Lokesh Vutla <lokeshvutla@...com>,
        <linux-remoteproc@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 0/4] TI K3 R5F remoteproc support

Hi Rob,

On 9/22/20 2:47 PM, Rob Herring wrote:
> On Tue, Sep 08, 2020 at 12:45:52PM -0500, Suman Anna wrote:
>> Hi All,
>>
>> The following is v4 of the TI K3 R5F remoteproc driver series supporting all
>> the R5F processor clusters/subsystems on TI AM65x and J721E SoCs. Please
>> see the v1 cover-letter [1] for the features supported on these R5F processors.
>>
>> This series is a rebased version on top of the latest v5.9-rc baseline and
>> includes very minor fixes w.r.t v3. The previous K3 DSP dependencies are now
>> available in mainline kernel. Please see the individual patches for the delta
>> differences (Only patches 1 and 2 updated).
>>
>> Bjorn,
>> This series is only waiting on bindings ack and the conclusion on the bindings
>> discussion from v2 [4] on which I haven't seen any forward progress on this 
>> despite all the clarifications. I do not expect any changes even w.r.t System DT,
>> and we can't really have a common binding between TI and Xilinx R5Fs. 
>

First of all, thank you for reviewing this and your response.

> Why not? I'm pretty sure lockstep or not is a thing for both and TCMs 
> seem to be a common thing.

The cluster mode is a common theme, and if you have a preference for a common
property-name, both I and Ben can use that. The values though might vary between
different vendor SoCs.

I have given out all the differences and reasons on a v2 thread, the SoC and
clock and reset integration aspects make it look very different.
Please see the discussion here,
https://patchwork.kernel.org/comment/23560321/

There was only one open comment/question I had regarding Core identification
w.r.t my binding. Do you prefer a node-name index difference or a separate
core-id/cpu-id property identifying which is Core0 and Core1.

> 
> And I don't really think System DT will not impact it. Though it's not 
> well enough defined to say either way IMO.

Yeah agreed. But the current architecture in System DT does allow you to add
plugins to generate the proper compliant dts node.

In anycase, I doubt TI will ever be using it in general, because we do not have
a concept of DT on our firmwares. I have given all these inputs again on v2, but
haven't seen any responses on it. So, I do appreciate your feedback.

> 
> But if Bjorn wants to take this, fine. I'm not acking it though nor 
> worrying about it for any compatibility with system DT.

Any specific reasons? For the most part, I am using all standard properties.

regards
Suman