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]

Date:	Mon, 2 Apr 2007 00:15:43 -0400
From:	Dmitry Torokhov <dtor@...ightbb.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 Sunday 01 April 2007 21:47, Li Yu wrote:
> Let me explain the internal of my current HID bus implementation. I
> think that selecting one user scene as example is good idea.
> 
> Well, the user A plug a USB joystick into computer. The work processing
> of HID subsystem for this joystick is same with our mind: The USB/base
> driver works for it. However, the world is not faultless. This joystick
> is buggy, its some keys need specific handling, our good friend udev
> discover that there is also have another driver can handle it, so it
> insert that kernel module, then our sweet leading role specific/shadow
> HID driver appear on scene. Registering shadow driver let HID core clone
> a hid_device first, and start new usage configuration processing for new
> cloned hid_device (if we like, even I think we can reread reports from
> physical device), the shadow driver can join with HID core to
> custom/hook in this recofiguration processing. If this shadow driver is
> input-able, the HID core will unregister working input device come from
> USB/base hid_device, and register new input device for this shadow
> hid_device. So we have not two input_dev for one HID device at same time.
>

No, please don't do that. As soon as there is a special driver written
for a device that device's VID/PID should be added to generic HID
blacklist. This way udev will load the proper driver right away and
there will not be any flip-flopping of input devices. 
 
> When user A remove this shadow driver, the USB/base driver should resume
> work for this joystick, IOW, it should register back its input device again.
> 

Why would we want to revert to using generic HID's implementation if we
know that it is broken for that particular device???

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