1. 24 Feb, 2011 10 commits
  2. 23 Feb, 2011 27 commits
  3. 22 Feb, 2011 3 commits
    • Kevin Hilman's avatar
      i2c-omap: fix static suspend vs. runtime suspend · adf6e079
      Kevin Hilman authored
      When runtime PM is enabled, each OMAP i2c device is suspended after
      each i2c xfer.  However, there are two cases when the static suspend
      methods must be used to ensure the devices are suspended:
      
      1) runtime PM is disabled, either at compile time or dynamically
          via /sys/devices/.../power/control.
      2) an i2c client driver uses i2c during it's suspend callback, thus
         leaving the i2c driver active (NOTE: runtime suspend transitions are
         disabled during system suspend, so i2c activity during system
         suspend will runtime resume the device, but not runtime (re)suspend it.)
      
      Since the actual work to suspend the device is handled by the
      subsytem, call the bus methods to take care of it.
      
      NOTE: This takes care of a known suspend problem on OMAP3 where the
      TWL RTC driver does i2c xfers during its suspend path leaving the i2c
      driver in an active state (since runtime suspend transistions are
      disabled.)
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      adf6e079
    • Wolfram Sang's avatar
      i2c-stu300: make sure adapter-name is terminated · f10820e4
      Wolfram Sang authored
      Use strlcpy instead of strncpy.
      Signed-off-by: default avatarWolfram Sang <w.sang@pengutronix.de>
      Cc: Linus Walleij <linus.walleij@stericsson.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      f10820e4
    • Lukas Czerner's avatar
      xfs: check if device support discard in xfs_ioc_trim() · be715140
      Lukas Czerner authored
      Right now we, are relying on the fact that when we attempt to
      actually do the discard, blkdev_issue_discar() returns -EOPNOTSUPP
      and the user is informed that the device does not support discard.
      
      However, in the case where the we do not hit any suitable free
      extent to trim in FITRIM code, it will finish without any error.
      This is very confusing, because it seems that FITRIM was successful
      even though the device does not actually supports discard.
      
      Solution: Check for the discard support before attempt to search for
      free extents.
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      be715140