public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Linux regressions mailing list <regressions@lists.linux.dev>,
	Mark Brown <broonie@kernel.org>
Cc: Sven Frotscher <sven.frotscher@gmail.com>,
	git@augustwikerfors.se, alsa-devel@alsa-project.org,
	lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Takashi Iwai <tiwai@suse.com>
Subject: Re: [PATCH v4] ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM
Date: Mon, 2 Oct 2023 09:20:04 -0500	[thread overview]
Message-ID: <28e38593-4861-4d61-b27d-994328ea4e82@amd.com> (raw)
In-Reply-To: <048d9715-9cb2-4bc0-b8b0-5e30a0db54c7@leemhuis.info>

On 10/2/2023 09:13, Linux regression tracking (Thorsten Leemhuis) wrote:
> 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.

I don't like lists that enable something for a ton of systems and then 
lists that disable something for a subset of them.  This becomes 
difficult to maintain.

I'm not positive, but the only way we get a full list is from Lenovo.

> 
> 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.


  reply	other threads:[~2023-10-02 14:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 22:36 [PATCH v4] ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM Sven Frotscher
2023-10-02  9:32 ` Linux regression tracking (Thorsten Leemhuis)
2023-10-02 11:52   ` Mark Brown
2023-10-02 12:28     ` Linux regression tracking (Thorsten Leemhuis)
2023-10-02 12:54       ` Mark Brown
2023-10-02 13:00         ` Sven Frotscher
2023-10-02 13:04           ` Mark Brown
2023-10-02 13:17             ` Sven Frotscher
2023-10-02 13:47               ` Mark Brown
2023-10-02 13:47     ` Mario Limonciello
2023-10-02 14:13       ` Linux regression tracking (Thorsten Leemhuis)
2023-10-02 14:20         ` Mario Limonciello [this message]
2023-10-02 14:36           ` Linux regression tracking (Thorsten Leemhuis)
2023-10-02 14:40           ` Sven Frotscher
2023-10-02 18:51 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=28e38593-4861-4d61-b27d-994328ea4e82@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=git@augustwikerfors.se \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=sven.frotscher@gmail.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox