From: kaf@nwlink.com
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 08:56:15 -0700 [thread overview]
Message-ID: <fef8f9aa36c922e846d37e686b38f6c3@nwlink.com> (raw)
In-Reply-To: <2026101742-ouch-sensually-f5a4@gregkh>
On 2026-10-17 01:05, Greg Kroah-Hartman wrote:
> 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
I resent v2 as both it and v1 had received no review. I should have
stated
that in the cover letter.
I'm reviewing the Sashiko findings and will address relevant issues
before
submitting a revised series.
Thanks,
Kyle
prev parent reply other threads:[~2026-10-17 15:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 16:25 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 16:25 ` [PATCH v2 2/2 RESEND] usb: gadget: f_uac2: allow explicit channel count independent of channel mask Kyle Farrell
2026-10-17 8:05 ` [PATCH v2 0/2 RESEND] usb: gadget: uac2: support explicit channel counts Greg Kroah-Hartman
2026-10-17 15:56 ` kaf [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=fef8f9aa36c922e846d37e686b38f6c3@nwlink.com \
--to=kaf@nwlink.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®