On Thu, 16 Sep 2010 11:40:20 -0600 Grant Likely <[email protected]> wrote:
> However, what does compatible mean at the board level? Can a > BeagleBoard-xM claim compatibility with the original BeagleBoard? Or > even can a -b1 BeagleBoard claim compatibility with the original -a1 > revision? The -b1 has more SDRAM than the original, and the -xM has > removed the on board NAND flash. Neither change can be considered to > be "100% backwards compatible", so is it valid to claim compatibility > with the older board? Clearly the difference between the boards is > still described in the body of the tree so claiming compatibility > appears to be the Right Thing To Do, but a strict reading would say > no. It gets even uglier with virtualization, where you can have arbitrary subsets of a particular board's devices available -- and things like the interrupt controller that are currently normally hardcoded in the platform file may be swapped out for a paravirt interface. > benh has also been strongly against powerpc embedded board support > that can match against a family of boards or SoCs. Instead, he has > required that each platform code have a list of specific boards that > it works with. Example: arch/powerpc/platforms/5200/mpc5200_simple.c. > He doesn't want to get back into the situation where each machine type > gets a whole bunch of complex board-specific workarounds. Even as things are now, such workarounds can still be pretty awkward. They may actually be SoC (family) workarounds (and thus you end up with a bunch of identical machine_initcalls or similar), or it may need to go in the middle of code that doesn't normally go in the platform file, etc. And it excuses ordinary, non-workaround code (PCI and interrupt setup) sitting around duplicated in a bunch of platform files instead of being device-tree-based. > - Revisit the meaning of top-level compatible. > - I still don't think it makes sense for one board to claim > compatibility with another, Most of the time it doesn't, but there may be circumstances where things are only added, or where a new revision just fixes bugs but software that works around the bugs will still work. If we don't allow claiming compatibility in those cases, it may encourage people to lie and claim to just be that old board with no more specific entry in the list (or just not put the board rev in the name at all -- which might be reasonable if the rev info is presented in a separate property, allowing things like greater-than/less-than comparisons). > but it may be reasonable for the > board level to claim compatibility with the SoC used. Or a family of SoCs, or a family of boards, etc... The criteria simply ought to be that it is well documented what it means to be compatible with that string, and that there be something very specific that code can match on instead if^H^Hwhen things go wrong. -Scott _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
