On Thu, Jul 31, 2008 at 09:25:33PM -0600, Grant Likely wrote:
> On Fri, Aug 01, 2008 at 12:54:39PM +1000, David Gibson wrote:
> > On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
[snip]
> > > - Add a property to the device tree that explicitly specifies the SoC
> > > that the board is based on. Something like 'soc-model =
> > > "fsl,mpc5200b"' would be appropriate. This in and of itself does not
> > > change the usage conventions, it just provides more information about
> > > the hardware. (Another idea is to add a string to the top level
> > > compatible property, but there are still arguments about what
> > > compatible really means in the root node.)
> >
> > No. This sort of information belongs in the board compatible
> > property. compatible = "myspecificboard", "generic-mpc5200-board" or
> > the like.
>
> The last number of times this topic came up, there was opposition to
> using any kind of "generic-<blah>-board". Mostly because of the
> definition of what it means to be 'compatible' tends to change over
> time. That is why I suggested a new property explicitly for defining
Well, there is that. But fundamentally the trade-off is between
specifying mostly-compatible boards in the device tree and dealing
with the not-quite-compatible ones, and having a large and growing
list of compatible strings to match in the platform support files.
Creating new properties doesn't get rid of this tradeoff, it shuffles
it about.
> the SoC used. It encodes real information without trying to stretch the
> meaning of 'compatible'.
But the implication is that it will be used to pick compatible
platform code. This is *not* always a function of the SoC in use, so
using the SoC type in this way just muddies the waters.
We already have a method for having a heirarchy of things compatible
by other things, picking a specific form if available then a more
generic match if possible - matching on the compatible node (we
should, of course, make sure that the platform match code, like the
driver match code will always prefer a match early in the compatible
list to one later). Replacing this free-form heirarchy that we can
set up to match our needs with one that artificially assumes that
artificially assumes one of the levels will have a 1-to-1
correspondance with the SoC type is just silly.
> However, I'm raising this question as an RFC. I can probably be
> convinced otherwise.
>
> > Groups of boards sufficiently similar to share platform
> > code are *usually* divided by which SoC they're based on, but not
> > always. Sometimes they're divided by the main bridge chip, or by
> > vendor (if the vendor is careful to use the same conventions on
> > different boards even with different SoCs). And sometimes boards will
> > have idiosyncratic wiring that requires special platform support, even
> > if all the major components are the same as some standard design.
>
> Which is another reason I didn't want to encode it in compatible.
> However, it still leaves the problem of how to bind across platform
> lines. For the SoC case, I expect that the catch-all machines really
> perform a 'best-effort' match, as in if nothing has claimed the before
> it gets to it, and the SoC matches (or some other property for that
> matter), then it should be okay to bind.
We can already do this with compatible. In fact, that's precisely how
it's designed to work.
> > > - Prioritize board ports in the arch/powerpc/platforms directory to
> > > identify level-1 machines support from the level-2 ones. Make sure
> > > that level-1 stuff always gets probed before level-2 stuff within each
> > > SoC family. In all likelyhood, this would probably just involve
> > > making sure that board specific machines get linked in before the
> > > catchall machine.
> >
> > Again, this is imposing too much structure on which boards are
> > compatible with which. Certainly compatibility by SoC with a few
> > exceptions is common, but it's not universal.
> >
> > Splitting highly-specific from fairly-generic platform code might help
> > readability. But, we have to remember that the distinction is only a
> > useful-guideline one, not a true structural difference.
>
> Heh; I probably sounded more rigid than I intended to be. I fully
> understand that the distinction is in the useful guideline category and
> that Linux must always have the option of doing something different.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
