Hi Benoit, On Nov 7, 2012, at 12:12 PM, Benoit Cousson wrote: > On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: >> Hi Benoit, >> [snip] >> I don't know if this breaks any conventions but seems to work fine for our case. > > Yeah, my main concern with that approach is that you change the > structure of the tree by adding an extra node/hierarchy that will not be > there in case of non-versioned tree. > That's why I think we should have something lighter that will not change > the structure. > Ideally we should be able to add extra versioned node to the original > dts without changing it at all. > You will still need the versioned nodes to be injected to the non-versioned ones. FWIW the driver will use the standard of_property_read_* interface. You can patch of_property_read to hide the version node matching, and it will work. I'll leave Grant answer what approach is better, I don't claim to have the insight to handle all cases. >>> Maybe some extra version match table can just be passed during the board machine_init >>> >>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >>> >> >> Would we need explicit of_platform_populate calls if we have node modification notifiers? >> In that case the notifier would pick it up automatically, and can do the per >> version matching internally. > > Yes indeed, but here I was thinking about an intermediate step, i.e. > now, without any dynamic node insertion mechanism. > Thanks to this simple approach, when can already fix the board > versionning problem. > As I pointed, with a kind of injection mechanism. the versioned node contents end up in the proper place in the device tree. Your method will work in a much more simpler way. > Regards, > Benoit > Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
