[PATCH] Do not inline putprops function

[Michael Ellerman]

On Fri, 2009-08-07 at 20:24 +0530, M. Mohan Kumar wrote:
> On Fri, Aug 07, 2009 at 08:05:49PM +0530, M. Mohan Kumar wrote:
> > Hi,
> > 
> > After enabling EARLY_DEBUG (and DEBUG in some of the files in
> > arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
> > byte alignment: 
> > 
> > # ./kexec -e
> > Starting new kernel
> > console [udbg0] enabled
> >  -> early_setup(), dt_ptr: 0x7723000
> >  -> early_init_devtree(c000000007723000)
> > Invalid tag 5 scanning flattened device tree !
> > search "chosen", depth: 0, uname:
> > Invalid tag 5 scanning flattened device tree !
> > dt_root_size_cells = 2
> > dt_root_addr_cells = 2
> > Invalid tag 5 scanning flattened device tree !
> > reserving: 128c000 -> 5ec1f7
> > reserving: 7734000 -> 8cc000
> > reserving: 7723000 -> f698
> > Phys. mem: 0
> > -> move_device_tree
> > <- move_device_tree
> > Scanning CPUs ...
> > Invalid tag 5 scanning flattened device tree !
> >  <- early_init_devtree()
> > Probing machine type ...
> >   pSeries ...
> > No suitable machine found !
> > 
> > 
> > So device-tree is getting corrupted when dtstruct variable is not aligned to
> > 8 byte variable. This problem is not seen with gcc-3.4. Is it compiler
> > issue? or bug in the code.
> > 
> 
> I tried writing the device tree to a binary file with and without dt_len and
> compared the files after hexdump:

That sounds like a good idea.

> 0000 0001 2f00 0000 0000 0003 0000 0004                 0000 0001 2f00 0000 0000 0003 0000 0004
> 0000 0000 0000 0002 0000 0003 0000 0004                 0000 0000 0000 0002 0000 0003 0000 0004
> 0000 000f 0000 0002 0000 0003 0000 0004                 0000 000f 0000 0002 0000 0003 0000 0004
> 0000 001b 3ef1 4800 0000 0003 0000 000d                 0000 001b 3ef1 4800 0000 0003 0000 000d
> 0000 002b 0000 0000 4942 4d2c 3931 3135               | 0000 002b 4942 4d2c 3931 3135 2d35 3035
> 2d35 3035 0000 0000 0000 0003 0000 0005               | 0000 0000 0000 0003 0000 0005 0000 0036

So the one on the left (which is ?) - has extra padding after 0x2b,
which is the property data length, before the property value
"IBM,9115-505". There shouldn't be any padding there.

cheers
-------------- 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/20090810/adef9351/attachment.pgp>