1. 19 Jun, 2013 3 commits
  2. 14 Jun, 2013 2 commits
    • Bob Peterson's avatar
      GFS2: fix regression in dir_double_exhash · 512cbf02
      Bob Peterson authored
      Recent commit e8830d88
      
       introduced a bug in function dir_double_exhash;
      it was failing to set h in the fall-back case. This patch corrects it.
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      512cbf02
    • Steven Whitehouse's avatar
      GFS2: Add atomic_open support · 6d4ade98
      Steven Whitehouse authored
      
      
      I've restricted atomic_open to only operate on regular files, although
      I still don't understand why atomic_open should not be possible also for
      directories on GFS2. That can always be added in later though, if it
      makes sense.
      
      The ->atomic_open function can be passed negative dentries, which
      in most cases means either ENOENT (->lookup) or a call to d_instantiate
      (->create). In the GFS2 case though, we need to actually perform the
      look up, since we do not know whether there has been a new inode created
      on another node. The look up calls d_splice_alias which then tries to
      rehash the dentry - so the solution here is to simply check for that
      in d_splice_alias. The same issue is likely to affect any other cluster
      filesystem implementing ->atomic_open
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "J. Bruce Fields" <bfields fieldses org>
      Cc: Jeff Layton <jlayton@redhat.com>
      6d4ade98
  3. 11 Jun, 2013 1 commit
    • Steven Whitehouse's avatar
      GFS2: Only do one directory search on create · 5a00f3cc
      Steven Whitehouse authored
      
      
      Creation of a new inode requires a directory search in order to ensure
      that we are not trying to create an inode with the same name as an
      existing one. This was hidden away inside the create_ok() function.
      
      In the case that there was an existing inode, and a lookup can be
      substituted for a create (which is the case with regular files
      when the O_EXCL flag is not in use) then we were doing a second
      lookup in order to return the inode.
      
      This patch merges these two lookups into one. This can be done by
      passing a flag to gfs2_dir_search() to tell it to just return -EEXIST
      in the cases where we don't actually want to look up the inode.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      5a00f3cc
  4. 06 Jun, 2013 1 commit
  5. 05 Jun, 2013 10 commits
  6. 04 Jun, 2013 2 commits
    • Ping Cheng's avatar
      Input: wacom - fix a typo for Cintiq 22HDT · 3bd1f7e2
      Ping Cheng authored
      
      
      And make the lines easier to read.
      Signed-off-by: default avatarPing Cheng <pingc@wacom.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      3bd1f7e2
    • Eric Miao's avatar
      Input: synaptics - fix sync lost after resume on some laptops · eeb06558
      Eric Miao authored
      
      
      In summary, the symptom is intermittent key events lost after resume
      on some machines with synaptics touchpad (seems this is synaptics _only_),
      and key events loss is due to serio port reconnect after psmouse sync lost.
      Removing psmouse and inserting it back during the suspend/resume process
      is able to work around the issue, so the difference between psmouse_connect()
      and psmouse_reconnect() is the key to the root cause of this problem.
      
      After comparing the two different paths, synaptics driver has its own
      implementation of synaptics_reconnect(), and the missing psmouse_probe()
      seems significant, the patch below added psmouse_probe() to the reconnect
      process, and has been verified many times that the issue could not be reliably
      reproduced.
      
      There are two PS/2 commands in psmouse_probe():
      
        1. PSMOUSE_CMD_GETID
        2. PSMOUSE_CMD_RESET_DIS
      
      Only the PSMOUSE_CMD_GETID seems to be significant. The
      PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
      several times.  So we have only implemented this patch to issue
      the PSMOUSE_CMD_GETID so far.
      Tested-by: default avatarDaniel Manrique <daniel.manrique@canonical.com>
      Signed-off-by: default avatarJames M Leddy <james.leddy@canonical.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      eeb06558
  7. 03 Jun, 2013 21 commits