Board level compatibility matching

Board level compatibility matching

[Grant Likely]

This topic keeps coming up, so it is probably time to address it once
and for all.

When it comes to machine level support in arch/powerpc, there seems to
me that there are two levels or machine support.

Level 1 is the board specific stuff.  Board X has a, b, and c things
that need to be done for Linux to work correctly, but the fixups are
entirely board specific and will only ever be used on a single board
port.  The lite5200 support in arch/powerpc/platforms/52xx is an
example of this kind of board support.  It binds on a value in the top
level compatible property.

Level 2 is kind of the generic catch-all machine support for systems
that are unremarkable and don't require any special code to be run.
In most cases, new boards can be supported by this generic code
without any changes to the Linux kernel.
arch/powerpc/platforms/52xx/mpc5200_simple.c is an example here.
mpc5200_simple maintains a list of boards that are known to work with
it.

At the moment, every new board port forces a linux kernel source tree
change, even if it is just adding a single string to the match table.
I'm willing to wager that 99 times out of 100, boards based on the
mpc5200 SoC will want to use the common board support code and that
maintaining an explicit list of supported boards is completely
unnecessary.  I expect that the exact same is true for 8xxx and 4xx
SoCs.  So, rather than continuing to need to maintain explicit lists,
I propose the following:

- 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.)

- 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.

- Change level-2 machine support to bind on soc-model instead of an
explicit compatible list.

Doing so should simplify adding new board ports.  In many cases it
would just involve dropping in a new .dts file.  However, it retains
the flexability of overriding generic code with platform specific
fixups as the need arises.  I know we've been cautious about adding
catch-all bindings to the device tree, and it is a big deal to avoid
adding wildcards to compatible values.  However, this solution should
be workable because it doesn't involve stating something that is not
true in the device tree and it maintains the ability to override
cleanly when new bugs are discovered.  It also doesn't try to define
wildcard values in compatible or other device tree properties.

Thoughts?
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Board level compatibility matching

[Chris Friesen]

Grant Likely wrote:

> Doing so should simplify adding new board ports.  In many cases it
> would just involve dropping in a new .dts file.  However, it retains
> the flexability of overriding generic code with platform specific
> fixups as the need arises.

If it makes it easier for board vendors to do a clean port, you get a 
vote from me.

I've seen a large amount of vendor code from that needed a lot of 
massaging before it would play nice with support for similar boards from 
other vendors--not to mention how ugly it looked with all the 
board-specific ifdefs.

Chris

Re: Board level compatibility matching

[Jon Smirl]

On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> This topic keeps coming up, so it is probably time to address it once
>  and for all.
>
>  When it comes to machine level support in arch/powerpc, there seems to
>  me that there are two levels or machine support.
>
......
>
>  Thoughts?
>  g.


As part of this, how can we going to solve the problem with triggering
the load of a board specific machine/fabric driver in a generic way?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Board level compatibility matching

[Grant Likely]

On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
> On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > This topic keeps coming up, so it is probably time to address it once
> >  and for all.
> >
> >  When it comes to machine level support in arch/powerpc, there seems to
> >  me that there are two levels or machine support.
> >
> ......
> >
> >  Thoughts?
> >  g.
> 
> 
> As part of this, how can we going to solve the problem with triggering
> the load of a board specific machine/fabric driver in a generic way?

That really is a separate problem.  We *could* do this with a board
specific powerpc machine driver, but I don't think it is the best
solution.

I'm still thinking that the drivers module_init() function could check
the top level board model property and decide whether or not to load
based on that.

g.

Re: Board level compatibility matching

[Jon Smirl]

On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
>  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>  > > This topic keeps coming up, so it is probably time to address it once
>  > >  and for all.
>  > >
>  > >  When it comes to machine level support in arch/powerpc, there seems to
>  > >  me that there are two levels or machine support.
>  > >
>  > ......
>  > >
>  > >  Thoughts?
>  > >  g.
>  >
>  >
>  > As part of this, how can we going to solve the problem with triggering
>  > the load of a board specific machine/fabric driver in a generic way?
>
>
> That really is a separate problem.  We *could* do this with a board
>  specific powerpc machine driver, but I don't think it is the best
>  solution.
>
>  I'm still thinking that the drivers module_init() function could check
>  the top level board model property and decide whether or not to load
>  based on that.

You're assuming the driver is compiled in.

If the drivers are on initrd selection has to happen via the normal
device/driver matching process. Search for a device in the alias table
of the drive file.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Board level compatibility matching

[Scott Wood]

On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> - 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.

Shouldn't that go in the compatible property of the soc node?

> - 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.

I don't think we're too far away from being able to have a catch-all that
isn't even soc-type-specific -- the main things that come to mind are
instantiating PCI controllers (should be easily fixed) and finding the
root IRQ controller (I suppose we could pick a random interrupt
controller and follow the interrupt tree to its root, though it'd be more
robust if it were explicitly identified in the device tree).

-Scott

Re: Board level compatibility matching

[Grant Likely]

On Thu, Jul 31, 2008 at 03:59:06PM -0500, Scott Wood wrote:
> On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> > - 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.
> 
> Shouldn't that go in the compatible property of the soc node?

Not all SoC's (in particular 4xx SoCs) use an soc node.  Some of them
instead just describe the internal busses on the SoC.

> > - 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.
> 
> I don't think we're too far away from being able to have a catch-all that
> isn't even soc-type-specific -- the main things that come to mind are
> instantiating PCI controllers (should be easily fixed) and finding the
> root IRQ controller (I suppose we could pick a random interrupt
> controller and follow the interrupt tree to its root, though it'd be more
> robust if it were explicitly identified in the device tree).

Perhaps a root-interrupt-controller property?

g.

