On Tue, 22 Apr 2014 15:05:26 +0100, Leif Lindholm <leif.lindh...@linaro.org> wrote: > On Tue, Apr 22, 2014 at 02:08:29PM +0100, Grant Likely wrote: > > > I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here. > > > > I completely agree. > > OK. So do we keep this around on unaffected architectures in perpetuity? > > Or can there be some cut-off date when the majority of DT-enabled > platforms can stop including this workaround which permits new incorrect > DTs to be implemented so long as they are incorrect in this particular > way? > > > > Really, I would like to see quirks like this fixed up out of line from > > > the normal flow somewhat like how PCI quirks are handled. So in this > > > example, we would just add the missing property to the dtb for the > > > broken platform before doing the memory scan. That does then require > > > libfdt which is something I'm working on. > > > > In fact, for Leif's purposes, I would rather have a flag when booting via > > UEFI, and make the kernel skip the memory node parsing if the UEFI > > memory map is available. Then the stub doesn't need to do any munging of > > the DTB at all. > > The reason for me doing that is because we (including you) agreed at > the discussion held during LCU13 that this was the safest way of > preventing "mischief" like userland trying to read information from > /proc/device-tree...
I'm not the most consistent of people. I often change my mind and then have no recollection of ever thinking differently. Userland reading from /proc/device-tree isn't so much a problem, but kernel drivers doing it might be. But, regardless of whether or not the stub clears out the memory nodes, it is still I think good practice for the kernel to make the decision to ignore memory nodes, and not rely on them being cleared correctly. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
