From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Dec 2005 15:15:35 -0800
> Yes. But add the following as well:
>
> --- a/drivers/net/tg3.c 2005-12-13 14:28:05.000000000 -0800
> +++ b/drivers/net/tg3.c 2005-12-13 14:27:31.000000000 -0800
> @@ -9909,9 +9909,11 @@ static int __devinit tg3_get_device_addr
> (tp->tg3_flags2 & TG3_FLG2_5780_CLASS)) {
> if (tr32(TG3PCI_DUAL_MAC_CTRL) & DUAL_MAC_CTRL_ID)
> mac_offset = 0xcc;
> - if (tg3_nvram_lock(tp))
> + if (tg3_nvram_lock(tp)) {
> tw32_f(NVRAM_CMD, NVRAM_CMD_RESET);
> - else
> + /* reset undoes the nvram lock. */
> + tp->nvram_lock_cnt = 0;
> + } else
> tg3_nvram_unlock(tp);
> }
Actually, this shows that the tg3_nvram_lock() semantics are
questionable. Ideally, the counter should not be bumped if it returns
failure. But, we have lots of call sites not checking the
return value which would need to thus be changed...
Ugh! :-)
This is getting deeper than I had originally intended. It's
turning into a big cleanup instead of a bug fix.
So what I'm going to do is put your original version of this
patch upstream, so we can get the real bugs fixed. Then we
can dork around with getting this stuff cleaned up properly,
say in the 2.6.16 timeframe.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
