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:	Sun, 02 Nov 2008 16:43:23 +1000
From:	Adam Nielsen <a.nielsen@...kadi.net>
To:	Jiri Kosina <jkosina@...e.cz>
CC:	LKML Mailinglist <linux-kernel@...r.kernel.org>
Subject: Driver for new hid class (was: Can you use the USB HID interface
 within a driver?)

>> For 2.6.28, the HID code has been completely refactored, and converted 
>> into a proper bus, making it possible to write driver easily in a way 
>> that the driver implements only parts where device deviates from the 
>> HID standard, and lets the rest to be handled by generic code. I guess 
>> this is what you are looking for?
> 
> Yes, that sounds like exactly what I'm after!  This device seems to be 
> HID with a custom protocol over the top, so presumably I can let the HID 
> driver handle all the USB initialisation and just focus on the protocol.

Okay, I've upgraded to 2.6.28-rc2 and started writing a driver for the 
new hid class.  It didn't take long for me to get stuck though :-(

When I load my module, it calls hid_register_driver() which returns 
0/success.  However that's as far as it gets.  I've defined a probe 
function to attach to the device, but this never gets called.

Is there something else I need to do?  The USB IDs are right, and I 
tried replugging the device with my "driver" loaded but it seems to be 
ignored.  It seems the device appears as a full HID input 
implementation, so it gets an evdev device associated with it.

Does this mean I need to blacklist it to stop the HID input driver from 
claiming it?  Or should my driver be able to claim it in preference to 
the input driver as mine is for a specific device, as opposed to the 
whole class?

Thanks,
Adam.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