linux-kernel - Re: pinctrl_cherryview: massive error messages (handle_bad

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] [day] [month] [year] [list]

Date:   Tue, 25 Oct 2016 13:35:53 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Christian Steiner <christian.steiner@...look.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: pinctrl_cherryview: massive error messages (handle_bad_irq)

On Tue, Oct 25, 2016 at 11:26:48AM +0200, Linus Walleij wrote:
> On Mon, Oct 24, 2016 at 10:14 AM, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> 
> > It is possible to detect the BIOS version using DMI strings and issue a
> > warning in the driver, if that's what you mean, but currently we don't
> > do that.
> 
> I was more thinking about detecting the old BIOS and if that
> is present, mask off the interrupts on the resume path or something,
> as it is probably a bigger problem to see the warnings than to
> loose these settings.
> 
> Possibly also add a warning at probe() like you describe.

I think we can do masking of these IRQs (0..community->nirqs-1)
unconditionally in probe() because those should belong to the GPIO
driver as far as I understand. But I need to double check that from the
spec.