From: Adrian Bunk <bunk@kernel.org>
To: Andreas Mohr <andi@lisas.de>
Cc: Richard Jonsson <richie@coderworld.net>,
linux-kernel@vger.kernel.org, Ayaz Abdulla <aabdulla@nvidia.com>,
jgarzik@pobox.com, netdev@vger.kernel.org
Subject: Re: forcedeth: MAC-address reversed on resume from suspend
Date: Thu, 3 Jan 2008 01:42:09 +0200 [thread overview]
Message-ID: <20080102234209.GA10831@does.not.exist> (raw)
In-Reply-To: <20080102214843.GA19224@rhlx01.hs-esslingen.de>
[ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr wrote:
> Hi,
>
> On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote:
> > Bugreport regarding forcedeth driver.
> >
> > When returning from suspend-to-RAM the MAC-address byteorder is reversed.
> > After another suspend-resume cycle the MAC-address is again correct. This
> > brings a great deal of pain since the NIC is assigned a random MAC-address
> > when it is detected as invalid.
> >
> > I cannot say if this issue appeared recently or if it's been in the kernel
> > for a while, as I've been using wireless until recently.
> >
> > I read somewhere on lkml that the mac is read from the device, then
> > reversed and finally written back to the device. Can it be that it is read
> > again on resume and reversed, and then again written to the device? This
> > would explain why it's ok every other resume cycle.
>
> Uh, Use The Source, Luke?
>
> But no, I think it's simply driver dainbreadness, not a matter of
> complicated writing and reading back in reversed order.
>
> drivers/net/forcedeth.c has a nice DEV_HAS_CORRECT_MACADDR flag which is
> being enabled for certain cards (those which need this) and disabled for others.
>
> The nv_probe() function then nicely obeys this flag by reversing the
> address if needed, _however_ there's another function, nv_copy_mac_to_hw(),
> which does _NOT_ obey it and simply copies the _raw_ netdev dev_addr
> to the card register (NvRegMacAddrA etc.).
>
> I don't know, this all looks a bit dirty to me, MAC reading/writing
> should have been implemented in a more central way, then those people
> wouldn't have confused heaven and hell with MAC address fiddling.
>
> And yeah, this certainly looks like a bug that should be fixed ASAP,
> unless my short analysis somehow happened to be wrong.
> (I could probably fix it, but then the forcedeth people
> most likely know better how they would like to see it implemented)
>
> Thank you for your report!
>
> Now the only thing remaining would be: is there a specific way to
> contact forcedeth-related people? I didn't find anything within a short
> search.
Cc's added.
> Andreas Mohr
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2008-01-02 23:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-02 21:04 forcedeth: MAC-address reversed on resume from suspend Richard Jonsson
2008-01-02 21:48 ` Andreas Mohr
2008-01-02 23:42 ` Adrian Bunk [this message]
2008-01-04 3:43 ` Björn Steinbrink
2008-01-04 8:45 ` Andreas Mohr
2008-01-04 10:17 ` Björn Steinbrink
2008-01-04 22:43 ` Andreas Mohr
2008-01-05 6:10 ` Björn Steinbrink
2008-01-05 6:39 ` Björn Steinbrink
2008-01-04 14:08 ` Richard Jonsson
2008-01-04 22:26 ` [PATCH] Fix forcedeth reversing the MAC address on suspend Björn Steinbrink
2008-01-07 1:47 ` Björn Steinbrink
2008-01-06 21:49 ` forcedeth: MAC-address reversed on resume from suspend Adolfo R. Brandes
2008-01-07 1:46 ` Björn Steinbrink
2008-01-07 12:02 ` Adolfo R. Brandes
2008-01-07 15:51 ` Richard Jonsson
2008-01-08 7:23 ` David Miller
2008-02-16 9:41 ` Adolfo R. Brandes
2008-01-04 1:35 ` Richard Jonsson
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=20080102234209.GA10831@does.not.exist \
--to=bunk@kernel.org \
--cc=aabdulla@nvidia.com \
--cc=andi@lisas.de \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=richie@coderworld.net \
/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.