linux-kernel - Re: [linux-usb-devel] [RFC] HID bus design overview.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d120d5000703300913n6c4e7d54jc6054daffe81a1f@mail.gmail.com>
Date:	Fri, 30 Mar 2007 12:13:17 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Li Yu" <raise.sail@...il.com>
Cc:	"Jiri Kosina" <jkosina@...e.cz>, yanghong@...ss.com.cn,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>,
	hongzhiyi@...ss.com.cn, "Marcel Holtmann" <marcel@...tmann.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.

On 3/30/07, Li Yu <raise.sail@...il.com> wrote:
> I think I can understand your words. but I need confirm:
>
> Before specific driver register this device, the
> fundamental/standard/common(select one by your mind:) driver had already
> attach on it likely. At this case, we should detach this hid_device from
> its working driver, let this hid_device attach with our new specific
> driver. then new driver will handle all input event later, so the your
> words is same with the third choice in fact, is it right? if so, the
> actual behavior is same with former HID simple interface.
>

I was thinking that as we write customized drivers we would add them
(manually or automatically) to the HID blacklist so that generic
driver would not bind to such devices. Then, as your driver loads it
would parse reports and construct input device structure in the same
fashion that it processes the reports - if it is an "interesting"
report/usage it will handle setup itself; otherwise just call generic
setup function shared with the generic HID driver. This way there is
only one input device and there is no storm of add/remove events as we
loking for the proper driver to bind to the device.

Does this make sense?

This would not quite work for (potentially out of tree) HID drivers
brought in after compiling generic HID driver but that should be a
very rate occurance and we still can manually bind such drivers via
sysfs bind/unbind and new_id manipulations.

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