Doug / smarc-fsl-linux-kernel

18 Jul, 2007

1 commit

  • 8dfd588c3   smp_call_function_single() should be a macro on UP ... Browse Code »

    ... or we end up with header include order problems from hell.

    E.g. on m68k this is 100% fatal - local_irq_enable() there
    wants preempt_count(), which wants task_struct fields, which
    we won't have when we are in smp.h pulled from sched.h.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

16 Jul, 2007

1 commit

17 May, 2007

1 commit

  • 79974a0e4   Let smp_call_function_single return -EBUSY on UP ... Browse Code »

    All architectures that have an implementation of smp_call_function_single
    let it return -EBUSY if it is asked to execute func on the current cpu.
    (akpm: except for x86_64). Therefore the UP version must always return
    -EBUSY.

    [akpm@linux-foundation.org: build fix]
    Signed-off-by: Heiko Carstens
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

10 May, 2007

1 commit

  • 2f4dfe206   Remove hardcoding of hard_smp_processor_id on UP systems ... Browse Code »

    With the advent of kdump, the assumption that the boot CPU when booting an UP
    kernel is always the CPU with a particular hardware ID (often 0) (usually
    referred to as BSP on some architectures) is not valid anymore. The reason
    being that the dump capture kernel boots on the crashed CPU (the CPU that
    invoked crash_kexec), which may be or may not be that particular CPU.

    Move definition of hard_smp_processor_id for the UP case to
    architecture-specific code ("asm/smp.h") where it belongs, so that each
    architecture can provide its own implementation.

    Signed-off-by: Fernando Luis Vazquez Cao
    Cc: "Luck, Tony"
    Acked-by: Andi Kleen
    Cc: "Eric W. Biederman"
    Cc: Vivek Goyal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Fernando Luis Vazquez Cao
     

08 Dec, 2006

1 commit

26 Sep, 2006

1 commit

  • a3bc0dbc8   [PATCH] smp_call_function_single() cleanup ... Browse Code »

    If we're going to implement smp_call_function_single() on three architecture
    with the same prototype then it should have a declaration in a
    non-arch-specific header file.

    Move it into .

    Cc: Stephane Eranian
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

01 Jul, 2006

1 commit

  • 033ab7f8e   [PATCH] add smp_setup_processor_id() ... Browse Code »

    Presently, smp_processor_id() isn't necessarily set up until setup_arch().
    But it's used in boot_cpu_init() and printk() and perhaps in other places,
    prior to setup_arch() being called.

    So provide a new smp_setup_processor_id() which is called before anything
    else, wire it up for Voyager (which boots on a CPU other than #0, and broke).

    Cc: James Bottomley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

26 Apr, 2006

1 commit

27 Mar, 2006

1 commit

22 Mar, 2006

1 commit

  • 78eef01b0   [PATCH] on_each_cpu(): disable local interrupts ... Browse Code »

    When on_each_cpu() runs the callback on other CPUs, it runs with local
    interrupts disabled. So we should run the function with local interrupts
    disabled on this CPU, too.

    And do the same for UP, so the callback is run in the same environment on both
    UP and SMP. (strictly it should do preempt_disable() too, but I think
    local_irq_disable is sufficiently equivalent).

    Also uninlines on_each_cpu(). softirq.c was the most appropriate file I could
    find, but it doesn't seem to justify creating a new file.

    Oh, and fix up that comment over (under?) x86's smp_call_function(). It
    drives me nuts.

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

08 Feb, 2006

1 commit

24 Nov, 2005

1 commit

23 Nov, 2005

1 commit

  • af2b4079a   [NET]: Shut up warnings in net/core/flow.c ... Browse Code »

    Not really a network problem, more a !SMP issue.

    net/core/flow.c:295: warning: statement with no effect

    flow.c:295: smp_call_function(flow_cache_flush_per_cpu, &info, 1, 0);

    Fix this by converting the macro to an inline function, which
    also increases the typechecking for !SMP builds.

    Signed-off-by: Russell King
    Signed-off-by: David S. Miller

    Russell King
     

29 Jul, 2005

1 commit

  • 2ac6608c4   Revert broken "statement with no effect" warning fix ... Browse Code »

    It may shut up gcc, but it also incorrectly changes the semantics of the
    smp_call_function() helpers.

    You can fix the warning other ways if you are interested (create another
    inline function that takes no arguments and returns zero), but
    preferably gcc just shouldn't complain about unused return values from
    statement expressions in the first place.

    Linus Torvalds
     

28 Jul, 2005

1 commit

  • 79a881022   [PATCH] alpha: fix "statement with no effect" warnings ... Browse Code »

    Apparently gcc 4.0 complains about "({ 0; });", which leads to -Werror
    breakage in one of the alpha oprofile modules.

    One might could argue that this is a gcc bug, in that statement-expressions
    should be considered to be function-like rather than statement-like for the
    purposes of this warning. But it's just as easy to use an inline function
    in the first place, side-stepping the issue.

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Henderson
     

22 Jun, 2005

1 commit

  • 39c715b71   [PATCH] smp_processor_id() cleanup ... Browse Code »

    This patch implements a number of smp_processor_id() cleanup ideas that
    Arjan van de Ven and I came up with.

    The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
    spaghetti was hard to follow both on the implementational and on the
    usage side.

    Some of the complexity arose from picking wrong names, some of the
    complexity comes from the fact that not all architectures defined
    __smp_processor_id.

    In the new code, there are two externally visible symbols:

    - smp_processor_id(): debug variant.

    - raw_smp_processor_id(): nondebug variant. Replaces all existing
    uses of _smp_processor_id() and __smp_processor_id(). Defined
    by every SMP architecture in include/asm-*/smp.h.

    There is one new internal symbol, dependent on DEBUG_PREEMPT:

    - debug_smp_processor_id(): internal debug variant, mapped to
    smp_processor_id().

    Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
    lib/smp_processor_id.c file. All related comments got updated and/or
    clarified.

    I have build/boot tested the following 8 .config combinations on x86:

    {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}

    I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT. (Other
    architectures are untested, but should work just fine.)

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds