"permanently" unbind a device from a driver?
Michael Tokarev
given device no matter how/when it gets plugged?
For example, there's a series of power supplies
(UPSes) with USB connection (common nowadays)
which, by default, gets claimed by usbhid module.
But it does not work as a HID device, instead it
uses a serial line logic and has a USB<=>serial
converter inside, which works just fine with
cypress_m8 usbserial driver.
usbhid module is loaded on startup (to handle
usb keyboards/mouses), and it claims this device
too. Using /sys/bus/.../drivers/usbhid/unbind
releases it, after which cypress_m8 works as
expected. But after re-plugging it gets claimed
by usbhid again.
I understand that it's easy to write an udev rule
(I don't use udev but that's another story) to
unbind the device from the driver and bind it to
another driver automatically. That's basically
what I have for now (handling hidraw* device).
But that seems somewhat... ugly, at best.
The question is: is it possible to tell usbhid
to STOP claiming devices with given vendor:device
identifier, from now on?
I also understand that to do it permanently the
given vendor:device has to be blacklisted in the
driver source. But I don't think it's worth the
effort. Sort of runtime blacklist support --
possible?
Thanks!
/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
> Is there a way to stop a module from claiming a
> given device no matter how/when it gets plugged?
>
> For example, there's a series of power supplies
> (UPSes) with USB connection (common nowadays)
> which, by default, gets claimed by usbhid module.
> But it does not work as a HID device, instead it
> uses a serial line logic and has a USB<=>serial
> converter inside, which works just fine with
> cypress_m8 usbserial driver.
>
> usbhid module is loaded on startup (to handle
> usb keyboards/mouses), and it claims this device
> too. Using /sys/bus/.../drivers/usbhid/unbind
> releases it, after which cypress_m8 works as
> expected. But after re-plugging it gets claimed
> by usbhid again.
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.
> I understand that it's easy to write an udev rule
> (I don't use udev but that's another story) to
> unbind the device from the driver and bind it to
> another driver automatically. That's basically
> what I have for now (handling hidraw* device).
> But that seems somewhat... ugly, at best.
>
> The question is: is it possible to tell usbhid
> to STOP claiming devices with given vendor:device
> identifier, from now on?
>
> I also understand that to do it permanently the
> given vendor:device has to be blacklisted in the
> driver source. But I don't think it's worth the
> effort.
Why wouldn't it be worth the effort? It's obviously a problem.
thanks,
greg k-h
Ming Lei
> On Tue, Jan 20, 2009 at 11:50:07PM +0300, Michael Tokarev wrote:
>> Is there a way to stop a module from claiming a
>> given device no matter how/when it gets plugged?
>>
>> For example, there's a series of power supplies
>> (UPSes) with USB connection (common nowadays)
>> which, by default, gets claimed by usbhid module.
>> But it does not work as a HID device, instead it
>> uses a serial line logic and has a USB<=>serial
>> converter inside, which works just fine with
>> cypress_m8 usbserial driver.
>>
>> usbhid module is loaded on startup (to handle
>> usb keyboards/mouses), and it claims this device
>> too. Using /sys/bus/.../drivers/usbhid/unbind
>> releases it, after which cypress_m8 works as
>> expected. But after re-plugging it gets claimed
>> by usbhid again.
>
> 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?
Thanks!
>
>> I understand that it's easy to write an udev rule
>> (I don't use udev but that's another story) to
>> unbind the device from the driver and bind it to
>> another driver automatically. That's basically
>> what I have for now (handling hidraw* device).
>> But that seems somewhat... ugly, at best.
>>
>> The question is: is it possible to tell usbhid
>> to STOP claiming devices with given vendor:device
>> identifier, from now on?
>>
>> I also understand that to do it permanently the
>> given vendor:device has to be blacklisted in the
>> driver source. But I don't think it's worth the
>> effort.
>
> Why wouldn't it be worth the effort? It's obviously a problem.
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Lei Ming
Greg KH
> 2009/1/21 Greg KH <gr...@kroah.com>:
> > On Tue, Jan 20, 2009 at 11:50:07PM +0300, Michael Tokarev wrote:
> >> Is there a way to stop a module from claiming a
> >> given device no matter how/when it gets plugged?
> >>
> >> For example, there's a series of power supplies
> >> (UPSes) with USB connection (common nowadays)
> >> which, by default, gets claimed by usbhid module.
> >> But it does not work as a HID device, instead it
> >> uses a serial line logic and has a USB<=>serial
> >> converter inside, which works just fine with
> >> cypress_m8 usbserial driver.
> >>
> >> usbhid module is loaded on startup (to handle
> >> usb keyboards/mouses), and it claims this device
> >> too. Using /sys/bus/.../drivers/usbhid/unbind
> >> releases it, after which cypress_m8 works as
> >> expected. But after re-plugging it gets claimed
> >> by usbhid again.
> >
> > 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?
Sam Liddicott
> On Wed, Jan 21, 2009 at 11:44:03PM +0800, Ming Lei wrote:
>
>> 2009/1/21 Greg KH <gr...@kroah.com>:
>>
>>> 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?
>
I've often felt that a /proc or /sys interface to allow blacklist
additions or quirk addition would be great.
Hacking of new devices often runs faster than distro's kernel releases;
it will often be very simple to distribute a 1 liner to make some
hardware available than tell people to wait until the next major release
of their distro.
As a point in instance, a couple of years ago I gave up trying to get
some quirks added for usb dual and quad joystick adaptors. I got them
added for one of them but not the other. It was just too much hard work.
I will say for the record that you, Greg, were very helpful, but all
told it was a couple of hours to build and test each quirk patch (I
didn't get the controllers at the same time), and then knowing that I
would either have to maintain my own out-of-distro kernel or wait about
18 months for my distro to get the patch - meant that the work was not
solving any immediate problem; so the pay-off in relation to the
scarcity of my time meant it just got forgotten.
An user-space post-boot uploadable quirk/blacklist would be great and
IMHO result in a bigger supply of quirks.
Sam
Greg KH
> * 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 <gr...@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?
> >
>
> 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 :)
It is a subsystem-specific thing as they all do their binding in
different ways, we can't make this "generic" very easily, sorry.
> Hacking of new devices often runs faster than distro's kernel releases;
> it will often be very simple to distribute a 1 liner to make some
> hardware available than tell people to wait until the next major release
> of their distro.
>
> As a point in instance, a couple of years ago I gave up trying to get
> some quirks added for usb dual and quad joystick adaptors. I got them
> added for one of them but not the other. It was just too much hard work.
Where did you send them? That shouldn't happen, sorry about that.
> An user-space post-boot uploadable quirk/blacklist would be great and
> IMHO result in a bigger supply of quirks.
Again, some subsystems, like HID already support this.
thanks,
greg k-h
Michael Tokarev
> 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 <gr...@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
Ming Lei
Yes.
>
> Care to send a patch?
Each low level subsystem(pci/usb/...) has its own
device id format and binding way, so it is impossible
to implement a generic blacklist mechanism in driver core.
It is even difficult to do the blacklist in low level
subsystem of usb. Quirk tables in drivers of high level
subsystem(hid/bt/...) contain information specific to
the high level subsystem,some of which is used to
ignore the device by driver, some of which is used to
do some fixes to support the device.
Maybe we can provide a blacklist mechanism in usb subsystem
to ignore some broken device for driver,but it can not replace the
existing quirks in drivers of high level subsystem.
>
> thanks,
>
> greg k-h
>
--
Lei Ming
Greg KH
> 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 <gr...@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.
No, add the device to the hid_ignore_list[] table in
drivers/hid/hid-core.c.
> >> 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... ;)
There is some way to do this, but I can't recall how at the moment. Try
asking the HID maintainer about this.
good luck,
greg k-h
Jiri Kosina
> > 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... ;)
> There is some way to do this, but I can't recall how at the moment.
> Try asking the HID maintainer about this.
There is a 'quirks=' parameter that can be passed to the usbhid driver.
Unfortunately the need for IGNORE_QUIRK went away when the whole hid stuff
got converted to proper bus with proper drivers.
But for backward userspace compatibility we want to have the
HID_IGNORE_QUIRK in place, solely for the purpose of users being able to
specify it during the module load, I agree. I currently have this queued
in my tree.
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index f0a0f72..eed05a3 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -711,6 +711,9 @@ static int usbhid_parse(struct hid_device *hid)
quirks = usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
le16_to_cpu(dev->descriptor.idProduct));
+ if (quirks & HID_QUIRK_IGNORE)
+ return -ENODEV;
+
/* Many keyboards and mice don't like to be polled for reports,
* so we will always set the HID_QUIRK_NOGET flag for them. */
if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT) {
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 81aa84d..da481b3 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -270,6 +270,7 @@ struct hid_item {
#define HID_QUIRK_INVERT 0x00000001
#define HID_QUIRK_NOTOUCH 0x00000002
+#define HID_QUIRK_IGNORE 0x00000004
#define HID_QUIRK_NOGET 0x00000008
#define HID_QUIRK_BADPAD 0x00000020
#define HID_QUIRK_MULTI_INPUT 0x00000040
--
Jiri Kosina
SUSE Labs