[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?
