Eric Lee / smarc-ti-linux-kernel

11 Jan, 2015

1 commit

  • f27bd5bfe   m68k: Wire up execveat ... Browse Code »

    Check success of execveat(3, '../execveat', 0)... [OK]
    Check success of execveat(5, 'execveat', 0)... [OK]
    Check success of execveat(6, 'execveat', 0)... [OK]
    Check success of execveat(-100, '/root/selftest-exec/exec/execveat', 0)... [OK]
    Check success of execveat(99, '/root/selftest-exec/exec/execveat', 0)... [OK]
    Check success of execveat(8, '', 4096)... [OK]
    Check success of execveat(17, '', 4096)... [OK]
    Check success of execveat(9, '', 4096)... [OK]
    Check success of execveat(14, '', 4096)... [OK]
    Check success of execveat(14, '', 4096)... [OK]
    Check success of execveat(15, '', 4096)... [OK]
    Check failure of execveat(8, '', 0) with ENOENT... [OK]
    Check failure of execveat(8, '(null)', 4096) with EFAULT... [OK]
    Check success of execveat(5, 'execveat.symlink', 0)... [OK]
    Check success of execveat(6, 'execveat.symlink', 0)... [OK]
    Check success of execveat(-100, '/root/selftest-exec/...xec/execveat.symlink', 0)... [OK]
    Check success of execveat(10, '', 4096)... [OK]
    Check success of execveat(10, '', 4352)... [OK]
    Check failure of execveat(5, 'execveat.symlink', 256) with ELOOP... [OK]
    Check failure of execveat(6, 'execveat.symlink', 256) with ELOOP... [OK]
    Check failure of execveat(-100, '/root/selftest-exec/exec/execveat.symlink', 256) with ELOOP... [OK]
    Check success of execveat(3, '../script', 0)... [OK]
    Check success of execveat(5, 'script', 0)... [OK]
    Check success of execveat(6, 'script', 0)... [OK]
    Check success of execveat(-100, '/root/selftest-exec/exec/script', 0)... [OK]
    Check success of execveat(13, '', 4096)... [OK]
    Check success of execveat(13, '', 4352)... [OK]
    Check failure of execveat(18, '', 4096) with ENOENT... [OK]
    Check failure of execveat(7, 'script', 0) with ENOENT... [OK]
    Check success of execveat(16, '', 4096)... [OK]
    Check success of execveat(16, '', 4096)... [OK]
    Check success of execveat(4, '../script', 0)... [OK]
    Check success of execveat(4, 'script', 0)... [OK]
    Check success of execveat(4, '../script', 0)... [OK]
    Check failure of execveat(4, 'script', 0) with ENOENT... [OK]
    Check failure of execveat(5, 'execveat', 65535) with EINVAL... [OK]
    Check failure of execveat(5, 'no-such-file', 0) with ENOENT... [OK]
    Check failure of execveat(6, 'no-such-file', 0) with ENOENT... [OK]
    Check failure of execveat(-100, 'no-such-file', 0) with ENOENT... [OK]
    Check failure of execveat(5, '', 4096) with EACCES... [OK]
    Check failure of execveat(5, 'Makefile', 0) with EACCES... [OK]
    Check failure of execveat(11, '', 4096) with EACCES... [OK]
    Check failure of execveat(12, '', 4096) with EACCES... [OK]
    Check failure of execveat(99, '', 4096) with EBADF... [OK]
    Check failure of execveat(99, 'execveat', 0) with EBADF... [OK]
    Check failure of execveat(8, 'execveat', 0) with ENOTDIR... [OK]
    Invoke copy of 'execveat' via filename of length 4093:
    Check success of execveat(19, '', 4096)... [OK]
    Check success of execveat(5, 'xxxxxxxxxxxxxxxxxxxx...yyyyyyyyyyyyyyyyyyyy', 0)... [OK]
    Invoke copy of 'script' via filename of length 4093:
    Check success of execveat(20, '', 4096)... [OK]
    Check success of execveat(5, 'xxxxxxxxxxxxxxxxxxxx...yyyyyyyyyyyyyyyyyyyy', 0)... [OK]

    Signed-off-by: Geert Uytterhoeven

    Geert Uytterhoeven
     

27 Oct, 2014

1 commit

10 Oct, 2014

