linux-kernel - Re: [PATCH 1/4] ASoC: dt-bindings: document new symmetric-clock-role flag

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:   Mon, 5 Jun 2023 11:42:44 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Mark Brown <broonie@...nel.org>
CC:     Alvin Šipraga <alvin@...s.dk>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] ASoC: dt-bindings: document new symmetric-clock-role
 flag

On Fri, Jun 02, 2023 at 01:19:08PM +0100, Mark Brown wrote:
> On Fri, Jun 02, 2023 at 12:12:52PM +0000, Alvin Šipraga wrote:
> > On Fri, Jun 02, 2023 at 12:43:51PM +0100, Mark Brown wrote:
> 
> > > Why would we have a property for this and not just describe whatever the
> > > actual clocking arrangement is?
> 
> > Sure - let me just elaborate on my thinking and maybe you can help me with a
> > better approach:
> 
> > The clocking arrangement is encoded in the dai_fmt field of snd_soc_dai_link,
> > but this is a single value that describes the format on both ends. The current
> > behaviour of ASoC is to flip the clock roles encoded in dai_fmt when applying it
> > to the CPU side of the link.
> 
> > Looking from a DT perspective, if I do not specify e.g. bitclock-master on
> > either side of the link, then the dai_fmt will describe the codec as a bitclock
> > consumer and (after flipping) the CPU as a provider. That's the default
> > implication of the DT bindings and I can't break compatibility there.
> 
> None of this addresses my question.  To repeat why would we not just
> describe the actual clocking arrangement here - this property does not
> specify where the clock actually comes from at all, we're still going to
> need additional information for that and if we've described that clock
> then we already know it's there without having to specify any more
> properties.

Maybe I overcomplicated your point with my previous reply. Some questions to
clarify:

1. You don't like the DT property because it should be inferrable by other
means. Correct?

2. As for the flag added to snd_soc_dai_link, do you think that is an OK
approach?

Just want to understand which direction you would like me to focus the
effort.

Kind regards,
Alvin