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
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev
