From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Kyle Farrell <kaf@nwlink.com>
Cc: linux-usb@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v2 0/2 RESEND] usb: gadget: uac2: support explicit channel counts
Date: Sat, 17 Oct 2026 10:05:12 +0200 [thread overview]
Message-ID: <2026101742-ouch-sensually-f5a4@gregkh> (raw)
In-Reply-To: <20261016162534.384844-1-kaf@nwlink.com>
On Fri, Oct 16, 2026 at 09:25:32AM -0700, Kyle Farrell wrote:
> USB Audio Class 2.0 permits up to 255 channels in an audio channel cluster
> via bNrChannels. Independently, a channel-location bitmap is specified via
> bmChannelConfig for up to 27 predefined spatial locations. Setting
> bmChannelConfig to zero indicates that the channels have no predefined
> spatial positions.
>
> The current UAC2 gadget driver derives bNrChannels from the number of set
> bits in bmChannelConfig. Since bmChannelConfig provides 27 predefined
> spatial locations this limits playback and capture streams to 27 channels.
>
> This series allows channel counts up to the UAC2 limit of 255 without
> requiring predefined spatial channel locations in bmChannelConfig.
> Existing ConfigFS channel-mask configuration continues to work unchanged.
> New optional playback and capture count attributes allow the number of
> channels to be specified separately from the channel-location bitmap.
>
> The series is split so that the shared u_audio infrastructure is updated
> first without changing behavior, followed by the UAC2 functional change.
>
> Patch 1:
> Pass resolved playback and capture channel counts explicitly into
> the UAC1/UAC2 shared u_audio implementation instead of deriving them
> from channel masks.
>
> Patch 2:
> Add ConfigFS playback/capture channel-count attributes to the UAC2
> function driver and use them when generating descriptors and stream
> configuration, allowing counts beyond the 27 predefined channel
> locations.
>
> Testing
>
> Testing was performed using a Raspberry Pi Zero 2 W configured as a USB
> UAC2 gadget. Streaming and descriptor validation were performed against
> both Linux and macOS hosts. Windows hosts were not tested.
>
> UAC1
> - Verified playback/capture operation via alsaloop.
> - No descriptor or behavioral changes observed.
>
> UAC2
> - Verified legacy channel-mask configuration (1-27 channels).
> - Verified explicit channel-count mode with 2, 28, 61, 62, 96 channels.
> - Verified invalid channel-count/channel-mask combinations are rejected.
> - Verified Feature Unit descriptor size limits at 61/62 channel boundary.
> - Verified descriptors including:
> * bNrChannels
> * bmChannelConfig
> * Feature Unit presence and bLength
> * AudioControl wTotalLength
> * endpoint wMaxPacketSize
> - Verified ALSA-reported playback and capture channel counts.
> - Verified streaming using alsaloop.
>
> Changes in v2:
> - Edit commit messages for clarity and brevity.
> - Add Assisted-by: LLM attribution.
> - No code changes.
Why was RESEND needed here? Saying that would be nice.
Also, sashiko points out a number of problems...
thanks,
greg k-h
prev parent reply other threads:[~2026-10-17 8:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 16:25 [PATCH v2 0/2 RESEND] usb: gadget: uac2: support explicit channel counts Kyle Farrell
2026-10-16 16:25 ` [PATCH v2 1/2 RESEND] usb: gadget: u_audio: pass channel counts explicitly Kyle Farrell
2026-10-16 17:04 ` sashiko-bot
2026-10-16 16:25 ` [PATCH v2 2/2 RESEND] usb: gadget: f_uac2: allow explicit channel count independent of channel mask Kyle Farrell
2026-10-16 17:07 ` sashiko-bot
2026-10-17 8:05 ` Greg Kroah-Hartman [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=2026101742-ouch-sensually-f5a4@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=corbet@lwn.net \
--cc=kaf@nwlink.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
/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.