[PATCH] powerpc: consolidate mpc83xx platform files
Kim Phillips
kim.phillips at freescale.com
Wed Dec 13 09:38:03 EST 2006
On Tue, 12 Dec 2006 16:28:38 -0600
Kumar Gala <galak at 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 at 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
More information about the Linuxppc-dev
mailing list