Re: [PATCH] Revert "[Bluetooth] Eliminate checks for impossible conditions in IRQ handler"

[Mike Frysinger <vapier.adi@gmail.com>]

On Mon, Sep 14, 2009 at 19:17, Robert Hancock wrote:
> On 09/13/2009 11:18 PM, Mike Frysinger wrote:
>> Commit ac019360fe3 changed the irq handler logic to BUG_ON rather than
>> returning IRQ_NONE when the incoming argument is invalid.  While this
>> works in most cases, it doesn't work when the IRQ is shared with other
>> devices (or when DEBUG_SHIRQ is enabled).
>
> Something doesn't add up here. It shouldn't be possible for the incoming
> argument to be invalid. I'd think that if it is it means that the IRQ
> handler is being registered too soon, before the data structures it requires
> are set up fully. If that's the case, reverting the change just partially
> papers over the bug.

it's a shared irq.  so there is no way to guarantee that the incoming
interrupt is from the bluetooth device.

aaaand there's the issue of registering too soon, but the pcmcia
framework doesnt seem to provide a way to fix this.  enable
DEBUG_SHIRQ and you too will see the kernel crash (since this causes
the IRQ to "fire" as soon as it's generated).

i dont know anything about these devices, but another fix may be to
remove the shareable flag from the irq registration.
-mike