Rob Herring <robh+dt@xxxxxxxxxx> writes:
> On Mon, Jul 30, 2018 at 4:47 AM Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote:
>> Rob Herring <robh+dt@xxxxxxxxxx> writes:
>> > On Thu, Jul 26, 2018 at 11:36 PM Michael Ellerman <mpe@xxxxxxxxxxxxxx> 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@0" node with no
>> >> device_type.
>> >>
>> >> That check was then made to only apply to PPC32 in b44aa25d20e2 ("of:
>> >> Handle memory@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.
OK I'll leave it as-is then.
>> - 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.
Yeah.
> It would also be nice if I had some dumps of DTs for some of
> these OpenFirmware systems.
Yeah it would. What if I threw some in a git tree somewhere?
I guess fully unpacked is the most useful form, ie. just a direct copy
from /proc/device-tree.
cheers
--
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
