[PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc
Kumar Gala
galak at kernel.crashing.org
Tue May 15 06:10:04 EST 2007
On May 14, 2007, at 2:30 PM, Andrew Morton wrote:
> On Mon, 14 May 2007 08:56:52 -0500
> Kumar Gala <galak at kernel.crashing.org> wrote:
>
>> On May 14, 2007, at 6:06 AM, Sam Ravnborg wrote:
>>
>>> On Mon, May 14, 2007 at 06:53:32PM +0800, Li Yang wrote:
>>>> This patch fixes the following "Section mismatch" warnings when
>>>> build powerpc platforms.
>>>>
>>>> -------------
>>>> WARNING: arch/powerpc/mm/built-in.o - Section mismatch:
>>>> reference to
>>>> .init.text:early_get_page from .text between
>>>> 'pte_alloc_one_kernel' (at
>>>> offset 0xc68) and 'pte_alloc_one'
>>>> WARNING: mm/built-in.o - Section mismatch: reference to
>>>> .init.text:set_up_list3s from .text between
>>>> 'kmem_cache_create' (at offset
>>>> 0x20300) and 'cache_reap'
>>>> -------------
>>
>> This warnings should be handled by __init_refok instead.
>>
>
> Yes, I think so.
>
>>
>>>> Massive warnings represented by:
>>>> -------------
>>>> WARNING: arch/powerpc/kernel/built-in.o - Section mismatch:
>>>> reference to
>>>> .init.data:.got2 from prom_entry (offset 0x0)
>>>> WARNING: arch/powerpc/platforms/built-in.o - Section mismatch:
>>>> reference to
>>>> .init.text:mpc8313_rdb_probe from .machine.desc after
>>>> 'mach_mpc8313_rdb'
>>>> (at offset 0x4)
>>>> -------------
>>>>
>>>> Signed-off-by: Li Yang <leoli at freescale.com>
>>> Acked-by: Sam Ravnborg <sam at ravnborg.org>
>
> I always get confused when a git-tree-owner says "acked-by" against
> a patch
> which falls within his tree's area. An acked-by would mean "I'm OK
> with
> the patch, please apply it". But I'd have expected to see a "thanks,
> applied" instead.
>
> If it was "Andrew: please merge and send to Linus because it's
> urgent and I
> can't be bothered setting up a git pull for it" then fine, but
> please be
> explicit about that.
I'd prefer to handle the ppc specific bits through the powerpc.git
since they are only warnings and we should be able to fix them up for
the next 2.6.22-rc unless Linus is on a made dash to get 2.6.22 out
faster than any previous release :)
- k
More information about the Linuxppc-dev
mailing list