Load partially USB composite device
Hi everybody, In my project I have an USB composite device (a LTE modem) which use USB to communicate with the processor. This device has several interface to communicate but I do not use all of them. In particular, it loads cdc_ether device which I don't use and I have an undesired ethXX which interferes with a service in my system. To schematize, let's say my device is loaded on port 2 of usb1, I have the following USB topology: - 1-2:1.0: tty - 1-2:1.1: tty - 1-2:1.2: tty - 1-2:1.3: tty - 1-2:1.4: tty - 1-2:1.5: eth (not desired) Is there a way to prevent this specific ethXX to mount? I've already tried to create a udev rules, but I don't manage to stop the loading process. Here is a summary of my tries: 1/ I couldn't use the /sys/bus/usb1/.../1-2/activated file in my udev rule because it's an USB composite device and I want to use the tty interfaces but not the eth interface 2/ I have tried to stop the udev loading process, but setting MODALIAS environment variable to a NULL-string doesn(t do the trick and last-rule udev option has been removed in my udev version (1.8.2). 3/ I have tried to create a custom environment variable IGNORE_ETH and modify my last rule which run modprobe with the modalias variable. In the logs I see that modprobe isn't called by udev rules, but the cdc_ether device is loaded all the same. 4/ I have think of creating a stub cdc_ether driver and use the /etc/modprobe.d/my_file.conf to preempt the loading for my specific usb composite device but this solution is ugly and I'm not sure it will work. Any idea will be great. Best Regads Loic
loïc tourlonias <loic.tourlonias@gmail.com> writes:
Hi everybody,
In my project I have an USB composite device (a LTE modem) which use USB to communicate with the processor. This device has several interface to communicate but I do not use all of them. In particular, it loads cdc_ether device which I don't use and I have an undesired ethXX which interferes with a service in my system.
Sounds like your system has other issues, but whatever...
To schematize, let's say my device is loaded on port 2 of usb1, I have the following USB topology: - 1-2:1.0: tty - 1-2:1.1: tty - 1-2:1.2: tty - 1-2:1.3: tty - 1-2:1.4: tty - 1-2:1.5: eth (not desired)
Is there a way to prevent this specific ethXX to mount?
I've already tried to create a udev rules, but I don't manage to stop the loading process. Here is a summary of my tries: 1/ I couldn't use the /sys/bus/usb1/.../1-2/activated file in my udev rule because it's an USB composite device and I want to use the tty interfaces but not the eth interface
2/ I have tried to stop the udev loading process, but setting MODALIAS environment variable to a NULL-string doesn(t do the trick and last-rule udev option has been removed in my udev version (1.8.2).
3/ I have tried to create a custom environment variable IGNORE_ETH and modify my last rule which run modprobe with the modalias variable. In the logs I see that modprobe isn't called by udev rules, but the cdc_ether device is loaded all the same.
4/ I have think of creating a stub cdc_ether driver and use the /etc/modprobe.d/my_file.conf to preempt the loading for my specific usb composite device but this solution is ugly and I'm not sure it will work.
The cdc_ether driver treats any ID entry with .driver_info = 0 as a blacklist entry. So you can dynamically blacklist devices by writing the "VID PID" to /sys/bus/usb/drivers/cdc_ether/new_id before the device is probed. Bjørn
On Wed, Aug 9, 2017 at 9:25 AM, Bjørn Mork <bjorn@mork.no> wrote:
loïc tourlonias <loic.tourlonias@gmail.com> writes:
Thank's for the quick response
Hi everybody,
In my project I have an USB composite device (a LTE modem) which use USB to communicate with the processor. This device has several interface to communicate but I do not use all of them. In particular, it loads cdc_ether device which I don't use and I have an undesired ethXX which interferes with a service in my system.
Sounds like your system has other issues, but whatever...
I may not have been clear in my explanation. What seems wrong with my system?
To schematize, let's say my device is loaded on port 2 of usb1, I have the following USB topology: - 1-2:1.0: tty - 1-2:1.1: tty - 1-2:1.2: tty - 1-2:1.3: tty - 1-2:1.4: tty - 1-2:1.5: eth (not desired)
Is there a way to prevent this specific ethXX to mount?
I've already tried to create a udev rules, but I don't manage to stop the loading process. Here is a summary of my tries: 1/ I couldn't use the /sys/bus/usb1/.../1-2/activated file in my udev rule because it's an USB composite device and I want to use the tty interfaces but not the eth interface
2/ I have tried to stop the udev loading process, but setting MODALIAS environment variable to a NULL-string doesn(t do the trick and last-rule udev option has been removed in my udev version (1.8.2).
3/ I have tried to create a custom environment variable IGNORE_ETH and modify my last rule which run modprobe with the modalias variable. In the logs I see that modprobe isn't called by udev rules, but the cdc_ether device is loaded all the same.
4/ I have think of creating a stub cdc_ether driver and use the /etc/modprobe.d/my_file.conf to preempt the loading for my specific usb composite device but this solution is ugly and I'm not sure it will work.
The cdc_ether driver treats any ID entry with .driver_info = 0 as a blacklist entry. So you can dynamically blacklist devices by writing the "VID PID" to /sys/bus/usb/drivers/cdc_ether/new_id before the device is probed.
I have tried this and look at the source code of driver/usb/core/driver.c. But I think this is not what I required. What I understand is that the new_id file is used to dynamically add new USB id to the cdc_ether driver. What I want is the opposite, currently my device is loaded with cdc_ether.ko and I want this device to remain unloaded. Furthermore, after sending this email I have thought of renaming my device in an udev rule. But unfortunately, it passed by an eth0 state which I want to get rid of.
Bjørn
loïc tourlonias <loic.tourlonias@gmail.com> writes:
On Wed, Aug 9, 2017 at 9:25 AM, Bjørn Mork <bjorn@mork.no> wrote:
Sounds like your system has other issues, but whatever...
I may not have been clear in my explanation. What seems wrong with my system?
"ethXX which interferes with a service". It should not.
The cdc_ether driver treats any ID entry with .driver_info = 0 as a blacklist entry. So you can dynamically blacklist devices by writing the "VID PID" to /sys/bus/usb/drivers/cdc_ether/new_id before the device is probed.
I have tried this and look at the source code of driver/usb/core/driver.c. But I think this is not what I required. What I understand is that the new_id file is used to dynamically add new USB id to the cdc_ether driver.
True. But as I said: The cdc_ether driver use the device ID list for blacklisting. This is an implementation detail specific to this driver. It will use the .driver_info field as a pointer to usbnet specific data. But if the field is 0, then the entry becomes a blacklist entry instead. Dynamically added entries have all fields set to 0 by default, and will also be tried before the built-in entries (since v3.15). So adding a dynamic entry to the cdc_ether driver means adding a blacklist entry (Unless you explicitly reference an existing entry for inheritance). Try it. Bjørn
On Wed, Aug 9, 2017 at 10:15 AM, Bjørn Mork <bjorn@mork.no> wrote:
loïc tourlonias <loic.tourlonias@gmail.com> writes:
On Wed, Aug 9, 2017 at 9:25 AM, Bjørn Mork <bjorn@mork.no> wrote:
Sounds like your system has other issues, but whatever...
I may not have been clear in my explanation. What seems wrong with my system?
"ethXX which interferes with a service". It should not.
Agreed, but fixing our service is really complex, that's why I'm looking for a simple solution for this specific device before we have the resource to fix the service.
The cdc_ether driver treats any ID entry with .driver_info = 0 as a blacklist entry. So you can dynamically blacklist devices by writing the "VID PID" to /sys/bus/usb/drivers/cdc_ether/new_id before the device is probed.
I have tried this and look at the source code of driver/usb/core/driver.c. But I think this is not what I required. What I understand is that the new_id file is used to dynamically add new USB id to the cdc_ether driver.
True. But as I said: The cdc_ether driver use the device ID list for blacklisting. This is an implementation detail specific to this driver. It will use the .driver_info field as a pointer to usbnet specific data. But if the field is 0, then the entry becomes a blacklist entry instead.
Dynamically added entries have all fields set to 0 by default, and will also be tried before the built-in entries (since v3.15). So adding a dynamic entry to the cdc_ether driver means adding a blacklist entry (Unless you explicitly reference an existing entry for inheritance).
Try it.
I have (finally) understood how it works and I will try it a little bit harder and try to figure out why my first attempts doesn't work as expected. Thanks Loic
Bjørn
participants (2)
-
Bjørn Mork -
loïc tourlonias