On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
On Nov 1, 2007, at 11:55 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
On 11/2/07, Kumar Gala galak@kernel.crashing.org wrote:
[snip a bunch more setter functions]
Hi Kumar,
The direction Grant Likely went with 5xxx and where Sergej was heading with 82xx (if only I got around to applying his patch) and where I want to go is to replace the table-driven methodology with direct calls to more generic functions, eliminating the hordes of specialized "setter" functions (all nearly identical).
Discussions and patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ focus=32573 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577
If we get the mpc5xxx style setter functions combined with your fdt_node_offset_by_prop_and_compat() finding changes, I think we would be in fat city.
So we can easily extend what I have to include generic call backs and remove the specific set props. The problem I have with the 5xxx mechanism is its requires too much knowledge of how the device tree is laid out since it uses explicit paths to the nodes.
Yes, I agree. The hard coded paths are stinky. Looking for device_type or compatible might be better.
However, even with using some combination of property values, figuring out which device is which is still a problem. (ie, which network device is eth0 and which is eth1?). Relying on the implicit order in the device tree is just as fragile as using the full path. At least with using the full path, you don't run the risk of getting the wrong node (you just don't find the node at all).
I wasn't thinking of using implicit order, We can use reg or the node name in addition to compat.
Ah, okay. I wasn't sure if name was optional in your last email.
However, if name is specified does compatible even matter?
Or, on the other hand, is name specific enough? For example; is it still possible to wire up two 82xx chips back to back and have one CPU control both socs? In which case you could end up with 2 identical devices with identical node names in the tree.
If you have one cpu controller things will have different reg props than.
If you have two identical SoCs back-to-back, the soc nodes will have different ranges, but the device nodes themselves will be pretty much identical. You'd need to parse all the ranges properties to get a real physaddr before you as sure to get a unique addr.
Name is one way to distinguish. For a given board you're going to know some level of detail about the setup such that you can choose the best mechanism to match on.
Possibly true; but I am concerned that it just trades one fragile method (strict path) for another (expected differences between nodes for identical devices in the tree)
Cheers, g.