Re: [Sound-open-firmware] Signed firmware availability for kbl/cnl

From: Jaroslav Kysela <perex@perex.cz>
To: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Daniel Drake <drake@endlessm.com>,
	"Lin, Mengdong" <mengdong.lin@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>,
	ALSA development <alsa-devel@alsa-project.org>,
	sound-open-firmware@alsa-project.org
Subject: Re: [Sound-open-firmware] Signed firmware availability for kbl/cnl
Date: Wed, 31 Jul 2019 19:29:02 +0200	[thread overview]
Message-ID: <1718d316-4c65-a39d-53dd-7f40f0e49e28@perex.cz> (raw)
In-Reply-To: <0059ed8e8f2fbd7ffbc258ca53ce5efbf1885c5b.camel@linux.intel.com>

Dne 31. 07. 19 v 15:23 Liam Girdwood napsal(a):
> + Mengdong
> 
> On Wed, 2019-07-24 at 18:23 +0200, Jaroslav Kysela wrote:
>>> Yeah, been thinking about this atm. It may be better to package the
>>> binaries (firmware and topologies) as part of Linux firmware repo
>>> (since the driver expects to load them all from lib/firmware) and
>>> package the sources (firmware and topology) via sof tarball ?
>>
>> It looks good in my eyes, because topology files are another pieces
>> of the
>> driver from the user space perspective. The unanswered question is
>> the UCM
>> configuration which is linked to the topology configuration (if I
>> understand
>> this correctly). I proposed to place an unique identifier/version to
>> the
>> topology file and propagate this identifier to the user space, so the
>> alsa-lib
>> can pick the right UCM configuration when topology changes. The
>> component
>> string (snd_component_add function / struct snd_ctl_card_info ->
>> components)
>> can be used for this identification.
> 
> Apologizes for the delay, Pierre and I have been discussing this
> internally as we have to synchronise the deployment of the topologies
> and UCMs alongside the FW.

My strong point is that the driver with the different firmware and the
topology file behaves differently from the user space perspective. It seems
that there is no way to propagate the firmware (and topology?) version to the
user space at the moment.

> Current thinking has changed from shipping FW + tplg via linux-firmware 
> repo to only shipping FW binaries in the FW repo and using alsa-ucm-
> conf.git for UCMs + topologies (since the coupling between UCM and
> topology is tighter than the FW coupling).

This is fine, but I think that we should have a check (compatibility
verification) in the user space level, too. More precisely, each level should
do a verification if it's compatible with the tied level (driver -> firmware
-> topology -> ucm).

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.