netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Jeff Garzik <jeff@garzik.org>
Cc: netdev@vger.kernel.org, mb@bu3sch.de,
	Gary Zambrano <zambrano@broadcom.com>,
	akpm@osdl.org
Subject: Re: [patch 09/11] b44: fix eeprom endianess issue
Date: Tue, 26 Sep 2006 17:47:25 +0200	[thread overview]
Message-ID: <200609261747.25575.mb@bu3sch.de> (raw)
In-Reply-To: <45186D66.1000508@garzik.org>

On Tuesday 26 September 2006 01:59, Jeff Garzik wrote:
> akpm@osdl.org wrote:
> > From: Michael Buesch <mb@bu3sch.de>
> > 
> > This fixes eeprom read on big-endian architectures.
> > 
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
> > Cc: Jeff Garzik <jeff@garzik.org>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > ---
> > 
> >  drivers/net/b44.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff -puN drivers/net/b44.c~b44-fix-eeprom-endianess-issue drivers/net/b44.c
> > --- a/drivers/net/b44.c~b44-fix-eeprom-endianess-issue
> > +++ a/drivers/net/b44.c
> > @@ -2055,7 +2055,7 @@ static int b44_read_eeprom(struct b44 *b
> >  	u16 *ptr = (u16 *) data;
> >  
> >  	for (i = 0; i < 128; i += 2)
> > -		ptr[i / 2] = readw(bp->regs + 4096 + i);
> > +		ptr[i / 2] = cpu_to_le16(readw(bp->regs + 4096 + i));
> 
> Seems highly silly to me:  readw() already swaps on big endian, so 
> you're just swapping again.  And then...  read the call of 
> b44_read_eeprom():  bp->dev->dev_addr[] assignment is such that it swaps 
> YET AGAIN.
> 
> Seems like a better solution would be to remove the manual swap from the 
> caller of b44_read_eeprom().

I already explained this to you, but I will repeat me.
readw returns the data in CPU order.
With cpu_to_le16 we convert it to little endian, because
"ptr" is a pointer to a _byte_ arrray. See the cast above.
A byte array is little endian.
Should I go into deeper detail, or did you get it? ;)

The dev_addr assignment _intentionally_ swaps yet again, because
the values are stored in bigendian format in the SPROM.

Removing the swap for dev_addr would definately the worse and wrong
solution.

-- 
Greetings Michael.

  reply	other threads:[~2006-09-26 15:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-25 23:39 [patch 09/11] b44: fix eeprom endianess issue akpm
2006-09-25 23:59 ` Jeff Garzik
2006-09-26 15:47   ` Michael Buesch [this message]
2006-09-26 15:59     ` Jeff Garzik
2006-09-26 16:04       ` Michael Buesch
2006-09-26 16:08         ` Jeff Garzik
2006-09-26 16:20           ` Michael Buesch
2006-09-26 17:00             ` Jeff Garzik
2006-09-26 17:14               ` Michael Buesch
2006-09-27  7:55               ` Johannes Berg
2006-09-26 16:49   ` Johannes Berg
2006-09-26 17:49     ` Francois Romieu
2006-09-26 18:10       ` Michael Buesch
2006-09-26 19:05         ` Francois Romieu

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=200609261747.25575.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=akpm@osdl.org \
    --cc=jeff@garzik.org \
    --cc=netdev@vger.kernel.org \
    --cc=zambrano@broadcom.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;
as well as URLs for NNTP newsgroup(s).