Eric Lee / smarc-fsl-linux-kernel

23 Aug, 2011

1 commit

04 Aug, 2011

1 commit

  • 20feaab03   ARM: Fix build error for SMP=n builds ... Browse Code »

    Unfortunately, the module fixups cause the kernel to fail to build
    when SMP is not enabled. Fix this by removing the reference to
    fixup_smp on non-SMP fixup kernels, but ensuring that if we do have
    the SMP fixup section, we refuse to load the module.

    Signed-off-by: Russell King

    Russell King
     

24 Jul, 2011

1 commit

  • 66574cc05   modules: make arch's use default loader hooks ... Browse Code »

    This patch removes all the module loader hook implementations in the
    architecture specific code where the functionality is the same as that
    now provided by the recently added default hooks.

    Signed-off-by: Jonas Bonn
    Acked-by: Mike Frysinger
    Acked-by: Geert Uytterhoeven
    Tested-by: Michal Simek
    Signed-off-by: Rusty Russell

    Jonas Bonn
     

17 Jun, 2011

1 commit

  • 9a00318ea   ARM: 6963/1: Thumb-2: Relax relocation requirements for non-function symbols ... Browse Code »

    The "Thumb bit" of a symbol is only really meaningful for function
    symbols (STT_FUNC).

    However, sometimes a branch is relocated against a non-function
    symbol; for example, PC-relative branches to anonymous assembler
    local symbols are typically fixed up against the start-of-section
    symbol, which is not a function symbol. Some inline assembler
    generates references of this type, such as fixup code generated by
    macros in .

    The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24
    interprets this case as an error, because the target symbol appears
    to be an ARM symbol; but this is really not the case, since the
    target symbol is just a base in these cases. The addend defines
    the precise offset to the target location, but since the addend is
    encoded in a non-interworking Thumb branch instruction, there is no
    explicit Thumb bit in the addend. Because these instructions never
    interwork, the implied Thumb bit in the addend is 1, and the
    destination is Thumb by definition.

    This patch removes the extraneous Thumb bit check for non-function
    symbols, enabling modules containing the affected relocation types
    to be loaded. No modification to the actual relocation code is
    required, since this code does not take bit[0] of the
    location->destination offset into account in any case.

    Function symbols are always checked for interworking conflicts, as
    before.

    Signed-off-by: Dave Martin
    Acked-by: Catalin Marinas
    Signed-off-by: Russell King

    Dave Martin
     

17 Mar, 2011

2 commits

24 Feb, 2011

1 commit

  • 68e6fad48   ARM: improve module relocation fixup diagnostics ... Browse Code »

    Current diagnostics are rather poor when things go wrong:
    ipv6: relocation out of range, section 2 reloc 0 sym 'snmp_mib_free'

    Let's include a little more information about the problem:
    ipv6: section 2 reloc 0 sym 'snmp_mib_free': relocation 28 out of range (0xbf0000a4 -> 0xc11b4858)

    so that we show exactly what the problem is - not only what type of
    relocation but also the offending address range too.

    Signed-off-by: Russell King

    Russell King
     

18 Feb, 2011

1 commit

  • dc21af99f   ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching ... Browse Code »

    This idea came from Nicolas, Eric Miao produced an initial version,
    which was then rewritten into this.

    Patch the physical to virtual translations at runtime. As we modify
    the code, this makes it incompatible with XIP kernels, but allows us
    to achieve this with minimal loss of performance.

    As many translations are of the form:

    physical = virtual + (PHYS_OFFSET - PAGE_OFFSET)
    virtual = physical - (PHYS_OFFSET - PAGE_OFFSET)

    we generate an 'add' instruction for __virt_to_phys(), and a 'sub'
    instruction for __phys_to_virt(). We calculate at run time (PHYS_OFFSET
    - PAGE_OFFSET) by comparing the address prior to MMU initialization with
    where it should be once the MMU has been initialized, and place this
    constant into the above add/sub instructions.

    Once we have (PHYS_OFFSET - PAGE_OFFSET), we can calculate the real
    PHYS_OFFSET as PAGE_OFFSET is a build-time constant, and save this for
    the C-mode PHYS_OFFSET variable definition to use.

    At present, we are unable to support Realview with Sparsemem enabled
    as this uses a complex mapping function, and MSM as this requires a
    constant which will not fit in our math instruction.

    Add a module version magic string for this feature to prevent
    incompatible modules being loaded.

    Tested-by: Tony Lindgren
    Reviewed-by: Nicolas Pitre
    Tested-by: Nicolas Pitre
    Signed-off-by: Russell King

    Russell King
     

10 Feb, 2011

1 commit

  • 4a9cb3601   ARM: fixup SMP alternatives in modules ... Browse Code »

    With certain configurations, we inline the unlock functions in modules,
    which results in SMP alternatives being created in modules. We need to
    fix those up when loading a module to prevent undefined instruction
    faults.

    Signed-off-by: Russell King

    Russell King
     

14 Jan, 2011

1 commit

  • d0a21265d   mm: unify module_alloc code for vmalloc ... Browse Code »

    Four architectures (arm, mips, sparc, x86) use __vmalloc_area() for
    module_init(). Much of the code is duplicated and can be generalized in a
    globally accessible function, __vmalloc_node_range().

    __vmalloc_node() now calls into __vmalloc_node_range() with a range of
    [VMALLOC_START, VMALLOC_END) for functionally equivalent behavior.

    Each architecture may then use __vmalloc_node_range() directly to remove
    the duplication of code.

    Signed-off-by: David Rientjes
    Cc: Christoph Lameter
    Cc: Russell King
    Cc: Ralf Baechle
    Cc: "David S. Miller"
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Rientjes
     

