Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
From: Grant Likely <hidden>
Date: 2012-11-05 20:14:37
Also in:
linux-omap, lkml
On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou [off-list ref] wrote:
quoted
This handles many of the use cases, but it assumes that an overlay is board specific. If it ever is required to support multiple base boards with a single overlay file then there is a problem. The .dtb overlays generated in this manor cannot handle different phandles or nodes that are in a different place. On the other hand, the overlay source files should have no problem being compiled for multiple targets, so maybe it isn't an issue. Plus if dtc is installed on the target, then the live tree from /proc can be used as the reference when compiling the overlay.My worry is that this format is dependent on linking against the board DTS file. One of the ideas thrown around here was that it might make sense to store the DTB fragment in the EEPROM of the device.
Right, that wouldn't work well if the base DT changed, or if a BeagleBone2 is released that has the same header configuration, but different backing devices. It would be nice to have a solution for that.
In that case you have a OS independent hardware description, which can be even used even by the bootloader to access devices it knows not about at compile time. Other than that, I have no other objections.
I'm open to suggestions if anyone has any. I have not objections to a fixup approach, but I'm not comfortable with anything that is fragile to modifications to the fragment. g.