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]
Message-ID: <CAHk-=whCWwWwdqbeYTDTSTWC11czp0QxR_FUuzeAgSpjRj7Gig@mail.gmail.com>
Date:   Wed, 10 Apr 2019 09:50:29 -1000
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        linux-bluetooth <linux-bluetooth@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Rajat Jain <rajatja@...gle.com>,
        Heiko Stuebner <heiko@...ech.de>
Subject: Re: [PULL -- 5.1 REGRESSION] Bluetooth: btusb: request wake pin with NOAUTOEN

On Wed, Apr 10, 2019 at 7:44 AM Brian Norris <briannorris@...omium.org> wrote:
>
> I think our key difference here is in how much we trust the device:
> knowing the quality of the firmware running on some of these devices,
> I wouldn't totally trust that they get it right.

No.

You claim that IRQ_NOAUTOEN makes any difference, It doesn't.

I claim that you should get rid of the disable/enable_irq() games you
play, and replace them with just requesting the interrupt.

At which point the whole  IRQ_NOAUTOEN dance is entirely pointless.

Just don't do it.

This has nothing to do with trusting hardware, and everything to do
with "why do you request an interrupt that you aren't actually ready
to accept, and the hardware isn't even properly configured to generate
yet"?

See my point?

               Linus

Powered by blists - more mailing lists