Received-SPF: pass (google.com: domain of linux-kernel+bounces-135835-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 8 Apr 2024 19:45:00 +0100
From: Mark Brown <broonie@kernel.org>
To: Dmitry Rokosov <ddrokosov@salutedevices.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>, neil.armstrong@linaro.org,
	lgirdwood@gmail.com, conor+dt@kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, perex@perex.cz, tiwai@suse.com,
	khilman@baylibre.com, martin.blumenstingl@googlemail.com,
	kernel@salutedevices.com, rockosov@gmail.com,
	linux-amlogic@lists.infradead.org, alsa-devel@alsa-project.org,
	linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 2/2] ASoC: meson: implement link-name optional
 property in meson card utils
Message-ID: <51b39153-d1a4-4e7f-9b30-8c77fc4ee46f@sirena.org.uk>
References: <20240408164947.30717-1-ddrokosov@salutedevices.com>
 <20240408164947.30717-3-ddrokosov@salutedevices.com>
 <1j1q7fpv1n.fsf@starbuckisacylon.baylibre.com>
 <20240408184041.3jcav5tabxiblpn4@CAB-WSD-L081021>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="HMiKwoGIkQvD3cpD"
Content-Disposition: inline
In-Reply-To: <20240408184041.3jcav5tabxiblpn4@CAB-WSD-L081021>


--HMiKwoGIkQvD3cpD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Apr 08, 2024 at 09:40:41PM +0300, Dmitry Rokosov wrote:
> On Mon, Apr 08, 2024 at 08:15:54PM +0200, Jerome Brunet wrote:

> > Userspace pcm, otherwise known as DPCM frontend, are merely that:
> > frontends. What they do is entirely defined by the routing defined by
> > the userspace (amixer and friends)

> > So naming the interface in DT (the FW describing the HW) after what the
> > the userspace SW could possibly set later on is wrong.

> > Bottom line: I have mixed feeling about this change. It could allow all
> > sort of bad names to be set.

> > The only way it could make sense HW wise is if the only allowed names
> > where (fr|to)ddr_[abcd], which could help maps the interface and the
> > kcontrol.

> The link-name is an optional parameter. Yes, you are right, it can be
> routed in a way that it no longer functions as a speaker in most cases.
> However, if you plan to use your board's dt for common purposes, you
> should not change the common names for DAI links. But if you know that
> you have a static setup for speakers, microphones, loopback, or other
> references (you 100% know it, because you are HW developer of this
> board), why not help the user understand the PCM device assignment in
> the easiest way?

I would expect that the place to fix names based on the userspace
configuration is in whatever userspace is using to define it's
configurations, like a UCM config.

> Ultimately, it is the responsibility of the DT board developer to define
> specific DAIs and name them based on their own knowledge about HW and
> understanding of the board's usage purposes.

DT seems like the wrong abstraction layer here.

--HMiKwoGIkQvD3cpD
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmYUOywACgkQJNaLcl1U
h9CJAAf+NxTZb3cXYXbGTve/uEzcktraeaWPmfFUvb/1M7/+tCcBBz0yT9v7uXI4
C9xy3I9MIztGRHi9jO6p25fZLtP+ln+t7E0M5/ZZwq9Q05hriYlM6ymQPmaXkSB7
9T7DiddU6mESy1rS2BUxYYYJTBNEmDmFmjq2XA0bn3Mg/FfRVkfDdsZ3uXl5SHIi
UYkeAdeNkOtHqg64KTPIVZcfAYm12yUtZT4z86mWQ1CH+rb/EpuPTkzKwaq/QKhH
XAwPgTdo2kjLEj136u6vQ0blmTxYjaNsh8u+FbIKIc6AYtWAFfh+UXox9D36Tdlu
71tgaf6AzlkMjR4U+gGfe99OK8NETg==
=7H+m
-----END PGP SIGNATURE-----

--HMiKwoGIkQvD3cpD--