Re: [PATCH v4] ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM
From: Linux regression tracking (Thorsten Leemhuis)
Date: Mon Oct 02 2023 - 10:14:01 EST
On 02.10.23 15:47, Mario Limonciello wrote:
> On 10/2/2023 06:52, Mark Brown wrote:
>> On Mon, Oct 02, 2023 at 11:32:48AM +0200, Linux regression tracking
>> (Thorsten Leemhuis) wrote:
>>
>>> Makes me wonder: How many more such quirk entries will be needed? Will
>>> we have all machines listed soon, or do we expect that future Lenovo
>>> hardware will need entries as well? If it's the latter: are quirks
>>> really the right solution here, or do they just hide some bug or then
>>> need for code that automatically handles things?
>>
>> x86 firmware descriptions are terrible, it's just an endless procession
>> of quirks. The model for ACPI is not to describe key information in the
>> kernel and instead on Windows load device specific information from
>> separately supplied tables. On Linux that translates into these endless
>> quirks, on Windows it's platform specific drivers for otherwise generic
>> audio hardware.
>
> I knew there was a TON of "82" prefix systems from Lenovo so it was an
> educated guess that all of them needed DMIC support. This was incorrect
> because one of them didn't have DMIC and that caused a no mic support
> problem on that system.
>
> So in the case of this seemingly endless list of systems being added to
> enable DMIC support Mark is right, Windows does it differently.
Now I understand things better, many thx. But please allow me one more
question from the cheap seats:
Seems before c008323fe361 things worked for a lot of systems for about
one year thx to 2232b2dd8cd4 (which added the wide "82" prefix quirk).
We then made that one machine work with c008323fe361, but broke a lot of
others with it that now need to be fixed with additional quirks; that
"TON of 82 prefix systems" sounds like we might not be close to the end
of that journey.
So can't we just do it the other way around and assume DMIC support on
Lenovo 82* machines, except on those where we know it to cause trouble?
Again: you are the experts here. If you are positive that we soon got
all machines covered where c008323fe361 causes a regression, then I
guess it's best to continue the patch we're on.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.