[PATCH v3] powerpc/85xx: Add P2020DS board support
Kumar Gala
galak at kernel.crashing.org
Thu Apr 23 04:11:29 EST 2009
On Apr 22, 2009, at 12:38 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:
>>> Kumar Gala wrote:
>>>> On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
>>>>> Kumar Gala wrote:
>>>>>>> If this has an elbc more recent than 1.0 (looks like it), we
>>>>>>> should
>>>>>>> indicate that here.
>>>>>> that might be the case, but I leave it to u-boot to do that.
>>>>>
>>>>> Why? There's no p2020 with an older eLBC, and there's no block
>>>>> version register.
>>>> But there might be a p2020 w/a newer eLBC version in the future.
>>>
>>> At which point we can add something to u-boot -- but magic SVR
>>> tables seem a step backward from the dts except where needed to
>>> avoid the creation of extra dts files.
>> I don't see the value of complicating u-boot
>
> But complicating u-boot is just what you're suggesting. Put it in
> the dts, and u-boot has *zero* code to deal with this unless we find
> ourselves wanting to share the dts with another board rev with a
> newer chip with a newer elbc.
>
>> to have to parse and "fixup" the compatible instead of just having
>> to prepend to it. Especially since I don't believe there is
>> anything specific we care about in the 1.2 version of elbc at this
>> point.
>
> If the new elbc is compatible with the current one, then you will
> still just be prepending. If it is not, then it very likely isn't
> compatible with 1.0 either, so you'll have to remove fsl,elbc anyway.
>
> What "we care about" at this point is irrelevant, given the PITA it
> would be to change the device trees (or u-boot) that are already in
> use once we do begin to care.
Which is exactly why I didn't put it in the .dts right now. Today we
know NO code exists that cares about "fsl,elbc-1.2". Once someone adds
such code they can also update the .dts to match it.
- k
More information about the Linuxppc-dev
mailing list