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:   Fri, 2 Jun 2023 12:12:52 +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

Hi Mark,

On Fri, Jun 02, 2023 at 12:43:51PM +0100, Mark Brown wrote:
> On Fri, Jun 02, 2023 at 11:03:18AM +0200, Alvin Šipraga wrote:
> > From: Alvin Šipraga <alsi@...g-olufsen.dk>
> > 
> > The new flag specifies that both ends of the dai-link have the same
> > clock consumer/provider role. This should be used to describe hardware
> > where e.g. the CPU and codec both receive their bit- and frame-clocks
> > from an external source.
> 
> 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.

The other issue is that for the simple-card the DAI format is only parsed in one
place and applied to the whole link. Are you proposing that it be modified to
explicitly try and parse both ends in order to determine if both sides want to
be clock consumers? In that case I'd have to also introduce bitclock-consumer
and frameclock-consumer properties to mirror the existing bitclock-master and
frameclock-master properties, as an explicit absence of the *-master property on
both sides would have to default to the original ASoC behaviour described above.

Or did you have something else in mind?

Thanks for your review.

Kind regards,
Alvin