Re: [PATCH 00/12] HID: hid-lg, hid-lg4ff: Mostly cleanup patches

From: Elias Vanderstuyft
Date: Sun Mar 29 2015 - 05:01:31 EST


On Sat, Mar 21, 2015 at 12:47 PM, Michal MalÃ
<madcatxster@xxxxxxxxxxxxxxxxxx> wrote:
> Hello everyone,
>
> this is a mostly boring series that deals with a few inconsistencies in the
> code that have accumulated over the years. Besides that it patches up a handful
> of problems such a return values not being checked etc.
>
> The only significant change comes in patch 0007 which introduces a spinlock to
> handle concurrent access to the HID report that is used by the driver to send
> data to the wheel. I would appreciate some comments on this one, particularly
> on the way it handles deinitialization.
>
> Michal Malà (12):
> HID: hid-lg4ff: (Cleanup) Remove double underscore prefix from numeric
> types.
> HID: hid-lg4ff: (Cleanup) Remove "hid_" prefix from some functions
> names.
> HID: hid-lg4ff: (Cleanup) Replace DEVICE_ATTR_RW with DEVICE_ATTR to
> have all internal functions prefixed with "lg4ff_"
> HID: hid-lg4ff: (Cleanup) Remove unused variable from the
> "lg4ff_device_entry" struct.
> HID: hid-lg4ff: Update a warning message for a case where device is
> incorrectly flagged to be handled by hid-lg4ff in hid-lg.
> HID: hid-lg: Check return values from lg[N]ff_init()
> HID: hid-lg4ff: Protect concurrent access to the output HID report
> values with a spinlock.
> HID: hid-lg4ff: Store pointer to the output HID report struct in the
> device entry struct.
> HID: hid-lg4ff: Constify those members of lg4ff_device_entry struct
> whose value is not supposed to change.
> HID: hid-lg4ff: Allow the driver to continue without sysfs interface.
> HID: hid-lg4ff: Update respective sysfs interface documentation
> HID: hid-lg: Only one of LG_FF flags can be set for a given device.
>
> .../ABI/testing/sysfs-driver-hid-logitech-lg4ff | 8 +-
> drivers/hid/hid-lg.c | 21 +-
> drivers/hid/hid-lg4ff.c | 459 ++++++++++++++-------
> drivers/hid/hid-lg4ff.h | 4 +-
> 4 files changed, 319 insertions(+), 173 deletions(-)
>
> --
> 2.3.3
>

Tested on kernel 3.18.6 (I had to apply some uptream patches first).
I tried to crash the kernel by simultaneously running many instances
of FF applications (which made use of effects with nonzero attack
times, thus the ff-memless timer's timeout got modified often), and
then unplugging the device while in use.
Instead of crashing, the kernel behaved like it should, no panics or
lockups were found.

Tested with to following devices:
- Logitech MOMO (Black) : PID 0xCA03
- Logitech Formula Vibration : PID 0xCA04

Tested-by: Elias Vanderstuyft <elias.vds@xxxxxxxxx>

Regards,
Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/