Doug / smarc-fsl-linux-kernel

15 Jul, 2013

1 commit

  • 2066aadd5   sparc: delete __cpuinit/__CPUINIT usage from all users ... Browse Code »

    The __cpuinit type of throwaway sections might have made sense
    some time ago when RAM was more constrained, but now the savings
    do not offset the cost and complications. For example, the fix in
    commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
    is a good example of the nasty type of bugs that can be created
    with improper use of the various __init prefixes.

    After a discussion on LKML[1] it was decided that cpuinit should go
    the way of devinit and be phased out. Once all the users are gone,
    we can then finally remove the macros themselves from linux/init.h.

    Note that some harmless section mismatch warnings may result, since
    notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
    are flagged as __cpuinit -- so if we remove the __cpuinit from
    arch specific callers, we will also get section mismatch warnings.
    As an intermediate step, we intend to turn the linux/init.h cpuinit
    content into no-ops as early as possible, since that will get rid
    of these warnings. In any case, they are temporary and harmless.

    This removes all the arch/sparc uses of the __cpuinit macros from
    C files and removes __CPUINIT from assembly files. Note that even
    though arch/sparc/kernel/trampoline_64.S has instances of ".previous"
    in it, they are all paired off against explicit ".section" directives,
    and not implicitly paired with __CPUINIT (unlike mips and arm were).

    [1] https://lkml.org/lkml/2013/5/20/589

    Cc: "David S. Miller"
    Cc: sparclinux@vger.kernel.org
    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

01 Apr, 2013

1 commit

  • 54df2db36   sparc/srmmu: clear trailing edge of bitmap properly ... Browse Code »

    srmmu_nocache_bitmap is cleared by bit_map_init(). But bit_map_init()
    attempts to clear by memset(), so it can't clear the trailing edge of
    bitmap properly on big-endian architecture if the number of bits is not
    a multiple of BITS_PER_LONG.

    Actually, the number of bits in srmmu_nocache_bitmap is not always
    a multiple of BITS_PER_LONG. It is calculated as below:

    bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;

    srmmu_nocache_size is decided proportionally by the amount of system RAM
    and it is rounded to a multiple of PAGE_SIZE. SRMMU_NOCACHE_BITMAP_SHIFT
    is defined as (PAGE_SHIFT - 4). So it can only be said that bitmap_bits
    is a multiple of 16.

    This fixes the problem by using bitmap_clear() instead of memset()
    in bit_map_init() and this also uses BITS_TO_LONGS() to calculate correct
    size at bitmap allocation time.

    Signed-off-by: Akinobu Mita
    Cc: "David S. Miller"
    Cc: sparclinux@vger.kernel.org
    Signed-off-by: David S. Miller

    Akinobu Mita
     

27 Jul, 2012

7 commits

28 May, 2012

1 commit

23 May, 2012

1 commit

20 May, 2012

2 commits

16 May, 2012

1 commit

15 May, 2012

1 commit

14 May, 2012

7 commits

13 May, 2012

12 commits

12 May, 2012

6 commits