is there a reason "usbhid.quirks" parameter is not root writable?

is there a reason "usbhid.quirks" parameter is not root writable?

[Robert P. J. Day]

  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
========================================================================

is there a reason "usbhid.quirks" parameter is not root writable?

[Greg KH]

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

is there a reason "usbhid.quirks" parameter is not root writable?

[Valdis.Kletnieks at vt.edu]

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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151112/a7eb0f33/attachment.bin 

is there a reason "usbhid.quirks" parameter is not root writable?

[Greg KH]

On Thu, Nov 12, 2015 at 08:02:00PM -0500, Valdis.Kletnieks at 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

is there a reason "usbhid.quirks" parameter is not root writable?

[Robert P. J. Day]

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
========================================================================

is there a reason "usbhid.quirks" parameter is not root writable?

[Bjørn Mork]

"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

is there a reason "usbhid.quirks" parameter is not root writable?

[Robert P. J. Day]

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
========================================================================