Re: Board level compatibility matching

[David Gibson]

On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
> On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
> >  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> >  > > This topic keeps coming up, so it is probably time to address it once
> >  > >  and for all.
> >  > >
> >  > >  When it comes to machine level support in arch/powerpc, there seems to
> >  > >  me that there are two levels or machine support.
> >  > >
> >  > ......
> >  > >
> >  > >  Thoughts?
> >  > >  g.
> >  >
> >  >
> >  > As part of this, how can we going to solve the problem with triggering
> >  > the load of a board specific machine/fabric driver in a generic way?
> >
> >
> > That really is a separate problem.  We *could* do this with a board
> >  specific powerpc machine driver, but I don't think it is the best
> >  solution.
> >
> >  I'm still thinking that the drivers module_init() function could check
> >  the top level board model property and decide whether or not to load
> >  based on that.
> 
> You're assuming the driver is compiled in.
> 
> If the drivers are on initrd selection has to happen via the normal
> device/driver matching process. Search for a device in the alias table
> of the drive file.

This can still be done via the board platform code.  The platform code
creates a platform device which the driver can later bind to.


-- 
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

Re: Board level compatibility matching

[David Gibson]

On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> This topic keeps coming up, so it is probably time to address it once
> and for all.
> 
> When it comes to machine level support in arch/powerpc, there seems to
> me that there are two levels or machine support.
> 
> Level 1 is the board specific stuff.  Board X has a, b, and c things
> that need to be done for Linux to work correctly, but the fixups are
> entirely board specific and will only ever be used on a single board
> port.  The lite5200 support in arch/powerpc/platforms/52xx is an
> example of this kind of board support.  It binds on a value in the top
> level compatible property.
> 
> Level 2 is kind of the generic catch-all machine support for systems
> that are unremarkable and don't require any special code to be run.
> In most cases, new boards can be supported by this generic code
> without any changes to the Linux kernel.
> arch/powerpc/platforms/52xx/mpc5200_simple.c is an example here.
> mpc5200_simple maintains a list of boards that are known to work with
> it.
> 
> At the moment, every new board port forces a linux kernel source tree
> change, even if it is just adding a single string to the match table.
> I'm willing to wager that 99 times out of 100, boards based on the
> mpc5200 SoC will want to use the common board support code and that
> maintaining an explicit list of supported boards is completely
> unnecessary.  I expect that the exact same is true for 8xxx and 4xx
> SoCs.  So, rather than continuing to need to maintain explicit lists,
> I propose the following:
> 
> - 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.  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.

> - 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.

> - Change level-2 machine support to bind on soc-model instead of an
> explicit compatible list.
> 
> Doing so should simplify adding new board ports.  In many cases it
> would just involve dropping in a new .dts file.  However, it retains
> the flexability of overriding generic code with platform specific
> fixups as the need arises.  I know we've been cautious about adding
> catch-all bindings to the device tree, and it is a big deal to avoid
> adding wildcards to compatible values.  However, this solution should
> be workable because it doesn't involve stating something that is not
> true in the device tree and it maintains the ability to override
> cleanly when new bugs are discovered.  It also doesn't try to define
> wildcard values in compatible or other device tree properties.
> 
> Thoughts?
> g.
> 

-- 
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

Re: Board level compatibility matching

[Jon Smirl]

On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
>  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>  > > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
>  > >  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>  > >  > > This topic keeps coming up, so it is probably time to address it once
>  > >  > >  and for all.
>  > >  > >
>  > >  > >  When it comes to machine level support in arch/powerpc, there seems to
>  > >  > >  me that there are two levels or machine support.
>  > >  > >
>  > >  > ......
>  > >  > >
>  > >  > >  Thoughts?
>  > >  > >  g.
>  > >  >
>  > >  >
>  > >  > As part of this, how can we going to solve the problem with triggering
>  > >  > the load of a board specific machine/fabric driver in a generic way?
>  > >
>  > >
>  > > That really is a separate problem.  We *could* do this with a board
>  > >  specific powerpc machine driver, but I don't think it is the best
>  > >  solution.
>  > >
>  > >  I'm still thinking that the drivers module_init() function could check
>  > >  the top level board model property and decide whether or not to load
>  > >  based on that.
>  >
>  > You're assuming the driver is compiled in.
>  >
>  > If the drivers are on initrd selection has to happen via the normal
>  > device/driver matching process. Search for a device in the alias table
>  > of the drive file.
>
>
> This can still be done via the board platform code.  The platform code
>  creates a platform device which the driver can later bind to.

That is what I'm doing now. But it requires every board to add a file
to arch/powerpc/platforms.  Can we have some common code to make the
fabric device? Can it be an OF device instead of a platform one? An OF
device could be compatible with boardname-fabric, generic-fabric. That
allows a stub fabric driver to always bind.

>
>
>
>  --
>  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
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Board level compatibility matching

[Grant Likely]

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:
> > This topic keeps coming up, so it is probably time to address it once
> > and for all.
> > 
> > When it comes to machine level support in arch/powerpc, there seems to
> > me that there are two levels or machine support.
> > 
> > Level 1 is the board specific stuff.  Board X has a, b, and c things
> > that need to be done for Linux to work correctly, but the fixups are
> > entirely board specific and will only ever be used on a single board
> > port.  The lite5200 support in arch/powerpc/platforms/52xx is an
> > example of this kind of board support.  It binds on a value in the top
> > level compatible property.
> > 
> > Level 2 is kind of the generic catch-all machine support for systems
> > that are unremarkable and don't require any special code to be run.
> > In most cases, new boards can be supported by this generic code
> > without any changes to the Linux kernel.
> > arch/powerpc/platforms/52xx/mpc5200_simple.c is an example here.
> > mpc5200_simple maintains a list of boards that are known to work with
> > it.
> > 
> > At the moment, every new board port forces a linux kernel source tree
> > change, even if it is just adding a single string to the match table.
> > I'm willing to wager that 99 times out of 100, boards based on the
> > mpc5200 SoC will want to use the common board support code and that
> > maintaining an explicit list of supported boards is completely
> > unnecessary.  I expect that the exact same is true for 8xxx and 4xx
> > SoCs.  So, rather than continuing to need to maintain explicit lists,
> > I propose the following:
> > 
> > - 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
the SoC used.  It encodes real information without trying to stretch the
meaning of 'compatible'.

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.

