[NET]: Fix drivers to handle napi_disable() disabling interrupts.
authorDavid S. Miller <davem@davemloft.net>
Tue, 8 Jan 2008 04:53:33 +0000 (20:53 -0800)
committerDavid S. Miller <davem@davemloft.net>
Wed, 9 Jan 2008 07:30:12 +0000 (23:30 -0800)
commitd1d08d1265810ef1f165864850416dcbc9725ee7
tree9c053e8822e33ff719da72df620f1335207ab73d
parent1706287f6eb58726a9a0e5cbbde87f49757615e3
[NET]: Fix drivers to handle napi_disable() disabling interrupts.

When we add the generic napi_disable_pending() breakout
logic to net_rx_action() it means that napi_disable()
can cause NAPI poll interrupt events to be disabled.

And this is exactly what we want.  If a napi_disable()
is pending, and we are looping in the ->poll(), we want
->poll() event interrupts to stay disabled and we want
to complete the NAPI poll ASAP.

When ->poll() break out during device down was being handled on a
per-driver basis, often these drivers would turn interrupts back on
when '!netif_running()' was detected.

And this would just cause a reschedule of the NAPI ->poll() in the
interrupt handler before the napi_disable() could get in there and
grab the NAPI_STATE_SCHED bit.

The vast majority of drivers don't care if napi_disable() might have
the side effect of disabling NAPI ->poll() event interrupts.  In all
such cases, when a napi_disable() is performed, the driver just
disabled interrupts or is about to.

However there were three exceptions to this in PCNET32, R8169, and
SKY2.  To fix those cases, at the subsequent napi_enable() points, I
added code to ensure that the ->poll() interrupt events are enabled in
the hardware.

Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Don Fry <pcnet32@verizon.net>
drivers/net/pcnet32.c
drivers/net/r8169.c
drivers/net/sky2.c