Received-SPF: pass (google.com: domain of linux-kernel+bounces-78820-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 23 Feb 2024 17:20:09 +0000
From: Mark Brown <broonie@kernel.org>
To: "Ding, Shenghao" <shenghao-ding@ti.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"andriy.shevchenko@linux.intel.com" <andriy.shevchenko@linux.intel.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"perex@perex.cz" <perex@perex.cz>,
	"13916275206@139.com" <13916275206@139.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"liam.r.girdwood@intel.com" <liam.r.girdwood@intel.com>,
	"bard.liao@intel.com" <bard.liao@intel.com>,
	"mengdong.lin@intel.com" <mengdong.lin@intel.com>,
	"yung-chuan.liao@linux.intel.com" <yung-chuan.liao@linux.intel.com>,
	"Xu, Baojun" <baojun.xu@ti.com>, "Lu, Kevin" <kevin-lu@ti.com>,
	"tiwai@suse.de" <tiwai@suse.de>, "soyer@irl.hu" <soyer@irl.hu>
Subject: Re: [EXTERNAL] Re: [PATCH v9] ASoc: tas2783: Add tas2783 codec driver
Message-ID: <ZdjTyccCDoD9QYpi@finisterre.sirena.org.uk>
References: <20240222074000.659-1-shenghao-ding@ti.com>
 <10f53a13-a0ff-40f9-b089-f5baacdb76b6@linux.intel.com>
 <5c7127256bf54fcd921fc1ec83f3e527@ti.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="JSSHE0FUht8S9Os8"
Content-Disposition: inline
In-Reply-To: <5c7127256bf54fcd921fc1ec83f3e527@ti.com>


--JSSHE0FUht8S9Os8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 23, 2024 at 10:12:49AM +0000, Ding, Shenghao wrote:
> Hi Pierre-Louis
>=20
> > In the SoundWire spec, the unique_id is *LINK SPECIFIC*, and only used =
at
> > the bus level within the context of a link to help avoid enumeration
> > conflicts

> > If you are using the unique_id as a SYSTEM-UNIQUE value to lookup EFI
> > data, this is a TI-specific requirement that needs to be documented.
> > That also means you need to double-check for errors so make sure there
> > are no board configurations where the same unique_id is used in multiple
> > links, or by devices other than tas2783.

> This code only covers the tas2783s sitting in the same bus link. As to ca=
ses of the
> different SWD links, customer will be required to have the secondary deve=
lopment
> on current code. I'm sure my customers have much knowledge to handle this.

As Pierre says I think we really should have some sort of defensive
programming here, even if you're going to leave multi-link systems to
future work people will still have older versions in distributions or
whtaever.  While I'm not sure the consequences of getting things wrong
are likely to be that bad (I'm expecting bad quality audio) it's also
going to be kind of hard to figure out if we just silently pick the
wrong calibration, especially if it's actually a valid calibration for
another device in the system.  Other vendors (eg, Cirrus) seem to have
figured out a scheme here?

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

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmXY08gACgkQJNaLcl1U
h9CDTAf/bo/BBm0FaalBPQlGYIf6F1SuRLsnvDOwApCG85Z6wSol1qV1EdXwsRHM
4ijYqyHPymwdgpesQnl3LhgpuZ2m/eMk8xXOqOtjC/yCLN0f59uCAmw7XglxhQsP
WmS/0JEZ3Xv2+JcddbErmCdrWi+uJQkiJuhUYkxpx9p0gao5pYarIOoNyHC9vCFF
K+Cxv/YKjuQqakXNVGTfvC7ywD7iX3tT2UVtlAFm8VnFr9W44jkggE9MzyJPP9xb
yvqkqyrcKIEUCGSdMJLxXFTiT1N3cfWPN2/kjJ933DZMEHp2L1ytio4p1lionLE7
+KMiDfhfNZabb3w0gy+dU7MI71OnbA==
=aP7c
-----END PGP SIGNATURE-----

--JSSHE0FUht8S9Os8--