linux-kernel - Re: [PATCH v1 08/29] dt-bindings: interconnect: tegra: Add initial IDs

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]

Date:   Thu, 21 Nov 2019 20:14:35 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        Mikko Perttunen <mperttunen@...dia.com>,
        Georgi Djakov <georgi.djakov@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, linux-tegra@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v1 08/29] dt-bindings: interconnect: tegra: Add initial
 IDs

19.11.2019 19:56, Dmitry Osipenko пишет:
> 19.11.2019 09:25, Thierry Reding пишет:
>> On Mon, Nov 18, 2019 at 11:02:26PM +0300, Dmitry Osipenko wrote:
>>> Define interconnect IDs for memory controller (MC), external memory
>>> controller (EMC), external memory (EMEM) and memory clients of display
>>> controllers (DC).
>>>
>>> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
>>> ---
>>>  include/dt-bindings/interconnect/tegra-icc.h | 11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>  create mode 100644 include/dt-bindings/interconnect/tegra-icc.h
> 
> 
> Hello Thierry,
> 
>> There was a bit of discussion regarding this for a recent patch that I
>> was working on, see:
>>
>> 	http://patchwork.ozlabs.org/project/linux-tegra/list/?series=140318
> 
> Thank you very much for the link.
> 
>> I'd rather not use an additional set of definitions for this. The memory
>> controller already has a set of native IDs for memory clients that I
>> think we can reuse for this.
> 
> I missed that it's fine to have multiple ICC connections defined
> per-path, at quick glance looks like indeed it should be fine to re-use
> MC IDs.

Well, it is not quite correct to have multiple connections per-path.

Please take look at interconnect's binding and core.c:

  1. there should be one src->dst connection per-path
  2. each connection should comprise of one source and one destination nodes

>> I've only added these client IDs for Tegra194 because that's where we
>> need it to actually describe a specific hardware quirk, but I can come
>> up with the equivalent for older chips as well.
> 
> Older Tegra SoCs have hardware units connected to MC through AHB bus,
> like USB for example. These units do not have MC client IDs and there is
> no MC ID defined for the AHB bus either, but probably it won't be a
> problem to define IDs for them if will be necessary.
> 

Since interconnect binding requires to define both source and
destination nodes for the path, then MC IDs are not enough in order to
define interconnect path because these IDs represent only the source
nodes. Destination node should be either EMC or EMEM.