1. 08 12月, 2013 2 次提交
  2. 26 11月, 2013 13 次提交
  3. 15 11月, 2013 1 次提交
  4. 14 11月, 2013 2 次提交
  5. 26 9月, 2013 1 次提交
  6. 25 9月, 2013 1 次提交
  7. 10 9月, 2013 1 次提交
  8. 26 8月, 2013 2 次提交
    • G
      m68k: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not · 0c7e59c4
      Greg Ungerer 提交于
      Define 'VM_DATA_DEFAULT_FLAGS' when 'NOMMU' to pass compiling.
      
      So move it from "include/asm/page_mm.h to "include/asm/page.h"
      
      The related make:
      
        make ARCH=m68k randconfig
        make ARCH=m68k menuconfig
          choose cross compiler
          disable MMU support
        make ARCH=m68k V=1 EXTRA_CFLAGS=-W
      
      The related error:
      
        security/selinux/hooks.c: In function ‘selinux_init’:
        security/selinux/hooks.c:5821:21: error: ‘VM_DATA_DEFAULT_FLAGS’ undeclared (first use in this function)
      Signed-off-by: NChen Gang <gang.chen@asianux.com>
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      0c7e59c4
    • G
      m68knommu: user generic iomap to support ioread*/iowrite* · f79b8592
      Greg Ungerer 提交于
      There is no reason we cannot use the generic iomap support to give us
      the ioread* and iowrite* family of IO access functions. The m68k arch with
      MMU enabled does, so this makes us consistent for all m68k now.
      
      Some potentially valid drivers will fail to compile without these,
      for example:
      
      drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of
      function ‘iowrite8’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of
      function ‘iowrite16’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:91:2: error: implicit declaration of
      function ‘iowrite32’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:96:2: error: implicit declaration of
      function ‘ioread8’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:101:2: error: implicit declaration of
      function ‘ioread16’ [-Werror=implicit-function-declaration]
      drivers/i2c/busses/i2c-ocores.c:106:2: error: implicit declaration of
      function ‘ioread32’ [-Werror=implicit-function-declaration]
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      f79b8592
  9. 23 8月, 2013 1 次提交
    • G
      m68k: Ignore disabled HSYNC interrupt on Atari for irqs_disabled() · 3c776a07
      Geert Uytterhoeven 提交于
      When running a multi-platform kernel on Atari, warning messages like
      the following may be printed:
      
          WARNING: at /root/linux-3.10.1/init/main.c:698 do_one_initcall+0x12e/0x13a()
          initcall param_sysfs_init+0x0/0x1a4 returned with disabled interrupts
      
      This is caused by the different definitions of ALLOWINT for Atari and
      other platforms:
      
          #if defined(MACH_ATARI_ONLY)
          #define ALLOWINT        (~0x500)
          #else
          #define ALLOWINT        (~0x700)
          #endif
      
      On Atari, we want to disable the high-frequency HSYNC interrupt:
        - On Atari-only kernels, this is handled completely through ALLOWINT,
        - On multi-platform kernels, this is handled by disabling the HSYNC
          interrupt from the interrupt handler.
      
      However, as in the latter case arch_irqs_disabled_flags() didn't ignore the
      disabling of the HSYNC interrupt, irqs_disabled() would detect false
      positives.
      
      Ignore the HSYNC interrupt when running on Atari to fix this.
      For single-platform kernels this test is optimized away by the compiler.
      Reported-by: NThorsten Glaser <tg@debian.org>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: NThorsten Glaser <tg@debian.org>
      3c776a07
  10. 14 8月, 2013 2 次提交
    • F
      m68k: hardirq_count() only need preempt_mask.h · a703f9b7
      Frederic Weisbecker 提交于
      The m68k irqflags implementation needs to check hardirq
      context in some cases.
      
      As it is a very low level header file, it's better to
      include preempt_mask.h rather than hardirq.h when the
      only purpose is to use irq context APIs. This way we
      can avoid future header circular dependencies when
      vtime.h will expand to use static keys.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      a703f9b7
    • A
      m68k: Truncate base in do_div() · ea077b1b
      Andreas Schwab 提交于
      Explicitly truncate the second operand of do_div() to 32 bits to guard
      against bogus code calling it with a 64-bit divisor.
      
      [Thorsten]
      
      After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with:
      
      btrfs: setting nodatacow, compression disabled
      btrfs: enabling auto recovery
      btrfs: disk space caching is enabled
      *** ZERO DIVIDE ***   FORMAT=2
      Current process id is 722
      BAD KERNEL TRAP: 00000000
      Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c
      PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs]
      SR: 2000  SP: 30c1fab4  a2: 30f0faf0
      d0: 00000000    d1: 00001000    d2: 00000000    d3: 00000000
      d4: 00010000    d5: 00000000    a0: 3085c72c    a1: 3085c72c
      Process mount (pid: 722, task=30f0faf0)
      Frame format=2 instr addr=319535ae
      Stack from 30c1faec:
              00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00
              00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000
              00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000
              30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003
              00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000
              0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002
      Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000
      
          [...]
      
      Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68
      
      [Geert]
      
      As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block()
      calls
      
          do_div(stripe_nr, stripe_len);
      
      with stripe_len u64, while do_div() assumes the divisor is a 32-bit number.
      
      Due to the lack of truncation in the m68k-specific implementation of
      do_div(), the division is performed using the upper 32-bit word of
      stripe_len, which is zero.
      
      This was introduced by commit 53b381b3
      ("Btrfs: RAID5 and RAID6"), which changed the divisor from
      map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary.
      Reported-by: NThorsten Glaser <tg@debian.org>
      Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
      Tested-by: NThorsten Glaser <tg@debian.org>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: stable@vger.kernel.org
      ea077b1b
  11. 29 6月, 2013 1 次提交
  12. 25 6月, 2013 3 次提交
    • G
      m68k/q40: Undefine insl/outsl before redefining them · db8ac55c
      Geert Uytterhoeven 提交于
      To use the PC parallel port driver on Q40, we need non-standard versions of
      the insl/outsl accessors. Make sure to undefine them first, to kill this
      compiler warning:
      
      In file included from drivers/parport/parport_pc.c:67:
      arch/m68k/include/asm/parport.h:14:1: warning: "insl" redefined
      In file included from arch/m68k/include/asm/io.h:4,
                       from include/linux/scatterlist.h:10,
                       from include/linux/dma-mapping.h:9,
                       from drivers/parport/parport_pc.c:54:
      arch/m68k/include/asm/io_mm.h:370:1: warning: this is the location of the previous definition
      In file included from drivers/parport/parport_pc.c:67:
      arch/m68k/include/asm/parport.h:15:1: warning: "outsl" redefined
      In file included from arch/m68k/include/asm/io.h:4,
                       from include/linux/scatterlist.h:10,
                       from include/linux/dma-mapping.h:9,
                       from drivers/parport/parport_pc.c:54:
      arch/m68k/include/asm/io_mm.h:373:1: warning: this is the location of the previous definition
      Reported-by: NThorsten Glaser <tg@debian.org>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      db8ac55c
    • G
      m68k/uaccess: Fix asm constraints for userspace access · 631d8b67
      Geert Uytterhoeven 提交于
      When compiling a MMU kernel with CPU_HAS_ADDRESS_SPACES=n (e.g. "MMU=y
      allnoconfig": "echo CONFIG_MMU=y > allno.config && make KCONFIG_ALLCONFIG=1
      allnoconfig"), we use plain "move" instead of "moves", and I got:
      
        CC      arch/m68k/lib/uaccess.o
      {standard input}: Assembler messages:
      {standard input}:47: Error: operands mismatch -- statement `move.b %a0,(%a1)' ignored
      
      This happens because plain "move" doesn't support byte transfers between
      memory and address registers, while "moves" does.
      
      Fix the asm constraints for __generic_copy_from_user(),
      __generic_copy_to_user(), and __clear_user() to only use data registers
      when accessing userspace.
      
      Also, relax the asm constraints for 16-bit userspace accesses in
      __put_user() and __get_user(), as both "move" and "moves" do support
      such transfers between memory and address registers.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      631d8b67
    • G
      m68k: Remove inline strcpy() and strcat() implementations · d346a5db
      Geert Uytterhoeven 提交于
      Gcc may replace calls to standard string functions by open code and/or
      calls to other standard string functions. If the replacement function is
      not available out-of-line, link errors will happen.
      
      To avoid this, the out-of-line versions were provided by
      arch/m68k/lib/string.c, but they were usually not linked in anymore as
      typically none of its symbols are referenced by built-in code.
      However, if any module would need them, they would not be available.
      
      Hence remove the inline strcpy() and strcat() implementations, remove
      arch/m68k/lib/string.c, and let the generic string library code handle it.
      
      Impact on a typical kernel build seems minimal or nonexistent:
      
      -      .text : 0x00001000 - 0x002aac74   (2728 KiB)
      -      .data : 0x002ada48 - 0x00392148   ( 914 KiB)
      +      .text : 0x00001000 - 0x002aacf4   (2728 KiB)
      +      .data : 0x002adac8 - 0x00392148   ( 914 KiB)
      
      See also commit e00c73ee ("m68k: Remove
      inline strlen() implementation").
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      d346a5db
  13. 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
  14. 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
  15. 29 4月, 2013 4 次提交
  16. 17 4月, 2013 4 次提交