> > - 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.

g.

Re: Board level compatibility matching

[David Gibson]

On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
> >  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> >  > > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
> >  > >  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> >  > >  > > This topic keeps coming up, so it is probably time to address it once
> >  > >  > >  and for all.
> >  > >  > >
> >  > >  > >  When it comes to machine level support in arch/powerpc, there seems to
> >  > >  > >  me that there are two levels or machine support.
> >  > >  > >
> >  > >  > ......
> >  > >  > >
> >  > >  > >  Thoughts?
> >  > >  > >  g.
> >  > >  >
> >  > >  >
> >  > >  > As part of this, how can we going to solve the problem with triggering
> >  > >  > the load of a board specific machine/fabric driver in a generic way?
> >  > >
> >  > >
> >  > > That really is a separate problem.  We *could* do this with a board
> >  > >  specific powerpc machine driver, but I don't think it is the best
> >  > >  solution.
> >  > >
> >  > >  I'm still thinking that the drivers module_init() function could check
> >  > >  the top level board model property and decide whether or not to load
> >  > >  based on that.
> >  >
> >  > You're assuming the driver is compiled in.
> >  >
> >  > If the drivers are on initrd selection has to happen via the normal
> >  > device/driver matching process. Search for a device in the alias table
> >  > of the drive file.
> >
> >
> > This can still be done via the board platform code.  The platform code
> >  creates a platform device which the driver can later bind to.
> 
> That is what I'm doing now. But it requires every board to add a file
> to arch/powerpc/platforms.  Can we have some common code to make the
> fabric device? Can it be an OF device instead of a platform one? An OF
> device could be compatible with boardname-fabric, generic-fabric. That
> allows a stub fabric driver to always bind.

There are several ways to do this, and which is the most sensible
depends on the specific design, and whether / how many boards the
design is shared amongst.

In some cases it's suitable to have a "fake" device node for the sound
wiring, to which a fabric driver can bind.  I think I've argued
against this approach in the past, but I've since been convinced that
it is a reasonable approach for some situations.  There's precedent,
too, a number of Apple device trees do this.

In other cases it may be possible to deduce the correct fabric driver
from the interconnections of individual sound components.

In yet others, we need board-specific platform code to instantiate the
fabric driver.  In some cases that's simply the most straightforward
way to do things.  In others it's not ideal, but we can use it as a
fallback technique because deployed device trees simply don't have
sufficient information in other places to use another approach.

There doesn't have to be One True Method for doing this.

-- 
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

Re: Board level compatibility matching

[David Gibson]

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

Re: Board level compatibility matching

[Jon Smirl]

On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
>  > On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
>  > > On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
>  > >  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>  > >  > > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
>  > >  > >  > On 7/31/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>  > >  > >  > > This topic keeps coming up, so it is probably time to address it once
>  > >  > >  > >  and for all.
>  > >  > >  > >
>  > >  > >  > >  When it comes to machine level support in arch/powerpc, there seems to
>  > >  > >  > >  me that there are two levels or machine support.
>  > >  > >  > >
>  > >  > >  > ......
>  > >  > >  > >
>  > >  > >  > >  Thoughts?
>  > >  > >  > >  g.
>  > >  > >  >
>  > >  > >  >
>  > >  > >  > As part of this, how can we going to solve the problem with triggering
>  > >  > >  > the load of a board specific machine/fabric driver in a generic way?
>  > >  > >
>  > >  > >
>  > >  > > That really is a separate problem.  We *could* do this with a board
>  > >  > >  specific powerpc machine driver, but I don't think it is the best
>  > >  > >  solution.
>  > >  > >
>  > >  > >  I'm still thinking that the drivers module_init() function could check
>  > >  > >  the top level board model property and decide whether or not to load
>  > >  > >  based on that.
>  > >  >
>  > >  > You're assuming the driver is compiled in.
>  > >  >
>  > >  > If the drivers are on initrd selection has to happen via the normal
>  > >  > device/driver matching process. Search for a device in the alias table
>  > >  > of the drive file.
>  > >
>  > >
>  > > This can still be done via the board platform code.  The platform code
>  > >  creates a platform device which the driver can later bind to.
>  >
>  > That is what I'm doing now. But it requires every board to add a file
>  > to arch/powerpc/platforms.  Can we have some common code to make the
>  > fabric device? Can it be an OF device instead of a platform one? An OF
>  > device could be compatible with boardname-fabric, generic-fabric. That
>  > allows a stub fabric driver to always bind.
>
>
> There are several ways to do this, and which is the most sensible
>  depends on the specific design, and whether / how many boards the
>  design is shared amongst.
>
>  In some cases it's suitable to have a "fake" device node for the sound
>  wiring, to which a fabric driver can bind.  I think I've argued
>  against this approach in the past, but I've since been convinced that
>  it is a reasonable approach for some situations.  There's precedent,
>  too, a number of Apple device trees do this.
>
>  In other cases it may be possible to deduce the correct fabric driver
>  from the interconnections of individual sound components.
>
>  In yet others, we need board-specific platform code to instantiate the
>  fabric driver.  In some cases that's simply the most straightforward
>  way to do things.  In others it's not ideal, but we can use it as a
>  fallback technique because deployed device trees simply don't have
>  sufficient information in other places to use another approach.
>
>  There doesn't have to be One True Method for doing this.

We're running into a need for the true method. With ALSA you need to
have the codec driver, i2s/ac97 driver and the fabric driver all load
and say here I am before ALSA can finish binding. ALSA won't complete
initializing on boards without all three.

So what do you do on board that doesn't need a fabric driver? That's
why you want the fake device with the compatible string =
board-fabric, noop-fabric. Now you know for sure one of those two
drivers will bind.

Why does the fake fabric device need to be in the device tree? Can't
we just dynamically create it as part of the boot process?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Board level compatibility matching

[David Gibson]

On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
> On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> >  > On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
[snip]
> >  > That is what I'm doing now. But it requires every board to add a file
> >  > to arch/powerpc/platforms.  Can we have some common code to make the
> >  > fabric device? Can it be an OF device instead of a platform one? An OF
> >  > device could be compatible with boardname-fabric, generic-fabric. That
> >  > allows a stub fabric driver to always bind.
> >
> >
> > There are several ways to do this, and which is the most sensible
> >  depends on the specific design, and whether / how many boards the
> >  design is shared amongst.
> >
> >  In some cases it's suitable to have a "fake" device node for the sound
> >  wiring, to which a fabric driver can bind.  I think I've argued
> >  against this approach in the past, but I've since been convinced that
> >  it is a reasonable approach for some situations.  There's precedent,
> >  too, a number of Apple device trees do this.
> >
> >  In other cases it may be possible to deduce the correct fabric driver
> >  from the interconnections of individual sound components.
> >
> >  In yet others, we need board-specific platform code to instantiate the
> >  fabric driver.  In some cases that's simply the most straightforward
> >  way to do things.  In others it's not ideal, but we can use it as a
> >  fallback technique because deployed device trees simply don't have
> >  sufficient information in other places to use another approach.
> >
> >  There doesn't have to be One True Method for doing this.
> 
> We're running into a need for the true method. With ALSA you need to
> have the codec driver, i2s/ac97 driver and the fabric driver all load
> and say here I am before ALSA can finish binding. ALSA won't complete
> initializing on boards without all three.
> 
> So what do you do on board that doesn't need a fabric driver? That's
> why you want the fake device with the compatible string =
> board-fabric, noop-fabric. Now you know for sure one of those two
> drivers will bind.

No... that would be exactly my example of a case where instantiating
the fabric driver from the platform code isn't ideal, but is a usable
fallback option.

> Why does the fake fabric device need to be in the device tree? Can't
> we just dynamically create it as part of the boot process?

Um.. yes.. that would be exactly what instatiating it from the
platform code does.

-- 
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

Re: Board level compatibility matching

[Benjamin Herrenschmidt]

About this whole generic board mumbo-jumbo: not happening. It's a pipe
dream, it doesn't work, and it leads to the sort of mess we have in chrp
where we end up having hacks to identify what exact sort of chrp we have
and do things differently etc...

NOT HAPPENING.

Now, there are two approaches here that are possible:

 - Your board is really pretty much exactly the same as board XXX,
except maybe you have a different flash size or such, and the support
for board XXX can cope perfectly with it simply due to the device-tree
the right information.

If that happens to be the case, make your board compatible with board
XXX. Make that entry -second- in your compatible list, because one day
you'll figure out that there -is- indeed a difference and I don't want
to see board XXX code start to grow code to recognise your other board
and work around the difference. So at that stage, copy board XXX.c file
and start over with your own board support that matches on your first
compatible propery entry.

 - Once you figure out that really, those 5 boards here -do- share 99%
of the code... it's just that one need a workaround at the IRQ fixup
level, maybe one needs a tweak on a GPIO at boot and one has an issue on
reboot that needs to be whacked a bit differently ... well, make
-library- code.

I have no objection of having something like for each ppc_md field
called X, having a utility file providing an mpc52xx_generic_X function.
Such a board could then basically have a small .c file whose ppc_md just
use the generic functions for all except the ones that need to be
hooked/wrapped/replaced/whatever.

In fact, if you start from the first approach, and then decide that you
need to split off board XXX, it's legit to move some of board XXX ppc_md
functions to such a library if you believe they can be of use to a few
other boards, try to be a bit creative with the name tho :-)

It's then just a matter of doing the right Kconfig select of
non-user-visible options for your board support to build in the right
libraries it needs.

Ben.

Re: Board level compatibility matching

[Jon Smirl]

On 8/1/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
>  > On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
>  > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
>  > >  > On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
>
> [snip]
>
> > >  > That is what I'm doing now. But it requires every board to add a file
>  > >  > to arch/powerpc/platforms.  Can we have some common code to make the
>  > >  > fabric device? Can it be an OF device instead of a platform one? An OF
>  > >  > device could be compatible with boardname-fabric, generic-fabric. That
>  > >  > allows a stub fabric driver to always bind.
>  > >
>  > >
>  > > There are several ways to do this, and which is the most sensible
>  > >  depends on the specific design, and whether / how many boards the
>  > >  design is shared amongst.
>  > >
>  > >  In some cases it's suitable to have a "fake" device node for the sound
>  > >  wiring, to which a fabric driver can bind.  I think I've argued
>  > >  against this approach in the past, but I've since been convinced that
>  > >  it is a reasonable approach for some situations.  There's precedent,
>  > >  too, a number of Apple device trees do this.
>  > >
>  > >  In other cases it may be possible to deduce the correct fabric driver
>  > >  from the interconnections of individual sound components.
>  > >
>  > >  In yet others, we need board-specific platform code to instantiate the
>  > >  fabric driver.  In some cases that's simply the most straightforward
>  > >  way to do things.  In others it's not ideal, but we can use it as a
>  > >  fallback technique because deployed device trees simply don't have
>  > >  sufficient information in other places to use another approach.
>  > >
>  > >  There doesn't have to be One True Method for doing this.
>  >
>  > We're running into a need for the true method. With ALSA you need to
>  > have the codec driver, i2s/ac97 driver and the fabric driver all load
>  > and say here I am before ALSA can finish binding. ALSA won't complete
>  > initializing on boards without all three.
>  >
>  > So what do you do on board that doesn't need a fabric driver? That's
>  > why you want the fake device with the compatible string =
>  > board-fabric, noop-fabric. Now you know for sure one of those two
>  > drivers will bind.
>
>
> No... that would be exactly my example of a case where instantiating
>  the fabric driver from the platform code isn't ideal, but is a usable
>  fallback option.
>
>
>  > Why does the fake fabric device need to be in the device tree? Can't
>  > we just dynamically create it as part of the boot process?
>
>
> Um.. yes.. that would be exactly what instantiating it from the
>  platform code does.

