[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070807230458.GA9883@infradead.org>
Date: Wed, 8 Aug 2007 00:04:59 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Michael Buesch <mb@...sch.de>
Cc: Jeff Garzik <jeff@...zik.org>, Michael Chan <mchan@...adcom.com>,
davem@...emloft.net, netdev@...r.kernel.org, eliezert@...adcom.com,
lusinsky@...adcom.com, eilong@...adcom.com
Subject: Re: [RFC][BNX2X]: New driver for Broadcom 10Gb Ethernet.
On Wed, Aug 08, 2007 at 12:20:35AM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 00:15:47 Jeff Garzik wrote:
> > Michael Buesch wrote:
> > > On Wednesday 01 August 2007 10:31:17 Michael Chan wrote:
> > >> +static irqreturn_t bnx2x_msix_sp_int(int irq, void *dev_instance)
> > >> +{
> > >> + struct net_device *dev = dev_instance;
> > >
> > > You need to check if dev==NULL and bail out.
> > > Another driver sharing the IRQ with this might choose to pass the dev
> > > pointer as NULL.
> >
> > NAK that advice: It is pointless having such a check in the hottest of
> > driver hot paths, since a large majority of drivers do not have such a
> > check.
> >
> > It is better to fix the extremely rare oddball that passes NULL to
> > request_irq(), than to update all drivers to be slower due to the oddballs.
>
> Ah, well. IMO one should better go safe than Oops. ;)
> It's not that an if branch takes more than 2 or 3 CPU cycles at worst.
> But well, if you don't like it, I can live without it, too.
Please take a look at kernel/irq/handle.c. The irq handler is
always called with the right dev_id argument. Everything would be a complete
nightmare to handle because you usually need to access the device private
data to check whether the shared irq is for this device.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists