From: Takashi Iwai <tiwai@suse.de>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: tiwai@suse.com, perex@perex.cz, jikos@kernel.org,
bentiss@kernel.org, linux-sound@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 0/2] ALSA: usb-audio: the Topping M62's vendor controls
Date: Thu, 03 Sep 2026 10:30:45 +0200 [thread overview]
Message-ID: <87se3q91oq.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260826180607.324604-1-mikhail.v.gavrilov@gmail.com>
On Wed, 26 Aug 2026 20:06:07 +0200,
Mikhail Gavrilov wrote:
>
> 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.
Thinking more on this, I see another possibility. Namely, create an
individual HID driver like your previous plan 2, but instead of
creating an own snd_card object, use the component framework
(include/linux/component.h) for binding between the audio and the HID
drivers.
That is, in USB-audio side, you'll have a mixer quirk to add the
component master. In the HID driver, you'll register a component to
be bound. In the bind callback, the snd_card object is passed from
the USB-audio component master, and you can instantiate the mixer
kcontrols there.
At disconnection of USB-audio, the mixer quirk calls the component
unbind, and the HID component unbind callback frees the created
kcontrols in turn. If the HID is unbound first, it just unregister
the component (and frees the kcontrols). If the HID is re-bound, it
just re-adds the kcontrols at its bind callback again.
The component match might be a bit tricky, but it should be certainly
feasible.
thanks,
Takashi
next prev parent reply other threads:[~2026-09-03 8:31 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 17:10 snd-usb-audio: exposing a vendor HID control channel as mixer controls (Topping M62, 152a:875c) Mikhail Gavrilov
2026-08-13 7:24 ` Takashi Iwai
2026-08-20 15:13 ` [RFC 0/2] Two ways to reach the Topping M62's analogue gains Mikhail Gavrilov
2026-08-20 15:13 ` [RFC 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-20 15:13 ` [RFC 2/2] HID: topping: driver for the M62's vendor control channel Mikhail Gavrilov
2026-08-21 11:23 ` [RFC 0/2] Two ways to reach the Topping M62's analogue gains Mikhail Gavrilov
2026-08-23 8:50 ` Takashi Iwai
2026-08-23 14:22 ` [PATCH v2 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-08-23 14:22 ` [PATCH v2 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-23 14:22 ` [PATCH v2 2/2] ALSA: usb-audio: let the M62's outputs say what they listen to Mikhail Gavrilov
2026-08-23 19:48 ` [PATCH v3 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-08-23 19:48 ` [PATCH v3 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-23 19:48 ` [PATCH v3 2/2] ALSA: usb-audio: let the M62's outputs say what they listen to Mikhail Gavrilov
2026-08-23 22:29 ` [PATCH v4 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-08-23 22:29 ` [PATCH v4 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-23 22:29 ` [PATCH v4 2/2] ALSA: usb-audio: let the M62's outputs say what they listen to Mikhail Gavrilov
2026-08-24 20:13 ` [PATCH v5 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-08-24 20:13 ` [PATCH v5 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-24 20:13 ` [PATCH v5 2/2] ALSA: usb-audio: let the M62's outputs say what they listen to Mikhail Gavrilov
2026-08-24 22:31 ` [PATCH v6 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-08-24 22:31 ` [PATCH v6 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-24 22:31 ` [PATCH v6 2/2] ALSA: usb-audio: let the M62's outputs say what they listen to Mikhail Gavrilov
2026-08-25 8:56 ` [PATCH v7 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-08-25 8:56 ` [PATCH v7 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-25 8:56 ` [PATCH v7 2/2] ALSA: usb-audio: let the M62's outputs say what they listen to Mikhail Gavrilov
2026-08-25 11:12 ` [PATCH v8 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-08-25 11:12 ` [PATCH v8 1/2] ALSA: usb-audio: expose the Topping M62's analogue gains as mixer controls Mikhail Gavrilov
2026-08-25 11:12 ` [PATCH v8 2/2] ALSA: usb-audio: let the M62's outputs say what they listen to Mikhail Gavrilov
2026-08-26 18:06 ` [PATCH v8 0/2] ALSA: usb-audio: the Topping M62's vendor controls Mikhail Gavrilov
2026-09-03 8:30 ` Takashi Iwai [this message]
2026-09-03 9:35 ` Mikhail Gavrilov
2026-09-03 10:02 ` Takashi Iwai
2026-09-03 10:19 ` Mikhail Gavrilov
2026-09-04 0:18 ` Mikhail Gavrilov
2026-09-04 7:05 ` Mikhail Gavrilov
2026-09-04 11:26 ` [RFC PATCH 0/2] the Topping M62's vendor controls, on the component framework Mikhail Gavrilov
2026-09-04 11:26 ` [RFC PATCH 1/2] HID: topping-m62: driver for the M62's vendor controls Mikhail Gavrilov
2026-09-04 11:26 ` [RFC PATCH 2/2] ALSA: usb-audio: bind the Topping " Mikhail Gavrilov
2026-09-04 14:11 ` [RFC PATCH v2 0/2] the Topping M62's vendor controls, on the component framework Mikhail Gavrilov
2026-09-04 14:11 ` [RFC PATCH v2 1/2] HID: topping-m62: driver for the M62's vendor controls Mikhail Gavrilov
2026-09-04 14:11 ` [RFC PATCH v2 2/2] ALSA: usb-audio: bind the Topping " Mikhail Gavrilov
2026-09-04 14:42 ` [RFC PATCH v3 0/2] the Topping M62's vendor controls, on the component framework Mikhail Gavrilov
2026-09-04 14:42 ` [RFC PATCH v3 1/2] HID: topping-m62: driver for the M62's vendor controls Mikhail Gavrilov
2026-09-04 14:43 ` [RFC PATCH v3 2/2] ALSA: usb-audio: bind the Topping " Mikhail Gavrilov
2026-09-04 15:30 ` [RFC PATCH v4 0/2] the Topping M62's vendor controls, on the component framework Mikhail Gavrilov
2026-09-04 15:30 ` [RFC PATCH v4 1/2] HID: topping-m62: driver for the M62's vendor controls Mikhail Gavrilov
2026-09-04 15:30 ` [RFC PATCH v4 2/2] ALSA: usb-audio: bind the Topping " Mikhail Gavrilov
2026-09-04 16:22 ` [RFC PATCH v5 0/2] the Topping M62's vendor controls, on the component framework Mikhail Gavrilov
2026-09-04 16:22 ` [RFC PATCH v5 1/2] HID: topping-m62: driver for the M62's vendor controls Mikhail Gavrilov
2026-09-04 16:22 ` [RFC PATCH v5 2/2] ALSA: usb-audio: bind the Topping " Mikhail Gavrilov
2026-09-04 16:58 ` [RFC PATCH v6 0/2] the Topping M62's vendor controls, on the component framework Mikhail Gavrilov
2026-09-04 16:58 ` [RFC PATCH v6 1/2] HID: topping-m62: driver for the M62's vendor controls Mikhail Gavrilov
2026-09-04 16:58 ` [RFC PATCH v6 2/2] ALSA: usb-audio: bind the Topping " Mikhail Gavrilov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87se3q91oq.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=bentiss@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=mikhail.v.gavrilov@gmail.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox