linux-kernel - Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties

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]

Message-ID: <20210115183527.GG4384@sirena.org.uk>
Date:   Fri, 15 Jan 2021 18:35:27 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc:     Rob Herring <robh@...nel.org>, kuninori.morimoto.gx@...esas.com,
        nsaenzjulienne@...e.de, f.fainelli@...il.com,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        alsa-devel@...a-project.org, patches@...nsource.cirrus.com,
        bcm-kernel-feedback-list@...adcom.com,
        linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and
 sysclks properties

On Fri, Jan 15, 2021 at 04:15:21PM +0000, Richard Fitzgerald wrote:

> If I do:
>  	sound {
>  		clocks = <&clock>;
>  	};
> 
> 	clock: clock {
> 		compatible = "fixed-clock";
> 		clock-frequency = <98304000>;
> 	};
> 
> I can clk_bulk_get_all().
> But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
> will return -EPROBE_DEFER and log:

OK, so if this is only supposed to represent a fixed clock on the board
separate to the CODEC then yes, of course you do need to instantiate a
driver for it like you do for every device on the board.  However it
shouldn't be a subdevice of the CODEC as you had it originally, it
should be a distinct device as the above has it since that is what
physically exists.  This obviously won't configure the FLL at all though
(which was what the binding you were proposing was for, the above is
definitely not a direct substitute for the binding you originally
proposed).

> > When we say to use the clock binding what we are saying is to use the
> > actual clock bindings to describe the clocks, not make a custom binding
> > that looks kind of like them - making a custom binding doesn't address
> > the problem.

> But I don't know what you mean by "use the actual clock bindings to
> describe the clocks".

> What is not clear to me is how you want me to use a clock binding to
> describe something that isn't a clk-framework clk. If you know what you
> want, then please.. an example would help explain.

The concept of a clock framework is an implementation detail of Linux
which should not affect how the DT bindings for a device or system are
written, DT bindings should be clear and idiomatic as DT bindings.  The
goal is to represent the system in a clear and standardized fashion
which is useful to OSs in general, not just something convenient for
Linux as it happens to be implemented right now.  Current Linux
internals are not a constraint for DT bindings.

In this case if you can't figure out how to parse clock bindings without
moving the clocks over to standard Linux clock APIs (which seems likely)
then it follows that if you want to describe the clock configuration in
DT then the driver support for these clocks should use the standard
Linux clock framework.  This seems like a good idea in general anyway.

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