+ edac-cpc925-mc-platform-device-setup.patch added to -mm tree

[Michael Ellerman]

On Thu, 2009-04-16 at 09:57 +0800, Harry Ciao wrote:
> Kumar Gala wrote:
> > On Apr 15, 2009, at 5:27 PM, akpm at linux-foundation.org wrote:
> >> arch/powerpc/kernel/prom_init.c      |   33 +++++++++++++
> >> arch/powerpc/platforms/maple/setup.c |   59 +++++++++++++++++++++++++
> >> 2 files changed, 92 insertions(+)
> >>
> >> diff -puN 
> >> arch/powerpc/kernel/prom_init.c~edac-cpc925-mc-platform-device-setup 
> >> arch/powerpc/kernel/prom_init.c
> >> --- 
> >> a/arch/powerpc/kernel/prom_init.c~edac-cpc925-mc-platform-device-setup
> >> +++ a/arch/powerpc/kernel/prom_init.c
> >> @@ -1947,8 +1947,40 @@ static void __init fixup_device_tree_map
> >>     prom_setprop(isa, name, "ranges",
> >>             isa_ranges, sizeof(isa_ranges));
> >> }
> >> +
> >> +#define CPC925_MC_START        0xf8000000
> >> +#define CPC925_MC_LENGTH    0x1000000
> >> +/* The values for memory-controller don't have right number of cells */
> >> +static void __init fixup_device_tree_maple_memory_controller(void)
> >> +{
> >
> > I don't see why this cant be part of the existing 
> > fixup_device_tree_maple().
> >
> > I also find it odd we don't ensure we are running on a maple before we 
> > apply this fixup.

> Hi Kumar,
> 
> Thanks a lot for your concern.
> 
> This newly added fixup for memory controller on Maple will be placed 
> right after fixup_device_tree_maple(), both of them will be controlled 
> by CONFIG_PPC_MAPLE, so there is no worry that it will be applied 
> against anything other than Maple.

Hi Harry,

We regularly build a single kernel with multiple platforms enabled, so
just having it controlled by a CONFIG symbol is not sufficient. Someone
might build a kernel for MAPLE & PSERIES & ISERIES & CELL, so the maple
fixup needs to be careful it doesn't break the other platforms.

The existing maple fixup doesn't check if it's on a maple either, but it
is a bit more discerning about what it finds before it fixes things up.

Your code already checks that "reg" is 8 bytes long to start with, I
think if it also checks that #address-cells and #size-cells are == 2,
then it's pretty safe. Because at that point we know we have a node with
the right name, the reg property has a known value, and reg is short WRT
#cells.

> Meanwhile, it aims at fixup bad cell numbers for the memory controller, 
> whereas the original fixup_device_tree_maple() aiming at fixing up the 
> ISA controller on HT channel, we'd better separate them in different 
> function IMHO.

I think I agree it's better as a separate routine. We could have a
firmware that doesn't need the original maple fixup (and so exits from
that routine early) but does need this one.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090416/444fd7cb/attachment.pgp>