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]
Message-ID: <2f05708e-3ee8-472e-a24f-6f3eb118133c@linux.intel.com>
Date:   Wed, 18 Oct 2023 08:47:40 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Wesley Cheng <quic_wcheng@...cinc.com>, mathias.nyman@...el.com,
        gregkh@...uxfoundation.org, lgirdwood@...il.com,
        broonie@...nel.org, perex@...ex.cz, tiwai@...e.com,
        agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, srinivas.kandagatla@...aro.org,
        bgoswami@...cinc.com, Thinh.Nguyen@...opsys.com
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        alsa-devel@...a-project.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v9 09/34] ASoC: qcom: qdsp6: Introduce USB AFE port to
 q6dsp


>>> Specifically, the QC ADSP can support all potential endpoints that are
>>> exposed by the audio data interface.  This includes, feedback endpoints
>>> (both implicit and explicit) as well as the isochronous (data)
>>> endpoints.
>>
>> implicit feedback means support for capture. This is confusing...
>>
> 
> I mean, a USB device can expose a capture path, but as of now, we won't
> enable the offloading to the audio DSP for it.  However, if we're
> executing playback, and device does support implicit feedback, we will
> pass that along to the audio DSP to utilize.

Not following. Implicit feedback means a capture stream *SHALL* be
started. Are you saying this capture stream is hidden and handled at the
DSP level only? If yes, what prevents you from exposing the capture
stream to userspace as well?

I must be missing something.

>>>   +static const struct snd_soc_dai_ops q6usb_ops = {
>>> +    .probe        = msm_dai_q6_dai_probe,
>>> +    .prepare    = q6afe_dai_prepare,
>>> +    .hw_params    = q6usb_hw_params,
>>
>> this is rather confusing with two different layers used for hw_params
>> and prepare? Additional comments or explanations wouldn't hurt.
>>
> 
> I thought this was how the ASoC design was.  Each DAI defined for a
> particular path has it own set of callbacks implemented to bring up any
> required resources for that entity.  So in this case, it initializes the
> "cpu" DAI, which is the main component that handles communication with
> the audio DSP.

Usually prepare and hw_params rely on the type of DAI callbacks, but
here you are mixing "q6afe" and "q6usb" which are shown in your Patch0
diagram as "cpu" and "codec" dais respectively. I don't think it's
correct to tie the two, it's a clear layering violation IMHO. The codec
dai .prepare should not invoke something that modifies the state of the
CPU dai, which should have its own .prepare callback.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