From: Jarek Poplawski <redacted>
Date: Tue, 12 Jan 2010 07:50:59 +0000

I think, I can see similar problems e.g. in gianfar or netxen, where
napi_disable() is done after netif_device_detach(), especially in
suspend procedures (there might be less severe (than oops) effects
yet). IMHO, it all looks simply error prone (sometime you have to
know a driver well to track all possible paths to say it's really
safe).

Then that's an even larger bug.

Until you do napi_disable(), the device can be touched.

Asynchronous paths outside of the driver's control, even
with interrupts disabled, can call back into the driver
and touch the chip.

F.e. netpoll via netconsole output on another cpu

So it therefore must be done before doing the actual work of bringing
the device down or suspending it.