Re: The problems for driver module loading
Alan Cox
>
> How can I do for this?
The easiest way is probably to submit some changes to cdc_ether to add
QMI support, or when submitting the QMI driver to also submit a patch to
cdc_ether to make it leave the device alone.
That doesn't help with exising systems however. What do the descriptors
for the hardware look like as cdc_* do actually try to avoid vendor
specific modem intefaces ?
Alan
--
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
> Dear All:
>
> I am sorry, I want to know is there the feature of priority (PRI) for
> kernel driver loading in Linux, such as in Windows or Mac OS.
No, Linux does not have that. It is really a "first driver
loaded/linked that wants to grab the driver, wins."
> I develop an independent ECM driver for our standard ECM ether device.
> And then I install it on some Linux system, such as OpenSUSE 11.0 or
> Fedora 10.
Why a separate driver? Why not just modify the existing one?
> But in these systems, they also have a built-in ECM driver
> cdc_ether.ko. So, while I plug in our device, then the system often
> attaches cdc_ether.ko driver for our device, but not attaching ours.
>
> Because cdc_ether.ko driver can not support our QMI protocol, so we
> want the Linux system can always attach our driver to our device, but
> not cdc_ether.ko driver.
>
> How can I do for this?
Add a blacklist entry in the cdc_ether driver.
Or, from userspace, unbind the device from cdc_ether and bind it to your
device. This can easily be done in userspace through sysfs using a
script triggered from udev.
Do you have a pointer to your driver anywhere?
thanks,
greg k-h