[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m11vmy737x.fsf@fess.ebiederm.org>
Date: Wed, 26 Aug 2009 13:02:58 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: David Dillow <dave@...dillows.org>
Cc: Francois Romieu <romieu@...zoreil.com>,
Michael Riepe <michael.riepe@...glemail.com>,
Michael Buesch <mb@...sch.de>,
Rui Santos <rsantos@...popie.com>,
Michael B??ker <m.bueker@...lin.de>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] r8169: Reduce looping in the interrupt handler.
David Dillow <dave@...dillows.org> writes:
> On Wed, 2009-08-26 at 09:56 -0400, David Dillow wrote:
>> On Wed, 2009-08-26 at 00:58 -0700, Eric W. Biederman wrote:
>> > diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
>> > index 3b19e0c..2214945 100644
>> > --- a/drivers/net/r8169.c
>> > +++ b/drivers/net/r8169.c
>>
>> > +
>> > + /* Ignore the parts of status that reflect more than
>> > + * the enabled interrupts.
>> > + */
>> > + smp_rmb();
>> > + if (!(status & tp->intr_mask & tp->intr_event))
>> > + break;
>> > }
>>
>> This looks like an odd construct, since we're just about to go back the
>> while condition up top -- why not just mask it here and let the loop
>> handle it naturally?
>
> Never mind, I see what you are doing -- avoiding a false loop if we get
> status == 0xffff. I still don't like the aesthetics of it, but it makes
> sense, and I'll blame it on the card. :)
>
> I should really get some caffeine before posting...
It is a bit weird but it also means we aren't playing silly games
with status inside the loop. So if we go through the loop we ack
everything in status.
Eric
--
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