Comment 12 for bug 1779173

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)