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: <81d106c0-e1c8-a79a-8caf-1f3be0d61f0c@nvidia.com>
Date:   Tue, 30 Jun 2020 18:23:49 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     Mark Brown <broonie@...nel.org>
CC:     <spujar@...dia.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        <perex@...ex.cz>, <tiwai@...e.com>, <robh+dt@...nel.org>,
        <lgirdwood@...il.com>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <digetx@...il.com>,
        <alsa-devel@...a-project.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <sharadg@...dia.com>,
        <mkumard@...dia.com>, <viswanathl@...dia.com>,
        <rlokhande@...dia.com>, <dramesh@...dia.com>,
        <atalambedu@...dia.com>, <nwartikar@...dia.com>,
        <swarren@...dia.com>, <nicoleotsuka@...il.com>
Subject: Re: Re: [PATCH v4 12/23] ASoC: simple-card: Support DPCM DAI link
 with multiple Codecs



On 6/30/2020 4:31 PM, Mark Brown wrote:
> On Tue, Jun 30, 2020 at 01:22:29PM +0530, Sameer Pujar wrote:
>
>> Yes there are complex use cases, but if we look at the amount of changes
>> required in simple-card driver that is not too much. Existing binding for
>> simple-card driver would still work fine for our cases. Yes there are some
>> deviations and we don't want to break existing users, that is why a *new*
>> compatible was introduced and specific items can be pushed under it.
>> Majority of the simple-card driver is getting re-used here. We just need to
>> make sure it does not affect anyone else.
> Why simple-card and not audio-graph-card?

Frankly speaking I have not used audio-graph-card before. I had a brief 
look at the related binding. It seems it can use similar DT properties 
that simple-card uses, although the binding style appears to be 
different. However I am not sure if it offers better solutions to the 
problems I am facing. For example, the ability to connect or form a 
chain of components to realize more complicated use cases with DPCM, 
some of which were discussed in [0]. Can you please help me understand 
why it could be preferred?

[0] https://lkml.org/lkml/2020/4/30/519

>>> Using fe/be instead of cpu/codec is easy to understand.
>> I guess you are referring to DT binding part. The parsing code specifically
>> looks for "codec" sub node and thus present conventions had to be used.
> Remember that this stuff gets fixed into the ABI so we'd have to live
> with this for ever.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