[alsa-devel] [PATCH] ASoC: Intel: skl_hda_dsp_common: Fix global-out-of-bounds bug

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Mon Jan 27 16:30:40 CET 2020


>>> As it was agreed with you Pierre the Skylake driver will be kept 
>>> under maintenance and the proposed changes are about to keep hda-dsp 
>>> configuration functional for anyone who would like to use it. Linus 
>>> laptop issue is actually one of the good reasons why we would like to 
>>> keep hda-dsp configuration functional
>>
>> We have to agree on what 'maintained' means then.
>>
>> I don't mind leaving the Skylake driver in the kernel and letting 
>> people who have access to Intel support use it. Cezary is listed as 
>> the maintainer as I suggested it, and this patch provides an necessary 
>> fix.
>>
>> But does this mean this Hdaudio option is usable by distributions and 
>> Linux users who don't have access to Intel support?
>>
>> I will assert that it's not, based on my own experience only 2 weeks 
>> ago. I tried to make audio work on a KBL NUC and had to comment stuff 
>> out due to an obsolete topology. see 
>> https://github.com/thesofproject/linux/pull/1667#issuecomment-572312157
> That is exactly the reason why we would like to update the Skylake 
> driver upstream code and it configuration files so that it will be 
> usable by the community and not only keep it functional internally. As 
> it was clarified by Cezary, we would like to make a minimum number of 
> changes that are required.
> 
> Is there Pierre any non-technical reason why we should not fix the 
> Skylake driver code on the upstream?

My comment was only regarding support of HDaudio codecs w/ the Skylake 
driver. I personally gave up trying to support this option after 1.5 yrs 
of recurring issues. It will take a lot more than minimal patches I am 
afraid if you want this option to work across all known commercial 
devices, you will have to address race conditions such as the probe 
failing when DRM is built as a module, or on specific SKL/APL devices.

If you are signing-up to do this work I have no objections, and if in 
addition you add support for DMICs you'd solve existing issues with 
KBL/AmberLake for which users are left without a solution.

Just be aware of what you are signing up for, it's not a 'minimal' effort.


More information about the Alsa-devel mailing list