Eric Lee / smarc-fsl-linux-kernel

15 Feb, 2007

1 commit

  • cd354f1ae   [PATCH] remove many unneeded #includes of sched.h ... Browse Code »

    After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

11 Jul, 2006

1 commit

  • a8f340e39   [PATCH] vt: Remove VT-specific declarations and definitions from tty.h ... Browse Code »

    MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
    function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
    allows all of the framebuffer and VT console drivers to remove their
    dependency on tty.h.

    [akpm@osdl.org: fix alpha build]
    Signed-off-by: Jon Smirl
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jon Smirl
     

01 Jun, 2006

1 commit

  • 8fd66ab85   [PATCH] maxinefb: Fix compilation error ... Browse Code »

    From: Martin Michlmayr

    Fix the following compilation error:

    CC drivers/video/maxinefb.o
    drivers/video/maxinefb.c:58: warning: initializer-string for array of chars is too long
    drivers/video/maxinefb.c:58: warning: (near initialization for \u2018maxinefb_fix.id\u2019)
    drivers/video/maxinefb.c:110: error: unknown field \u2018fb_get_fix\u2019 specified in initializer
    drivers/video/maxinefb.c:110: error: \u2018gen_get_fix\u2019 undeclared here (not in a function)
    drivers/video/maxinefb.c:111: error: unknown field \u2018fb_get_var\u2019 specified in initializer
    drivers/video/maxinefb.c:111: error: \u2018gen_get_var\u2019 undeclared here (not in a function)
    make[2]: *** [drivers/video/maxinefb.o] Error 1

    Signed-off-by: Martin Michlmayr
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Martin Michlmayr
     

07 Nov, 2005

1 commit

  • c465e05a0   [PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon ... Browse Code »

    According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
    drivers that do not support hardware cursors is redundant. The soft_cursor
    function is usable by all drivers because it is just a wrapper around
    fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is
    moved to the console directory.

    Thus, drivers that do not support hardware cursors can leave the fb_cursor
    field blank. For drivers that do, they can fill up this field with their own
    version.

    The end result is a smaller code size. And if the framebuffer console is not
    loaded, module/kernel size is also reduced because the soft_cursor module will
    also not be loaded.

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

    Antonino A. Daplas
     

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