Re: [PATCH v8 0/2] ALSA: usb-audio: the Topping M62's vendor controls

[Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>]

Found on my own bench while chasing something else, and I would rather
bring it than have it found for me.

The problem, as a user could see it: after unbinding the vendor
interface by hand, the driver keeps writing to the card. Reads stop --
the control freezes on its last announced value -- while writes go on
reaching the hardware, and the two-second keepalive presumably goes on
with them, into an interface the driver no longer owns.

  # echo 3-1.3:1.4 > /sys/bus/usb/drivers/snd-usb-audio/unbind
  # amixer -c M62 cget name='Mic-1 Analog Capture Volume'   # frozen
  # amixer -c M62 cset name='Mic-1 Analog Capture Volume' 50
  ... and the gain really moves on the card.

The sound card itself survives the unbind untouched, which is right and
is the good half of the result.

My reading of why, and I would be glad to be corrected on it. The quirk
claims that interface with usb_driver_claim_interface() and marks it
USB_AUDIO_IFACE_UNUSED, so usb_audio_disconnect() returns at its first
line and nothing ever tells the quirk to wind down. Meanwhile
usb_interrupt_msg() takes a struct usb_device and an endpoint address,
not an interface, so losing the claim costs the driver nothing on the
write path; the read path dies only because usbcore kills the URBs on
the interface being unbound.

So the claim is what keeps usbhid away, not what grants the right to
write, and the two are easy to conflate -- I had conflated them.

How reachable this is: only by hand from sysfs. A plain unplug takes
the whole device, and there disconnect runs on the audio interfaces and
the quirk is freed with the mixer. I have not found a path that reaches
it in ordinary use.

How I plan to solve it, and this is where I need your word, because the
change is in card.c rather than in my own file. An interface the quirk
claimed is marked exactly like one nobody wanted, and those two are
different things: the first has a driver behind it that should be told
when it goes away. The shapes I can see are

  (a) let the quirk register a small teardown callback at claim time
      and have usb_audio_disconnect() run it before the early return,

  (b) give the claimed-and-used case its own sentinel instead of
      USB_AUDIO_IFACE_UNUSED, so disconnect can tell them apart,

  (c) leave card.c alone and have the quirk take a usb_device
      reference plus its own notifier, which keeps the fix inside
      sound/usb/mixer_topping.c at the cost of a second path watching
      the same event.

I lean to (b) as the smallest honest change, but this is your file and
the sentinel is your convention.

Whichever you prefer, I would rather send it as a follow-up once the
current series lands than fold it into v9: it is a separate defect,
it touches a path shared by every quirk, and stirring it into a series
under review would make both harder to read.

Mikhail