Also fixes all drivers that set this field, and removes some other devfs
specfic USB logic.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

 drivers/usb/class/usblp.c           |    3 +--
 drivers/usb/core/file.c             |   19 ++++---------------
 drivers/usb/image/mdc800.c          |    3 +--
 drivers/usb/input/aiptek.c          |    2 +-
 drivers/usb/input/hiddev.c          |    3 +--
 drivers/usb/media/dabusb.c          |    3 +--
 drivers/usb/misc/auerswald.c        |    3 +--
 drivers/usb/misc/idmouse.c          |    5 ++---
 drivers/usb/misc/legousbtower.c     |    5 ++---
 drivers/usb/misc/rio500.c           |    3 +--
 drivers/usb/misc/sisusbvga/sisusb.c |    5 -----
 drivers/usb/misc/usblcd.c           |    9 ++++-----
 drivers/usb/usb-skeleton.c          |    3 +--
 include/linux/usb.h                 |    7 ++-----
 14 files changed, 22 insertions(+), 51 deletions(-)

When trying to make the hiddev driver issue several Set_Report control
transfers to a custom device with 2.6.13-rc6, only the first transfer in a
row is carried out, while others immediately following it are silently
dropped.

This happens where hid_submit_report() (in hid-core.c) tests for
HID_CTRL_RUNNING, which seems to be still set because the first transfer is
not finished yet.

As a workaround, inserting a delay between the two calls to
ioctl(HIDIOCSREPORT) in userspace "solves" the problem.  The
straightforward fix is to add a call to hid_wait_io() to the implementation
of HIDIOCSREPORT (in hiddev.c), just like for HIDIOCGREPORT.  Works fine
for me.

Apparently, this issue has some history:
http://marc.theaimsgroup.com/?l=linux-usb-users&m=111100670105558&w=2Signed-off-by: NStefan Nickl <Stefan.Nickl@kontron.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NVojtech Pavlik <vojtech@suse.cz>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!