linux-kernel - Re: Interrupt storm from pinctrl-amd on Acer AN515-42

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: <CACRpkdaDT9xZe6r3pJvYqubrvHh4+PkV8D38yYMEbv8fhdHMKQ@mail.gmail.com>
Date:   Fri, 28 Dec 2018 13:48:29 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Leonard Crestez <cdleonard@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Daniel Kurtz <djkurtz@...omium.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Nehal Shah <Nehal-bakulchandra.Shah@....com>,
        Shyam Sundar S K <Shyam-sundar.S-k@....com>,
        Daniel Drake <drake@...lessm.com>,
        Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@....com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: Interrupt storm from pinctrl-amd on Acer AN515-42

On Fri, Dec 28, 2018 at 12:02 AM Leonard Crestez <cdleonard@...il.com> wrote:

> Digging a little deeper it seems the touchpad interrupt is active on
> boot and since it's configured as "level" and no touchpad driver is
> available yet there does not seem to be any way to clear it.

I think these are called "spurious interrupts".

> I don't know how this should be handled, booting with an active enabled but
> unclearable interrupt seems like a platform bug to me. There is even an
> option to set touchpad to "basic" which does some sort of ps2 emulation
> but the IRQ issue still happens!
>
> One workaround is to explicitly disable the interrupt from the handler
> if no mapping is found; this will keep it disabled until
> amd_gpio_irq_set_type is called later.

I don't know how x86 and ACPI systems usually deal with this stuff
so I'm kind of lost. On the embedded systems that I develop on,
I would just disable all interrupts on probe() (usually writing 0x0 in
some interrupt enable register) and then they will get enabled
once consumers need them.

But I have come to understand that maybe ACPI systems are
not so happy about drivers doing things like that?

Yours,
Linus Walleij