Making structs const prevents accidental bugs and with the proper debug
options they're protected against corruption.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Make a read of a HID device block until data is available. Without it, the
read goes into a busy-wait loop until data is available.
Cc: Greg KH <greg@kroah.com>
Acked-by: Vojtech Pavlik <vojtech@suse.cz>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Found this when working with a HAPP UGCI device. It has a usage with 7
indexes. I could read them all one at a time, but using a multiref it
would only allow me to read the first 6. The patch below fixed it.
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
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=2
Signed-off-by: Stefan Nickl <Stefan.Nickl@kontron.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>
Signed-off-by: Dmitry 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!
