Thanks for the reply. But the problem is, my device is compatible with Mass Storage Class driver as well. If my custom driver is present in kernel i want custom driver to be loaded. But when my customer driver is not present default storage driver should be loaded. I want my custom driver should have more preference over default storage driver when both drivers are present in kernel. Is there any unique way to categorize both drivers. Regards, Madhukar On Wed, Feb 4, 2009 at 6:00 PM, Paulius Zaleckas <paulius.zaleckas@xxxxxxxxxxxx> wrote: > > > Madhukar G wrote: >> Hi All, >> >> I'm developing a USB class driver for a custom device which is >> something similiar to Mass Storage Device (USB Stick). I can modify >> the exisiting storage class driver provided in /drivers/usb/storage. >> But i thought of keeping the original driver in the directory. I had >> taken a copy of storage and renamed to USBCustom and did the required >> modifications in code. But still lot of modifications left. >> >> Now, i want to load my driver when device is plugged in. But core >> always probes default storage driver. By the way, the device class of >> my device is USB_CLASS_MASS_STORAGE. So, storage driver is loaded by >> default. > > IMO thats the way it should be... > >> Also, i dont want to depend of VendorId and DeviceId for >> probing. > > But that is almost the only way to tell kernel to use another driver. > How to distinguish between your device and usual USB Flash drive? > >> How can i tell USB core to load my custom driver instead of default >> storage driver. > > rmmod <old_driver> > insmod <new_driver> > >> Any help is much appreciated. >> >> Thank you. >> >> Regards, >> Madhukar >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@xxxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- 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
