[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130613230341.GB16632@electric-eye.fr.zoreil.com>
Date: Fri, 14 Jun 2013 01:03:41 +0200
From: Francois Romieu <romieu@...zoreil.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: netdev@...r.kernel.org, mcgrof@...not-panic.com, kvalo@...rom.com,
adrian.chadd@...il.com
Subject: Re: [PATCH] alx: add a simple AR816x/AR817x device driver
Johannes Berg <johannes@...solutions.net> :
[...]
> Yes, I suppose I could, but is it worth it? It's held only for a very
> short amount of time to get the indirect register access correct. I
> don't really see any reason to prefer a mutex here?
Neither a spinlock nor a mutex should be needed but I have to sleep
before figuring it.
> Not sure what you mean by "push it in the common core methods"? I
> actually suspect that this lock can't ever be contended because the
> callers hold the RTNL anyway, but I don't really want to rely on just
> that.
Don't be shy :o)
[...]
> Hmm, yeah, I'll have to think about that. I don't really care about the
> performance all that much ... just want the device to work :-)
Ok. It's fine.
> Would I really want to rely on NAPI for error interrupts and the like
> though? I thought NAPI could potentially be deferred due to budget etc.
It will have to wait for ksoftirqd once its budget is exhausted.
If the irq and napi handlers don't share a lock, either they are racing
or the napi handler will be kicked on irq return.
I'll admit a bias towards some extra latency if it can buy user context
comfort.
--
Ueimor
--
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