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

[Wasko, Michal]

On 1/27/2020 4:30 PM, Pierre-Louis Bossart wrote:
>
>>>> 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.
>
The proposed patch-set is to restore the Skylake driver functionality 
for Skylake base targets. I called it ‘minimal’ because last time when 
we have tried to upstream the wide range of patch-sets with code 
refactors it was rejected because of ‘maintenance’ mark on the driver.

As we discussed on the call we will take a closer look on the HW boards 
that continue to reproduce the race condition issue. However the fix on 
that specific problem will be addressed as a separate patch-set.
Additionally we will work on providing reference topology configuration 
files that support DMICs.

I can’t commit any timeframe but as long as we will be maintainers and 
the changes will be welcome on the upstream we will work on improving 
the functionality of the Skylake driver.