Hi Laurent, Am Donnerstag, den 13.03.2014, 18:13 +0100 schrieb Laurent Pinchart: > Hi Philipp, > > On Thursday 13 March 2014 12:08:16 Philipp Zabel wrote: > > Am Montag, den 10.03.2014, 14:37 +0000 schrieb Grant Likely: > > > > > Nak. I made comments that haven't been resolved yet. I've replied with > > > > > more detail tonight. The big issues are how drivers handle the > > > > > optional 'ports' node and I do not agree to the double-linkage in the > > > > > binding description. > > > > so as I understand it, nobody is against dropping the double-linkage *if* we > > can agree on a way to recreate the backlinks in the kernel. > > I'm not sure about "nobody", but even though it might not be my favorite > option I'd be OK with that. Ok, I make that assumption going by the discussion about link direction that ensued. > > My current suggestion would be to parse the complete device tree into an > > internal graph structure once, at boot to achieve this. This code could > > look for the optional 'ports' node if and only if the parent device node > > contains #address-cells != <1> or #size-cells != <0> properties. > > With backlinks in DT we can assume that, if a node is the target of a link, it > will be compatible with the of-graph bindings, and thus parse the node to > locate other ports and other links. This allows parsing the full graph without > help of individual drivers. Yes. > Without backlinks in DT we need to parse the full DT to reconstruct backlinks > in the kernel. One possible issue with that is that we can't know whether a > node implements the of-graph bindings. We can use the heuristic you've > described above, but I wonder if it could lead to problems. Grant pointed out > that the compatibility string defines what binding a node uses, and that we > can't thus look for properties randomly. I don't think there's a risk to > interpret an unrelated node as part of a graph though. False positives would just take up a bit of space in the endpoint lists, but otherwise should be no problem, as they would only be used when either a driver implementing the bindings is bound, or when they are connected to other endpoints. Whether or not we scan the whole tree, using this heuristic, is more a matter of principle. > > People completely disagree about the direction the phandle links should > > point in. I am still of the opinion that the generic binding should describe > > just the topology, that the endpoint links in the kernel should represent an > > undirected graph and the direction of links should not matter at all for the > > generic graph bindings. > > I would also not mandate a specific direction at the of-graph level and leave > it to subsystems (or possibly drivers) to specify the direction. Thank you. Can everybody live with this? regards Philipp -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
