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: <CACRpkdYRYR0hSacpxieG6k9qHyjMFsr6ViYU3HCcQEzB9NXLGQ@mail.gmail.com>
Date:   Wed, 14 Sep 2016 14:46:01 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     Marc Zyngier <marc.zyngier@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Phidias Chiang <phidias.chiang@...onical.com>,
        Anisse Astier <anisse@...ier.eu>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Yu C Chen <yu.c.chen@...el.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe

On Wed, Sep 14, 2016 at 10:26 AM, Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
> On Tue, Sep 13, 2016 at 10:57:31PM +0200, Linus Walleij wrote:

>> Isn't this (a list of what IRQs are reserved by BIOS) by sheer logic
>> something that ACPI should provide?
>>
>> Or is this one of those "well we could alter ACPI tables but we can't
>> because they already shipped so we just can't so now we need to
>> hack around it"?
>
> Isn't it always the case? ;-)
>
> Once the hardware enters stores the firmware cannot be changed anymore
> and we get all the fun working around problems in the OS.

To me this is just a big proof that the ACPI design-by-committee isn't
working. With Device Tree we review bindings and drivers together
and then we tend to not miss stuff like this as much.

But I realize as soon as I say that someone will pull out a counter-example
of stupid DT bindings used in the wild and make me look stupid.

>> Letting Linux map an interrupt it cannot access and then papering it
>> over by using handle_simple_irq() just feels wrong to me.
>>
>> I would argue for associating the mask of BIOS-reserved IRQs with
>> something in ACPI and implement the mentioned scheme to avoid
>> even mapping them seems most logical.
>
> I'm going to re-read the hardware spec and see if there is anything we
> can do about this. The newer hardware (Skylake, Broxton) has a bit that
> tells the IRQ is routed directly to I/O-APIC but unfortunately Braswell
> misses that. There may be something else, though.

So as far as we can determine:

(A) we are running on Braswell and
(B) we are probing this driver

we can conclude that

(C) IRQs A,B,C are reserved by BIOS?

That sounds doable?

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