Re: [RFC PATCH v6 0/2] the Topping M62's vendor controls, on the component framework

[Takashi Iwai <tiwai@suse.de>]

On Tue, 29 Sep 2026 19:29:02 +0200,
Mikhail Gavrilov wrote:
> 
> Hi Takashi,
> 
> A gentle ping on this. The problem is unchanged: on Linux the M62's
> preamp gains, output volumes and source selectors can only be set by
> hand on the front panel. v6 is the component split you suggested; v8
> stays posted as the alternative.
> 
> Since posting, v6 has run on the hardware as sent: all nine controls,
> panel and ALSA following each other, fifty module unload/load cycles
> and the cable pulled out mid-write three times, under KASAN and
> lockdep. Nothing in the log.
> 
> The one wart in the cover letter is worse than it says. Reloading the
> HID module takes the controls off a live card and puts them back, and
> ALSA reports that correctly, but WirePlumber does not merely lose its
> faders -- it segfaults. That is for WirePlumber to fix and an issue is
> open there, but it is a cost of this road that v8 does not have.
> 
> One thing points the other way. The card also reports its battery
> level unasked, and the natural home for that is a power_supply with
> device scope, as hid-corsair-void does. In a HID driver that is a
> small patch on top; on the v8 road it would have to be registered
> from a snd-usb-audio mixer quirk, and I cannot find anything there
> that does so. I have not written it and would like to know the road
> first.
> 
> So the question is the one from the cover letter: this road or v8?

If the implementation with the component works actually, I'm for it.
So, from the audio side, feel free to submit patches for upstreaming
without RFC.

> Jiri, Benjamin: the needs_remote_wakeup question is still open --
> whether clearing it after hid_hw_open() is acceptable, or whether
> usbhid should offer a way to take input reports without it.

There is a question which tree would take, too, but let's clarify the
issues in HID side at first.


thanks,

Takashi