.\" This manpage has been automatically generated by docbook2man 
.\" from a DocBook document.  This tool can be found at:
.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
.\" Please send any bug reports, improvements, comments, patches, 
.\" etc. to Steve Cheng <steve@ggi-project.org>.
.TH "MC32_COMMAND" "" "06 October 2005" "" ""

.SH NAME
mc32_command \- send a command and sleep until completion
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
int mc32_command  (struct net_device * \fIdev\fB, u16 \fIcmd\fB, void * \fIdata\fB, int \fIlen\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIdev\fB\fR
The 3c527 card to issue the command to
.TP
\fB\fIcmd\fB\fR
The command word to write to the mailbox
.TP
\fB\fIdata\fB\fR
A data block if the command expects one
.TP
\fB\fIlen\fB\fR
Length of the data block
.SH "DESCRIPTION"
.PP
Sends exec commands in a user context. This permits us to wait around
for the replies and also to wait for the command buffer to complete
from a previous command before we execute our command. After our 
command completes we will complete any pending multicast reload
we blocked off by hogging the exec buffer.
.PP
You feed the card a command, you wait, it interrupts you get a 
reply. All well and good. The complication arises because you use
commands for filter list changes which come in at bh level from things
like IPV6 group stuff.
.PP
We have a simple state machine
.PP
0 - nothing issued
.PP
1 - command issued, wait reply
.PP
2 - reply waiting - reader then goes to state 0
.PP
3 - command issued, trash reply. In which case the irq
takes it back to state 0