[PATCH] powerpc: consolidate mpc83xx platform files

[Kumar Gala]

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

> Kumar Gala wrote:
>
>> It adds code to all those people that don't need it just so we  
>> don't  duplicate a few lines of source code.
>>
>
> Sounds like you're describing the raison d'être for device-trees  
> though? After all, if you want to build a kernel that supports  
> these minor h/w variations depending on the device-tree it's booted  
> with, then the "few lines of duplicated source code" you're talking  
> 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  
for the freescale referend boards into the kernel I'm building for my  
custom board.

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

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

Over time will we improve the spec, it will cover more cases and  
that's great, but trying to come up with some generic board port  
right now is a waste of time.  There are a ton of better things to be  
spending your guys time on.

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

> Kumar Gala also wrote:
>
>> On Dec 12, 2006, at 4:41 PM, Scott Wood wrote:
>>
>>> And an 83xx-generic machine description does not stop them from   
>>> doing so.  "Generic" does not mean "universal".  It means  
>>> "there's  nothing special about this board".  If you need board- 
>>> specific code  in the kernel, then don't label it generic.
>>>
>>
>> But what value does this have?  83xx, and the majority of  
>> freescale's  devices are not put into something as standard as a  
>> desktop computer.
>
> Then what value do device-trees have at all? Why require new code  
> for new h/w if it's technically unnecessary? If I've understood  
> correctly (I confess to not having followed all of the discussion  
> nor the finer technical points), this would require new code to  
> find its way "upstream" (to whoever/wherever/whatever that means)  
> from freescale and then downstream to it's user before the h/w is  
> supported, when this situation is precisely what device-trees  
> apparently ought to resolve.

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

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

My argument is that trying to describe all HW variants for embedded  
systems in the device tree is never going to happen.  Describing the  
generality of devices on SoC is useful because everyone has to deal  
with that.  Once you start going past that you get into trouble  
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  
pointless and the only arguments I've heard are some concern about  
duplication of code and the ability to boot a kernel w/o modification  
on new HW.

The duplication code I believe is a style issue and we can reduce the  
duplication to a minimum.  The ability to boot a kernel w/o  
modification on new HW is a nice to have, but I dont see this as  
providing any "real value".

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

- k