01 Dec, 2010

2 commits

02 Sep, 2010

3 commits

05 Aug, 2010

3 commits

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

24 Jul, 2009

1 commit

  • adca6dc23   Thumb-2: Add support for loadable modules ... Browse Code »

    Modules compiled to Thumb-2 have two additional relocations needing to
    be resolved at load time, R_ARM_THM_CALL and R_ARM_THM_JUMP24, for BL
    and B.W instructions. The maximum Thumb-2 addressing range is +/-2^24
    (+/-16MB) therefore the MODULES_VADDR macro in asm/memory.h is set to
    (MODULES_END - 8MB) for the Thumb-2 compiled kernel.

    Signed-off-by: Catalin Marinas

    Catalin Marinas
     

08 May, 2009

1 commit

  • ae51e6098   [ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation types ... Browse Code »

    From: Bruce Ashfield

    To fully support the armv7-a instruction set/optimizations, support
    for the R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocation types is
    required.

    The MOVW and MOVT are both load-immediate instructions, MOVW loads 16
    bits into the bottom half of a register, and MOVT loads 16 bits into the
    top half of a register.

    The relocation information for these instructions has a full 32 bit
    value, plus an addend which is stored in the 16 immediate bits in the
    instruction itself. The immediate bits in the instruction are not
    contiguous (the register # splits it into a 4 bit and 12 bit value),
    so the addend has to be extracted accordingly and added to the value.
    The value is then split and put into the instruction; a MOVW uses the
    bottom 16 bits of the value, and a MOVT uses the top 16 bits.

    Signed-off-by: David Borman
    Signed-off-by: Bruce Ashfield
    Signed-off-by: Paul Gortmaker
    Signed-off-by: Russell King

    Paul Gortmaker
     

29 Mar, 2009

1 commit

21 Mar, 2009

1 commit

  • 4731f8b66   [ARM] 5428/1: Module relocation update for R_ARM_V4BX ... Browse Code »

    It would seem when building kernel modules with modern binutils
    (required by modern GCC) for ARM v4T targets (specifically observed
    with the Samsung 24xx SoC which is an 920T) R_ARM_V4BX relocations
    are emitted for function epilogues.

    This manifests at module load time with an "unknown relocation: 40"
    error message.

    The following patch adds the R_ARM_V4BX relocation to the ARM kernel
    module loader. The relocation operation is taken from that within the
    binutils bfd library.

    Signed-off-by: Simtec Linux Team
    Signed-off-by: Vincent Sanders
    Signed-off-by: Russell King

    Daniel Silverstone
     

19 Feb, 2009

1 commit

01 Dec, 2008

1 commit

  • 37efe6427   [ARM] use asm/sections.h ... Browse Code »

    Update to use the asm/sections.h header rather than declaring these
    symbols ourselves. Change __data_start to _data to conform with the
    naming found within asm/sections.h.

    Signed-off-by: Russell King

    Russell King
     

07 Nov, 2008

1 commit

  • ab4f2ee13   [ARM] fix naming of MODULE_START / MODULE_END ... Browse Code »

    As of 73bdf0a60e607f4b8ecc5aec597105976565a84f, the kernel needs
    to know where modules are located in the virtual address space.
    On ARM, we located this region between MODULE_START and MODULE_END.
    Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
    Update ARM to use the same naming, so is_vmalloc_or_module_addr()
    can work properly. Also update the comment on mm/vmalloc.c to
    reflect that ARM also places modules in a separate region from the
    vmalloc space.

    Signed-off-by: Russell King

    Russell King
     

01 Oct, 2008

1 commit

  • 8ec53663d   [ARM] Improve non-executable support ... Browse Code »

    Add support for detecting non-executable stack binaries, and adjust
    permissions to prevent execution from data and stack areas. Also,
    ensure that READ_IMPLIES_EXEC is enabled for older CPUs where that
    is true, and for any executable-stack binary.

    Signed-off-by: Russell King

    Russell King
     

25 Jul, 2008

1 commit

  • 27ac792ca   PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architectures ... Browse Code »

    On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
    boundary. For example:

    u64 val = PAGE_ALIGN(size);

    always returns a value < 4GB even if size is greater than 4GB.

    The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
    example):

    #define PAGE_SHIFT 12
    #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
    #define PAGE_MASK (~(PAGE_SIZE-1))
    ...
    #define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK)

    The "~" is performed on a 32-bit value, so everything in "and" with
    PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
    Using the ALIGN() macro seems to be the right way, because it uses
    typeof(addr) for the mask.

    Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
    include/linux/mm.h.

    See also lkml discussion: http://lkml.org/lkml/2008/6/11/237

    [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
    [akpm@linux-foundation.org: fix v850]
    [akpm@linux-foundation.org: fix powerpc]
    [akpm@linux-foundation.org: fix arm]
    [akpm@linux-foundation.org: fix mips]
    [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
    [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
    [akpm@linux-foundation.org: fix powerpc]
    Signed-off-by: Andrea Righi
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrea Righi
     

09 May, 2007

1 commit

  • c5f125031   [ARM] Fix ARM branch relocation range ... Browse Code »

    Branches in the ARM architecture are restricted to a range of +/- 32MB.
    However, the code in .../arch/arm/kernel/module.c::apply_relocate() was
    checking offset against a range of +/- 64MB.

    Signed-off-by: Kevin Welton
    Signed-off-by: Russell King

    Kevin Welton
     

28 Sep, 2006

1 commit

01 Jul, 2006

1 commit

15 Dec, 2005

1 commit

28 Oct, 2005

1 commit

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