1. 11 Apr, 2008 6 commits
    • Till Harbaum's avatar
      i2c-tiny-usb: New VID/PID pair · fa16eefd
      Till Harbaum authored
      I have recently bought some USB PIDs from EZPrototypes for my USB projects
      and one will be for the i2c-tiny-usb. I have not yet started to use the new 
      one in the official i2c-tiny-usb firmware since i think it makes sense to get 
      the change into the kernel before releasing a modified firmware.
      
      This patch adds support for the EZPrototypes USB vid/pid pair used in later
      i2c-tiny-usb firmware versions (avrusb v1.06 and up, usbtiny v2.06 and up).
      Signed-off-by: default avatarTill Harbaum <Till@Harbaum.org>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      fa16eefd
    • Troy Kisky's avatar
      i2c-davinci: Fix lost interrupt · b73a9aec
      Troy Kisky authored
      DAVINCI_I2C_STR_REG is a write 1 to clear register,
      so don't use a read/modify/write cycle.
      Signed-off-by: default avatarTroy Kisky <troy.kisky@boundarydevices.com>
      Acked-by: default avatarDirk Behme <dirk.behme@gmail.com>
      Signed-off-by: default avatarKevin Hilman <khilman@mvista.com>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      b73a9aec
    • Paul Mundt's avatar
      i2c-ibm_iic: Fast mode parm desc fixup · 852fb2ac
      Paul Mundt authored
      Noticed this when grepping for fast mode module params, the i2c-ibm_iic
      driver was using a non-existent variable for MODULE_PARM_DESC. Fix it up
      to reflect what it's actually supposed to be describing.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      852fb2ac
    • Linus Torvalds's avatar
      Add commentary about the new "asmlinkage_protect()" macro · d10d89ec
      Linus Torvalds authored
      It's really a pretty ugly thing to need, and some day it will hopefully
      be obviated by teaching gcc about the magic calling conventions for the
      low-level system call code, but in the meantime we can at least add big
      honking comments about why we need these insane and strange macros.
      
      I took my comments from my version of the macro, but I ended up deciding
      to just pick Roland's version of the actual code instead (with his
      prettier syntax that uses vararg macros).  Thus the previous two commits
      that actually implement it.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d10d89ec
    • Roland McGrath's avatar
      asmlinkage_protect sys_io_getevents · 598af051
      Roland McGrath authored
      Use asmlinkage_protect in sys_io_getevents, because GCC for i386 with
      CONFIG_FRAME_POINTER=n can decide to clobber an argument word on the
      stack, i.e. the user struct pt_regs.  Here the problem is not a tail
      call, but just the compiler's use of the stack when it inlines and
      optimizes the body of the called function.  This seems to avoid it.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      598af051
    • Roland McGrath's avatar
      asmlinkage_protect replaces prevent_tail_call · 54a01510
      Roland McGrath authored
      The prevent_tail_call() macro works around the problem of the compiler
      clobbering argument words on the stack, which for asmlinkage functions
      is the caller's (user's) struct pt_regs.  The tail/sibling-call
      optimization is not the only way that the compiler can decide to use
      stack argument words as scratch space, which we have to prevent.
      Other optimizations can do it too.
      
      Until we have new compiler support to make "asmlinkage" binding on the
      compiler's own use of the stack argument frame, we have work around all
      the manifestations of this issue that crop up.
      
      More cases seem to be prevented by also keeping the incoming argument
      variables live at the end of the function.  This makes their original
      stack slots attractive places to leave those variables, so the compiler
      tends not clobber them for something else.  It's still no guarantee, but
      it handles some observed cases that prevent_tail_call() did not.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      54a01510
  2. 10 Apr, 2008 17 commits
  3. 09 Apr, 2008 17 commits