linux-kernel - Re: [EXTERNAL] Re: [PATCH v9] ASoc: tas2783: Add tas2783 codec driver

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]

Message-ID: <2c7e33e5-6904-467d-9912-417bab95e517@linux.intel.com>
Date: Mon, 26 Feb 2024 10:56:41 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Mark Brown <broonie@...nel.org>, "Ding, Shenghao" <shenghao-ding@...com>
Cc: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>,
 "lgirdwood@...il.com" <lgirdwood@...il.com>, "perex@...ex.cz"
 <perex@...ex.cz>, "13916275206@....com" <13916275206@....com>,
 "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "liam.r.girdwood@...el.com" <liam.r.girdwood@...el.com>,
 "bard.liao@...el.com" <bard.liao@...el.com>,
 "mengdong.lin@...el.com" <mengdong.lin@...el.com>,
 "yung-chuan.liao@...ux.intel.com" <yung-chuan.liao@...ux.intel.com>,
 "Xu, Baojun" <baojun.xu@...com>, "Lu, Kevin" <kevin-lu@...com>,
 "tiwai@...e.de" <tiwai@...e.de>, "soyer@....hu" <soyer@....hu>
Subject: Re: [EXTERNAL] Re: [PATCH v9] ASoc: tas2783: Add tas2783 codec driver

On 2/23/24 12:20 PM, Mark Brown wrote:
> On Fri, Feb 23, 2024 at 10:12:49AM +0000, Ding, Shenghao wrote:
>> Hi Pierre-Louis
>>
>>> 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 cases of the
>> different SWD links, customer will be required to have the secondary development
>> on current code. I'm sure my customers have much knowledge to handle this.

PC OEMs don't usually have a Linux team capable of handling this sort of 
low-level plumbing, so the burden of this "secondary development" will 
come back at you...

> 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?

Leaving multi-link aside has to be seen as as temporary step, there are 
a number of electrical issues that will prevent more than 4 amps to be 
placed on the same link. And indeed this "secondary development" has to 
be backwards compatible with initial calibration schemes.