Platform devices are missing the compatible chain process. If we do
this with platform drivers the boot code creates a 'fabric' device
then I'll have to ensure that my board-fabric driver gets probed
before default-fabric because they both want to bind to the fabric
device.

I can do this, but building ordering dependencies like this is not the
most robust way to do things. With an OF device the ordering is
obvious via the compatible attribute.


>
>
>  --
>  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
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Board level compatibility matching

[David Gibson]

On Fri, Aug 01, 2008 at 12:37:25AM -0400, Jon Smirl wrote:
> On 8/1/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
> >  > On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> >  > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> >  > >  > On 7/31/08, David Gibson <david@gibson.dropbear.id.au> wrote:
[snip]
> >  > Why does the fake fabric device need to be in the device tree? Can't
> >  > we just dynamically create it as part of the boot process?
> >
> >
> > Um.. yes.. that would be exactly what instantiating it from the
> >  platform code does.
> 
> Platform devices are missing the compatible chain process. If we do
> this with platform drivers the boot code creates a 'fabric' device
> then I'll have to ensure that my board-fabric driver gets probed
> before default-fabric because they both want to bind to the fabric
> device.

If you need a board-specific fabric driver, the board platform code
shouldn't be instantiating the generic fabric driver.  Given the board
specific driver a different name...

-- 
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

Re: Board level compatibility matching

[Josh Boyer]

On Fri, 01 Aug 2008 14:25:39 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chrp we have
> and do things differently etc...
> 
> NOT HAPPENING.
> 
> Now, there are two approaches here that are possible:
> 
>  - Your board is really pretty much exactly the same as board XXX,
> except maybe you have a different flash size or such, and the support
> for board XXX can cope perfectly with it simply due to the device-tree
> the right information.
> 
> If that happens to be the case, make your board compatible with board
> XXX. Make that entry -second- in your compatible list, because one day
> you'll figure out that there -is- indeed a difference and I don't want
> to see board XXX code start to grow code to recognise your other board
> and work around the difference. So at that stage, copy board XXX.c file
> and start over with your own board support that matches on your first
> compatible propery entry.

44x does this today for a small number of boards.  The "issue", if
there really is one, is that there's no clear definition on what is
acceptable to be called "compatible".  If _Linux_ platform support for
board FOO
> 
>  - Once you figure out that really, those 5 boards here -do- share 99%
> of the code... it's just that one need a workaround at the IRQ fixup
> level, maybe one needs a tweak on a GPIO at boot and one has an issue on
> reboot that needs to be whacked a bit differently ... well, make
> -library- code.
> 
> I have no objection of having something like for each ppc_md field
> called X, having a utility file providing an mpc52xx_generic_X function.
> Such a board could then basically have a small .c file whose ppc_md just
> use the generic functions for all except the ones that need to be
> hooked/wrapped/replaced/whatever.

This is sort of the part that sucks.  Look at 44x.  There are 10
board.c files there.  There really only needs to be 3 or 4 (sam440ep,
warp, virtex, and "generic") because the board files are identical in
everything except name. By doing the library code approach, one still
has to create a board.c file for a new board and plug in the library
functions to ppc_md.

Alternatively, you could do the:

compatible = "specific-board", "similar-board"

approach that has been done for e.g. Bamboo and Yosemite.  Again, the
issue is that is that OK?  Is it OK for a board to claim compatibility
with another board when it might not have all the devices of that
board, or might have additional devices, etc.  I was of the opinion
it is, and the device tree handles this just fine, as does the platform
code. But it can be confusing, hence the discussion here.

josh

Re: Board level compatibility matching

[Josh Boyer]

On Fri, 2008-08-01 at 08:06 -0400, Josh Boyer wrote:
> On Fri, 01 Aug 2008 14:25:39 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > About this whole generic board mumbo-jumbo: not happening. It's a pipe
> > dream, it doesn't work, and it leads to the sort of mess we have in chrp
> > where we end up having hacks to identify what exact sort of chrp we have
> > and do things differently etc...
> > 
> > NOT HAPPENING.
> > 
> > Now, there are two approaches here that are possible:
> > 
> >  - Your board is really pretty much exactly the same as board XXX,
> > except maybe you have a different flash size or such, and the support
> > for board XXX can cope perfectly with it simply due to the device-tree
> > the right information.
> > 
> > If that happens to be the case, make your board compatible with board
> > XXX. Make that entry -second- in your compatible list, because one day
> > you'll figure out that there -is- indeed a difference and I don't want
> > to see board XXX code start to grow code to recognise your other board
> > and work around the difference. So at that stage, copy board XXX.c file
> > and start over with your own board support that matches on your first
> > compatible propery entry.
> 
> 44x does this today for a small number of boards.  The "issue", if
> there really is one, is that there's no clear definition on what is
> acceptable to be called "compatible".  If _Linux_ platform support for
> board FOO

Ignore that last line.  Emailing before coffee is considered dangerous.

josh

Re: Board level compatibility matching

[Grant Likely]

On Thu, Jul 31, 2008 at 10:25 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chrp we have
> and do things differently etc...

I am fully aware of the hell and hacks that went along with chrp.  I
am *not* suggesting a do everything platform that must figure out all
the quirks of a board in a single machine definition.  I know too well
that is the way of pain.

>
> NOT HAPPENING.
>
> Now, there are two approaches here that are possible:
>
>  - Your board is really pretty much exactly the same as board XXX,
> except maybe you have a different flash size or such, and the support
> for board XXX can cope perfectly with it simply due to the device-tree
> the right information.
>
> If that happens to be the case, make your board compatible with board
> XXX. Make that entry -second- in your compatible list, because one day
> you'll figure out that there -is- indeed a difference and I don't want
> to see board XXX code start to grow code to recognise your other board
> and work around the difference. So at that stage, copy board XXX.c file
> and start over with your own board support that matches on your first
> compatible propery entry.

I agree with most of your argument, except I really have problems with
boards claiming compatibility with an older board.  My reason is
exactly the reason you state; One day you'll figure out that there is
indeed a difference.  The problem is; when the original board (the one
others are claiming compatibility with) gains additional code to fixup
quirks or something, then that code will get changed with no
visibility that it is borking up other boards that are currently
depending on it.

I far prefer the solution I'm currently using in 5200-land where there
is a simple (boring?) board port which *explicitly* states which
boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c).
 When someone goes to modify that file, it is explicit that it
currently supports multiple boards.  If a board becomes 'non-boring',
then it is removed from the simple platform; the simple platform is
*not* extended to accommodate it.

I *fully* agree that it is insane for the code to grow detection logic
and I've been explicit about not doing anything of the sort in 5200
land.  What I am suggesting is that if nothing else claims the board,
then allow the simple platform to bind against it based on the fact
that it uses the same SoC.

However, if I can't get concensus on this approach, then I do /not/
want to go to a boards compatible with other boards scheme.  It will
cause breakage and pain that is non-obvious to debug for many users.

BTW, I am also not suggesting that the .dts files themselves try to
claim some kind of 'generic' compatibility.  I'm proposing handling
any catch-all cases in the Linux code itself, where it is easy to
change because it is just an implementation detail.  Trying to make
the dt 'generic' doesn't make any sense because doing so is almost
always wrong (or will become wrong in the future).

>  - Once you figure out that really, those 5 boards here -do- share 99%
> of the code... it's just that one need a workaround at the IRQ fixup
> level, maybe one needs a tweak on a GPIO at boot and one has an issue on
> reboot that needs to be whacked a bit differently ... well, make
> -library- code.
>
> I have no objection of having something like for each ppc_md field
> called X, having a utility file providing an mpc52xx_generic_X function.
> Such a board could then basically have a small .c file whose ppc_md just
> use the generic functions for all except the ones that need to be
> hooked/wrapped/replaced/whatever.

I agree.  5200 code already does this.

g.

Re: Board level compatibility matching

[Grant Likely]

On Fri, Aug 1, 2008 at 6:06 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Fri, 01 Aug 2008 14:25:39 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> About this whole generic board mumbo-jumbo: not happening. It's a pipe
>> dream, it doesn't work, and it leads to the sort of mess we have in chrp
>> where we end up having hacks to identify what exact sort of chrp we have
>> and do things differently etc...
>>
>> NOT HAPPENING.
>>
>> Now, there are two approaches here that are possible:
>>
>>  - Your board is really pretty much exactly the same as board XXX,
>> except maybe you have a different flash size or such, and the support
>> for board XXX can cope perfectly with it simply due to the device-tree
>> the right information.
>>
>> If that happens to be the case, make your board compatible with board
>> XXX. Make that entry -second- in your compatible list, because one day
>> you'll figure out that there -is- indeed a difference and I don't want
>> to see board XXX code start to grow code to recognise your other board
>> and work around the difference. So at that stage, copy board XXX.c file
>> and start over with your own board support that matches on your first
>> compatible propery entry.
>
> 44x does this today for a small number of boards.  The "issue", if
> there really is one, is that there's no clear definition on what is
> acceptable to be called "compatible".  If _Linux_ platform support for
> board FOO

As stated in my previous email; I dislike this approach.  I far prefer
making the board support code provide an explicit list rather than
trying to define what it means for one board to be compatible with
another.

>> I have no objection of having something like for each ppc_md field
>> called X, having a utility file providing an mpc52xx_generic_X function.
>> Such a board could then basically have a small .c file whose ppc_md just
>> use the generic functions for all except the ones that need to be
>> hooked/wrapped/replaced/whatever.
>
> This is sort of the part that sucks.  Look at 44x.  There are 10
> board.c files there.  There really only needs to be 3 or 4 (sam440ep,
> warp, virtex, and "generic") because the board files are identical in
> everything except name. By doing the library code approach, one still
> has to create a board.c file for a new board and plug in the library
> functions to ppc_md.
>
> Alternatively, you could do the:
>
> compatible = "specific-board", "similar-board"
>
> approach that has been done for e.g. Bamboo and Yosemite.  Again, the
> issue is that is that OK?  Is it OK for a board to claim compatibility
> with another board when it might not have all the devices of that
> board, or might have additional devices, etc.  I was of the opinion
> it is, and the device tree handles this just fine, as does the platform
> code. But it can be confusing, hence the discussion here.

