Guys, I'm in an environment where I'm not allowed to make kernel changes. (Customer's development box, they've turned off updates, and believe that their current system is PERFECT).So, that means that upon insertion of my module, whenever that occurs, I have to see if my device is already inserted, and if it is, I have to disconnect it from usbhid, and claim it for my driver.The HID blacklist is a great idea, but I can't change the on-disk kernel, so I can't simply add this device to it, unless I do it at RUNTIME. And that requires doing shifty things like getting the address of usbhid_modify_dquirk from kallsyms, and calling it via a function pointer in order to accomplish this. This is an interim driver for a piece of development hardware that in all honesty, will never be submitted for inclusion in the kernel, as it'll only be used for a few months until the chip that replaces the hardware is done, at which point this driver gets punted. it truly is a "one-off driver". I hope this clears things up a bit, and explains why my methods of doing what seems to be really simple are always the toughest, most illegal, and most dangerous methods. Just trying to make something work within the constraints that I've been given. ---------------------------------------- > Date: Wed, 31 Aug 2011 08:36:35 -0700 > From: greg@xxxxxxxxx > To: chrisfurlough@xxxxxxxxxxx > CC: linux-usb@xxxxxxxxxxxxxxx > Subject: Re: HID device question. > > On Tue, Aug 30, 2011 at 08:20:04PM -0700, Chris Furlough wrote: > > OK, hopefully my last couple of questions: > > > > 1. From the kernel, what's the best way to enumerate the devices > > that are already plugged in? > > > > 2. I can use filp_open to open the devices in USBFS, this gives me > > a struct file, from which I can get the struct file_operations, from > > which I can get a pointer to the IOCTL function for that device. I > > can cast that as a function pointer, and call it, but I believe that > > it's expecting the last parameter to be a pointer to a buffer in > > userspace. Is there a correct way to handle this? > > Alan has pointed out how to do all of this, but again, these are all > things that you should not be doing, and are not allowed in any code you > want to have accepted into the kernel tree. > > What exactly are you trying to accomplish here? No kernel code should > EVER be opening usbfs files. > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
