Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

[Rob Herring]

On Wed, Jun 13, 2018 at 7:35 AM, Suzuki K Poulose
<Suzuki.Poulose@xxxxxxx> wrote:
> Hi Matt,
>
> Thanks for your comments, responses inline.
>
> On 13/06/18 13:49, Matt Sealey wrote:
>>
>> Suzuki,
>>
>> Why not use âunitâ?
>>
>> I believe we had this discussion years ago about numbering serial ports
>> and sdhci (i.e. how do you know itâs UART0 or UART1 from just the address?
>> Some SoCâs donât address sequentially *or* in a forward direction) - I
>> believe itâs not exactly codified in ePAPR, not am I sure where it may be
>> otherwise, but it exists.
>
>
> We have different situation here. We need to know *the port number* as
> understood by the
> hardware, so that we can enable *the specific* port for a given path.
>
>>
>> I agree with Rob on the slave-mode nonsense, this is an SPI controller
>> concept weirdly stuffed into a directed graph which implicitly tells you the
>> data direction - itâs a rooted tree (just like DT!).

OF graph is not directional. All links must be bi-directional and in
fact dtc checks that now. The parent node should know the numbering
and direction of each port.

> Btw, the "slave-mode" is not a standard DT graph binding. It is not part of
> the
> generic DT graph binding. In fact the generic bindings stay away from the
> direction
> aspect and explicitly mentions the same.

I really don't like slave-mode nor coresight,hwid.

I would prefer to see getting rid of both and splitting ports into
"in-ports" and "out-ports" nodes instead of a single "ports" node.
Then you don't need any of these properties and reg can be used as the
hwid.

Rob