is there a reason "usbhid.quirks" parameter is not root writable?
short form: is there some reason that the usbhid "quirks" parameter is not by default compiled to be writable in case you wanted to adjust those values on a running system? long form: i have a USB device that, sadly, is automatically claimed by the usbhid driver upon insertion, and i want to prevent that so it behaves as a regular USB device. from what i've read, the solution is to, at boot time, add the kernel command line parameter: usbhid.quirks=0x2123:0x1010:0x04 that's fine if i want to reboot so that that takes effect, but it would of course be convenient if i could add that info to /sys/module/usbhid/parameters/quirks at run-time. currently, on my fedora 22 system: $ cat /sys/module/usbhid/parameters/quirks (null),(null),(null),(null) $ with permissions: $ ls -l /sys/module/usbhid/parameters/quirks -r--r--r--. 1 root root 4096 Nov 12 02:41 /sys/module/usbhid/parameters/quirks $ and i can see in drivers/hid/usbhid/hid-core.c the fact that that array is defined as non-writable: /* Quirks specified at module load time */ static char *quirks_param[MAX_USBHID_BOOT_QUIRKS]; module_param_array_named(quirks, quirks_param, charp, NULL, 0444); MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying " " quirks=vendorID:productID:quirks" " where vendorID, productID, and quirks are all in" " 0x-prefixed hex"); so the obvious(?) question is, is there some reason that that parameter is defined as read-only rather than, say, writable by root? would it not be useful to be able to modify that parameter at run-time? or is there something about that parameter for which that would be a really bad idea? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Thu, Nov 12, 2015 at 03:15:41AM -0700, Robert P. J. Day wrote:
short form: is there some reason that the usbhid "quirks" parameter is not by default compiled to be writable in case you wanted to adjust those values on a running system?
long form: i have a USB device that, sadly, is automatically claimed by the usbhid driver upon insertion, and i want to prevent that so it behaves as a regular USB device. from what i've read, the solution is to, at boot time, add the kernel command line parameter:
usbhid.quirks=0x2123:0x1010:0x04
that's fine if i want to reboot so that that takes effect, but it would of course be convenient if i could add that info to /sys/module/usbhid/parameters/quirks at run-time. currently, on my fedora 22 system:
$ cat /sys/module/usbhid/parameters/quirks (null),(null),(null),(null) $
with permissions:
$ ls -l /sys/module/usbhid/parameters/quirks -r--r--r--. 1 root root 4096 Nov 12 02:41 /sys/module/usbhid/parameters/quirks $
and i can see in drivers/hid/usbhid/hid-core.c the fact that that array is defined as non-writable:
/* Quirks specified at module load time */ static char *quirks_param[MAX_USBHID_BOOT_QUIRKS]; module_param_array_named(quirks, quirks_param, charp, NULL, 0444); MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying " " quirks=vendorID:productID:quirks" " where vendorID, productID, and quirks are all in" " 0x-prefixed hex");
so the obvious(?) question is, is there some reason that that parameter is defined as read-only rather than, say, writable by root? would it not be useful to be able to modify that parameter at run-time? or is there something about that parameter for which that would be a really bad idea?
You can add a runtime quirk to the device itself when it shows up in sysfs for the hid driver. Use that instead of the module parameter for that specific device. hope this helps, greg k-h
On Thu, 12 Nov 2015 16:44:35 -0800, Greg KH said:
On Thu, Nov 12, 2015 at 03:15:41AM -0700, Robert P. J. Day wrote:
module_param_array_named(quirks, quirks_param, charp, NULL, 0444); MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying "
You can add a runtime quirk to the device itself when it shows up in sysfs for the hid driver. Use that instead of the module parameter for that specific device.
That's a workaround. Still unexplained is why it's mode 0444 for "add/modify". But to answer Robert's question: I suspect that it's mode 0444 so you can read the current list, but changing the list after modprobe time is for some reason problematic. Having said that, I admit I haven't looked at the source deep enough to find the exact reason. It's probably something subtle, because simply adding an ID to a list of IDs shouldn't be that hard....
On Thu, Nov 12, 2015 at 08:02:00PM -0500, Valdis.Kletnieks@vt.edu wrote:
But to answer Robert's question: I suspect that it's mode 0444 so you can read the current list, but changing the list after modprobe time is for some reason problematic. Having said that, I admit I haven't looked at the source deep enough to find the exact reason. It's probably something subtle, because simply adding an ID to a list of IDs shouldn't be that hard....
To do that you now need to keep a separate dynmic list of ids that you also need to check, and clean up when shut down, it's not as "simple" as you might think. Not impossible, we do it for lots of other places, and the hid core does handle dynamic quirks as I pointed out, so you should be fine. If people have questions about this, please ask them on the linux-input mailing list, where the HID developers are at. thanks, greg k-h
On Thu, 12 Nov 2015, Greg KH wrote:
On Thu, Nov 12, 2015 at 03:15:41AM -0700, Robert P. J. Day wrote:
short form: is there some reason that the usbhid "quirks" parameter is not by default compiled to be writable in case you wanted to adjust those values on a running system?
long form: i have a USB device that, sadly, is automatically claimed by the usbhid driver upon insertion, and i want to prevent that so it behaves as a regular USB device. from what i've read, the solution is to, at boot time, add the kernel command line parameter:
usbhid.quirks=0x2123:0x1010:0x04
that's fine if i want to reboot so that that takes effect, but it would of course be convenient if i could add that info to /sys/module/usbhid/parameters/quirks at run-time. currently, on my fedora 22 system:
$ cat /sys/module/usbhid/parameters/quirks (null),(null),(null),(null) $
with permissions:
$ ls -l /sys/module/usbhid/parameters/quirks -r--r--r--. 1 root root 4096 Nov 12 02:41 /sys/module/usbhid/parameters/quirks $
and i can see in drivers/hid/usbhid/hid-core.c the fact that that array is defined as non-writable:
/* Quirks specified at module load time */ static char *quirks_param[MAX_USBHID_BOOT_QUIRKS]; module_param_array_named(quirks, quirks_param, charp, NULL, 0444); MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying " " quirks=vendorID:productID:quirks" " where vendorID, productID, and quirks are all in" " 0x-prefixed hex");
so the obvious(?) question is, is there some reason that that parameter is defined as read-only rather than, say, writable by root? would it not be useful to be able to modify that parameter at run-time? or is there something about that parameter for which that would be a really bad idea?
You can add a runtime quirk to the device itself when it shows up in sysfs for the hid driver. Use that instead of the module parameter for that specific device.
sorry, i'm not sure what you're suggesting here. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
On Thu, 12 Nov 2015, Greg KH wrote:
You can add a runtime quirk to the device itself when it shows up in sysfs for the hid driver. Use that instead of the module parameter for that specific device.
sorry, i'm not sure what you're suggesting here.
I don't know if this was what Greg meant, but you can always use /sys/bus/usb/drivers/usbhid/unbind to unbind the device from the usbhid driver. Then you can manually bind it to some other driver supporting the same device using the same mechanism (with s/un// of course), or load another supporting driver to make it probe and bind the device. Hmm, I was going to point you to the file documenting bind/unbind for the usb bus, but it doesn't seem to exist? There you have a task for someone wanting to improve the docs :) Anyway, it goes like this: Look at the device driver binding in sysfs: $ ls -l /sys/bus/usb/drivers/usbhid total 0 lrwxrwxrwx 1 root root 0 Nov 13 09:06 4-4:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0 --w------- 1 root root 4096 Nov 13 09:06 bind lrwxrwxrwx 1 root root 0 Nov 13 09:06 module -> ../../../../module/usbhid -rw-r--r-- 1 root root 4096 Nov 13 09:06 new_id -rw-r--r-- 1 root root 4096 Nov 13 09:06 remove_id --w------- 1 root root 4096 Nov 13 09:06 uevent --w------- 1 root root 4096 Nov 13 09:06 unbind Unbind the device you want to move somewhere else: $ echo 4-4:1.0 >/sys/bus/usb/drivers/usbhid/unbind Bind it to 'otherdriver': $ echo 4-4:1.0 >/sys/bus/usb/drivers/'otherdriver'/bind (wich will only succeed of that driver's probe succeeds, of course. If you need to add a device ID to another driver, then do that using 'new_id' instead. Which will trigger automatic probing of 'free' devices) Bjørn
On Fri, 13 Nov 2015, Bjørn Mork wrote:
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
On Thu, 12 Nov 2015, Greg KH wrote:
You can add a runtime quirk to the device itself when it shows up in sysfs for the hid driver. Use that instead of the module parameter for that specific device.
sorry, i'm not sure what you're suggesting here.
I don't know if this was what Greg meant, but you can always use
/sys/bus/usb/drivers/usbhid/unbind
to unbind the device from the usbhid driver. Then you can manually bind it to some other driver supporting the same device using the same mechanism (with s/un// of course), or load another supporting driver to make it probe and bind the device.
ah, got it, thanks. i've never done that but the concept seems easy enough.
Hmm, I was going to point you to the file documenting bind/unbind for the usb bus, but it doesn't seem to exist? There you have a task for someone wanting to improve the docs :)
and that's one of the things i mention occasionally when newbies ask how to get started working on the kernel. write/improve the docs. what a perfect example.
Anyway, it goes like this: Look at the device driver binding in sysfs:
$ ls -l /sys/bus/usb/drivers/usbhid total 0 lrwxrwxrwx 1 root root 0 Nov 13 09:06 4-4:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0 --w------- 1 root root 4096 Nov 13 09:06 bind lrwxrwxrwx 1 root root 0 Nov 13 09:06 module -> ../../../../module/usbhid -rw-r--r-- 1 root root 4096 Nov 13 09:06 new_id -rw-r--r-- 1 root root 4096 Nov 13 09:06 remove_id --w------- 1 root root 4096 Nov 13 09:06 uevent --w------- 1 root root 4096 Nov 13 09:06 unbind
Unbind the device you want to move somewhere else:
$ echo 4-4:1.0 >/sys/bus/usb/drivers/usbhid/unbind
Bind it to 'otherdriver':
$ echo 4-4:1.0 >/sys/bus/usb/drivers/'otherdriver'/bind
(wich will only succeed of that driver's probe succeeds, of course. If you need to add a device ID to another driver, then do that using 'new_id' instead. Which will trigger automatic probing of 'free' devices)
thank you kindly, i'll give this a shot. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
participants (4)
-
Bjørn Mork -
Greg KH -
Robert P. J. Day -
Valdis.Kletnieks＠vt.edu