linux-kernel - Re: Linux regressions report for mainline [2023-07-30]

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: <CAHk-=wj2+Mcvdr3PPvUvchhZRCtLdjSFbK7S5R3N2DrEUCz6jw@mail.gmail.com>
Date:   Sun, 30 Jul 2023 12:41:16 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Regzbot (on behalf of Thorsten Leemhuis)" 
        <regressions@...mhuis.info>, Rafael Wysocki <rafael@...nel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Mario Limonciello <mario.limonciello@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: Linux regressions report for mainline [2023-07-30]

On Sun, 30 Jul 2023 at 10:20, Regzbot (on behalf of Thorsten Leemhuis)
<regressions@...mhuis.info> wrote:
>
> One thing you might be interested in: seems the Ryzen keyboard problems
> that a9c4a912b7d ("ACPI: resource: Remove "Zen" specific match and
> quirks") [v6.5-rc1] was supposed to fix once and for all kinda came
> back, as the new approach apparently still doesn't work on all machines:

Gaah.

We must be doing something fundamentally wrong in the irq overrides,
this is ridiculous. One step forwards, two steps back.

Right now all our entries in that override table say "don't override".

In fact, right now they all seem to be about the legacy keyboard irq.
I get the feeling that we are just doing something horribly horribly
wrong wrt the override thing, and that all these quirks come from
that.

I get the feeling that maybe we simply should strive to use the values
the BIOS has _programmed_, not the DSDT or MADT values at all? After
all, the BIOS has presumably set things up so that the keyboard works,
so us taking values from the BIOS tables (which are clearly
unreliable) is a bit suspect.

IOW, maybe we should simply never touch the irq setup for irq 1?

Does anybody have any idea what MS does?

             Linus