1. 25 6月, 2013 7 次提交
  2. 31 5月, 2013 1 次提交
    • F
      m68k/mac: Fix unexpected interrupt with CONFIG_EARLY_PRINTK · df66834a
      Finn Thain 提交于
      The present code does not wait for the SCC to finish resetting itself
      before trying to initialise the device. The result is that the SCC
      interrupt sources become enabled (if they weren't already). This leads to
      an early boot crash (unexpected interrupt) given CONFIG_EARLY_PRINTK. Fix
      this by adding a delay. A successful reset disables the interrupt sources.
      
      Also, after the reset for channel A setup, the SCC then gets a second
      reset for channel B setup which leaves channel A uninitialised again. Fix
      this by performing the reset only once.
      Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      df66834a
  3. 29 5月, 2013 1 次提交
    • G
      m68k: only use local gpio_request_one if not using GPIOLIB · cf6c31fc
      Greg Ungerer 提交于
      Compiling for targets that use the local gpio code (not GPIOLIB) fail to
      compile with:
      
        CC      arch/m68k/platform/coldfire/device.o
      In file included from include/linux/gpio.h:45:0,
                       from arch/m68k/platform/coldfire/device.c:15:
      /home/gerg/new-wave.git/linux-3.x/arch/m68k/include/asm/gpio.h:89:19: error: static declaration of ‘gpio_request_one’ follows non-static declaration
      include/asm-generic/gpio.h:195:12: note: previous declaration of ‘gpio_request_one’ was here
      
      Fix by conditionally using the local gpio_request_one() function based on
      !CONFIG_GPIOLIB.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      cf6c31fc
  4. 28 5月, 2013 1 次提交
  5. 22 5月, 2013 1 次提交
    • M
      m68k: implement futex.h to support userspace robust futexes and PI mutexes · e4f2dfbb
      Mikael Pettersson 提交于
      Linux/M68K currently doesn't support robust futexes or PI mutexes.
      The problem is that the futex code needs to perform certain ops
      (cmpxchg, set, add, or, andn, xor) atomically on user-space
      addresses, and M68K's lack of a futex.h causes those operations
      to be unsupported and disabled.
      
      This patch adds that support, but only for uniprocessor machines,
      which is adequate for M68K.  For UP it's enough to disable preemption
      to ensure mutual exclusion (futexes don't need to care about other
      hardware agents), and the mandatory pagefault_disable() does just that.
      
      This patch is closely based on the one I co-wrote for UP ARM back
      in August 2008.  The main change is that this patch uses the C
      get_user/put_user accessors instead of inline assembly code with
      exception table fixups.
      
      For non-MMU machines the new futex.h simply redirects to the generic
      futex.h, so there is no functional change for them.
      
      Tested on aranym with the glibc-2.17 test suite: no regressions, and
      a number of mutex/condvar test cases went from failing to succeeding
      (tst-mutexpi{5,5a,6,9}, tst-cond2[45], tst-robust[1-9], tst-robustpi[1-8]).
      Also tested with glibc-2.18 HEAD and a local glibc patch to enable PI
      mutexes: no regressions.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Acked-by: NAndreas Schwab <schwab@linux-m68k.org>
      [geert: Added removal of ""generic-y += futex.h"]
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      e4f2dfbb
  6. 01 5月, 2013 1 次提交
    • T
      dump_stack: consolidate dump_stack() implementations and unify their behaviors · 196779b9
      Tejun Heo 提交于
      Both dump_stack() and show_stack() are currently implemented by each
      architecture.  show_stack(NULL, NULL) dumps the backtrace for the
      current task as does dump_stack().  On some archs, dump_stack() prints
      extra information - pid, utsname and so on - in addition to the
      backtrace while the two are identical on other archs.
      
      The usages in arch-independent code of the two functions indicate
      show_stack(NULL, NULL) should print out bare backtrace while
      dump_stack() is used for debugging purposes when something went wrong,
      so it does make sense to print additional information on the task which
      triggered dump_stack().
      
      There's no reason to require archs to implement two separate but mostly
      identical functions.  It leads to unnecessary subtle information.
      
      This patch expands the dummy fallback dump_stack() implementation in
      lib/dump_stack.c such that it prints out debug information (taken from
      x86) and invokes show_stack(NULL, NULL) and drops arch-specific
      dump_stack() implementations in all archs except blackfin.  Blackfin's
      dump_stack() does something wonky that I don't understand.
      
      Debug information can be printed separately by calling
      dump_stack_print_info() so that arch-specific dump_stack()
      implementation can still emit the same debug information.  This is used
      in blackfin.
      
      This patch brings the following behavior changes.
      
      * On some archs, an extra level in backtrace for show_stack() could be
        printed.  This is because the top frame was determined in
        dump_stack() on those archs while generic dump_stack() can't do that
        reliably.  It can be compensated by inlining dump_stack() but not
        sure whether that'd be necessary.
      
      * Most archs didn't use to print debug info on dump_stack().  They do
        now.
      
      An example WARN dump follows.
      
       WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
       Hardware name: empty
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #9
        0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
        ffffffff8108f50f ffffffff82228240 0000000000000040 ffffffff8234a03c
        0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
       Call Trace:
        [<ffffffff81c614dc>] dump_stack+0x19/0x1b
        [<ffffffff8108f50f>] warn_slowpath_common+0x7f/0xc0
        [<ffffffff8108f56a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff8234a071>] init_workqueues+0x35/0x505
        ...
      
      v2: CPU number added to the generic debug info as requested by s390
          folks and dropped the s390 specific dump_stack().  This loses %ksp
          from the debug message which the maintainers think isn't important
          enough to keep the s390-specific dump_stack() implementation.
      
          dump_stack_print_info() is moved to kernel/printk.c from
          lib/dump_stack.c.  Because linkage is per objecct file,
          dump_stack_print_info() living in the same lib file as generic
          dump_stack() means that archs which implement custom dump_stack()
          - at this point, only blackfin - can't use dump_stack_print_info()
          as that will bring in the generic version of dump_stack() too.  v1
          The v1 patch broke build on blackfin due to this issue.  The build
          breakage was reported by Fengguang Wu.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>	[s390 bits]
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Richard Kuo <rkuo@codeaurora.org>		[hexagon bits]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      196779b9
  7. 30 4月, 2013 1 次提交
  8. 29 4月, 2013 9 次提交
  9. 17 4月, 2013 10 次提交
  10. 16 4月, 2013 1 次提交
  11. 09 4月, 2013 1 次提交
  12. 08 4月, 2013 1 次提交
  13. 05 4月, 2013 1 次提交
  14. 21 3月, 2013 1 次提交
  15. 13 3月, 2013 1 次提交
  16. 06 3月, 2013 1 次提交
  17. 04 3月, 2013 1 次提交
    • G
      m68knommu: fix misnamed GPIO pin definition for ColdFire 528x CPU · 0371a1c5
      Greg Ungerer 提交于
      Compiling for a ColdFire 528x CPU will result in:
      
      arch/m68k/platform/coldfire/m528x.c: In function ‘m528x_uarts_init’:
      arch/m68k/platform/coldfire/m528x.c:72: error: ‘MCF5282_GPIO_PUAPAR’ undeclared (first use in this function)
      arch/m68k/platform/coldfire/m528x.c:72: error: (Each undeclared identifier is reported only once
      arch/m68k/platform/coldfire/m528x.c:72: error: for each function it appears in.)
      
      The MCF5282_GPIO_PUAPAR definition changed names in the ColdFire definitions
      cleanup. It is now MCFGPIO_PUAPAR, so change it.
      
      Not sure how this one got missed, 2 lines below it is the correct use of
      this definition.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      0371a1c5