linux-kernel - Re: [PATCH v23 32/32] ASoC: doc: Add documentation for SOC USB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <957b3c13-e4ba-45e3-b880-7a313e48c33f@quicinc.com>
Date: Fri, 26 Jul 2024 12:52:52 -0700
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Amadeusz Sławiński
	<amadeuszx.slawinski@...ux.intel.com>,
        <srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
        <perex@...ex.cz>, <conor+dt@...nel.org>, <corbet@....net>,
        <broonie@...nel.org>, <lgirdwood@...il.com>, <krzk+dt@...nel.org>,
        <Thinh.Nguyen@...opsys.com>, <bgoswami@...cinc.com>, <tiwai@...e.com>,
        <robh@...nel.org>, <gregkh@...uxfoundation.org>
CC: <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-sound@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <alsa-devel@...a-project.org>
Subject: Re: [PATCH v23 32/32] ASoC: doc: Add documentation for SOC USB

Hi Pierre/Amadeusz,

On 7/8/2024 4:16 PM, Wesley Cheng wrote:
> On 7/4/2024 4:25 AM, Pierre-Louis Bossart wrote:
>>>> Just so I understand...is it really desired that userspace doesn't
>>>> have the flexibility to choose which USB device is offloaded?  I know
>>>> it complicates what needs to be done, but it could be just an
>>>> additional feature that can be added later on.  Again, by default, we
>>>> select the last USB headset plugged in to be enabled for offload by
>>>> default.
>>> If it chooses endpoint by itself perhaps you can send patch set without
>>> controls first? This has added benefit of less patches in series, making
>>> it easier to review and it won't block whole patch set by discussion on
>>> controls feature. Controls can be added in followup series.
>> We do need read-only controls for userspace to know that offload is
>> possible and which card/device to use. That can be done in a first step
>> assuming there's a single device plugged-in.
> I agree, some kcontrol need to be present to at least determine:
>
> 1. USB SND device is offload capable (ASoC card and PCM index)- Fetches associated (mapped) ASoC platform card and PCM index (read only)
>
> 2. ASoC platform card offload status - Current offload status (read only)
>
> Those would be the minimum kcontrols we could have at this time.  I will remove the device selection part, and leave that for future discussions.  Does this sound good, Amadeusz/Pierre?

So I reworked the series a bit with respects to the kcontrols that we had, and I simplified it for the next submission.  I went ahead and just have a read only kcontrol residing in the USB SND device and will implement #1 above:

/ # tinymix -D 1 contents
Number of controls: 9
ctl     type    num     name                                    value
0       INT     2       Capture Channel Map                     0, 0 (range 0->36)
1       INT     2       Playback Channel Map                    0, 0 (range 0->36)
2       BOOL    1       Headset Capture Switch                  On
3       INT     1       Headset Capture Volume                  10 (range 0->13)
4       BOOL    1       Sidetone Playback Switch                On
5       INT     1       Sidetone Playback Volume                4096 (range 0->8192)
6       BOOL    1       Headset Playback Switch                 On
7       INT     2       Headset Playback Volume                 20, 20 (range 0->24)
8       INT     2       USB Offload Playback Route PCM#0        0, 0 (range -1->255)

If there is an available audio offload path, then the value will show the card and pcm index that it is mapped to.  That way the application will know which card/pcm device to open from there.  In the above example, the offload path is mapped to card#0 pcm#0.  If there is no offload path available, it will show -1, -1.

For now, I removed the control that allows for explicit selection of which USB card and PCM device to offload, and will take this up on a separate series as we see fit.  The codebase I have now will select the last USB headset plugged in for offloading.  Will clean up the changes and submit a new revision with the other feedback included as well.


Thanks

Wesley Cheng

>
>> Dealing with multiple devices and defining rules or configuration
>> options to select the offloaded device is a second-level problem.
>>
>> In most cases the only thing that will be offloaded is a headset
>> anyways, so the selection could be rather static based on a
>> vendor/system ID, all other USB devices would be ignored.
> If the USB SND offload driver (ie qc_audio_offload) isn't compiled in, then it would be disabled.  Do we need some over-arching mechanism to disable the offload functionality?  Although, one thing I can see if I can add is some device classification within the USB offload vendor driver.
>
> Thanks
>
> Wesley Cheng
>