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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0709141047580.24429@twin.jikos.cz>
Date:	Fri, 14 Sep 2007 10:55:46 +0200 (CEST)
From:	Jiri Kosina <jikos@...os.cz>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Adrian Bunk <bunk@...nel.org>, Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>,
	Oliver Neukum <oneukum@...e.de>,
	Matthew Dharm <mdharm-usb@...-eyed-alien.net>
Subject: Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6

On Thu, 13 Sep 2007, Alan Stern wrote:

> > Btw, this is in no way just an AUTOSUSPEND issue. The USB layer has a 
> > *lot* of these quirks. They are often called "UNUSUAL_DEV()", but the 
> > thing is, some of those things seem to be so usual that the naming is 
> > dubious, and thus calling it a "quirk" or "unusual" is pretty dubious 
> > too.
> You have concentrated your attention on the list for usb-storage,
> but the usbhid driver also has an impressively long quirks list.

This is true. First, there are HID_QUIRK_RDESC_* quirks, which we use to 
fix up badly broken report descriptor of certain devices before it enters 
the HID parser. There is nothing much we can do about them - these are 
just workarounds for really broken devices that don't follow the HID 
specification, but we can easily fix the things on the fly. Usually, these 
devices are handled in Windows by specialized driver, but if we fix the 
descriptor, we can use usbhid to handle them.

For the rest of the HID quirks -- most of them are also workarounds for 
broken classess of devices. Usually, they claim to be HID-compliant device 
in their file descriptor, but they do not follow the spec (they send 
inverted axes values, send usage codes that violate the specification, 
etc), but we can easily work around these bugs by a few lines of code and 
let the devices to be handled by usbhid flawlessly. I guess this is worth 
it.

Probably the only quirk entry that might be considered to be removed is 
HID_QUIRK_NOGET, I'd say.

Thanks,

-- 
Jiri Kosina
-
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