From: sashiko-bot@kernel.org
To: "Cristiano Souza" <cristianocps@gmail.com>, linux-sound@vger.kernel.org
Subject: Re: [PATCH v2] ALSA: usb-audio: Skip broken playback feature unit on XiiSound chips
Date: Sat, 07 Nov 2026 02:21:18 +0000 [thread overview]
Message-ID: <sashiko-outbox-202499@kernel.org> (raw)
In-Reply-To: <20261107020622.119529-1-cristianocps@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] ALSA: usb-audio: missing unit 5 re-pinning in
snd_usb_mixer_resume_quirk()
- [Medium] ALSA: usb-audio: missing short-read check in
snd_xiisound_init_fu_pins()
--
commit 599ffb39dcedddf5b2afe433d25ebe88e2031e78
Author: Cristiano Souza <cristianocps@gmail.com>
ALSA: usb-audio: Skip broken playback feature unit on XiiSound chips
This commit hides the broken playback feature unit (unit 5) on Weltrend
XiiSound devices (040b:0897) via usbmix_name_map and pins its volume to
maximum with mute cleared during mixer creation.
> diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c
> index 5839719444f8b..ee12bc7d1cacc 100644
> --- a/sound/usb/mixer_quirks.c
> +++ b/sound/usb/mixer_quirks.c
> @@ -4603,6 +4603,59 @@ static int snd_audiofuse_controls_create(struct usb_mixer_interface *mixer)
> return err;
> }
>
> +/*
> + * Weltrend XiiSound chips (040b:0897, e.g. Redragon H878):
> + * the playback feature unit (id 5) is broken; its volume controls act like
> + * mute switches below the maximum value and the channel mapping is
> + * unreliable, so the unit is hidden from userspace entirely (see the
> + * quirk in mixer_maps.c) and userspace falls back to software volume.
> + * Pin the unit's master and channel volumes to the reported maximum
> + * and unmute them, so the audio path stays fully open.
> + */
> +static int snd_xiisound_init_fu_pins(struct usb_mixer_interface *mixer)
> +{
> + struct snd_usb_audio *chip = mixer->chip;
> + unsigned char buf[2];
> + int ifnum, ch, err;
> +
> + if (mixer->protocol != UAC_VERSION_1)
> + return 0;
> +
> + ifnum = snd_usb_ctrl_intf(chip->ctrl_intf);
> +
> + /* unit 5 is the playback feature unit on these chips */
> + for (ch = 0; ch <= 2; ch++) {
> + err = snd_usb_ctl_msg(chip->dev, usb_rcvctrlpipe(chip->dev, 0),
> + UAC_GET_MAX,
> + USB_DIR_IN | USB_TYPE_CLASS |
> + USB_RECIP_INTERFACE,
> + (UAC_FU_VOLUME << 8) | ch,
> + (5 << 8) | ifnum, buf, 2);
> + if (err < 0)
> + return 0; /* no such unit/channels, nothing to pin */
> +
> + err = snd_usb_ctl_msg(chip->dev, usb_sndctrlpipe(chip->dev, 0),
> + UAC_SET_CUR,
> + USB_DIR_OUT | USB_TYPE_CLASS |
> + USB_RECIP_INTERFACE,
> + (UAC_FU_VOLUME << 8) | ch,
> + (5 << 8) | ifnum, buf, 2);
[Severity: Medium]
Can a short read from UAC_GET_MAX cause UAC_SET_CUR to send uninitialized
stack bytes from buf[]?
snd_usb_ctl_msg() returns the transferred byte count from usb_control_msg().
If UAC_GET_MAX returns 0 or 1 bytes, checking only err < 0 lets execution
proceed to UAC_SET_CUR, writing uninitialized stack memory on ch == 0 (or
buf[0] overwritten with 0 by UAC_FU_MUTE on ch > 0) to the hardware volume
control. Should this check err < 2 instead?
> + if (err < 0)
> + return err;
> +
> + buf[0] = 0; /* unmute */
> + err = snd_usb_ctl_msg(chip->dev, usb_sndctrlpipe(chip->dev, 0),
> + UAC_SET_CUR,
> + USB_DIR_OUT | USB_TYPE_CLASS |
> + USB_RECIP_INTERFACE,
> + (UAC_FU_MUTE << 8) | ch,
> + (5 << 8) | ifnum, buf, 1);
> + if (err < 0)
> + return err;
> + }
> + return 0;
> +}
> +
> int snd_usb_mixer_apply_create_quirk(struct usb_mixer_interface *mixer)
> {
> int err = 0;
> @@ -4616,6 +4669,9 @@ int snd_usb_mixer_apply_create_quirk(struct usb_mixer_interface *mixer)
> case USB_ID(0x0644, 0x8047):
> err = snd_us16x08_controls_create(mixer);
> break;
> + case USB_ID(0x040b, 0x0897):
> + err = snd_xiisound_init_fu_pins(mixer);
> + break;
[Severity: Medium]
Should snd_xiisound_init_fu_pins() also be called from
snd_usb_mixer_resume_quirk(), similar to dell_dock_mixer_init() for
USB_ID(0x0bda, 0x4014)?
Because xiisound_map ignores unit 5, __build_feature_ctl() never registers an
element in mixer->id_elems[5], so snd_usb_mixer_resume() ->
restore_mixer_value() will not restore unit 5 after a suspend/resume cycle
that resets the device, leaving playback audio muted or broken with no userspace
controls to recover it.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107020622.119529-1-cristianocps@gmail.com?part=1
prev parent reply other threads:[~2026-11-07 2:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 2:06 [PATCH v2] ALSA: usb-audio: Skip broken playback feature unit on XiiSound chips Cristiano Souza
2026-11-07 2:21 ` sashiko-bot [this message]
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=sashiko-outbox-202499@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=cristianocps@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.