1. 11 Apr, 2007 4 commits
    • Paul Walmsley's avatar
      USB HID: specify explicit size for hid_blacklist.quirks · 4cbe7d28
      Paul Walmsley authored
      Explicitly specify the size of the hid_blacklist quirks member, to guard
      against surprises on architectures where unsigned ints aren't 32 bits long.
      Signed-off-by: default avatarPaul Walmsley <paul@booyaka.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      4cbe7d28
    • Alan Stern's avatar
      USB HID: fix retry & reset logic · 5e2a55f2
      Alan Stern authored
      The USB HID driver fails to reset its error-retry timeout when there
      has been a long time interval between I/O errors with no successful URB
      completions in the meantime.  As a result, the very next error would
      trigger an immediate reset, even if it was a chance event occurring
      long after the previous error.
      
      More USB keyboards and mice than one might expect end up getting I/O
      errors. Almost always this results from hardware problems of one sort of
      another. For example, people attach the device to a USB extension cable,
      which degrades the signal.  Or they simply have poor quality cables to
      begin with. Or they use a KVM switch which doesn't handle USB messages
      correctly. Etc...
      
      There have been reports from several users in which these I/O
      errors would occur more or less randomly, at intervals ranging from
      seconds to minutes.  The error-handling code in hid-core.c was originally
      meant for situations where a single outage would persist for a few hundred
      ms (electromagnetic interference, for example).  It didn't work right when
      these more sporadic errors occurred, because of a flaw in the logic
      which this patch fixes.
      
      This patch (as873) fixes that oversight.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      5e2a55f2
    • Jiri Kosina's avatar
      USB HID: consolidate vendor/product ids · 48b4554a
      Jiri Kosina authored
      The vendor/product IDs for the purposes of hid_blacklist got
      scathered around the hid-core.c in a rather random way over the
      time.
      
      Move all the related definitions at the beginning of the file,
      and make them sorted again. Sort also hid_blacklist properly.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      48b4554a
    • Jiri Kosina's avatar
      USB HID: move usbhid code from drivers/usb/input to drivers/hid/usbhid · 6db3dfef
      Jiri Kosina authored
      Separate usbhid code into dedicated drivers/hid/usbhid directory as
      discussed previously with Greg, so that it eases maintaineance process.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6db3dfef
  2. 06 Apr, 2007 1 commit
  3. 05 Apr, 2007 12 commits
  4. 04 Apr, 2007 21 commits
  5. 03 Apr, 2007 1 commit
    • Eric W. Biederman's avatar
      [PATCH] msi: synchronously mask and unmask msi-x irqs. · 348e3fd1
      Eric W. Biederman authored
      This is a simplified and actually more comprehensive form of a bug
      fix from Mitch Williams <mitch.a.williams@intel.com>.
      
      When we mask or unmask a msi-x irqs the writes may be posted because
      we are writing to memory mapped region.  This means the mask and
      unmask don't happen immediately but at some unspecified time in the
      future.  Which is out of sync with how the mask/unmask logic work
      for ioapic irqs.
      
      The practical result is that we get very subtle and hard to track down
      irq migration bugs.
      
      This patch performs a read flush after writes to the MSI-X table for mask
      and unmask operations.  Since the SMP affinity is set while the interrupt
      is masked, and since it's unmasked immediately after, no additional flushes
      are required in the various affinity setting routines.
      
      The testing by Mitch Williams on his especially problematic system should
      still be valid as I have only simplified the code, not changed the
      functionality.
      
      We currently have 7 drivers: cciss, mthca, cxgb3, forceth, s2io,
      pcie/portdrv_core, and qla2xxx in 2.6.21 that are affected by this
      problem when the hardware they driver is plugged into the right slot.
      
      Given the difficulty of reproducing this bug and tracing it down to
      anything that even remotely resembles a cause, even if people are
      being affected we aren't likely to see many meaningful bug reports, and
      the people who see this bug aren't likely to be able to reproduce this
      bug in a timely fashion.  So it is best to get this problem fixed
      as soon as we can so people don't have problems.
      
      Then if people do have a kernel message stating "No irq for vector" we
      will know it is yet another novel cause that needs a complete new
      investigation.
      
      Cc: Greg KH <greg@kroah.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Acked-by: default avatar"Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      348e3fd1
  6. 02 Apr, 2007 1 commit