linux-kernel - Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph 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: <CAL_Jsq+0kExVY33kdDoR6bAxbr2VzRUzW2j0k+2wmv4CSNVnpQ@mail.gmail.com>
Date:   Thu, 14 Jun 2018 07:59:33 -0600
From:   Rob Herring <robh@...nel.org>
To:     Suzuki K Poulose <Suzuki.Poulose@....com>
Cc:     Matt Sealey <Matt.Sealey@....com>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Sudeep Holla <Sudeep.Holla@....com>,
        Mark Rutland <Mark.Rutland@....com>,
        "frowand.list@...il.com" <frowand.list@...il.com>,
        Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>,
        John Horley <John.Horley@....com>,
        "mike.leach@...aro.org" <mike.leach@...aro.org>,
        "coresight@...ts.linaro.org" <coresight@...ts.linaro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

On Thu, Jun 14, 2018 at 2:53 AM, Suzuki K Poulose
<Suzuki.Poulose@....com> wrote:
> On 13/06/18 22:07, Matt Sealey wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: Mathieu Poirier <mathieu.poirier@...aro.org>
>>>
>>>> So, if the suggestion is to use an existing property "unit", I am fine
>>>> with it, if people agree to it.
>>>
>>>
>>> If we're going to have something sharply different than ACPI I prefer
>>> Rob's idea.
>
>
> No, the above comment is about using "unit" ( if it is a standard property
> for specifying something specific to hardware) instead of "coresight,hwid".
> I would prefer to stick to the DT graph bindings, because :

"unit" is not a standard property and I don't like it either.

>
> 1) The connections are bi-directional => Well, not necessarily
> bi-directional
> in terms of the data flow. But the connection information is critical. i.e,
> we need information about both the end-points of a connection, which the DT
> graph bindings solves.
>
> All we are missing is a way for specifying the "hardware port" number and
> the
> direction of flow. I don't see why do we need to create something new just
> for
> these two properties for something that exists today and works reasonably
> well
> for the usecase.

If you have "in-ports" and "out-ports" nodes, then that gives you
direction and you can use reg for the "hardware port".

in-ports {
  port@0 {
    reg = <0>;
    endpoint {...};
  };
  port@1 {
    reg = <1>;
    endpoint {...};
  };
};
out-ports {
  port@0 {
    reg = <0>;
    endpoint {...};
  };
};

I'll need to check, but dtc may need an update to not warn about this.

>
>>
>> What are you trying to say about being sharply different than ACPI?
>
>
> The proposed Coresight ACPI draft bindings are based on the ACPI Graph
> bindings
> (just like the DT graph bindings and is compatible with it, in terms of the
> APIs.
> i.e, fwnode_graph_* operations work for both ACPI and DT  alike).
>
> So, what Mathieu, in turn means is, if we depart from the DT Graph bindings,
> which
> I personally don't see any benefit in.

If DT bindings can be reused for ACPI, that's fine, but don't expect
any DT bindings to be accepted simply because they match ACPI
bindings.

Rob