linux-kernel - Re: "permanently" unbind a device from a driver?

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: <49779284.50603@msgid.tls.msk.ru>
Date:	Thu, 22 Jan 2009 00:24:20 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Greg KH <greg@...ah.com>
CC:	Sam Liddicott <sam@...dicott.com>,
	Ming Lei <tom.leiming@...il.com>,
	Linux-kernel <linux-kernel@...r.kernel.org>,
	Linux USB list <linux-usb@...r.kernel.org>
Subject: Re: "permanently" unbind a device from a driver?

Greg KH wrote:
> On Wed, Jan 21, 2009 at 05:20:45PM -0000, Sam Liddicott wrote:
>> * Greg KH wrote, On 21/01/09 16:23:
>>> On Wed, Jan 21, 2009 at 11:44:03PM +0800, Ming Lei wrote:
>>>   
>>>> 2009/1/21 Greg KH <greg@...ah.com>:
>>>>     
>>>>> Just add a blacklist rule to the usbhid driver for this device.  There
>>>>> are a number of devices out there that need this functionality, which is
>>>>> why there is such a list.
>>>>>       
>>>> Is it possible to implement a generic blacklist mechanism in driver core
>>>> to support the function for all kinds of drivers? or is it necessary to do that?
>>>>     
>>> It's not necessary as the hid core already supports this very thing due
>>> to the need for it (it's the easiest way to write a userspace Windows
>>> driver, so lots of manufacturers lie about their devices in order to
>>> work around having to write a Windows kernel driver.)
>>>
>>> So just add this device to the hid core blacklist, and you are all set.
>>>
>>> Care to send a patch?

Ok, I'm looking at this now, but have a question:
which quirk code(s)/bits should I use for that?
Assuming the table in question is in
 drivers/hid/usbhid/hid-quirks.c
file.
What's needed is to stop usbhid module from claiming this device in the
first place.

>> I've often felt that a /proc or /sys interface to allow blacklist
>> additions or quirk addition would be great.
> 
> Some subsystems support this, like the HID subsystem :)

Oh, I didn't know.  In fact, that's exactly what I was asking in my
first email in this thread - to have some module parameter or a sysfs
file which can be touched to stop the module from claiming the device.
This also helps to debug it, to know the right bits to use.. which I
don't know...  ;)

The device in question which I'm dealing with is an UPS by Powercom,
Imperial series (they sold other series with UPS support too, namely
some KING PRO ones, which has exactly the same "interface").  It's

 Bus 001 Device 002: ID 0d9f:0002 Powercom Co., Ltd  Serial to USB adaptor

and this vendor:device is known to cypress_m8 driver, in
drivers/usb/serial/cypress_m8.[ch]:

 /* Powercom UPS, chip CY7C63723 */
 #define VENDOR_ID_POWERCOM               0x0d9f
 #define PRODUCT_ID_UPS                   0x0002

So here we go - I only need to know which quirk to use ;)

What I do *not* know is if there are other UPS model from the same
vendor with the same product ID but which really ARE HID devices.
But having in mind amount of questions asked about this very device,
all with the same answer (before it was "use this custom binary kernel
module", since 2.6.25 it's "use cypress_m8 driver"), i think it does
not matter anymore... ;)

Thanks!

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