1 commit

  • cd2567b68   m68k: call find_vma with the mmap_sem held in sys_cacheflush() ... Browse Code »

    Performing vma lookups without taking the mm->mmap_sem is asking for
    trouble. While doing the search, the vma in question can be modified or
    even removed before returning to the caller. Take the lock (shared) in
    order to avoid races while iterating through the vmacache and/or rbtree.
    In addition, this guarantees that the address space will remain intact
    during the CPU flushing.

    Signed-off-by: Davidlohr Bueso
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     

01 Sep, 2014

2 commits

06 Aug, 2014

2 commits

11 Jul, 2014

1 commit

10 Jul, 2014

1 commit

  • f1a1b6352   m68k: Fix boot regression on machines with RAM at non-zero ... Browse Code »

    My enhancement to store the initial mapping size for later reuse in commit
    486df8bc4627bdfc032d11bedcd056cc5343ee62 ("m68k: Increase initial mapping
    to 8 or 16 MiB if possible") broke booting on machines where RAM doesn't
    start at address zero.

    Use pc-relative addressing to fix this.

    Reported-by: Andreas Schwab
    Signed-off-by: Geert Uytterhoeven
    Tested-by: Andreas Schwab

    Geert Uytterhoeven
     

03 Jun, 2014

1 commit

  • b55a0ff8d   Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu into next ... Browse Code »

    Pull m68knommu updates from Greg Ungerer:
    "Nothing too big, just a handfull of small changes.

    A couple of dragonball fixes, coldfire qspi cleanup and fixes, and
    some coldfire gpio cleanup, fixes and extensions"

    * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
    m68knommu: Implement gpio support for m54xx.
    m68knommu: Make everything thats not exported, static.
    m68knommu: setting the gpio data direction register to output doesn't dependent upon the value to output!
    m68knommu: add to_irq function so we can map gpios to external interrupts.
    m68knommu: qspi declutter.
    m68knommu: Fix the 5249/525x qspi base address.
    m68knommu: Add qspi clk for Coldfire SoCs without real clks.
    m68k: fix a compiler warning when building for DragonBall
    m68knommu: Fix mach_sched_init for EZ and VZ DragonBall chips

    Linus Torvalds
     

28 May, 2014

4 commits

  • 486df8bc4   m68k: Increase initial mapping to 8 or 16 MiB if possible ... Browse Code »
    13

    If the size of the first memory chunk is at least 8 or 16 MiB increase the
    initial mapping to 8 resp. 16 MiB instead of 4 MiB.
    This makes it possible to
    1. Map more memory in the first node without running out of space for the
    page tables,
    2. Boot kernels that don't fit in 4 MiB (e.g. multi_defconfig).

    Signed-off-by: Andreas Schwab

    - Add support for 8 MiB,
    - Store initial mapping size in head.S for later reuse,
    - Add comment about large kernels.

    Signed-off-by: Geert Uytterhoeven

    Andreas Schwab
     
  • 83adc1811   m68k/atari: fix SCC initialization for debug console ... Browse Code »

    Fix SCC initialization for Atari as was previously fixed for Mac. It's
    probably not practical to share more code but some attempt is made to
    align the Mac and Atari variants.

    Signed-off-by: Finn Thain
    Signed-off-by: Geert Uytterhoeven

    Finn Thain
     
  • c46f46d02   m68k/mvme16x: Adopt common boot console ... Browse Code »

    In a multi-platform kernel binary we only need one early console instance.

    The difficulty here is that the common early console is started by
    early_param(), whereas the MVME16x instance is started later by
    config_mvme16x(). That means some interrupt setup must be done earlier.

    Signed-off-by: Finn Thain
    Tested-by: Stephen N Chivers
    [Geert] Tag debug_cons_write() with __ref to kill section mismatch warning
    Signed-off-by: Geert Uytterhoeven

    Finn Thain
     
  • 7913ad1ad   m68k: Multi-platform EARLY_PRINTK ... Browse Code »

    Make the boot console available to more m68k platforms by leveraging
    the head.S debug console.

    The boot console is enabled by the "earlyprintk" command line argument
    which is how most other architectures do this.

    This is a change of behaviour for the Mac but does not negatively impact
    the common use-case which is not debugging.

    This is also a change of behaviour for other platforms because it means
    the serial port stays quiet when CONFIG_EARLY_PRINTK is not enabled. This
    is also an improvement for the common use-case.

    Signed-off-by: Finn Thain
    Tested-by: Stephen N Chivers
    [Geert: CONSOLE_DEBUG should depend on CONFIG_FONT_SUPPORT]
    Reported-by: kbuild test robot
    Signed-off-by: Geert Uytterhoeven

    Finn Thain
     

27 May, 2014

1 commit

  • 97f3f68c2   m68k: Toward platform agnostic framebuffer debug logging ... Browse Code »

    Code subject to #ifdef CONSOLE is made more generic, as was apparently
    intended by the original author.

    Remove console_put_stats() routine. If it should be somehow useful, it
    should also be useful on platforms without framebuffer debug logging. The
    present implementation is only built #if defined CONFIG_MAC && defined
    CONSOLE even though puts() works everywhere.

    Signed-off-by: Finn Thain
    Tested-by: Stephen N Chivers
    Signed-off-by: Geert Uytterhoeven

    Finn Thain
     

26 May, 2014

1 commit

  • 5198f847f   m68k: fix a compiler warning when building for DragonBall ... Browse Code »

    In file included from arch/m68k/kernel/setup.c:4:0:
    arch/m68k/kernel/setup_no.c:70:0: warning: "CPU_NAME" redefined [enabled by default]
    #define CPU_NAME "MC68VZ328"
    ^
    arch/m68k/kernel/setup_no.c:61:0: note: this is the location of the previous definition
    #define CPU_NAME "MC68000"
    ^

    Signed-off-by: Daniel Palmer
    Signed-off-by: Greg Ungerer

    Daniel Palmer
     

20 May, 2014

1 commit

02 Apr, 2014

1 commit

  • 683b6c6f8   Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip ... Browse Code »

    Pull irq code updates from Thomas Gleixner:
    "The irq department proudly presents:

    - Another tree wide sweep of irq infrastructure abuse. Clear winner
    of the trainwreck engineering contest was:
    #include "../../../kernel/irq/settings.h"

    - Tree wide update of irq_set_affinity() callbacks which miss a cpu
    online check when picking a single cpu out of the affinity mask.

    - Tree wide consolidation of interrupt statistics.

    - Updates to the threaded interrupt infrastructure to allow explicit
    wakeup of the interrupt thread and a variant of synchronize_irq()
    which synchronizes only the hard interrupt handler. Both are
    needed to replace the homebrewn thread handling in the mmc/sdhci
    code.

    - New irq chip callbacks to allow proper support for GPIO based irqs.
    The GPIO based interrupts need to request/release GPIO resources
    from request/free_irq.

    - A few new ARM interrupt chips. No revolutionary new hardware, just
    differently wreckaged variations of the scheme.

    - Small improvments, cleanups and updates all over the place"

    I was hoping that that trainwreck engineering contest was a April Fools'
    joke. But no.

    * 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (68 commits)
    irqchip: sun7i/sun6i: Disable NMI before registering the handler
    ARM: sun7i/sun6i: dts: Fix IRQ number for sun6i NMI controller
    ARM: sun7i/sun6i: irqchip: Update the documentation
    ARM: sun7i/sun6i: dts: Add NMI irqchip support
    ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
    genirq: Export symbol no_action()
    arm: omap: Fix typo in ams-delta-fiq.c
    m68k: atari: Fix the last kernel_stat.h fallout
    irqchip: sun4i: Simplify sun4i_irq_ack
    irqchip: sun4i: Use handle_fasteoi_irq for all interrupts
    genirq: procfs: Make smp_affinity values go+r
    softirq: Add linux/irq.h to make it compile again
    m68k: amiga: Add linux/irq.h to make it compile again
    irqchip: sun4i: Don't ack IRQs > 0, fix acking of IRQ 0
    irqchip: sun4i: Fix a comment about mask register initialization
    irqchip: sun4i: Fix irq 0 not working
    genirq: Add a new IRQCHIP_EOI_THREADED flag
    genirq: Document IRQCHIP_ONESHOT_SAFE flag
    ARM: sunxi: dt: Convert to the new irq controller compatibles
    irqchip: sunxi: Change compatibles
    ...

    Linus Torvalds
     

01 Apr, 2014

1 commit

12 Mar, 2014

1 commit

11 Mar, 2014

3 commits

05 Mar, 2014

1 commit

  • abcfc543b   m68k: Do not rely on magic indirect includes ... Browse Code »

    commit: 8f945a33 (genirq: Move kstat_incr_irqs_this_cpu() to core)
    unearthed the following:

    arch/m68k/kernel/ints.c:34:15: error: variable 'auto_irq_chip' has initializer but incomplete type
    arch/m68k/kernel/ints.c:35:2: error: unknown field 'name' specified in initializer
    arch/m68k/kernel/ints.c:35:2: warning: excess elements in struct initializer [enabled by default]

    The reason is that this file requires linux/irq.h and magically
    pulled that in via linux/kernel_stat.h

    The commit above got rid of the pointless include of linux/irq.h in
    linux/kernel_stat.h and therefor broke the build.

    Include linux/irq.h

    Reported-by: fengguang.wu@intel.com
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

11 Feb, 2014

1 commit

19 Jan, 2014

1 commit

31 Dec, 2013

1 commit

  • 245b815c3   m68k: Convert arch/m68k/kernel/traps.c to pr_*() ... Browse Code »

    Also fix a few printf-style formats, to get rid of the following compiler
    warnings when DEBUG is enabled:

    arch/m68k/kernel/traps.c: In function ‘access_error060’:
    arch/m68k/kernel/traps.c:166: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long unsigned int’
    arch/m68k/kernel/traps.c: In function ‘bus_error030’:
    arch/m68k/kernel/traps.c:568: warning: format ‘%#lx’ expects type ‘long unsigned int’, but argument 2 has type ‘void *’
    arch/m68k/kernel/traps.c:682: warning: format ‘%#lx’ expects type ‘long unsigned int’, but argument 2 has type ‘void *’

    Signed-off-by: Geert Uytterhoeven

    Geert Uytterhoeven
     

08 Dec, 2013

2 commits

26 Nov, 2013

10 commits

14 Nov, 2013

1 commit

  • 09f90f668   m68k: Simplify low level interrupt handling code ... Browse Code »

    The low level interrupt entry code of m68k contains the following:

    add_preempt_count(HARDIRQ_OFFSET);

    do_IRQ();
    irq_enter();
    add_preempt_count(HARDIRQ_OFFSET);
    handle_interrupt();
    irq_exit();
    sub_preempt_count(HARDIRQ_OFFSET);
    if (in_interrupt())
    return; 0)
    return;
    if (local_softirq_pending())
    do_softirq();

    ret_from_exception:
    if (interrupted_context_is_kernel)
    return:
    ....

    I tried to find a proper explanation for this, but the changelog is
    sparse and there are no mails explaining it further. But obviously
    this relates to the interrupt priority levels of the m68k and tries to
    be extra clever with nested interrupts. Though this cleverness just
    adds code bloat to the interrupt hotpath.

    For the common case of non nested interrupts the code runs through two
    extra conditionals to the only important one, which checks whether the
    return is to kernel or user space.

    For the nested case the checks for in_hardirq() and the priority mask
    value on stack catch only the case where the nested interrupt happens
    inside the hard irq context of the first interrupt. If the nested
    interrupt happens while the first interrupt handles soft interrupts,
    then these extra checks buy nothing. The nested interrupt will fall
    through to the final kernel/user space return check at
    ret_from_exception.

    Changing the code flow in the following way:

    do_IRQ();
    irq_enter();
    add_preempt_count(HARDIRQ_OFFSET);
    handle_interrupt();
    irq_exit();
    sub_preempt_count(HARDIRQ_OFFSET);
    if (in_interrupt())
    return;
    if (local_softirq_pending())
    do_softirq();

    ret_from_exception:
    if (interrupted_context_is_kernel)
    return:

    makes the region protected by the hardirq count slightly smaller and
    the softirq handling is invoked with a minimal deeper stack. But
    otherwise it's completely functional equivalent and saves 104 bytes of
    text in arch/m68k/kernel/entry.o.

    This modification allows us further to get rid of the limitations
    which m68k puts on the preempt_count layout, so we can make the
    preempt count bits completely generic.

    Signed-off-by: Thomas Gleixner
    Tested-by: Michael Schmitz
    Acked-by: Geert Uytterhoeven
    Cc: Linux/m68k
    Cc: Andreas Schwab
    Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311112052360.30673@ionos.tec.linutronix.de

    Thomas Gleixner