Skip to content
Snippets Groups Projects
  1. Jan 12, 2014
  2. Nov 15, 2013
  3. Nov 13, 2013
  4. Sep 26, 2013
  5. Sep 25, 2013
  6. Sep 10, 2013
  7. Aug 26, 2013
    • Greg Ungerer's avatar
      m68k: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not · 0c7e59c4
      Greg Ungerer authored
      
      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: default avatarChen Gang <gang.chen@asianux.com>
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      0c7e59c4
    • Greg Ungerer's avatar
      m68knommu: user generic iomap to support ioread*/iowrite* · f79b8592
      Greg Ungerer authored
      
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      f79b8592
  8. Aug 23, 2013
    • Geert Uytterhoeven's avatar
      m68k: Ignore disabled HSYNC interrupt on Atari for irqs_disabled() · 3c776a07
      Geert Uytterhoeven authored
      
      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: default avatarThorsten Glaser <tg@debian.org>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: default avatarThorsten Glaser <tg@debian.org>
      3c776a07
  9. Aug 14, 2013
    • Frederic Weisbecker's avatar
      m68k: hardirq_count() only need preempt_mask.h · a703f9b7
      Frederic Weisbecker authored
      
      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: default avatarFrederic 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
    • Andreas Schwab's avatar
      m68k: Truncate base in do_div() · ea077b1b
      Andreas Schwab authored
      
      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: default avatarThorsten Glaser <tg@debian.org>
      Signed-off-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      Tested-by: default avatarThorsten Glaser <tg@debian.org>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: stable@vger.kernel.org
      ea077b1b
  10. Jun 29, 2013
  11. Jun 24, 2013
    • Geert Uytterhoeven's avatar
      m68k/q40: Undefine insl/outsl before redefining them · db8ac55c
      Geert Uytterhoeven authored
      
      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: default avatarThorsten Glaser <tg@debian.org>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      db8ac55c
    • Geert Uytterhoeven's avatar
      m68k/uaccess: Fix asm constraints for userspace access · 631d8b67
      Geert Uytterhoeven authored
      
      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: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      631d8b67
    • Geert Uytterhoeven's avatar
      m68k: Remove inline strcpy() and strcat() implementations · d346a5db
      Geert Uytterhoeven authored
      
      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: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      d346a5db
  12. May 29, 2013
    • Greg Ungerer's avatar
      m68k: only use local gpio_request_one if not using GPIOLIB · cf6c31fc
      Greg Ungerer authored
      
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      cf6c31fc
  13. May 21, 2013
    • Mikael Pettersson's avatar
      m68k: implement futex.h to support userspace robust futexes and PI mutexes · e4f2dfbb
      Mikael Pettersson authored
      
      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: default avatarMikael Pettersson <mikpe@it.uu.se>
      Acked-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      [geert: Added removal of ""generic-y += futex.h"]
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      e4f2dfbb
  14. Apr 29, 2013
  15. Apr 16, 2013
  16. Apr 09, 2013
  17. Apr 05, 2013
  18. Mar 04, 2013
  19. Feb 26, 2013
  20. Feb 14, 2013
    • Al Viro's avatar
      burying unused conditionals · d64008a8
      Al Viro authored
      __ARCH_WANT_SYS_RT_SIGACTION,
      __ARCH_WANT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_SCHED_RR_GET_INTERVAL - not used anymore
      CONFIG_GENERIC_{SIGALTSTACK,COMPAT_RT_SIG{ACTION,QUEUEINFO,PENDING,PROCMASK}} -
      can be assumed always set.
      d64008a8
  21. Feb 09, 2013
  22. Feb 06, 2013
    • Greg Ungerer's avatar
      m68knommu: fix trap on execing /bin/init · e95c3f7a
      Greg Ungerer authored
      
      As of commit fea82210 ("m68k: switch to saner kernel_execve() semantics")
      the non-mmu m68k targets have trapped on booting. The execing of /bin/init
      causes the exec path to try and return through a 0x0 return address - thus
      trapping or otherwise hanging or crashing.
      
      The problem isn't in the exec path as such though, but rather in the
      m68knommu start_thread() macro. It is trying to clear the a6 register that
      it assumes is part of a struct switch_stack below the thread registers on
      our stack. But that is not what the stack frames look like when this is run.
      So it ends up corrupting our call stack and zeroing out a function return
      address that is sitting there.
      
      The clearing of a6 was introduced many years ago in commit 7bf9a37d
      ("m68knommu: force stack alignment on ColdFire"). It used to work because
      the kernel init exec code path had a short cut back to the exception return
      code, and it didn't need to return through the calls on the stack.
      
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      e95c3f7a
  23. Feb 04, 2013
  24. Feb 03, 2013
  25. Jan 29, 2013
    • Geert Uytterhoeven's avatar
      m68k: Provide dma_mmap_coherent() and dma_get_sgtable() · 546eda4b
      Geert Uytterhoeven authored
      
      m68k/allmodconfig:
      
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’
      
      For architectures using dma_map_ops, dma_mmap_coherent() and
      dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>.
      
      M68k does not use dma_map_ops, hence it should implement them as inline
      stubs using dma_common_mmap() and dma_common_get_sgtable().
      
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: linux-m68k@lists.linux-m68k.org
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      546eda4b
Loading