Hi David,
On 04/01/2012 11:10 PM, David Herrmann wrote:
On Sun, Apr 1, 2012 at 9:44 PM, Nikolai Kondrashov<spbnick@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
