linux-kernel - Re: [PATCH 2/9] ASoC: cygnus: Update bindings for audio clock changes

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:   Tue, 22 Aug 2017 17:07:03 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Lori Hikichi <lori.hikichi@...adcom.com>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        Jon Mason <jonmason@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/9] ASoC: cygnus: Update bindings for audio clock changes

On Wed, Aug 16, 2017 at 12:39:42PM -0700, Lori Hikichi wrote:

> By far the most common usage case for Cygnus is a configuration which
> uses only the three i2s/tdm ports. In this case each port is assigned
> a clock.  Each clock has the same capabilities so there would never be
> a reason change the static mapping.

The usual reason would be to bring things into sync.

> Now for the case when the "non-audio block" uses one of these clocks.
> In this situation we will only need one i2s port because this
> configuration of the chip is not audio intensive.  When the system
> is designed we know if this non-audio block will be in use, it is not
> a runtime configurable thing. Again, a static mapping is fine.

Is this limitation when the other block is in use a physical limitation
or is it just a case of not seeing the use case.

> At the time it did not seem necessary to make addition driver changes to
> support a use case that will very likely never arise. As it turns out,
> we are working on a new version of this audio block.  The clocking
> configuration for this new version is more complex and I am already in
> the process of creating clock bindings for all this this. I am hopeful
> that the driver for this new version will be applicable to Cygnus.

If the clocking is more complex that seems like even more reason to not
fix this in the binding, and possibly to do as I think I suggested
earlier and use the common clock bindings to manage this rather than
doing something custom and driver specific.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)