do_start_xmit() {
...
SelectPage(X);
GetByte(...);
PutByte(...);
...
}
Now, if the scheduler chose to stop this after the SelectPage(X) and
then do something else (like, say, an ifport-triggered do_config()
reconfiguration) and the do_config() code then has something in there
which does
do_config() {
...
SelectPage(Y);
GetByte(...);
...
}
Then the GetByte(...) in do_start_xmit would be reading from the wrong page
of the card. My question is, is this possible? Should I be adding...
save_flags(flags);
cli();
SelectPage(X);
[operations on page X]
restore_flags(flags);
or maybe a semaphore handling code sections where the card must be kept
on the same 'page'?
The IRQ handler routine for the device queries the "page register" of the
device at the start and sets it back to the original value once it's finished.
I'm just wondering if it's possible that some other interrupt or scheduling
causes one routine in the driver to execute while another is in the middle of
selecing a page and doing stuff on it.
Also, do_start_xmit reads the 'free space' from the card - if there's a lot
of simultaneous xmit's, is it possible that one call will be suspended after
reading the free space, a new one will buffer up a packet, then the first call
will attempt to put the packet in the buffer when there is no space left?
There is no locking that I can see in the driver itself.
A pointer to an enlightening 'when locking is required' type document on the
Linux kernel would be welcomed.
TIA for any help,
David.
[note - the driver I'm looking at is xirc2ps_cs.c from the pcmcia-cs package.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu