As it's rather hard to correctly respond to your mails from web archives I'm simply going to respond here.
- [v4,1/4] Use dev->intf to get interface information: This is imho a bad idea; in cdc_ether `((..)(&dev->data))->control` is not necessarily the same as `dev->intf` (the "probed" interface); see the `rndis` quirk handling. To export `usbnet_cdc_update_filter` it needs a second parameter for the control interface imho ( or maybe it needs an explicit field in `struct usbnet`?); this requires a local wrapper function so it can be used as set_rx_mode hook. - [v3,2/4] Export usbnet_cdc_update_filter When rewriting the first patch this should probably just get merged into it. - [v3,3/4] Replace the way cdc_ncm hooks into usbnet_change_mtu Many "minidrivers" define their own `struct net_device_ops` set; if you want to refactor that you really have to change all of them. But I think it looks like the maintainers don't want that (i.e. they want const `net_device_ops` data). I see only the following option: export usbnet_set_rx_mode and use it in those drivers that use the set_rx_mode hook and have their own net_device_ops. - [v3,4/4] Hook into set_rx_mode to admit multicast traffic Fine, but needs to adapt to changes in the other patches (i.e. requires a local function that calls `usbnet_cdc_update_filter(dev, dev->intf);`, as in cdc_ncm the control interface actually always is the probed interface). I think some reviewer asked to add this in all mini drivers, but considering there is no generic control interface I don't think that is possible yet. Right now I'm running this set of patches: https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches I'm not sure why your patches got stuck ("ignored"); but one problem I see is that you didn't consistently prefix the subject with the subsystems. Sadly I also have to report that my docking station often resets (i.e. disconnects all devices, then reconnects); usually just for a few minutes after booting. With my new set of patches I couldn't reproduce it yet, but I think this might have been broken before your patches too, so not sure whether it is related in any way. I also sometimes get scary unregister_netdevice: waiting for endock to become free. Usage count = 11 messages (endock is my local interface name), which even prevent the kernel from shutting down. Perhaps they are related to those messages: ACPI Error: Thread 3936419840 cannot release Mutex [PATM] acquired by thread 3940941824 (20180531/exmutex-382) ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.ECDV._Q66, AE_AML_NOT_OWNER (20180531/psparse-516) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1779173 Title: Dell D6000 dock lacks multicast Ethernet functionality Status in Linux: Confirmed Status in linux package in Ubuntu: Triaged Bug description: Dell D6000 exposes a CDC_NCM device for Ethernet traffic. However, multicast Ethernet traffic is not processed making IPv6 not functional. Other services, like mDNS used for LAN service discovery are also hindered. The actual reason is that CDC_NCM driver was not processing requests to filter (admit) multicast traffic. I provide two patches to the linux kernel that admit all Ethernet multicast traffic whenever a multicast group is being joined. The solution is not optimal, as it makes the system receive more traffic than that strictly needed, but otherwise this only happens when the computer is connected to a dock and thus is running on AC power. I believe it is not worth the hassle to join only the requested groups. This is the same that is done in the CDN_ETHER driver. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1779173/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
