Re: [PATCH] SMP support on 3c527 net driver for 2.6

Hi Guys, 

This patch against 2.6-test4 updates the 3c527 net driver for 2.6. 

It is tested, but only as a back-port to 2.4, as I was unable to 
get my scsi driver booting on 2.6. 

It also includes a number of trivial clean-ups. If you would prefer it
broken into pieces, please ask.

best regards,  
Richard. 

Questions: 
  -
    {
     u16 x; 
     [...] 
     x=5; 
    } 	
  
    Is that x=5 atomic on SMP? 

  - Is atomic_t atomic on SMP? 

  I'm pretty sure both are ok, but it'll need some more work if not.  

Changes: 

* Replaces sti/sleep_on/cli with semaphores+completions. 
		 
  This made me realise I could get rid of the state-machine, simplifying
  the code. It also meant avoiding having to do things like:
 
	   while (state != state_wanted) { 
		 /* Manually Sleep */  
           } 

  , because we give each state_wanted a separate
  semaphore/completion. Also, the above, inlined, increased mc32_command
  by 770% (438% non-inlined) over the semaphore version (at a cost of 1
  sem + 2 completions per driver).

* Removed mutex covering mc32_send_packet (hard_start_xmit). 

  This lets the interrupt handler operate concurrently and removes
  unnecessary locking. It makes the code only slightly more brittle. 

  Here is why I believe it works: 

  - hard_start_xmit is serialised at a higher layer, so
    no reentrancy problems. 

  - Other than tx_count and tx_ring_head, the interrupt
    handler will not touch the data structures being 
    modified until we increment tx_ring_head to reveal the 
    new queue entry. 

  - This leaves tx_count and tx_ring_head. 
    tx_count is atomic_t, so can be modified by both
    mc32_tx_ring() and mc32_send_packet without racing. 

    mc32_send_packet is the only function to modify 
    u16 tx_ring_head, and tx_ring_head=head; will execute 
    atomically with respect to reads by the rest of the
    driver (line 1056). 


PS. Would be interesting to generalise completions: whereas semaphores
allow us to Wait() x times without blocking, allow a completion to
Complete() x times without waking? 

This would help with situations where multiple independent events had to
occur before the thing you were waiting for could be considered complete
(eg, in the driver, where you issue separate commands to halt the tx and
rx, and only want to wake when the transceiver as a whole has stopped).