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: <460C7EB4.9080009@gmail.com>
Date:	Fri, 30 Mar 2007 11:06:28 +0800
From:	Li Yu <raise.sail@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...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>, Li Yu <raise.sail@...il.com>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.

Dmitry Torokhov wrote:
> On 3/28/07, Jiri Kosina <jkosina@...e.cz> wrote:
>>
>> The crucial thing here is that all reports but the ones that the driver
>> registered to will be processed in a standard way by the generic hid bus
>> layer, and those reports that the driver registered to will be
>> ignored by
>> the layer, and passed for processing to the driver.
>>
>
> I don't think it is a good idea to register driver for specific
> usages/reports. Quite often you want to adjust processing of a report
> for a specific device. What if there are 2 devices that need such
> quirks? How will you do hotplug and module loading? Emit new uevent
> for every report? Also, what about users and Kconfig? "Driver for
> usage 0x000012345. Say Y if your hardware does not wotk correctly with
> defautl handler for this usage and require special processing"???
>
> Just register based on VID/PID and provide standard
> hid_default_input_event() to drivers so they would call it for reports
> they don't need to do special processing on.
>

    I think the shadow driver can not share inputdev with the related
fundamental driver, so here are two input devices for one hid_device,
how we should process both? It seem we have three choices:

1. Shadow | Fundamental means

    I think this is Jiri said. Fundamental driver handle all common
input events, and Shadow driver handle anther specific input events,
this imply user space process need monitor both input devices at same
time, I do not think this is good idea.

2. Shadow & Fundamental means

    Let Fundamental driver and Shadow driver work at same time! but
shadow also handle specific input event. So, the user may get twice
input events! For example, the keyboard input in console.
Also, I do not like this.

3. Shadow ^ Fundamental means

    Let Shadow driver handle every thing, and fundamental device silent,
even unregister it. I think this is best choice between them, this means
have a bit of complex.

Welcome for your words.

PS: Have we need more than one shadow driver for same fundamental
driver? I do not think so.

Good luck.

- Li Yu




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