Platform numbers

[Benjamin Herrenschmidt]

> > No, they are not local. Think about kexec, and firmwares that directly
> > pass a flattened device-tree
> 
> Ok. But AIUI there isn't any firmware yet which does that? 

There is kexec already though, but changing Maple for now is probably
ok.

> So we could change 
> the MAPLE number now and get away with it?

Yes.

> > > Only challenge with going with bitmap is that the number of possible
> > > platforms are quite a bit lower, I'm not sure how quickly that will hurt
> > > us. We'll have other, bigger, headaches before we run out of platform
> > > bits anyway.
> >
> > Yes, but I think we should kill the platform number. We should replace
> > it with a "HV type" (native, iseries, rpa, xen, ...) and have the
> > ppc_md.probe() function use the device-tree to identify the platform.
> >
> > There are bits & pieces here or there that will need to be fixed for
> > that approach to work though. Like gross hacks in the interrupt tree
> > parsing.
> 
> We'd still have the problem that there's little bits of code outside of ppc_md 
> functions which uses the platform number to work out which platform it's on. 
> How would it check what platform it was on without the number?

That is the "bits & pieces" I'm talking about :) In most cases, testing
the platform number shouldn't be needed though.

> I also see we #define _machine (systemcfg->platform) for drivers?

Yes, for compatibility with ppc32 stuff that uses _machine, but again,
it should be possible to fix all of that by proper use of the
device-tree instead and/or adding things in ppc_md.

Ben.