lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a3feafc-b843-420a-9b04-c835f8210c1a@amd.com>
Date:   Mon, 2 Oct 2023 08:47:21 -0500
From:   Mario Limonciello <mario.limonciello@....com>
To:     Mark Brown <broonie@...nel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>
Cc:     Sven Frotscher <sven.frotscher@...il.com>, git@...ustwikerfors.se,
        alsa-devel@...a-project.org, lgirdwood@...il.com,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Takashi Iwai <tiwai@...e.com>
Subject: Re: [PATCH v4] ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM

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.

With the "next" generation of hardware (Phoenix) both Windows and Linux 
*should* be using the same _DSD, so hopefully we don't need more quirks 
like this for those.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