Commit 6344f052 authored by Mark Brown's avatar Mark Brown Committed by David S. Miller

natsemi: Update locking documentation

The documentation regarding synchronisation at the head of the natsemi
driver was badly bitrotted so replace it with a general statement about
the techniques used which is less likely to bitrot.

Also remove the note saying these chips are uncommon - it makes little
difference but they were used in a number of laptops and at least one mass
market PCI ethernet card.
Signed-off-by: default avatarMark Brown <broonie@sirena.org.uk>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 35b5f6b1
...@@ -203,22 +203,8 @@ skbuff at an offset of "+2", 16-byte aligning the IP header. ...@@ -203,22 +203,8 @@ skbuff at an offset of "+2", 16-byte aligning the IP header.
IIId. Synchronization IIId. Synchronization
Most operations are synchronized on the np->lock irq spinlock, except the Most operations are synchronized on the np->lock irq spinlock, except the
performance critical codepaths: recieve and transmit paths which are synchronised using a combination of
hardware descriptor ownership, disabling interrupts and NAPI poll scheduling.
The rx process only runs in the interrupt handler. Access from outside
the interrupt handler is only permitted after disable_irq().
The rx process usually runs under the netif_tx_lock. If np->intr_tx_reap
is set, then access is permitted under spin_lock_irq(&np->lock).
Thus configuration functions that want to access everything must call
disable_irq(dev->irq);
netif_tx_lock_bh(dev);
spin_lock_irq(&np->lock);
IV. Notes
NatSemi PCI network controllers are very uncommon.
IVb. References IVb. References
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment