From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v2 4/8] ASoC: topology: ABI - Add name element to snd_soc_tplg_stream Date: Wed, 07 Oct 2015 12:04:19 +0200 Message-ID: References: <08b095d38f59c43690daaa45e1d201f367812228.1443605139.git.mengdong.lin@intel.com> <20151002165907.GU12635@sirena.org.uk> <1443809055.10986.10.camel@loki> <20151006103403.GH12635@sirena.org.uk> <1444144590.25504.27.camel@intel.com> <20151006162520.GB30592@sirena.org.uk> <5613F850.1040605@metafoo.de> <20151006173654.GY12635@sirena.org.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id C3F37265A3E for ; Wed, 7 Oct 2015 12:04:14 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "Lin, Mengdong" Cc: "alsa-devel@alsa-project.org" , Lars-Peter Clausen , "Koul, Vinod" , "liam.r.girdwood@linux.intel.com" , Mark Brown , "Kp, Jeeja" , "Prusty, Subhransu S" , "Patel, Vedang" List-Id: alsa-devel@alsa-project.org On Wed, 07 Oct 2015 11:48:37 +0200, Lin, Mengdong wrote: > > > -----Original Message----- > > From: Mark Brown [mailto:broonie@kernel.org] > > Sent: Wednesday, October 07, 2015 1:37 AM > > To: Lars-Peter Clausen > > Cc: Koul, Vinod; alsa-devel@alsa-project.org; tiwai@suse.de; Lin, Mengdong; > > liam.r.girdwood@linux.intel.com; Kp, Jeeja; Prusty, Subhransu S; Patel, > > Vedang > > Subject: Re: [alsa-devel] [PATCH v2 4/8] ASoC: topology: ABI - Add name > > element to snd_soc_tplg_stream > > > > On Tue, Oct 06, 2015 at 06:35:28PM +0200, Lars-Peter Clausen wrote: > > > On 10/06/2015 06:25 PM, Mark Brown wrote: > > > > > > The problem isn't detecting the error, the point is that if someone > > > > upgrades their kernel and someone changed the DAI link name then > > > > their existing userspace will break. We don't want that error to be > > > > there to be detected in the first place. > > > > > Another thing to consider is that the topology firmware might be > > > developed against a non-upstream driver. And in order for the driver > > > to go upstream it needs changes that breaks the ABI interface to the > > > firmware which is already shipped and the vendor might not provide > > > support for updating the firmware file. Having these kind of tightly > > > coupled interdependencies between driver and firmware is quite risky > > business. > > > > Yeah, I think we're kind of stuck with some degree of fairly tight coupling at > > some point though - at some point we're going to need to work out which > > link in the driver corresponds to which link in the firmware file. > > There is a 'version' field in struct snd_soc_tplg_hdr, which is a vendor-specific version number. > The driver can check this field of a firmware topology and decide whether to support this firmware or not. > > Is this okay? Well, you can't assure that the third vendor would set that field always right. I won't bet it, as the odds are too bad :) How about to allow leaving this name empty as default? Or better to ask: what's the exact merit of having strict binding to DAI link? thanks, Takashi