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

Date: Fri, 21 Jun 2024 10:27:29 +0200
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Wesley Cheng <quic_wcheng@...cinc.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

> I'll spend some time to evaluate your suggestion about moving the logic
> to control the offloading from USB SND versus ASoC, since there are
> valid points.  However, before I do that, I just want to make sure folks
> are also inline with that thinking.  I've had to put a lot of effort
> moving things around such as the previous example, and now you've
> suggested to move it back to the vendor specific drivers.
> 
> @Pierre, since you've helped with providing a lot of valuable input in
> the previous revisions on the kcontrol uses, what do you think about the
> proposal from Amadeusz?  Basically shifting the offload device selection
> into USB SND from the ASoC USB BE driver, and having this per USB SND
> device.
> 
> [1]
> https://lore.kernel.org/linux-usb/20231017200109.11407-30-quic_wcheng@quicinc.com/

This thread is very hard to follow, I am not sure I fully understood the
initial proposal, and I am not sure I follow Amadeusz' either.

There are really multiple layers to deal with

a) is the controller able to support the offload path? IIRC this is
embedded in an obscure XHCI property, it would make sense to expose it
as a control, or component string, of the USB card.

b) is there a companion card capable of dealing with the offload path?
Since the presence of this card may depend on driver probe, there should
be a control on the USB card. userspace could detect changes to this
control and detect if that path is or is no longer enabled.

c) which PCM device is actually offloaded? This could be plural for some
implementations. The mapping between PCM devices exposed by the USB
card, and those exposed by the companion card, should be known to
userspace. I am not sure how this would be done though, a variable
number of controls is a sure way to confuse userspace.

At any rate, I would put all the controls under the USB generic card,
because it's always present no matter what the controller or DSP
configurations are.