1. 18 Oct, 2011 7 commits
    • Greg Ungerer's avatar
      m68k: merge mmu and non-mmu include/asm/entry.h files · 61619b12
      Greg Ungerer authored
      The changes in the mmu version of entry.h (entry_mm.h) and the non-mmu
      version (entry_no.h) are not about the presence or use of an MMU at all.
      The main changes are to support the ColdFire processors. The code for
      trap entry and exit for all types of 68k processor outside coldfire is
      the same.
      
      So merge the files back to a single entry.h and share the common 68k
      entry/exit code. Some changes are required for the non-mmu entry
      handlers to adopt the differing macros for system call and interrupt
      entry, but this is quite strait forward. The changes for the ColdFire
      remove a couple of instructions for the separate a7 register case, and
      are no worse for the older single a7 register case.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      61619b12
    • Greg Ungerer's avatar
      m68k: merge the mmu and non-mmu kernel/Makefiles · 0a01b310
      Greg Ungerer authored
      The few differences between the mmu and non-mmu kernel/Makefiles can
      easily be handled inside of a single Makefile. Merge the 2 back into
      a single Makefile.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      0a01b310
    • Greg Ungerer's avatar
      m68k: merge mmu and non-mmu arch Makefiles · 281eff53
      Greg Ungerer authored
      Most of the build logic is the same for the mmu and non-mmu m68k targets.
      Merge the top level architecture Makefiles back into a single Makefile.
      
      For the most part this is just adding the non-mmu processor types and
      their specific cflags and other options into the mmu Makefile.
      
      Note that all the BOARD setting logic that was in the non-mmu Makefile
      is completely removed. It was no longer being used at all.
      
      This has been build and run tested on ColdFire targets and ARAnyM.
      It has been build tested on all the m68k defconfig targets using a
      gcc-4.5.1 based toolchain.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      281eff53
    • Greg Ungerer's avatar
      m68k: reorganize Kconfig options to improve mmu/non-mmu selections · 0e152d80
      Greg Ungerer authored
      The current mmu and non-mmu Kconfig files can be merged to form
      a more general selection of options. The current break up of options
      is due to the simple brute force merge from the m68k and m68knommu
      arch directories.
      
      Many of the options are not at all specific to having the MMU enabled
      or not. They are actually associated with a particular CPU type or
      platform type.
      
      Ultimately as we support all processors with the MMU disabled we need
      many of these options to be selectable without the MMU option enabled.
      And likewise some of the ColdFire processors, which currently are only
      supported with the MMU disabled, do have MMU hardware, and will need
      to have options selected on CPU type, not MMU disabled.
      
      This patch removes the old mmu and non-mmu Kconfigs and instead breaks
      up the configuration into four areas: cpu, machine, bus, devices.
      
      The Kconfig.cpu lists all the options associated with selecting a CPU,
      and includes options specific to each CPU type as well.
      
      Kconfig.machine lists all options associated with selecting a machine
      type. Almost always the machines selectable is restricted by the chosen
      CPU.
      
      Kconfig.bus contains options associated with selecting bus types on the
      various machine types. That includes PCI bus, PCMCIA bus, etc.
      
      Kconfig.devices contains options for drivers and driver associated
      options.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      0e152d80
    • Peter Turczak's avatar
      m68knommu: fix problems with SPI/GPIO on ColdFire 520x · 89127ed3
      Peter Turczak authored
      The problem has its root in the calculation of the set-port offsets (macro
      MCFGPIO_SETR() in arch/m68k/include/asm/gpio.h), this assumes that all ports
      have the same offset from the base port address (MCFGPIO_SETR) which is
      defined in mcf520xsim.h as an alias of MCFGIO_PSETR_BUSCTL. Because the BUSCTL
      and BE port do not have a set-register (see MCF5208 Reference Manual Page
      13-10, Table 13-3) the offset calculations went wrong.
      
      Because the BE and BUSCTL port do not seem useful in these parts, as they
      lack a set register, I removed them and adapted the gpio chip bases which
      are also used for the offset-calculations. Now both setting and resetting
      the chip selects works as expected from userland and from the kernelspace.
      Signed-off-by: default avatarPeter Turczak <peter@turczak.de>
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      89127ed3
    • Greg Ungerer's avatar
      m68k: fix memcpy to unmatched/unaligned source and dest on 68000 · f230e80b
      Greg Ungerer authored
      The original 68000 processors cannot copy 16bit or larger quantities from
      odd addresses. All newer members of the 68k family (including ColdFire)
      can do this.
      
      In the current memcpy implementation after trying to align the destination
      address to a 16bit boundary if we end up with an odd source address we go
      off and try to copy multi-byte quantities from it. This will trap on the
      68000.
      
      The only solution if we end with an odd source address is to byte wise
      copy the whole memcpy region. We only need to do this if we are supporting
      original 68000 processors.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      f230e80b
    • Linus Torvalds's avatar
      Linux 3.1-rc10 · 899e3ee4
      Linus Torvalds authored
      899e3ee4
  2. 17 Oct, 2011 1 commit
    • Linus Torvalds's avatar
      Avoid using variable-length arrays in kernel/sys.c · a84a79e4
      Linus Torvalds authored
      The size is always valid, but variable-length arrays generate worse code
      for no good reason (unless the function happens to be inlined and the
      compiler sees the length for the simple constant it is).
      
      Also, there seems to be some code generation problem on POWER, where
      Henrik Bakken reports that register r28 can get corrupted under some
      subtle circumstances (interrupt happening at the wrong time?).  That all
      indicates some seriously broken compiler issues, but since variable
      length arrays are bad regardless, there's little point in trying to
      chase it down.
      
      "Just don't do that, then".
      Reported-by: default avatarHenrik Grindal Bakken <henribak@cisco.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a84a79e4
  3. 16 Oct, 2011 1 commit
  4. 15 Oct, 2011 3 commits
  5. 14 Oct, 2011 6 commits
  6. 13 Oct, 2011 7 commits
  7. 11 Oct, 2011 5 commits
  8. 10 Oct, 2011 10 commits