linux-kernel - Re: [RFC PATCH 3/5] HACK: ASoC: Tolerate N-cpus-to-M-codecs links

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]

Date:   Mon, 25 Apr 2022 15:55:32 +0200
From:   Martin Povišer <povik@...ebit.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Martin Povišer <povik+lin@...ebit.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mark Kettenis <kettenis@...nbsd.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>
Subject: Re: [RFC PATCH 3/5] HACK: ASoC: Tolerate N-cpus-to-M-codecs links


> On 25. 4. 2022, at 15:46, Mark Brown <broonie@...nel.org> wrote:
> 
> On Mon, Apr 25, 2022 at 03:11:14PM +0200, Martin Povišer wrote:
>>> On 25. 4. 2022, at 14:55, Mark Brown <broonie@...nel.org> wrote:
> 
>>> I am surprised that doesn't otherwise explode TBH - at the very least
>>> I'd expect it to show two PCMs to userspace which if I'm understanding
>>> your description correctly isn't really what's going on.
> 
>> I fill in a single snd_soc_dai_link, it exposes a single PCM and works
>> like a charm. That is as long as I patch the playback/capture check in
>> question.
> 
>> I read that to be the clear intention of ASoC code: a DAI link becomes
>> one snd_soc_pcm_runtime.
> 
> Yes, so long as you boil it down to a single link it works fine but the
> bit on top of the binding where you tie the two CPU DAIs to what is
> actually exposed is all in code.  The reason this stuff isn't filled in
> is that connecting the thing that applications see to the physical links
> isn't at all obvious and needs at least some driver sitting in the
> middle to make the links - I'd imagine there's a DSP sitting there which
> probably has quite a bit of flexability about how the various hardware
> components available are actually related.  This makes figuring out what
> to do with the relationship between the multiple CPU DAIs hard.

I get the gist. Anyway unless you tell me otherwise I will assume I need
to move to DPCM with the platform/machine driver.