Searched hist:"7 ab87ff4c770eed71e3777936299292739fcd0fe" (Results 1 – 1 of 1) sorted by relevance
| /openbmc/linux/drivers/net/ethernet/via/ |
| H A D | via-rhine.c | diff 3a5a883a8a663b930908cae4abe5ec913b9b2fd2 Fri May 01 15:14:45 CDT 2015 françois romieu <romieu@fr.zoreil.com> via-rhine: close SMP transmit races.
7ab87ff4c770eed71e3777936299292739fcd0fe ("via-rhine: move work from
irq handler to softirq and beyond") forgot to explicitely control the
lifespan of the tx_dirty and tx_cur pointers.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff 7ab87ff4c770eed71e3777936299292739fcd0fe Fri Jan 06 14:42:26 CST 2012 Francois Romieu <romieu@fr.zoreil.com> via-rhine: move work from irq handler to softirq and beyond.
- Tx processing is moved from the irq handler to NAPI poll
- link events and obscure event processing is moved to its proper work queue
Locking rules undergo some changes through the driver.
- the driver offers the usual lock-free Tx path
- besides the IRQ handler, the link event task schedules the napi handler.
The driver thus adds some internal locking to prevent a loop when both
must be disabled.
- the reset task keeps being scheduled from the Tx watchdog handler, thus
with implicit Tx queue disabling. It does not need to care about irq,
only napi softirq and competing task.
- it is not worth to add a dedicated lock between {g, s}et_wol and
rhine_shutdown. It should not hurt no narrow it down a bit though.
- rhine_reset_task must keep its huge spin_lock_bh protected section due
to :
- races for the CAM registers (see rhine_vlan_rx_{add, kill}_vid)
- implicit use of napi_enable (see init_registers)
- use of the same lock for stats read / update exclusion between
napi rx processing and rhine_get_stats
- rhine_resume requires a softirq disabled section for the same reason
as rhine_reset_task
- {free, request}_irq have been replaced with IntrEnable actions in
rhine_{suspend, resume}. It is hidden behind init_registers for the
latter.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
|