02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

10 Oct, 2014

1 commit

  • The ORIG_* macros definitions to access struct screen_info members and all
    of their users were removed 7 years ago by commit 3ea335100014785f
    ("Remove magic macros for screen_info structure members"), but (only) the
    definitions reappeared a few days later in commit ee8e7cfe9d330d6f ("Make
    asm-x86/bootparam.h includable from userspace.").

    Remove them for good. Amen.

    Signed-off-by: Geert Uytterhoeven
    Cc: "H. Peter Anvin"
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     

13 Oct, 2012

1 commit


17 Sep, 2012

1 commit

  • The majority of the DMI checks in efifb are for cases where the bootloader
    has provided invalid information. However, on some machines the overrides
    may do more harm than good due to configuration differences between machines
    with the same machine identifier. It turns out that it's possible for the
    bootloader to get the correct information on GOP-based systems, but we
    can't guarantee that the kernel's being booted with one that's been updated
    to do so. Add support for a capabilities flag that can be set by the
    bootloader, and skip the DMI checks in that case. Additionally, set this
    flag in the UEFI stub code.

    Signed-off-by: Matthew Garrett
    Acked-by: Peter Jones
    Signed-off-by: Matt Fleming

    Matthew Garrett
     

14 Nov, 2009

1 commit


30 Nov, 2007

1 commit

  • This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec
    deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output
    Protocol (GOP) is produced. Therefore, the boot loader needs to query the
    UEFI firmware with appropriate Output Protocol and pass the video information
    to the kernel. As a result of GOP protocol, an EFI framebuffer driver is
    needed for displaying console messages. The patch adds a EFI framebuffer
    driver. The EFI frame buffer driver in this patch is based on the Intel Mac
    framebuffer driver.

    The ELILO bootloader takes care of passing the video information as
    appropriate for EFI firmware.

    The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI
    platform.

    Signed-off-by: Chandramouli Narayanan
    Signed-off-by: Huang Ying
    Cc: "H. Peter Anvin"
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Andi Kleen
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Huang, Ying
     

23 Oct, 2007

1 commit


17 Oct, 2007

1 commit


13 Jul, 2007

1 commit


07 Dec, 2006

1 commit

  • This patch modifies the i386 kernel so that if CONFIG_RELOCATABLE is
    selected it will be able to be loaded at any 4K aligned address below
    1G. The technique used is to compile the decompressor with -fPIC and
    modify it so the decompressor is fully relocatable. For the main
    kernel relocations are generated. Resulting in a kernel that is relocatable
    with no runtime overhead and no need to modify the source code.

    A reserved 32bit word in the parameters has been assigned
    to serve as a stack so we figure out where are running.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Vivek Goyal
    Signed-off-by: Andi Kleen

    Eric W. Biederman
     

11 Apr, 2006

1 commit

  • Bugzilla Bug 6299:

    A pixel size of 8 bits produces wrong logo colors in x86_64.

    The driver has 2 methods for setting the color map, using the protected
    mode interface provided by the video BIOS and directly writing to the VGA
    registers. The former is not supported in x86_64 and the latter is enabled
    only in i386.

    Fix by enabling the latter method in x86_64 only if supported by the BIOS.
    If both methods are unsupported, change the visual of vesafb to
    STATIC_PSEUDOCOLOR.

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

    Antonino A. Daplas
     

11 Jan, 2006

1 commit

  • From: Bugzilla Bug 5351

    "After resuming from S3 (suspended while in X), the LCD panel stays black .
    However, the laptop is up again, and I can SSH into it from another
    machine.

    I can get the panel working again, when I first direct video output to the
    CRT output of the laptop, and then back to LCD (done by repeatedly hitting
    Fn+F5 buttons on the Toshiba, which directs output to either LCD, CRT or
    TV) None of this ever happened with older kernels."

    This bug is due to the recently added vesafb_blank() method in vesafb. It
    works with CRT displays, but has a high incidence of problems in laptop
    users. Since CRT users don't really get that much benefit from hardware
    blanking, drop support for this.

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

    Antonino A. Daplas
     

09 Jan, 2006

1 commit