[PATCH] of/fdt: Remove PPC32 longtrail hack in memory scan
Rob Herring
robh+dt at kernel.org
Tue Jul 31 03:19:42 AEST 2018
On Mon, Jul 30, 2018 at 4:47 AM Michael Ellerman <mpe at ellerman.id.au> wrote:
>
> Rob Herring <robh+dt at kernel.org> writes:
> > On Thu, Jul 26, 2018 at 11:36 PM Michael Ellerman <mpe at ellerman.id.au> wrote:
> >> When the OF code was originally made common by Grant in commit
> >> 51975db0b733 ("of/flattree: merge early_init_dt_scan_memory() common
> >> code") (Feb 2010), the common code inherited a hack to handle
> >> PPC "longtrail" machines, which had a "memory at 0" node with no
> >> device_type.
> >>
> >> That check was then made to only apply to PPC32 in b44aa25d20e2 ("of:
> >> Handle memory at 0 node on PPC32 only") (May 2014).
> >>
> >> But according to Paul Mackerras the "longtrail" machines are long
> >> dead, if they were ever seen in the wild at all. If someone does still
> >> have one, we can handle this firmware wart in powerpc platform code.
> >>
> >> So remove the hack once and for all.
> >
> > Yay. I guess Power Macs and other quirks will never die...
>
> Not soon.
>
> In base.c I see:
> - the hack in arch_find_n_match_cpu_physical_id()
> - we should just move that into arch code, it's a __weak arch hook
> after all.
Except then we'd have to export __of_find_n_match_cpu_property. I
somewhat prefer it like it is because arch specific functions tend to
encourage duplication. But if the implementation is completely
different like sparc, then yes, a separate implementation makes sense.
> - a PPC hack in of_alias_scan(), I guess we need to retain that
> behaviour, but it's pretty minor anyway.
It would be nice to know what platform(s) needs this as I don't have a
clue. It would also be nice if I had some dumps of DTs for some of
these OpenFirmware systems.
Rob
More information about the Linuxppc-dev
mailing list