On Tue, Jan 27, 2015 at 10:16:24AM -0500, Nicolas Pitre wrote: > On Tue, 27 Jan 2015, Pavel Machek wrote: > > (Note, that in 3.19 dts for n900 got too big, so we are actually > > triggering old bugs. That means that this is a regression fix, and > > should go in ASAP). > > It is queued here: > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8294/1 Irrespective of that patch, I commented on another thread (about adding the serial number to DT): | How about something a little more radical. | | Rather than trying to squeeze various ATAGs into DT, why don't we add a | standard ATAG to contain the DT and pass that through into the kernel. | This is IMHO how we _should_ have done the ATAG compatibility from the | start. | | That means we could get rid of most of the libfdt in the decompressor, | and instead resolve the differences in the kernel. That would allow us to get rid of all the FDT compatibility code in the decompressor, and when we encounter these special ATAGs, we can deal with them in the kernel instead of having to mess around with the DT. I'd also assume (although I haven't checked) that it would be much easier to add additional DT properties in the kernel environment, rather than in the rather restrictive decompressor environment. We'd need to be careful about how we deal with the atags vs DT. I'd suggest (as above) that we have a tag which points at the DT in physical memory, and its size, and pre-scan the atag list for that. When we find it, we kick off the DT based stuff as we would normally do, and follow it with a parse of the atags. This would cause the atags to override whatever is in the DT, which afaics is the behaviour that we actually want. We could augment that with code to update DT too so that we can export just the DT based information to kexec'd kernels. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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
