Re: [PATCH] powerpc: consolidate mpc83xx platform files

[Kim Phillips <kim.phillips@freescale.com>]

On Tue, 12 Dec 2006 16:28:38 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> On Dec 12, 2006, at 4:24 PM, Kim Phillips wrote:
> 
> > On Tue, 12 Dec 2006 16:06:41 -0600
> > Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> >>
> >>> I do prefer the middle ground approach he (and you) proposed to
> >>> have an
> >>> "mpc83xx_generic" in the compatible property and match on that, but
> >>> I'm
> >>> not 100% certain we are really there yet and I would have been a bit
> >>> more comfortable limiting that to known fsl boards. But you are the
> >>> guys
> >>> to maintain those things, so do as you like there.
> >>
> >> I'm against the idea of "mpc83xx_generic" if they want to introduce a
> >> "mpc83xx_freescale" or "mpc83xx_fsl_generic" I'm fine with that, but
> >> there is not such thing as a "mpc83xx_generic".
> >
> > I took a look at the TQM8349 code, and it looks like it will be  
> > identical in the platform code space.  That would subtract the  
> > 'fsl' part from the equation.  How about 'mpc83xx_eval'?  btw, this  
> > would be taking us back to the original patch, which I like since I  
> > personally don't want to see one file per eval board (I could ifdef  
> > protect platforms in machdefs.c if that works for you).
> 
> What's the issue with a file per board if all it has is the ppc_md/ 
> define_machine() in it.  Someone explain to me why this is a bad thing?
> 
well it depends on what you do with the _probe()s.  If you have multiple define_machine definitions built in, the generic probe will always succeed to match on the first machine probe_machine() tests, which may or may not be the machine it's currently running on.

Kim