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

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

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

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.

I've yet to see anything that describes any real value to a customer.

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.

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.

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?

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.

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.

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

I'd rather see people spending time on problems which need solutions =20
and this isn't one of them.

- k=