On 09/11/2012 08:02 AM, Guennadi Liakhovetski wrote:

Hi Stephen

Thanks for the review.

On Wed, 5 Sep 2012, Stephen Warren wrote:

quoted

On 09/05/2012 04:57 AM, Guennadi Liakhovetski wrote:

quoted

Hi all

Version 5 of this RFC is a result of a discussion of its version 4, which 
took place during the recent Linux Plumbers conference in San Diego. 
Changes are:

(1) remove bus-width properties from device (bridge and client) top level. 
This has actually already been decided upon during our discussions with 
Sylwester, I just forgot to actually remove them, sorry.

(2) links are now grouped under "ports." This should help better describe 
device connection topology by making clearer, which interfaces links are 
attached to. (help needed: in my notes I see "port" optional if only one 
port is present, but I seem to remember, that the final decision was - 
make ports compulsory for uniformity. Which one is true?)

I'd tend to make the port node compulsory.

A related question: What code is going to parse all the port/link
sub-nodes in a device?

I think we'll have to make a generic V4L DT parser. We certainly don't 
want each driver reimplement this.

quoted

And, how does it know which sub-nodes are ports,
and which are something else entirely? Perhaps the algorithm is that all
port nodes must be named "port"?

Yes, that was the idea. Is anything speaking against it?

I think that's fine; it's certainly a nice and simple requirement. It's
just a rule that will have to be thought about when designing bindings
for all the devices that use this feature, to make sure they don't
define any other kind of "port" node that would confuse the parser.

I suppose if this ever becomes a problem, an individual binding could
choose to avoid conflicts by placing the "port" nodes in some specific
child node of its device node, and the driver would pass the name of
that node into the common parsing code, which would default to using the
device's main node when not otherwise specified. However, we should
avoid the conflicts if we can. In other words:

Normal:

/foo {
    port at 0 { ... };
    port at 1 { ... };
};

If there's ever a need to resolve some conflict with that standard layout:

/foo {
    media-ports {
        port at 0 { ... };
        port at 1 { ... };
    };
};