diff options
author | Jarek Poplawski <jarkao2@o2.pl> | 2007-07-26 08:44:01 -0400 |
---|---|---|
committer | Jeff Garzik <jeff@garzik.org> | 2007-07-30 15:47:20 -0400 |
commit | 55b7b629b78cf82389baf604efcdd2b83b998ca7 (patch) | |
tree | 6c82f159c4bec8d27144c212bc5dc00f0f922898 | |
parent | 9351982b25ace7ee5ed82b6f4a7ea1151f31d267 (diff) |
lib8390: comment on locking by Alan Cox
Additional explanation of problems with locking by Alan Cox.
Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
-rw-r--r-- | drivers/net/lib8390.c | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/drivers/net/lib8390.c b/drivers/net/lib8390.c index 721ee38d2241..c429a5002dd6 100644 --- a/drivers/net/lib8390.c +++ b/drivers/net/lib8390.c | |||
@@ -143,6 +143,52 @@ static void __NS8390_init(struct net_device *dev, int startp); | |||
143 | * annoying the transmit function is called bh atomic. That places | 143 | * annoying the transmit function is called bh atomic. That places |
144 | * restrictions on the user context callers as disable_irq won't save | 144 | * restrictions on the user context callers as disable_irq won't save |
145 | * them. | 145 | * them. |
146 | * | ||
147 | * Additional explanation of problems with locking by Alan Cox: | ||
148 | * | ||
149 | * "The author (me) didn't use spin_lock_irqsave because the slowness of the | ||
150 | * card means that approach caused horrible problems like losing serial data | ||
151 | * at 38400 baud on some chips. Rememeber many 8390 nics on PCI were ISA | ||
152 | * chips with FPGA front ends. | ||
153 | * | ||
154 | * Ok the logic behind the 8390 is very simple: | ||
155 | * | ||
156 | * Things to know | ||
157 | * - IRQ delivery is asynchronous to the PCI bus | ||
158 | * - Blocking the local CPU IRQ via spin locks was too slow | ||
159 | * - The chip has register windows needing locking work | ||
160 | * | ||
161 | * So the path was once (I say once as people appear to have changed it | ||
162 | * in the mean time and it now looks rather bogus if the changes to use | ||
163 | * disable_irq_nosync_irqsave are disabling the local IRQ) | ||
164 | * | ||
165 | * | ||
166 | * Take the page lock | ||
167 | * Mask the IRQ on chip | ||
168 | * Disable the IRQ (but not mask locally- someone seems to have | ||
169 | * broken this with the lock validator stuff) | ||
170 | * [This must be _nosync as the page lock may otherwise | ||
171 | * deadlock us] | ||
172 | * Drop the page lock and turn IRQs back on | ||
173 | * | ||
174 | * At this point an existing IRQ may still be running but we can't | ||
175 | * get a new one | ||
176 | * | ||
177 | * Take the lock (so we know the IRQ has terminated) but don't mask | ||
178 | * the IRQs on the processor | ||
179 | * Set irqlock [for debug] | ||
180 | * | ||
181 | * Transmit (slow as ****) | ||
182 | * | ||
183 | * re-enable the IRQ | ||
184 | * | ||
185 | * | ||
186 | * We have to use disable_irq because otherwise you will get delayed | ||
187 | * interrupts on the APIC bus deadlocking the transmit path. | ||
188 | * | ||
189 | * Quite hairy but the chip simply wasn't designed for SMP and you can't | ||
190 | * even ACK an interrupt without risking corrupting other parallel | ||
191 | * activities on the chip." [lkml, 25 Jul 2007] | ||
146 | */ | 192 | */ |
147 | 193 | ||
148 | 194 | ||