1. 01 Jan, 2011 1 commit
  2. 30 Dec, 2010 3 commits
  3. 29 Dec, 2010 3 commits
  4. 24 Dec, 2010 4 commits
  5. 23 Dec, 2010 5 commits
  6. 21 Dec, 2010 5 commits
  7. 20 Dec, 2010 9 commits
  8. 19 Dec, 2010 3 commits
  9. 18 Dec, 2010 3 commits
  10. 17 Dec, 2010 4 commits
    • Chris Metcalf's avatar
      arch/tile: handle rt_sigreturn() more cleanly · 81711cee
      Chris Metcalf authored
      The current tile rt_sigreturn() syscall pattern uses the common idiom
      of loading up pt_regs with all the saved registers from the time of
      the signal, then anticipating the fact that we will clobber the ABI
      "return value" register (r0) as we return from the syscall by setting
      the rt_sigreturn return value to whatever random value was in the pt_regs
      for r0.
      
      However, this breaks in our 64-bit kernel when running "compat" tasks,
      since we always sign-extend the "return value" register to properly
      handle returned pointers that are in the upper 2GB of the 32-bit compat
      address space.  Doing this to the sigreturn path then causes occasional
      random corruption of the 64-bit r0 register.
      
      Instead, we stop doing the crazy "load the return-value register"
      hack in sigreturn.  We already have some sigreturn-specific assembly
      code that we use to pass the pt_regs pointer to C code.  We extend that
      code to also set the link register to point to a spot a few instructions
      after the usual syscall return address so we don't clobber the saved r0.
      Now it no longer matters what the rt_sigreturn syscall returns, and the
      pt_regs structure can be cleanly and completely reloaded.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      81711cee
    • Chris Metcalf's avatar
      arch/tile: handle CLONE_SETTLS in copy_thread(), not user space · bc4cf2bb
      Chris Metcalf authored
      Previously we were just setting up the "tp" register in the
      new task as started by clone() in libc.  However, this is not
      quite right, since in principle a signal might be delivered to
      the new task before it had its TLS set up.  (Of course, this race
      window still exists for resetting the libc getpid() cached value
      in the new task, in principle.  But in any case, we are now doing
      this exactly the way all other architectures do it.)
      
      This change is important for 2.6.37 since the tile glibc we will
      be submitting upstream will not set TLS in user space any more,
      so it will only work on a kernel that has this fix.  It should
      also be taken for 2.6.36.x in the stable tree if possible.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Cc: stable <stable@kernel.org>
      bc4cf2bb
    • Jean-Francois Moine's avatar
      [media] gspca - sonixj: Better handling of the bridge registers 0x01 and 0x17 · 0e4d413a
      Jean-Francois Moine authored
      The initial values of the registers 0x01 and 0x17 are taken from the sensor
      table at capture start and updated according to the flag PDN_INV.
      
      Their values are updated at each step of the capture initialization and
      memorized for reuse in capture stop.
      
      This patch also fixed automatically some bad hardcoded values of these
      registers.
      Signed-off-by: default avatarJean-François Moine <moinejf@free.fr>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      0e4d413a
    • Jean-Francois Moine's avatar