On Tue, Jul 5, 2022 at 8:27 PM Limonciello, Mario <Mario.Limonciello@xxxxxxx> wrote: > > [Public] > > > -----Original Message----- > > From: Rafael J. Wysocki <rafael@xxxxxxxxxx> > > Sent: Tuesday, July 5, 2022 13:24 > > To: Chuanhong Guo <gch981213@xxxxxxxxx> > > Cc: Rafael J. Wysocki <rafael@xxxxxxxxxx>; Limonciello, Mario > > <Mario.Limonciello@xxxxxxx>; ACPI Devel Maling List <linux- > > acpi@xxxxxxxxxxxxxxx>; Stable <stable@xxxxxxxxxxxxxxx>; Tighe Donnelly > > <tighe.donnelly@xxxxxxxxxxxxxx>; Kent Hou Man <knthmn0@xxxxxxxxx>; > > Len Brown <lenb@xxxxxxxxxx>; open list <linux-kernel@xxxxxxxxxxxxxxx> > > 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@xxxxxxxxx> > > wrote: > > > > > > On Fri, Jul 1, 2022 at 4:12 AM Limonciello, Mario > > > <mario.limonciello@xxxxxxx> 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.
