From: Krzysztof Halasa <khc@pm.waw.pl>
To: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] r8169: revert "read MAC address from EEPROM on init"
Date: Mon, 27 Oct 2008 23:29:59 +0100 [thread overview]
Message-ID: <m3mygplli0.fsf@maximus.localdomain> (raw)
In-Reply-To: <20081026160249.GA25443@electric-eye.fr.zoreil.com> (Francois Romieu's message of "Sun\, 26 Oct 2008 17\:02\:49 +0100")
[Reposting to lkml only, Gnus likes to eat quoting from email addresses
under specific circumstances and then vger doesn't pass them through]
Francois Romieu <romieu@fr.zoreil.com> writes:
> -static int rtl_eeprom_read(struct pci_dev *pdev, int cap, int addr, __le32 *val)
> -{
> - int ret, count = 100;
> - u16 status = 0;
> - u32 value;
> -
> - ret = pci_write_config_word(pdev, cap + PCI_VPD_ADDR, addr);
> - if (ret < 0)
> - return ret;
> -
> - do {
> - udelay(10);
> - ret = pci_read_config_word(pdev, cap + PCI_VPD_ADDR, &status);
> - if (ret < 0)
> - return ret;
> - } while (!(status & PCI_VPD_ADDR_F) && --count);
> -
> - if (!(status & PCI_VPD_ADDR_F))
> - return -ETIMEDOUT;
> -
> - ret = pci_read_config_dword(pdev, cap + PCI_VPD_DATA, &value);
> - if (ret < 0)
> - return ret;
> -
> - *val = cpu_to_le32(value);
> -
> - return 0;
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.
> -static void rtl_init_mac_address(struct rtl8169_private *tp,
> - 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.
> - * MAC address is stored in EEPROM at offset 0x0e
> - * Realtek says: "The VPD address does not have to be a DWORD-aligned
> - * address as defined in the PCI 2.2 Specifications, but the VPD data
> - * is always consecutive 4-byte data starting from the VPD address
> - * specified."
Nice.
> - 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?
Though obviously first reading a good address from the EEPROM and then
erasing first 32 bits is a different story. I wonder if changing the
MAC address by hand works (using ifconfig, to arbitrary address).
--
Krzysztof Halasa
prev parent reply other threads:[~2008-10-27 22:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-26 16:02 [PATCH 1/1] r8169: revert "read MAC address from EEPROM on init" Francois Romieu
2008-10-26 16:26 ` Jeff Garzik
[not found] ` <m3wsfvhx8c.fsf@maximus.localdomain>
2008-10-26 22:22 ` Francois Romieu
2008-10-27 14:49 ` Krzysztof Halasa
2008-10-27 22:29 ` Krzysztof Halasa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3mygplli0.fsf@maximus.localdomain \
--to=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.