0

I've a RTL8153 based USB ethernet adapter, which uses the cdc_ether driver by default.

I want to use the r8152 driver, which could be loaded by creating a custom udev rule, as present in the Realtek's linux driver source.

But here's confusing part, when I plug-in the adapter, both of the cdc_ether and r8152 modules are loaded. My questions are,

  1. Why?
  2. How can I find the udev rule responsible for loading cdc_ether?
  3. How can I stop loading that module? As it's not necessary to load two modules in this case.

A line of the Udev rule

ACTION=="add", DRIVER=="r8152", ATTR{idVendor}=="2357", ATTR{idProduct}=="0601", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

The DRIVER== part is not necessary.

  • Have you tried blacklisting? Check your /etc/modprobe.d for examples. – Gerard H. Pille Feb 2 '18 at 15:13
  • No, I don't want to blacklist the module, as it's also used for USB tethering. Thanks ! – Arnab Feb 2 '18 at 15:16
  • Please read 3. carefully: "that module, it's not necessary" – Gerard H. Pille Feb 2 '18 at 18:23
  • Yeah, thanks for correcting. Forgot to explicitly mention that it's not necessary in this case, but needed by other devices. – Arnab Feb 3 '18 at 3:20
  • 1
    What is your kernel version? lkml.org/lkml/2017/9/25/711 – Gerard H. Pille Feb 3 '18 at 6:09
2
ACTION=="add", DRIVER=="r8152", ATTR{idVendor}=="2357", ATTR{idProduct}=="0601", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

The meaning of this udev rule is as follows: "When a device with idVendor value 2357 and idProduct value 0601 (and managed by driver "r8152") is added to the system, if its bConfigurationValue is not whatever value is defined in environment variable REALTEK_NIC_MODE, set its bConfigurationValueto that value."

In other words, this udev rule is not loading the r8152 driver, it's switching the device to the correct mode for that driver if necessary.

When a new device is added, Linux kernel basically runs modprobe with the hardware IDs (and some other things) of the device encoded in the "name" of the module it requests. This "name" is then compared by modprobe to wildcard strings embedded into each module as module aliases. The depmod command gathers up these alias names and stores them into /lib/modules/<kernel version>/modules.alias[.bin] for quick searching. You can view the alias strings embedded into kernel modules with the modinfo command.

For your USB ethernet adapter, the "name" is something like usb:v2357p0601d.... Unfortunately, the cdc_ether module has a wildcard alias that will match it too.

Any aliases defined in /etc/modprobe.d will take precedence over aliases embedded into modules themselves. So, you could probably specify an alias that will match your ethernet adapter and causes the r8152 module to be loaded instead.

Try adding this as /etc/modprobe.d/usbnic.conf:

alias usb:v2357p0601d*dc*dsc*dp*ic*isc*ip*in* r8152

Then run depmod -a as root, unplug the USB ethernet adapter, unload both the r8152 and cdc_ether modules, plug the ethernet adapter back in and see what happens. If only the r8152 module is loaded, good.

If the cdc_ether still gets loaded too, the alias might need to be more specific (i.e. one or more of the asterisks in it needs to be replaced with actual values, whatever they might be) in order for this alias to be the most specific and thus the "best" match.

Update: Here is a description of the module alias format: http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html

  • That's exactly what I was looking for, perfect solution. But I have a question, how did you calculated the wildcard alias? – Arnab Feb 3 '18 at 15:06
  • 1
    If you do a modinfo <any USB device driver> you'll see one or more examples. The first two elements are pretty obviously vendor and product IDs, and the rest is just following the format and replacing any other variables with wildcards. Full description here: people.skolelinux.org/pere/blog/… – telcoM Feb 3 '18 at 22:21
3

There's a patch for this problem in recent kernels: https://lkml.org/lkml/2017/9/25/711

  • That patch does not seem to match the vendor&product IDs of the original poster's device, so I'm afraid it would have no effect. But it would be a great model for making a similar patch for the OP's device. – telcoM Feb 4 '18 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.