Hi,
On 29/10/13 20:23, Tomasz Figa wrote:
It's a very deeply nested structure, I'm not sure there's a need to
make a ports {} subnode really.
Also, I don't know if it makes sense to always name it remote-endpoint, or to use a more flexible name depending on what is actually connected, over which bus, etc.
I have been thinking about a 'bus_type' as an 'endpoint' node property. Currently the data bus type is derived from selected properties in endpoint node, which is IMO not good enough.
I'm not sure if naming 'remote-endpoint' differently would be helpful, as it is now it seems easier to write a generic links parser.
Nevertheless I wish we have defined a bit simplified option in this binding right from the beginning.
But overall this looks sane-ish.
I fully agree with you. Personally I would take a bit different design decisions when designing this bindings, but here I'm just pointing an already defined binding that should suit the needs described in this thread, to avoid reinventing the wheel.
The 'ports' node is optional. It needs to be used only if, e.g. bridge-a node contains device child nodes and these sub-nodes use 'reg' property. In such case #address-cells, #size-cells properties for 'port' nodes could be conflicting with those for the device child nodes.
Thanks, Sylwester