From: Grant Likely <hidden> Date: 2008-07-31 20:19:57
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.
From: Chris Friesen <hidden> Date: 2008-07-31 20:39:21
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
From: David Gibson <hidden> Date: 2008-08-01 02:54:39
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
From: Grant Likely <hidden> Date: 2008-08-01 03:25:33
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:
quoted
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.
quoted
- 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.
From: David Gibson <hidden> Date: 2008-08-01 03:38:03
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:
quoted
On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
[snip]
quoted
quoted
- 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.
quoted
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.
quoted
quoted
- 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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-08-01 04:25:39
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.
On Fri, 01 Aug 2008 14:25:39 +1000
Benjamin Herrenschmidt [off-list ref] 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
From: Grant Likely <hidden> Date: 2008-08-01 14:30:48
On Fri, Aug 1, 2008 at 6:06 AM, Josh Boyer [off-list ref] wrote:
On Fri, 01 Aug 2008 14:25:39 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
quoted
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.
quoted
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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-08-01 22:48:23
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.
On Sat, 02 Aug 2008 08:48:23 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
quoted
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.
quoted
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
From: Grant Likely <hidden> Date: 2008-08-01 14:27:41
On Thu, Jul 31, 2008 at 10:25 PM, Benjamin Herrenschmidt
[off-list ref] 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.
On Fri, 1 Aug 2008 08:27:41 -0600
"Grant Likely" [off-list ref] wrote:
quoted
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
From: M. Warner Losh <hidden> Date: 2008-08-01 16:01:07
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
From: Grant Likely <hidden> Date: 2008-08-01 16:24:58
On Fri, Aug 1, 2008 at 10:01 AM, M. Warner Losh [off-list ref] 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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-08-01 22:54:43
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.