[<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