linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Ivo van Doorn <ivdoorn@gmail.com>
Cc: "John W. Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH 8/28] rt2x00: optimize mac/bssid writing
Date: Wed, 28 Feb 2007 19:24:59 +0100	[thread overview]
Message-ID: <200702281924.59710.mb@bu3sch.de> (raw)
In-Reply-To: <200702281915.40940.IvDoorn@gmail.com>

On Wednesday 28 February 2007 19:15, Ivo van Doorn wrote:
> On Wednesday 28 February 2007 18:36, Michael Buesch wrote:
> > On Wednesday 28 February 2007 15:07, Ivo van Doorn wrote:
> > > Handling the mac and bssid configuration can be done much easier
> > > by writing the passed data directly into the register instead
> > > of moving it to a local variable first.
> > > 
> > > Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> > > 
> > > ---
> > > 
> > > diff --git a/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c b/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c
> > > index 27e151d..b6bf9f3 100644
> > > --- a/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c
> > > +++ b/drivers/net/wireless/mac80211/rt2x00/rt2400pci.c
> > > @@ -319,14 +319,11 @@ static inline void rt2400pci_close_debugfs(struct rt2x00_dev *rt2x00dev){}
> > >   */
> > >  static void rt2400pci_config_bssid(struct rt2x00_dev *rt2x00dev, u8 *bssid)
> > >  {
> > > -	u32 reg[2] = { 0, 0 };
> > > -
> > >  	/*
> > >  	 * The BSSID is passed to us as an array of bytes,
> > >  	 * that array is little endian, so no need for byte ordering.
> >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >  	 */
> > > -	memcpy(&reg, bssid, ETH_ALEN);
> > > -	rt2x00_register_multiwrite(rt2x00dev, CSR5, &reg[0], sizeof(reg));
> > > +	rt2x00_register_multiwrite(rt2x00dev, CSR5, (u32*)bssid, ETH_ALEN);
> >                                                     ^^^^^^
> > 
> > This doesn't break on BE machines?
> 
> No, the multiwrite (just like multiread) does not perform byteordering,
> so the device will receive each byte in the correct order.

No wait. It's not about performing byteordering somewhere.
It's that casting a bytearray (which is little endian) into an
u32 array (which is CPU endian) is almost always wrong.

Do you writel this array in a loop inside of register_multiwrite?
If yes, it's broken. writel expects values in CPU endianess.
This array will always be little endian.

-- 
Greetings Michael.

  reply	other threads:[~2007-02-28 18:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-28 14:07 [PATCH 8/28] rt2x00: optimize mac/bssid writing Ivo van Doorn
2007-02-28 17:36 ` Michael Buesch
2007-02-28 18:15   ` Ivo van Doorn
2007-02-28 18:24     ` Michael Buesch [this message]
2007-02-28 18:30       ` Ivo van Doorn
2007-02-28 18:46         ` Michael Buesch
2007-02-28 18:48           ` Ivo van Doorn

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=200702281924.59710.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=ivdoorn@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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).