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.