[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090120210254.GA5609@kroah.com>
Date: Tue, 20 Jan 2009 13:02:54 -0800
From: Greg KH <greg@...ah.com>
To: Michael Tokarev <mjt@....msk.ru>
Cc: Linux-kernel <linux-kernel@...r.kernel.org>,
Linux USB list <linux-usb@...r.kernel.org>
Subject: Re: "permanently" unbind a device from a driver?
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.
> 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 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