I say no [but you already know that. :-) ]

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Board level compatibility matching

[Josh Boyer]

On Fri, 1 Aug 2008 08:27:41 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:

> > NOT HAPPENING.
> >
> > Now, there are two approaches here that are possible:
> >
> >  - Your board is really pretty much exactly the same as board XXX,
> > except maybe you have a different flash size or such, and the support
> > for board XXX can cope perfectly with it simply due to the device-tree
> > the right information.
> >
> > If that happens to be the case, make your board compatible with board
> > XXX. Make that entry -second- in your compatible list, because one day
> > you'll figure out that there -is- indeed a difference and I don't want
> > to see board XXX code start to grow code to recognise your other board
> > and work around the difference. So at that stage, copy board XXX.c file
> > and start over with your own board support that matches on your first
> > compatible propery entry.
> 
> I agree with most of your argument, except I really have problems with
> boards claiming compatibility with an older board.  My reason is
> exactly the reason you state; One day you'll figure out that there is
> indeed a difference.  The problem is; when the original board (the one
> others are claiming compatibility with) gains additional code to fixup
> quirks or something, then that code will get changed with no
> visibility that it is borking up other boards that are currently
> depending on it.

There is that possibility yes.  And it is even non-theoretical to a
degree, as the situation may occur with the existing Bamboo/Yosemite
scenario when we get around to fixing up the horror that is the EBC on
Bamboo.  Admittedly, a single person did both those ports so the
inherent knowledge is already there, but that won't always be the case.

> I far prefer the solution I'm currently using in 5200-land where there
> is a simple (boring?) board port which *explicitly* states which
> boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c).
>  When someone goes to modify that file, it is explicit that it
> currently supports multiple boards.  If a board becomes 'non-boring',
> then it is removed from the simple platform; the simple platform is
> *not* extended to accommodate it.

To me, the solution you are using there seems like the best compromise
between the various options.  It allows a common "board".c (or
platform) file in the kernel, while still adhering to a form of purity
in the device tree itself.  The only slightly annoying issue is the
need to change the explicit list, but I don't consider that a burden
really.

If you haven't noticed, my primary reason for wanting to do _something_
is to prevent the proliferation of code duplication that we've seen.
Cleanup time is in order, and this is the most expedient and seemingly
correct way of doing things.

> I *fully* agree that it is insane for the code to grow detection logic
> and I've been explicit about not doing anything of the sort in 5200
> land.  What I am suggesting is that if nothing else claims the board,
> then allow the simple platform to bind against it based on the fact
> that it uses the same SoC.
> 
> However, if I can't get concensus on this approach, then I do /not/
> want to go to a boards compatible with other boards scheme.  It will
> cause breakage and pain that is non-obvious to debug for many users.

I think there is too much momentum behind the old method, and not a
clear enough definition on how one would bind to a generic SoC without
dealing with things like link order, etc.  Also, not every platform has
SoC nodes (as you already pointed out), and adding them to the DTS
files (or adding a new property or binding to the CPU node, etc) for
this purpose seems to be both overkill and contrary to not wanting to
break existing products out there that use the old DTS files and method.
They should be few in number, but they do exist (see PIKA Warp).

I'm growing very much of the opinion that the way you are _currently_
handling 52xx is more or less the way we should go.

josh

Re: Board level compatibility matching

[M. Warner Losh]

I'd float a radical definition of 'compatible' here.

If the generic code can handle it with just changes to the device
tree, then it is compatible.  And by generic code, I wouldn't suggest
a twisty maze of ifdefs or special case hacks.  I'm talking truly
generic code that is table driven entirely from the dtc.  If you need
special C code to initialize the board, then it isn't compatible.

This is exactly analogous to the pc-net driver supporting dozens of
different cards that differ only in their ID.  Are all these cards
100% the same: no.  There's plenty of differences between them.
However, the pc-net driver copes with the small differences so that
one driver can handle most of the ne2000 class of network cards.

Are there special drivers for ne2000-like cards that aren't quite
compatible enough or have extra features, sure.

That doesn't totally invalidate the utility.  There are always
engineering trade offs to be made.

Warner

Re: Board level compatibility matching

[Grant Likely]

On Fri, Aug 1, 2008 at 10:01 AM, M. Warner Losh <imp@bsdimp.com> wrote:
> I'd float a radical definition of 'compatible' here.
>
> If the generic code can handle it with just changes to the device
> tree, then it is compatible.  And by generic code, I wouldn't suggest
> a twisty maze of ifdefs or special case hacks.  I'm talking truly
> generic code that is table driven entirely from the dtc.  If you need
> special C code to initialize the board, then it isn't compatible.

When doing the initial board port, you don't *know* if you're going to
need special cases.  Or, you don't know if the special case code
belongs in the platform code, or belongs somewhere else
(implementation detail).  Or, the special code could get refactored in
the future and be moved into or out of the platform code.

Claiming one board is compatible with another tends to just encode a
Linux implementation detail into the device tree.

> This is exactly analogous to the pc-net driver supporting dozens of
> different cards that differ only in their ID.  Are all these cards
> 100% the same: no.  There's plenty of differences between them.
> However, the pc-net driver copes with the small differences so that
> one driver can handle most of the ne2000 class of network cards.

Yes, and we use lists of compatible values for devices.  However, the
board level has much higher complexity.  The likelyhood of getting it
wrong is much greater.

g.

Re: Board level compatibility matching

[Benjamin Herrenschmidt]

> This is sort of the part that sucks.  Look at 44x.  There are 10
> board.c files there.  There really only needs to be 3 or 4 (sam440ep,
> warp, virtex, and "generic") because the board files are identical in
> everything except name. By doing the library code approach, one still
> has to create a board.c file for a new board and plug in the library
> functions to ppc_md.

