[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+uiaqvdIL4IpRlC@sirena.org.uk>
Date: Tue, 14 Feb 2023 15:02:02 +0000
From: Mark Brown <broonie@...nel.org>
To: Alexander Sverdlin <alexander.sverdlin@...il.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
devicetree@...r.kernel.org,
Hartley Sweeten <hsweeten@...ionengravers.com>,
Liam Girdwood <lgirdwood@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: sound: ep93xx: Add I2S and AC'97
descriptions
On Tue, Feb 14, 2023 at 03:26:14PM +0100, Alexander Sverdlin wrote:
> On Tue, 2023-02-14 at 15:11 +0100, Krzysztof Kozlowski wrote:
> > OK, but then I like the example - if datasheet would use name
> > "clk_clk_this_is_clk" would you still find it meaningful?
> > Every clock input in clocks is a clock. There is usually no need to say
> > that a clock is a clock...
> I see you point, but this is legacy code (sound/soc/cirrus/ep93xx-i2s.c)
> which took these names back in platform data times... I also see that
> rather majority of *i2s*.yaml use something "*clk", so maybe it could
> be accepted for legacy code?
Even ignoring the whole legacy thing these are industry standard
names for the clocks - they are pretty much universally named and
referred to with the clk suffix. I can't see what removing it
would accomplish other than reducing clarity.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists