public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Greg KH <greg@kroah.com>
Cc: Sam Liddicott <sam@liddicott.com>,
	Ming Lei <tom.leiming@gmail.com>,
	Linux-kernel <linux-kernel@vger.kernel.org>,
	Linux USB list <linux-usb@vger.kernel.org>
Subject: Re: "permanently" unbind a device from a driver?
Date: Thu, 22 Jan 2009 00:24:20 +0300	[thread overview]
Message-ID: <49779284.50603@msgid.tls.msk.ru> (raw)
In-Reply-To: <20090121181124.GA17410@kroah.com>

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@kroah.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

  reply	other threads:[~2009-01-21 21:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-20 20:50 "permanently" unbind a device from a driver? Michael Tokarev
2009-01-20 21:02 ` Greg KH
2009-01-21 15:44   ` Ming Lei
2009-01-21 16:23     ` Greg KH
2009-01-21 17:20       ` Sam Liddicott
2009-01-21 18:11         ` Greg KH
2009-01-21 21:24           ` Michael Tokarev [this message]
2009-01-28  6:19             ` Greg KH
2009-01-29  9:43               ` Jiri Kosina
2009-01-22  2:31       ` Ming Lei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49779284.50603@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sam@liddicott.com \
    --cc=tom.leiming@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox