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.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
