linux-kernel - Re: [PATCH v30 00/30] Introduce QC USB SND audio offloading support

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>] [day] [month] [year] [list]

Message-ID: <e7b8f141-efd4-4933-b074-641638914905@intel.com>
Date: Wed, 4 Dec 2024 23:11:28 +0100
From: Cezary Rojewski <cezary.rojewski@...el.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
CC: Wesley Cheng <quic_wcheng@...cinc.com>, Takashi Iwai <tiwai@...e.de>,
	"Greg KH" <gregkh@...uxfoundation.org>, <srinivas.kandagatla@...aro.org>,
	<mathias.nyman@...el.com>, <perex@...ex.cz>, <conor+dt@...nel.org>,
	<dmitry.torokhov@...il.com>, <corbet@....net>, <broonie@...nel.org>,
	<lgirdwood@...il.com>, <krzk+dt@...nel.org>, <Thinh.Nguyen@...opsys.com>,
	<tiwai@...e.com>, <robh@...nel.org>, <linux-kernel@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <linux-sound@...r.kernel.org>,
	<linux-usb@...r.kernel.org>, <linux-input@...r.kernel.org>,
	<linux-arm-msm@...r.kernel.org>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v30 00/30] Introduce QC USB SND audio offloading support

On 2024-12-04 8:47 PM, Pierre-Louis Bossart wrote:
> 

...

>> UAOL is one of our priorities right now and some (e.g.: me) prefer to 
>> not pollute their mind with another approaches until what they have in 
>> mind is crystalized. In short, I'd vote for a approach where USB 
>> device has a ASoC representative in sound/soc/codecs/ just like it is 
>> the case for HDAudio. Either that or at least a ASoC-component 
>> representative, a dependency for UAOL-capable card to enumerate.
> 
> The main difference is that we don’t want the USB audio *control* part 
> to be seen in two places. The only requirement is to stream data with an 
> alternate optimized path, but all the volume control and whatnot is 
> supposed to be done using the regular usb-audio card. It would be 
> complete chaos for userspace if the same volume can be represented 
> differently.
> 
> The comparison with HDaudio is not quite right either. In the case of 
> HDaudio, it’s an all-or-nothing solution. The external device is 
> controlled by one entity, either legacy or ASoC based. That choice is 
> made at driver probe time. In the case of USB, the application needs to 
> have the choice of using either the legacy path, or the optimized path 
> that goes through a DSP. I think the last thing you want given this 
> context is to make the USB audio device an ASoC codec.
> 
> I find it rather interesting that this architectural feedback comes at 
> the v30, it’s unfair to Wesley really...
> 

Hi Pierre,

Obviously I'm late. After scanning the history of this one, indeed it's 
been a while since v1 has been sent. And thus I posted no NACKs. At the 
same time if I am to choose between: provide feedback vs provide 
no-feedback, I'd rather choose the former even if I'm to be 
ignored/overridden by a subsystem maintainer.

The subsystem maintainers also hold the last word, and I have no problem 
with them merging the patches if they believe its existing shape is 
good-enough. For example, my team could follow up this implementation 
next year with a patchset expanding/updating the functionality. I see 
this as a viable option.

Kind regards,
Czarek