From: "John W. Linville" <linville@tuxdriver.com>
To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Cc: Alex Owen <r.alex.owen@gmail.com>,
linux-kernel@vger.kernel.org, aabdulla@nvidia.com,
"H. Peter Anvin" <hpa@zytor.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: forcedeth net driver: reverse mac address after pxe boot
Date: Thu, 5 Oct 2006 15:31:20 -0400 [thread overview]
Message-ID: <20061005193113.GE18408@tuxdriver.com> (raw)
In-Reply-To: <45255059.3040908@gmx.net>
On Thu, Oct 05, 2006 at 08:35:05PM +0200, Carl-Daniel Hailfinger wrote:
> John W. Linville wrote:
> > On Wed, Oct 04, 2006 at 05:19:20PM +0100, Alex Owen wrote:
> >
> >> The obvious fix for this is to try and read the MAC address from the
> >> canonical location... ie where is the source of the address writen
> >> into the controlers registers at power on? But do we know where that
> >> may be?
> >
> > This seems like The Right Thing (TM) to me, but we need someone from
> > NVidia(?) to provide that information. Ayaz?
>
> The canonical location of the "original" MAC address is where we write
> back the reversed MAC address. So that won't work.
I think you misunderstand the suggestion (which is admittedly based
on supposition).
On most devices, the MAC address is programmed into a register at
runtime. It is not "burned-in" to the device itself. Instead it is
usually stored in some sort of eeprom/nvram/flash/whatever. The driver
retrieves it at runtime from the nvram and programs it into the device.
In this case, the forcedeth driver is retrieving the MAC address from
a register, reversing it, and writing it back to the _same_ register.
Experience suggests that this register is unlikely to have "magically"
received that information. The supposition is that instead some
firmware has pre-loaded the register, perhaps at IPL?
It is possible that the device itself is loading the MAC address
from e.g. a serial eeprom tied to the device and inaccessible to
the CPU. If that is the case, there may be no other solution than
the current silliness. Since the driver is reversed engineered,
the current silliness (and a prayer for fixed PXE firmware) is the
only good alternative we have.
John
--
John W. Linville
linville@tuxdriver.com
next prev parent reply other threads:[~2006-10-05 19:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 16:19 forcedeth net driver: reverse mac address after pxe boot Alex Owen
2006-10-04 16:50 ` H. Peter Anvin
2006-10-04 17:30 ` Alan Cox
2006-10-04 18:06 ` Ayaz Abdulla
2006-10-20 17:33 ` Alex Owen
2006-10-05 14:28 ` Denis Vlasenko
2006-10-05 14:44 ` John W. Linville
2006-10-05 18:35 ` Carl-Daniel Hailfinger
2006-10-05 19:31 ` John W. Linville [this message]
2006-10-05 19:45 ` Ayaz Abdulla
2006-10-06 14:37 ` Alex Owen
2006-10-06 17:29 ` Ayaz Abdulla
2006-10-06 19:11 ` John W. Linville
2006-10-06 21:02 ` Ayaz Abdulla
2006-10-05 19:45 ` Andrew de Quincey
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=20061005193113.GE18408@tuxdriver.com \
--to=linville@tuxdriver.com \
--cc=aabdulla@nvidia.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=c-d.hailfinger.devel.2006@gmx.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=r.alex.owen@gmail.com \
/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