Hello,
On Sat, Mar 25, 2000 at 03:05:50PM +0000, Andrew Morton wrote:
> Is wait_for_cmd_done() racy? It is called from hard_start_xmit()
> outside the spinlock as well as from get_stats(). set_multicast_list()
> also.
Here is an excerpt from speedo_get_stats()
1880 if (dev->start) {
1881 unsigned long flags;
1882 /* Take a spinlock to make wait_for_cmd_done and sending the
1883 * command atomic. --SAW */
1884 spin_lock_irqsave(&sp->lock, flags);
1885 wait_for_cmd_done(ioaddr + SCBCmd);
1886 outb(CUDumpStats, ioaddr + SCBCmd);
1887 spin_unlock_irqrestore(&sp->lock, flags);
1888 }
Which driver version are you looking at? :-)
> mdio_read() is called from various unprotected contexts, one of which is
> a bh. Confident about this?
I know about mdio_read() problem.
mdio_read() is used only in
- initialization code (no special care is needed)
- timer routine
- TX timeout routine (these two are exclusive against each other)
- ioctl
The easiest solution is to make reading ioctl being privileged too.
>
>
> mdio_read() and write() use a self-timed timeout which will get 30%
> shorter each year (Moore's law should be repealed).
Not exactly. The timings are bus (rather than CPU) bounded.
Discussion is welcome, but it's obviously not a so urgent problem.
> tx_timeout() appears to be unprotected from the ISR.
Any specific example?
> Then there's this magical construct which also appears in 3c59x's ioctl:
[snip]
>
> This makes my brain hurt. data[0] is an output, data[1] is an input,
> data[2] is unused, data[3] is an output.
>
> Is this right?
It's compatible with previous versions of the driver.
Best regards
Andrey V.
Savochkin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:18 EST