Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

Re: HID bus

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


jirislaby at gmail

Apr 19, 2008, 3:38 PM

Post #1 of 10 (289 views)
Permalink
Re: HID bus

Hmm, I must admit, I didn't know how exactly autoloading works. On suse,
at least, module aliases are used. So autoloading works for me after this
patch and slight modifications of the previous patches. The pro of this
is that it's in-kernel modification of modpost phase.

Now, I wonder for exactly what purpose are module.*map files in
/lib/modules/`uname -r`/ dir, i.e. what would break, if the devices won't
be listed there on systems with unpatched module-init-tools.

--

Generate aliases for usb hid device modules to support autoloading.

Signed-off-by: Jiri Slaby <jirislaby[at]gmail.com>
---
include/linux/hid.h | 7 +++++++
include/linux/mod_devicetable.h | 8 ++++++++
scripts/mod/file2alias.c | 21 +++++++++++++++++++++
3 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/linux/hid.h b/include/linux/hid.h
index d951ec4..44c1b8b 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -29,11 +29,18 @@
* Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
*/

+#ifdef __KERNEL__
+#include <linux/mod_devicetable.h>
+#endif
+
/*
* USB HID (Human Interface Device) interface class code
*/

+/* this one is for userspace, we define this in linux/mod_devicetable.h */
+#ifndef USB_INTERFACE_CLASS_HID
#define USB_INTERFACE_CLASS_HID 3
+#endif

