Is blacklisting mt76x2u necessary?

[tristianc]

I have both the Xbox One slim dongle and a USB 802.11ac device that uses the mt76x2u driver.

I run Fedora 32 with kernel 5.6.11.

I noticed after running xow's make install that my wireless dongle was completely disabled. Once I realized that the module was blacklisted, this behavior made sense.

I wanted to see what conflicts would arise if the blacklist was disabled. When I removed /etc/modules/xow.blacklist and rebooted, the wifi dongle and the xbox dongle both continued to function.

I haven't tried this configuration long enough to determine if there are long term issues.

What was the reason for blacklisting mt76x2u?

[medusalix]

The reason for the blacklisting is that the mt76 driver causes issue for people using the older bulky dongle (see #14). There seems to be a race condition where both the mt76 driver and xow try to access the dongle at the same time which causes xow to terminate.
This issue originally only affected users of the older dongle, but it was only a matter of time until the mt76 developers would add the device id of the newer dongle too (see this commit). So as soon as these changes are going to land in the kernel, people without the blacklist might eventually run into the same issue with the newer dongle.

[tristianc]

Thank you for the background. I started looking around for a solution and found this.

I am thinking that instead of blacklisting the whole module, xow could unbind the Xbox dongles from the mt76x2u drivers.

Individual devices can be unbound from the kernel module that's used to handle them. In order to unbind a device from a module, you need the USB device's bus and port ids.

I presume this information can be obtained programmatically with libusb; it'd take me some time to figure that out how to use the library. For the sake of proving the concept, we can use lsusb -t to unbind an example device, my ASUS wireless dongle with the ID 0b05:17eb.

Running libusb -t reports:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 1: Dev 23, If 0, Class=Vendor Specific Class, Driver=mt76x2u, 5000M
        ID 0b05:17eb ASUSTek Computer, Inc. USB-AC55 802.11a/b/g/n/ac Wireless Adapter [MediaTek MT7612U]
    |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
        ID 0bda:0316 Realtek Semiconductor Corp.
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 2: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M
        ID 046d:c52b Logitech, Inc. Unifying Receiver
    |__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        ID 046d:c52b Logitech, Inc. Unifying Receiver
    |__ Port 2: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        ID 046d:c52b Logitech, Inc. Unifying Receiver
    |__ Port 8: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2118 Acer, Inc
    |__ Port 8: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2118 Acer, Inc

Based on the tree, I know the device can be addressed via the path 2-1:1.0. I know it's a USB device already, and I know its driver, so I can run:

echo -n '2-1:1.0' > /sys/bus/usb/drivers/mt76x2u/unbind

Once that happens, the kernel module shouldn't fight with xow anymore to communicate with the device.

I think xow could:

1. identify if USB devices with IDs 045e:02fe or 045e:02e6 are present
2. identify if the devices are already bound to a driver
3. unbind them
4. Occassionally check if they've been rebound? (I'm not certain this is necessary)
5. rebind the devices when xow is cleanly shutdown

Does this sound like a sane approach? It'd take me some time to try this out, but I'd like to.

[medusalix]

Does this sound like a sane approach? It'd take me some time to try this out, but I'd like to.

Definitely. I'm not sure if it'll work though. As far as I know, libusb includes libusb_set_auto_detach_kernel_driver which I've tried to add to xow in a previous version and it unfortunately didn't solve the problem. I haven't tried manually detaching the driver with libusb_detach_kernel_driver though.
The call to libusb_reset_device in usb.cpp might also be problematic, since that might be causing the kernel driver to reattach.

[medusalix]

I've just tried using the openwrt/mt76 driver (which includes the device ids for the newer dongle) and xow at the same time and this is what happens (dmesg):

usbfs: interface 0 claimed by mt76x2u while 'xow' sets config #1

Now that I can reliably reproduce this issue, I'll see if I can find a workaround.

[medusalix]

@tristianc Summary so far:

• libusb_set_auto_detach_kernel_driver doesn't work at all, xow can't configure the device
• libusb_detach_kernel_driver does its job, but xow is unable to reset the dongle's firmware leading to a timeout
• ATTR{authorized}="0" (udev) doesn't prevent the mt76 driver from binding to the dongle

But I think I've found a much better solution: Replace the contents of /etc/modprobe.d/xow-blacklist.conf with the following:

alias usb:v045Ep02E6d*dc*dsc*dp*ic*isc*ip*in* xow_blacklist
alias usb:v045Ep02FEd*dc*dsc*dp*ic*isc*ip*in* xow_blacklist

This instructs the kernel to load the xow_blacklist module, which doesn't exist and prevents the mt76x2u driver from binding to the Xbox dongle. Your wireless dongle should still use the mt76x2u driver. Please give it a try.

EDIT: Changes have been merged to master.

[tristianc]

This worked for me while using the slim dongle. My aforementioned wireless dongle still remains active when the new blacklist file is available at boot.