Re: [PATCH 1/1] HID: add have_special_driver hid module parameter

[Nikolai Kondrashov <spbnick@gmail.com>]

Hi David,

On 04/01/2012 11:10 PM, David Herrmann wrote:
> On Sun, Apr 1, 2012 at 9:44 PM, Nikolai Kondrashov<spbnick@gmail.com>  wrote:
>> Thanks, but this doesn't suit me currently. I don't implement report parsing
>> in my drivers, but rather describe every device protocol separately with a
>> report descriptor and rely on the generic driver for parsing. Thus, I save
>> in code complexity and maintenance, but loose in portability.
>
> I think you don't understand me correctly.

Yes, I didn't, sorry :)

> I meant instead of using some static global table in the module you could
> instead implement something like the
> "new_id"/store_new_id()/dyn_list/dyn_lock mechanism but for the
> special_driver-id-array. So one could use "echo vid:pid
>> /sys/bus/hid/new_special_driver_id" and it would be added to a linked
> list which is checked additionally to the static array.
>
> Such a mechanism is already used by all kinds of buses, hid, usb,
> pci... but only for the id-lists of drivers, not a global module list.
> At least this would look less hackish than a fixed-length-array module
> parameter ;)

Yes, it could be done like this. However, I think Jiri would reject it. It
basically has the same hackishness WRT the overall design, while having more
complicated implementation.

Then, at least for my purpose, it would be worse. Because it would be harder
to configure it permanently. With a module parameter you could just modify
modprobe configuration, but with a sysfs node, you would need to have some
sort of a script. Then cold-plugged devices won't work unless you care to
unbind the existing devices when adding an ID.

Sincerely,
Nick