Re: [PATCH] powerpc: consolidate mpc83xx platform files

On Wed, 13 Dec 2006 00:07:43 -0600
Kumar Gala [off-list ref] wrote:

=20
On Dec 12, 2006, at 11:25 PM, Geoff Thorpe wrote:
=20

quoted

Kumar Gala wrote:

quoted

It adds code to all those people that don't need it just so we =20
don't  duplicate a few lines of source code.

Sounds like you're describing the raison d'=EAtre for device-trees =20
though? After all, if you want to build a kernel that supports =20
these minor h/w variations depending on the device-tree it's booted =20
with, then the "few lines of duplicated source code" you're talking =20
about would also "add code to all those people that don't need it".

=20
No, because those people (myself included) wouldn't build in support =20
for the freescale referend boards into the kernel I'm building for my =20
custom board.

my understanding is that embedded developers would *add* code to the generi=
c platform code base that this exercise proves exists.

=20
My question has been what's the value in trying to save a few lines =20
of code for the reference boards.  The idea of a generic board =20
doesn't make sense in the embedded space.  Just because the reference =20
boards for mpc83xx look similar doesn't mean anything else using it =20
will.  I know both of the boards I've worked would and still do =20
require custom code.

the boards aren't that similar, it's just that all board specific code has =
actually migrated to the right place for it; it now goes where it belongs, =
e.g. RTCs go to the RTC subsystem, PHYs go the PHY layer, etc.

=20
The reason for the custom code is the device tree doesn't describe =20
all variants of all hardware.  Its just not spec'd that far. How do =20
you describe the FPGA and local bus interface to it on my board? How =20
do you describe the compact flash drive on localbus?  How do you =20
describe the microcontroller connect over SPI?  You dont because =20
there isn't any spec.  The majority of developers dont have the time =20
to spend trying to come up with one to solve their specific problem =20
so they hard code some solution that works for them.

this has always been the case, and we're not changing that. You can still a=
dd code to support unspec'ed functionality. We're just trying to refactor t=
he code for its obvious benefits.

=20
Over time will we improve the spec, it will cover more cases and =20
that's great, but trying to come up with some generic board port =20
right now is a waste of time.  There are a ton of better things to be =20
spending your guys time on.
=20
I've yet to see anything that describes any real value to a customer.

The ability to have a single kernel run on multiple boards is of value, esp=
. if the only thing preventing that from happening is a strcmp between a ke=
rnel string and a string in the dt (both software sources).

=20

quoted

Kumar Gala also wrote:

quoted

On Dec 12, 2006, at 4:41 PM, Scott Wood wrote:

quoted

And an 83xx-generic machine description does not stop them from  =20
doing so.  "Generic" does not mean "universal".  It means =20
"there's  nothing special about this board".  If you need board-=20
specific code  in the kernel, then don't label it generic.

But what value does this have?  83xx, and the majority of =20
freescale's  devices are not put into something as standard as a =20
desktop computer.

Then what value do device-trees have at all? Why require new code =20
for new h/w if it's technically unnecessary? If I've understood =20
correctly (I confess to not having followed all of the discussion =20
nor the finer technical points), this would require new code to =20
find its way "upstream" (to whoever/wherever/whatever that means) =20
from freescale and then downstream to it's user before the h/w is =20
supported, when this situation is precisely what device-trees =20
apparently ought to resolve.

=20
This is partial true, but if freescale puts out a new processor/board =20
there is some expectation that its going to require some new code.  =20
If nothing else it's going to require a device-tree be provided.  If =20
the concern is about how long it takes to support new HW for existing =20
functionality I think that's BS.
=20

I don't think it's that, my problem is the redundancy in the code. I wanted=
 it gone before we added more :)

quoted

Maybe I'm missing something (quite possible). Ben's objection =20
seemed to be one of naming, but yours seems to be that new h/w =20
should require new code because it's not wintel fodder for desktop =20
grannies? So why bother separating h/w description from the =20
compiled kernel in the first place?

=20
My argument is that trying to describe all HW variants for embedded =20
systems in the device tree is never going to happen.  Describing the =20
generality of devices on SoC is useful because everyone has to deal =20
with that.  Once you start going past that you get into trouble =20
because of all the various ways people hook things up to busses.

but this patch isn't claiming to do that.  It doesn't stop providing a base=
 to start from.

There are a number of subtle reasons I think a generic port is =20
pointless and the only arguments I've heard are some concern about =20
duplication of code and the ability to boot a kernel w/o modification =20
on new HW.

yes, and those are indeed valid points.  I for one, have access to multiple=
 83xx based boards and would love to not have to build a kernel that has on=
e text in a string preventing it from booting on another.

The duplication code I believe is a style issue and we can reduce the =20
duplication to a minimum.  The ability to boot a kernel w/o =20
modification on new HW is a nice to have, but I dont see this as =20
providing any "real value".
=20
I'd rather see people spending time on problems which need solutions =20
and this isn't one of them.
=20

sorry, this redundancy has been going on for too long.  I brought this issu=
e up a long time ago on this list asking for your opinion and got no respon=
se.  Now a new board is here.  So how long would you have us submit code ge=
nerated by sed?

Having said all that, I acknowledge your comments.  For now, I'm willing to=
 settle for at least one line of less redundant code than what's in the tre=
e today.  How can we make that happen?

Kim