And ? How is that a big deal ? Real products (ie not eval boards, and
even those ...) will probably end up needing that due to subtle
differences anyway.

> Alternatively, you could do the:
> 
> compatible = "specific-board", "similar-board"
> 
> approach that has been done for e.g. Bamboo and Yosemite.  Again, the
> issue is that is that OK?  Is it OK for a board to claim compatibility
> with another board when it might not have all the devices of that
> board, or might have additional devices, etc.  I was of the opinion
> it is, and the device tree handles this just fine, as does the platform
> code. But it can be confusing, hence the discussion here.

Well, as I said. If it stops being ok, just create your own board
and it will take over provided you put it before the other one in
the link order.

If we generalize that approach, we might want to change the board
probing code a bit to first do a full pass based on the first
entry in compatible, then another full pass based on the second, etc...

Ben.

Re: Board level compatibility matching

[Benjamin Herrenschmidt]

On Fri, 2008-08-01 at 08:27 -0600, Grant Likely wrote:
> 
> I agree with most of your argument, except I really have problems with
> boards claiming compatibility with an older board.  My reason is
> exactly the reason you state; One day you'll figure out that there is
> indeed a difference.  The problem is; when the original board (the one
> others are claiming compatibility with) gains additional code to fixup
> quirks or something, then that code will get changed with no
> visibility that it is borking up other boards that are currently
> depending on it.

Then just use your own .c file. It's not like it was a big deal.

I don't know why it's -so- appealing to not have to do one at all.

> I far prefer the solution I'm currently using in 5200-land where there
> is a simple (boring?) board port which *explicitly* states which
> boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c).
>  When someone goes to modify that file, it is explicit that it
> currently supports multiple boards.  If a board becomes 'non-boring',
> then it is removed from the simple platform; the simple platform is
> *not* extended to accommodate it.

As long as you stick to -never- extend the simple platform to accomodate
for a variant, then I suppose that's ok I suppose, though that does
raise the point of what to put in the compatible property.

> I *fully* agree that it is insane for the code to grow detection logic
> and I've been explicit about not doing anything of the sort in 5200
> land.  What I am suggesting is that if nothing else claims the board,
> then allow the simple platform to bind against it based on the fact
> that it uses the same SoC.

See my comment in my reply to Josh about changing the board probe into a
multi-pass probe so that first, we only match on the first entry of the
compatible property, then we match on the second, etc... to go from more
specific to less specific.

> However, if I can't get concensus on this approach, then I do /not/
> want to go to a boards compatible with other boards scheme.  It will
> cause breakage and pain that is non-obvious to debug for many users.

As far as I'm concerned, this approach is mostly useful for revisions of
a board. Oh and I'm not going to whack you with a stick if in the end,
you do have a little bit of variation in a single board .c file to deal
with a glitch in rev. C of the board that wired something backward for
example ... it's a matter of perspective. But I would prefer a different
board (from a different vendor for example) to use a different .c file
even if it only differs by the same little glitch.

> BTW, I am also not suggesting that the .dts files themselves try to
> claim some kind of 'generic' compatibility.  I'm proposing handling
> any catch-all cases in the Linux code itself, where it is easy to
> change because it is just an implementation detail.  Trying to make
> the dt 'generic' doesn't make any sense because doing so is almost
> always wrong (or will become wrong in the future).

The problem is that I don't see a sane way to do the catch all in the
linux code, other than explicitely doing what you already do which is to
list all supported boards in the simple platform. It's either that or
adding some compatible "socname,linux-simple" or so property in
your .dts. I don't believe matching on SoC is of any use. It will
incorrectly try to match things that don't work and that's bad.

Ben.

Re: Board level compatibility matching

[Josh Boyer]

On Sat, 02 Aug 2008 08:48:23 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> > This is sort of the part that sucks.  Look at 44x.  There are 10
> > board.c files there.  There really only needs to be 3 or 4 (sam440ep,
> > warp, virtex, and "generic") because the board files are identical in
> > everything except name. By doing the library code approach, one still
> > has to create a board.c file for a new board and plug in the library
> > functions to ppc_md.
> 
> And ? How is that a big deal ? Real products (ie not eval boards, and
> even those ...) will probably end up needing that due to subtle
> differences anyway.

I didn't say it was a big deal.  But I also think it's pretty pointless
to carry around a bunch of C files that have to get the same set of
fixes across the board when updated because they really only differ by
the function names. Particularly when you could just have one C file
with a list of supported boards.

As I said, to me this is about cleanup and maintenance.  I totally
agree that truly custom boards (e.g. actual products) will likely
require different board.c files and that's just fine with me.  I'm just
looking for the best approach to cleanup the ones that don't need to
be, and the explicit list seems to be that way.

> > Alternatively, you could do the:
> > 
> > compatible = "specific-board", "similar-board"
> > 
> > approach that has been done for e.g. Bamboo and Yosemite.  Again, the
> > issue is that is that OK?  Is it OK for a board to claim compatibility
> > with another board when it might not have all the devices of that
> > board, or might have additional devices, etc.  I was of the opinion
> > it is, and the device tree handles this just fine, as does the platform
> > code. But it can be confusing, hence the discussion here.
> 
> Well, as I said. If it stops being ok, just create your own board
> and it will take over provided you put it before the other one in
> the link order.
> 
> If we generalize that approach, we might want to change the board
> probing code a bit to first do a full pass based on the first
> entry in compatible, then another full pass based on the second, etc...

I don't care much either way.  I guess I'd rather avoid relying on
strict link order to do the probing right, if only because a simple
mistake can break things.

There might not be a "one true way", but Grant and I thought it
pertinent to bring up a discussion in case there was a "very wrong
way", that's all.

josh