Message-ID: <465CABA3.10003@pobox.com>
Date: Tue, 29 May 2007 18:39:31 -0400
From: Jeff Garzik <jgarzik@pobox.com>
MIME-Version: 1.0
To: Gary Zambrano <zambrano@broadcom.com>
CC: Michael Buesch <mb@bu3sch.de>,
	Maximilian Engelhardt <maxi@daemonizer.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Stephen Hemminger <shemminger@linux-foundation.org>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: b44: regression in 2.6.22 (resend)
References: <20070525172431.60affaca@freepuppy> <200705281655.15105.mb@bu3sch.de> <1180448075.17146.12.camel@dhcp-10-12-136-115.broadcom.com> <200705292245.22940.mb@bu3sch.de> <1180472741.17711.19.camel@dhcp-10-12-136-115.broadcom.com>
In-Reply-To: <1180472741.17711.19.camel@dhcp-10-12-136-115.broadcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: linux-wireless-owner@vger.kernel.org

Gary Zambrano wrote:
> The b44 interrupt status reg returns a value of 0 if no interrupts are
> pending. The b44 uses a mask to determine which bits (events) can
> generate device interrupts on the system. If the masked interrupt status
> register bits are not asserted, then the b44 will return to the system
> with handled = 0. 
> So, I think the way the b44 interrupt code is written should be ok and
> not a bug. 


This is normal.

We check for 0xffffffff because that is often how a fault is indicated, 
when the memory location is read during or immediately after hotplug (or 
if the PCI bus is truly faulty).  So for most hardware, you see

tmp = read(irq status)
if (!tmp)
	return irq-none		/* no irq events raised */
if (tmp == 0xffffffff)
	return irq-none		/* hot unplug or h/w fault */

and the method that determines no interrupt handling is needed.

Regards,

	Jeff