Re: [PATCH 1/1] r8169: revert "read MAC address from EEPROM on init"

Krzysztof Halasa [off-list ref] :
[...]

Ahh, just PCI VPD.

IMHO the above shouldn't hurt anyone, in theory. You only write to
VPD_ADDR, and to change actual VPD data (i.e., EEPROM), you need to
write to VPD_DATA.

Anyone should be allowed to do that even for unknown PCI devices
without a problem.

Theorically, yes.

In practice I noticed rather different behaviors between a 8168b and
a 8110s when I tried accessing the eeprom through plain old bitbang
a few months ago (i.e. ok on the 8110, lots of zero on the 8168b).

quoted

-static void rtl_init_mac_address(struct rtl8169_private *tp,

quoted

-	if (!(cfg1  & VPD)) {
-		if (netif_msg_probe(tp))
-			dev_info(&pdev->dev, "VPD access disabled, enabling\n");
-		RTL_W8(Cfg9346, Cfg9346_Unlock);
-		RTL_W8(Config1, cfg1 | VPD);
-		RTL_W8(Cfg9346, Cfg9346_Lock);

Now I wonder what do they say the above does exactly.
Unfortunately the docs don't seem to be public.

Realtek's legal department has changed his mind :o(

From what I had received beforehand:

RTL8169:  R/W Set to enable Vital Product Data. The VPD data is stored in
          93C46 or 93c56 from within offset 40h-7fh.

RTL8168C: R (huh ?) Set to enable Vital Product Data. Always 1.

[...]

quoted

-	if (netif_msg_probe(tp)) {
-		DECLARE_MAC_BUF(buf);
-
-		dev_info(&pdev->dev, "MAC address found in EEPROM: %s\n",
-			 print_mac(buf, mac));
-	}
-
-	if (is_valid_ether_addr(mac))
-		rtl_rar_set(tp, mac);
-}

No RTL_W8(Config1, cfg1 | ~VPD) to disable (perhaps R/W) access?

Apparently not. See above.

Though obviously first reading a good address from the EEPROM and then
erasing first 32 bits is a different story.

Yes.

I wonder if changing the MAC address by hand works (using ifconfig, to
arbitrary address).

It does. It can be quite sticky. That was the whole point of the
patch.

-- 
Ueimor