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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox