[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