1. 17 Apr, 2012 1 commit
    • Greg Ungerer's avatar
      m68knommu: fix id number for second eth device on 5275 ColdFire · bfdd769a
      Greg Ungerer authored
      The second ColdFire FEC ethernet device should have an id number of 1,
      not 0. Otherwise it clashes with the first FEC ethernet device.
      
      On booting a kernel on a 5275 based board you will get messages out of
      the kernel like this:
      
          <4>------------[ cut here ]------------
          <4>WARNING: at fs/sysfs/dir.c:508 0x0a8b50()
          <4>sysfs: cannot create duplicate filename 'fec.0'
      
      And likely you won't be able to completely boot up after this at all.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      bfdd769a
  2. 16 Apr, 2012 5 commits
    • Greg Ungerer's avatar
      m68knommu: move and fix the 68VZ328 platform bootlogo.h · 89d78601
      Greg Ungerer authored
      The 68EZ328/bootlogo.h is not actually used in the 68EZ328 platform code
      at all. It is used by the 68VZ328 platform code though, so move it to be
      with the rest of the 68VZ328 platform code.
      
      Commit c0e0c89c ("fix broken boot logo
      inclusion") modified the bootlogo code to not be included in asm code.
      Modify 68VZ328/bootlogo.h so that the bootlogo bit map is named correctly
      for direct use in the C code.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      89d78601
    • Greg Ungerer's avatar
      m68knommu: remove the unused bootlogo.h processing for 68EZ328 and 68VZ328 · acb0c7ac
      Greg Ungerer authored
      The 68EZ328 and 68VZ328 platforms currently try to process their bootlogo.h
      to make it clean to include in asm files. This is no longer used, the
      bootlogo.h file is now included only in C code, so remove all the processing
      code in the 68EZ328 and 68VZ328 Makefiles.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      acb0c7ac
    • Linus Torvalds's avatar
      Linux 3.4-rc3 · e816b57a
      Linus Torvalds authored
      e816b57a
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · 9a8e5d41
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Nothing too disasterous, the biggest thing being the removal of the
        regulator support for vcore in the AMBA driver; only one SoC was using
        this and it got broken during the last merge window, which then
        started causing problems for other people.  Mutual agreement was
        reached for it to be removed."
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: 7386/1: jump_label: fixup for rename to static_key
        ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
        ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU
        ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus
        ARM: 7383/1: nommu: populate vectors page from paging_init
        ARM: 7381/1: nommu: fix typo in mm/Kconfig
        ARM: 7380/1: DT: do not add a zero-sized memory property
        ARM: 7379/1: DT: fix atags_to_fdt() second call site
        ARM: 7366/3: amba: Remove AMBA level regulator support
        ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler
        ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented
      9a8e5d41
    • Linus Torvalds's avatar
      x86-32: fix up strncpy_from_user() sign error · 12e993b8
      Linus Torvalds authored
      The 'max' range needs to be unsigned, since the size of the user address
      space is bigger than 2GB.
      
      We know that 'count' is positive in 'long' (that is checked in the
      caller), so we will truncate 'max' down to something that fits in a
      signed long, but before we actually do that, that comparison needs to be
      done in unsigned.
      
      Bug introduced in commit 92ae03f2 ("x86: merge 32/64-bit versions of
      'strncpy_from_user()' and speed it up").  On x86-64 you can't trigger
      this, since the user address space is much smaller than 63 bits, and on
      x86-32 it works in practice, since you would seldom hit the strncpy
      limits anyway.
      
      I had actually tested the corner-cases, I had only tested them on
      x86-64.  Besides, I had only worried about the case of a pointer *close*
      to the end of the address space, rather than really far away from it ;)
      
      This also changes the "we hit the user-specified maximum" to return
      'res', for the trivial reason that gcc seems to generate better code
      that way.  'res' and 'count' are the same in that case, so it really
      doesn't matter which one we return.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      12e993b8
  3. 15 Apr, 2012 12 commits
  4. 14 Apr, 2012 13 commits
  5. 13 Apr, 2012 9 commits