/*
* USB HID interface subclass and protocol codes
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 139d49d..2227c43 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -131,6 +131,14 @@ struct usb_device_id {
#define USB_DEVICE_ID_MATCH_INT_SUBCLASS 0x0100
#define USB_DEVICE_ID_MATCH_INT_PROTOCOL 0x0200

+#define USB_INTERFACE_CLASS_HID 3
+#define HID_ANY_ID (~0)
+
+struct hid_device_id {
+ __u32 vendor, product;
+ kernel_ulong_t driver_data;
+};
+
/* s390 CCW devices */
struct ccw_device_id {
__u16 match_flags; /* which fields to match against */
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 769b69d..d92445e 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -199,6 +199,23 @@ static void do_usb_table(void *symval, unsigned long size,
do_usb_entry_multi(symval + i, mod);
}

+/* Looks like: usb */
+static int do_hid_usb_entry(const char *filename,
+ struct hid_device_id *id, char *alias)
+{
+ __u16 v = TO_NATIVE((__u16)id->vendor);
+ __u16 p = TO_NATIVE((__u16)id->product);
+
+ strcpy(alias, "usb:");
+ ADD(alias, "v", id->vendor != HID_ANY_ID, v);
+ ADD(alias, "p", id->product != HID_ANY_ID, p);
+
+ sprintf(alias + strlen(alias), "d*dc*dsc*dp*ic%02Xisc*ip*",
+ USB_INTERFACE_CLASS_HID);
+
+ return 1;
+}
+
/* Looks like: ieee1394:venNmoNspNverN */
static int do_ieee1394_entry(const char *filename,
struct ieee1394_device_id *id, char *alias)
@@ -642,6 +659,10 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
else if (sym_is(symname, "__mod_usb_device_table"))
/* special case to handle bcdDevice ranges */
do_usb_table(symval, sym->st_size, mod);
+ else if (sym_is(symname, "__mod_hid_usb_device_table"))
+ do_table(symval, sym->st_size,
+ sizeof(struct hid_device_id), "hid_usb",
+ do_hid_usb_entry, mod);
else if (sym_is(symname, "__mod_ieee1394_device_table"))
do_table(symval, sym->st_size,
sizeof(struct ieee1394_device_id), "ieee1394",
--
1.5.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jirislaby at gmail

Apr 20, 2008, 4:57 AM

Post #2 of 10 (270 views)
Permalink
Re: HID bus [In reply to]

On 04/20/2008 12:38 AM, Jiri Slaby wrote:
> Now, I wonder for exactly what purpose are module.*map files in
> /lib/modules/`uname -r`/ dir, i.e. what would break, if the devices won't
> be listed there on systems with unpatched module-init-tools.

Well, used by /sbin/hotplug. I.e. on systems which uses that hotplugging system
and not new enough udev. It means older RHEL, SLE* et al., and older
distributions too...

So I suppose we still need the option to let users compile all the chosen
drivers into hid.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


anssi.hannula at gmail

Apr 20, 2008, 9:15 AM

Post #3 of 10 (266 views)
Permalink
Re: HID bus [In reply to]

Jiri Slaby wrote:
> Hmm, I must admit, I didn't know how exactly autoloading works. On suse,
> at least, module aliases are used. So autoloading works for me after this
> patch and slight modifications of the previous patches. The pro of this
> is that it's in-kernel modification of modpost phase.

Indeed in current systems udev uses module aliases for autoloading.

> --
>
> Generate aliases for usb hid device modules to support autoloading.
>
> Signed-off-by: Jiri Slaby <jirislaby[at]gmail.com>
[...]
> +/* Looks like: usb */

Looks like: "usb:vNpNd*dc*dsc*dp*ic3isc*ip*"

> +static int do_hid_usb_entry(const char *filename,
> + struct hid_device_id *id, char *alias)
> +{
> + __u16 v = TO_NATIVE((__u16)id->vendor);
> + __u16 p = TO_NATIVE((__u16)id->product);
> +
> + strcpy(alias, "usb:");
> + ADD(alias, "v", id->vendor != HID_ANY_ID, v);
> + ADD(alias, "p", id->product != HID_ANY_ID, p);
> +
> + sprintf(alias + strlen(alias), "d*dc*dsc*dp*ic%02Xisc*ip*",
> + USB_INTERFACE_CLASS_HID);
> +
> + return 1;
> +}

Oh, so we create a normal usb modalias entry anyway, not a custom
'usbhid:' one.

Why not just do something like

#define HID_DEVICE(vend, dev) \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
USB_DEVICE_ID_MATCH_INT_CLASS, \
.idVendor = (vend), \
.idProduct = (prod), \
.bInterfaceClass = USB_INTERFACE_CLASS_HID
(see linux/usb.h)

and use USB hotplugging?

Or do we plan to match against something else as well, such as hid
reports or something?

--
Anssi Hannula
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jirislaby at gmail

Apr 20, 2008, 11:07 AM

Post #4 of 10 (265 views)
Permalink
Re: HID bus [In reply to]

On 04/20/2008 06:15 PM, Anssi Hannula wrote:
> Oh, so we create a normal usb modalias entry anyway, not a custom
> 'usbhid:' one.

Arrr, thank you, this provoked me an idea. I'll repost the patch tomorrow or so.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jkosina at suse

Apr 21, 2008, 2:25 AM

Post #5 of 10 (263 views)
Permalink
Re: HID bus [In reply to]

On Sun, 20 Apr 2008, Anssi Hannula wrote:

> Why not just do something like
>
> #define HID_DEVICE(vend, dev) \
> .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
> USB_DEVICE_ID_MATCH_INT_CLASS, \
> .idVendor = (vend), \
> .idProduct = (prod), \
> .bInterfaceClass = USB_INTERFACE_CLASS_HID
> (see linux/usb.h)
>
> and use USB hotplugging?
> Or do we plan to match against something else as well, such as hid
> reports or something?

No, we plan to do matching based solely on VID/PID. The report-specific
stuff is then handled between the specific driver and HID generic code.

Thanks,

--
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dmitry.torokhov at gmail

Apr 21, 2008, 6:36 AM

Post #6 of 10 (263 views)
Permalink
Re: HID bus [In reply to]

On Mon, Apr 21, 2008 at 11:25:43AM +0200, Jiri Kosina wrote:
> On Sun, 20 Apr 2008, Anssi Hannula wrote:
>
> > Why not just do something like
> >
> > #define HID_DEVICE(vend, dev) \
> > .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
> > USB_DEVICE_ID_MATCH_INT_CLASS, \
> > .idVendor = (vend), \
> > .idProduct = (prod), \
> > .bInterfaceClass = USB_INTERFACE_CLASS_HID
> > (see linux/usb.h)
> >
> > and use USB hotplugging?
> > Or do we plan to match against something else as well, such as hid
> > reports or something?
>
> No, we plan to do matching based solely on VID/PID. The report-specific
> stuff is then handled between the specific driver and HID generic code.
>

Hmm, [ab]using USB modalias makes me a bit uneasy. What about bluetooth
HID devices?

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jirislaby at gmail

Apr 21, 2008, 4:05 PM

Post #7 of 10 (263 views)
Permalink
Re: HID bus [In reply to]

On 04/21/2008 03:36 PM, Dmitry Torokhov wrote:
> On Mon, Apr 21, 2008 at 11:25:43AM +0200, Jiri Kosina wrote:
>> On Sun, 20 Apr 2008, Anssi Hannula wrote:
>>
>>> Why not just do something like
>>>
>>> #define HID_DEVICE(vend, dev) \
>>> .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
>>> USB_DEVICE_ID_MATCH_INT_CLASS, \
>>> .idVendor = (vend), \
>>> .idProduct = (prod), \
>>> .bInterfaceClass = USB_INTERFACE_CLASS_HID
>>> (see linux/usb.h)
>>>
>>> and use USB hotplugging?
>>> Or do we plan to match against something else as well, such as hid
>>> reports or something?
>> No, we plan to do matching based solely on VID/PID. The report-specific
>> stuff is then handled between the specific driver and HID generic code.
>>
>
> Hmm, [ab]using USB modalias makes me a bit uneasy. What about bluetooth
> HID devices?

I do agree, it won't be nice and abstract enough. Working on it, give me some
time, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jkosina at suse

Apr 21, 2008, 5:00 PM

Post #8 of 10 (262 views)
Permalink
Re: HID bus [In reply to]

On Sun, 20 Apr 2008, Jiri Slaby wrote:

> So I suppose we still need the option to let users compile all the
> chosen drivers into hid.

Another possible workaround is to introduce dummy "hid" module, that will
just depend on all other drivers with a reference to certail symbol (and
this could of course be optional as CONFIG_HID_COMPAT, or whatever).

Thanks,

--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jirislaby at gmail

Apr 27, 2008, 4:22 AM

Post #9 of 10 (259 views)
Permalink
Re: HID bus [In reply to]

On 04/22/2008 02:00 AM, Jiri Kosina wrote:
> On Sun, 20 Apr 2008, Jiri Slaby wrote:
>
>> So I suppose we still need the option to let users compile all the
>> chosen drivers into hid.
>
> Another possible workaround is to introduce dummy "hid" module, that will
> just depend on all other drivers with a reference to certail symbol (and
> this could of course be optional as CONFIG_HID_COMPAT, or whatever).

If I understand correctly, it would create circular dependency:
hid->dummy_hid->hid_apple->hid

Is is correct?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jirislaby at gmail

May 9, 2008, 2:24 PM

Post #10 of 10 (233 views)
Permalink
Re: HID bus [In reply to]

On 04/22/2008 02:00 AM, Jiri Kosina wrote:
> On Sun, 20 Apr 2008, Jiri Slaby wrote:
>
>> So I suppose we still need the option to let users compile all the
>> chosen drivers into hid.

This won't work either. It wouldn't link due to multiple definitions of
module_init, module_exit and some module tables.

> Another possible workaround is to introduce dummy "hid" module, that will
> just depend on all other drivers with a reference to certail symbol (and
> this could of course be optional as CONFIG_HID_COMPAT, or whatever).

Actually this may work if we load hid_dummy by request_module from hid. I have
no other better idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.