On Fri, 18 Apr 2014 10:37:58 -0500, Rob Herring <robherring2@xxxxxxxxx> wrote: > On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm <leif.lindholm@xxxxxxxxxx> wrote: > > On Thu, Apr 17, 2014 at 07:43:13PM -0500, Rob Herring wrote: > >> On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm > >> <leif.lindholm@xxxxxxxxxx> wrote: > >> > drivers/of/fdt.c contains a workaround for a missing memory type > >> > entry on longtrail firmware. Make that quirk PPC32 only, and while > >> > at it - fix up the .dts files in the tree currently working only > >> > because of that quirk. > >> > >> But why do you need this? > > > > Apart from the current code permitting recreating a 15+ year old > > firmware bug into completely new platform ports? > > I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here. I completely agree. > 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. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
