r8169: remove work from irq handler.
authorFrancois Romieu <romieu@fr.zoreil.com>
Thu, 26 Jan 2012 13:18:23 +0000 (14:18 +0100)
committerFrancois Romieu <romieu@fr.zoreil.com>
Fri, 27 Jan 2012 20:26:25 +0000 (21:26 +0100)
commitda78dbff2e05630921c551dbbc70a4b7981a8fff
tree1ab4460f30ad2652a1b7d94aebb4a5f2caf42c5c
parent1e874e041fc7c222cbd85b20c4406070be1f687a
r8169: remove work from irq handler.

The irq handler was a mess.

See 7ab87ff4c770eed71e3777936299292739fcd0fe ("via-rhine: move work from
irq handler to softirq and beyond") for similar changes. One can notice:
- all non-napi tasks are explicitely scheduled trough a single work queue.
- hiding software tx queue start behind the rtl_hw_start method is mildly
  natural. Move it in the caller where needed.
- as can be seen from the heavy use of bh disabling locks, the driver is
  not safe for irq context messages with netconsole. It is still quite
  usable for general messaging though. Tested ok with concurrent registers
  dump (ethtool -d) + background traffic + "echo t > /proc/sysrq-trigger".

Tested with old PCI chipset, PCIe 8168 and 810x:
- XID 0c900800 RTL8168evl/8111evl
- XID 18000000 RTL8168b/8111b
- XID 98000000 RTL8169sc/8110sc
- XID 083000c0 RTL8168d/8111d
- XID 081000c0 RTL8168d/8111d
- XID 00b00000 RTL8105e
- XID 04a00000 RTL8102e

As a side note, the comments in f11a377b3f4e897d11f0e8d1fc688667e2f19708
("r8169: avoid losing MSI interrupts") does not seem completely clear: if
I hack the driver further to stop acking the irq link event bit, MSI
interrupts keep being delivered (RTL8168b/8111b, XID 18000000).

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
drivers/net/ethernet/realtek/r8169.c