[alsa-devel] [PATCH 00/35] ASoC: Intel: Clenaup SST initialization

[Mark Brown]

On Fri, Aug 23, 2019 at 03:12:18PM -0500, Pierre-Louis Bossart wrote:
> On 8/23/19 1:44 PM, Cezary Rojewski wrote:

> > Wasn't lying about FW version being unreliable. Let's say vendor
> > receives quick FW drop with new RCR.. such eng drop may carry invalid
> > numbers such as 0.0.0.0..
> > In general, I try to avoid relying on FW version whenever possible. It
> > can be dumped for debug reasons, true, but to be relied on? Not really.

> Goodness, that's really bad. I didn't realize this.

At a previous employer I modified our build stamping
infrastructure to also include both a timestamp and a serialized
build number in the version number since one of my colleagues was
fond of sending people prereleases of what he was working on to
other people with identical version numbers on different
binaries leading to much confusion and checksumming.  You do see
a lot of things with those serialized version numbers, especially
SVN based projects.

> > Personally, I'm against all hardcodes and would simply recommend all
> > user to redirect their symlinks when they do switch kernel - along with
> > dumping warning/ error message in dmesg. Hardcodes bring problems with
> > forward compatibility and that's why host should offload them away to
> > FW.

> Cezary, I know you are not responsible for all this, but at this point if we
> (Intel) can't guarantee any sort of interoperability with both firmware and
> topology we should make it clear that this driver is not recommended unless
> specific versions of the firmware/topology are used, and as a consequence
> the typical client distros and desktop/laptop users should use HDaudio
> legacy or SOF (for DMICs)

Not the most elegent solution but I'm wondering if keeping a copy
of the driver as is around and using new locations for the fixed
firmware might be the safest way to handle this.  We could have a
wrapper which tries to load the newer firmware and uses the fixed
driver code if that's there, otherwise tries the old driver with
the existing firmware paths.  This is obviously a horror show and
leaves the old code sitting there but given the mistakes that
have been made the whole situation looks like a house of cards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20190823/ed8ba1af/attachment.sig>