[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0h8_AEH2XgB_Zk2NKH01wBo9+YaB=V557m9H_1PBy_wQw@mail.gmail.com>
Date: Tue, 5 Jul 2022 20:31:11 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Limonciello, Mario" <Mario.Limonciello@....com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Chuanhong Guo <gch981213@...il.com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Stable <stable@...r.kernel.org>,
Tighe Donnelly <tighe.donnelly@...tonmail.com>,
Kent Hou Man <knthmn0@...il.com>,
Len Brown <lenb@...nel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5] ACPI: skip IRQ1 override on 3 Ryzen 6000 laptops
On Tue, Jul 5, 2022 at 8:27 PM Limonciello, Mario
<Mario.Limonciello@....com> wrote:
>
> [Public]
>
> > -----Original Message-----
> > From: Rafael J. Wysocki <rafael@...nel.org>
> > Sent: Tuesday, July 5, 2022 13:24
> > To: Chuanhong Guo <gch981213@...il.com>
> > Cc: Rafael J. Wysocki <rafael@...nel.org>; Limonciello, Mario
> > <Mario.Limonciello@....com>; ACPI Devel Maling List <linux-
> > acpi@...r.kernel.org>; Stable <stable@...r.kernel.org>; Tighe Donnelly
> > <tighe.donnelly@...tonmail.com>; Kent Hou Man <knthmn0@...il.com>;
> > Len Brown <lenb@...nel.org>; open list <linux-kernel@...r.kernel.org>
> > Subject: Re: [PATCH v5] ACPI: skip IRQ1 override on 3 Ryzen 6000 laptops
> >
> > On Fri, Jul 1, 2022 at 2:45 PM Chuanhong Guo <gch981213@...il.com>
> > wrote:
> > >
> > > On Fri, Jul 1, 2022 at 4:12 AM Limonciello, Mario
> > > <mario.limonciello@....com> wrote:
> > > > However I do want to point out that Windows doesn't care about legacy
> > > > format or not. This bug where keyboard doesn't work only popped up on
> > > > Linux.
> > > >
> > > > Given the number of systems with the bug is appearing to grow I wonder
> > > > if the right answer is actually a new heuristic that doesn't apply the
> > > > kernel override for polarity inversion anymore. Maybe if the system is
> > > > 2022 or newer? Or on the ACPI version?
> > >
> > > The previous attempt to limit the scope of IRQ override ends up
> > > breaking some other buggy devices:
> > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > hwork.kernel.org%2Fproject%2Flinux-
> > acpi%2Fpatch%2F20210728151958.15205-1-
> > hui.wang%40canonical.com%2F&data=05%7C01%7Cmario.limonciello%4
> > 0amd.com%7C106955e4611344d3bc3808da5eb3971d%7C3dd8961fe4884e608
> > e11a82d994e183d%7C0%7C0%7C637926422673112765%7CUnknown%7CTWF
> > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=xOaRbkCv9EMhpLO%2BGAP
> > mDjEhQ78xjYFBvehLZdg1k1I%3D&reserved=0
> > >
> > > It's unfortunate that the original author of this IRQ override doesn't
> > > limit the scope to their exact devices.
> > >
> > > Hi, Rafael! What do you think? should we skip this IRQ override
> > > one-by-one or add a different matching logic to check the bios date
> > > instead?
> >
> > It would be better to find something precise enough to identify the
> > machines in question without pulling in the others and use that for
> > skipping the override instead of listing them all one by one in the
> > blocklist.
>
> How about using the CPU family/model in this case?
That would work for me. The code in question is all quirks anyway.
Powered by blists - more mailing lists