Linus,
please pull from 'for-linus' branch from
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
to receive HID fixes below. The most important is the memory corruption
fix in hiddev, which was caused by Arnd's patch that tried to get rid of
BKL, but messed up intf private data. It's verified to fix various bug
reports (warnings from kobject core code, suspend-resume failures, etc).
Apart from that, a few minor fixes in picolcd driver and a device ID
addition.
Thanks.
Bruno Pr?mont (1):
HID: picolcd: correct ordering of framebuffer freeing
Chris Ball (2):
HID: hiddev: protect against disconnect/NULL-dereference race
USB HID: Add ID for eGalax Multitouch used in JooJoo tablet
Dan Carpenter (1):
HID: picolcd: testing the wrong variable
Jiri Kosina (1):
HID: hiddev: fix memory corruption due to invalid intfdata
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-egalax.c | 9 +++++++++
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-picolcd.c | 4 ++--
drivers/hid/usbhid/hiddev.c | 11 +++++++----
5 files changed, 20 insertions(+), 6 deletions(-)
--
Jiri Kosina
SUSE Labs, Novell Inc.
On Oct 24, 2010, at 2:19 AM, Jiri Kosina wrote:
> On Sat, 23 Oct 2010, Jarod Wilson wrote:
>
>>> please pull from 'for-linus' branch at
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
>>>
>>> to receive the HID subsystem patches below. Mostly adding support for a
>>> few new multitouch toys, and improving already existing drivers. Plus some
>>> bugfixes which were not urgent enough for .36.
>>
>> *cough*
>>
>> https://patchwork.kernel.org/patch/161481/
>>
>> What's a guy gotta do to get that patch merged too? :)
>
> Bah, it's still pending in my TODO folder, sorry for that. I am not really
> convinced whether it's the right aproach.
>
> First, I'll go check HUT how much non-standard the usages you are adding
> to generic code, are.
Just the four under HID_UP_TIVOVENDOR, I believe. Everything else should be bog-standard.
> Perhaps it would satisfy separate driver on the hid
> bus?
> (Second, I hope to shovel all the 'drivers' which only do specialized
> mappings into userspace/udev actually).
Yeah, I've heard that mentioned as Coming Soon(tm) for a while now though... ;)
Looks like the patch does require trivial massaging to apply now, I could do that and chop out the four vendor-specific usages and resubmit just the parts I believe are entirely in line with the HUT, then try to figure out what all is required on the udev side.
--
Jarod Wilson
[email protected]