diff mbox series

[v2] HID: core: Call request_module before doing device_add

Message ID 20190402141846.11027-1-hdegoede@redhat.com (mailing list archive)
State Mainlined
Commit a025a18fecd4429f4ca66b1746001263c052ecbb
Delegated to: Jiri Kosina
Headers show
Series [v2] HID: core: Call request_module before doing device_add | expand

Commit Message

Hans de Goede April 2, 2019, 2:18 p.m. UTC
Recent kernels allow the generic-hid driver to be used as fallback for
devices with a specialized driver, when the hiddev is not listed in
hid_have_special_driver. Over time we are removing more and more
devices from the hid_have_special_driver table as devices get tested
to support this setup.

Before this commit the following happens when a HID device which has a
special-driver and is no longer listed in hid_have_special_driver, gets
enumerated:

1) device_add() gets called
2) bus_add_device() looks for a matching already registered hid driver,
   and bind hid-generic to the new device
3) kobject_uevent(&dev->kobj, KOBJ_ADD) gets called notifying userspace of
   the new hid_dev. udev calls modprobe based on the modalias in the uevent
4) The special driver gets loaded by modprobe
5) __hid_bus_reprobe_drivers() unbinds hid-generic and binds the new driver

There are a couple of downsides to this:

a) The probing messages printend when a HID driver bounds show up twice in
dmesg, which is confusing for the user

b) The (un)binding typically causes one or more evdev device-nodes to get
(un)registed firing of udev events to which e.g. the xserver responds by
(un)registering xinput devices and reporting this to interested clients.
IOW the i. bind generic, ii. unbind generic, iii. bind special driver dance
sets in motion a whole chain of events each step, while we really only want
the events from step iii. to be reported to userspace.

This commits introduces a request_module call before the device_add()
call, so that the special-driver is loaded when step 2) looks for a
matching driver and we directly bind the specialized driver.

Note the request_module call translates to an execve("/sbin/modprobe", ...)
and we now do this for each HID device added. So this is not entirely free,
but adding HID devices is not something which happens 100s of times a
second, so this should be fine.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Things work better if we don't add '\n' at the end of the modalias
---
 drivers/hid/hid-core.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Benjamin Tissoires April 2, 2019, 3:35 p.m. UTC | #1
On Tue, Apr 2, 2019 at 4:18 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Recent kernels allow the generic-hid driver to be used as fallback for
> devices with a specialized driver, when the hiddev is not listed in
> hid_have_special_driver. Over time we are removing more and more
> devices from the hid_have_special_driver table as devices get tested
> to support this setup.
>
> Before this commit the following happens when a HID device which has a
> special-driver and is no longer listed in hid_have_special_driver, gets
> enumerated:
>
> 1) device_add() gets called
> 2) bus_add_device() looks for a matching already registered hid driver,
>    and bind hid-generic to the new device
> 3) kobject_uevent(&dev->kobj, KOBJ_ADD) gets called notifying userspace of
>    the new hid_dev. udev calls modprobe based on the modalias in the uevent
> 4) The special driver gets loaded by modprobe
> 5) __hid_bus_reprobe_drivers() unbinds hid-generic and binds the new driver
>
> There are a couple of downsides to this:
>
> a) The probing messages printend when a HID driver bounds show up twice in
> dmesg, which is confusing for the user
>
> b) The (un)binding typically causes one or more evdev device-nodes to get
> (un)registed firing of udev events to which e.g. the xserver responds by
> (un)registering xinput devices and reporting this to interested clients.
> IOW the i. bind generic, ii. unbind generic, iii. bind special driver dance
> sets in motion a whole chain of events each step, while we really only want
> the events from step iii. to be reported to userspace.
>
> This commits introduces a request_module call before the device_add()
> call, so that the special-driver is loaded when step 2) looks for a
> matching driver and we directly bind the specialized driver.
>
> Note the request_module call translates to an execve("/sbin/modprobe", ...)
> and we now do this for each HID device added. So this is not entirely free,
> but adding HID devices is not something which happens 100s of times a
> second, so this should be fine.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> -Things work better if we don't add '\n' at the end of the modalias

Thanks a lot for spotting that. I have now queued it for 5.2.

Applied to for-5.2/core

Cheers,
Benjamin

> ---
>  drivers/hid/hid-core.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9993b692598f..b321bd08d94c 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2349,6 +2349,14 @@ int hid_add_device(struct hid_device *hdev)
>         dev_set_name(&hdev->dev, "%04X:%04X:%04X.%04X", hdev->bus,
>                      hdev->vendor, hdev->product, atomic_inc_return(&id));
>
> +       /*
> +        * Try loading the module for the device before the add, so that we do
> +        * not first have hid-generic binding only to have it replaced
> +        * immediately afterwards with a specialized driver.
> +        */
> +       request_module("hid:b%04Xg%04Xv%08Xp%08X",
> +                      hdev->bus, hdev->group, hdev->vendor, hdev->product);
> +
>         hid_debug_register(hdev, dev_name(&hdev->dev));
>         ret = device_add(&hdev->dev);
>         if (!ret)
> --
> 2.21.0
>
diff mbox series

Patch

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9993b692598f..b321bd08d94c 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2349,6 +2349,14 @@  int hid_add_device(struct hid_device *hdev)
 	dev_set_name(&hdev->dev, "%04X:%04X:%04X.%04X", hdev->bus,
 		     hdev->vendor, hdev->product, atomic_inc_return(&id));
 
+	/*
+	 * Try loading the module for the device before the add, so that we do
+	 * not first have hid-generic binding only to have it replaced
+	 * immediately afterwards with a specialized driver.
+	 */
+	request_module("hid:b%04Xg%04Xv%08Xp%08X",
+		       hdev->bus, hdev->group, hdev->vendor, hdev->product);
+
 	hid_debug_register(hdev, dev_name(&hdev->dev));
 	ret = device_add(&hdev->dev);
 	if (!ret)