From: Michael Buesch <mb@bu3sch.de>
To: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] b43: use the bitrev helpers rather than rolling a private one
Date: Wed, 14 May 2008 03:03:23 +0200 [thread overview]
Message-ID: <200805140303.23590.mb@bu3sch.de> (raw)
In-Reply-To: <1210726437.6191.17.camel@brick>
On Wednesday 14 May 2008 02:53:56 Harvey Harrison wrote:
> On Wed, 2008-05-14 at 01:24 +0200, Michael Buesch wrote:
> > On Tuesday 13 May 2008 21:55:18 Harvey Harrison wrote:
> > > The 4-bit reversal flip_4bit is replaced with the bitrev helper
> > > bitrev8 and a 4-bit shift. The B43_WARN is moved to the location
> > > where a register is read from for checking there. The other caller
> > > explicitly passes an array index which is guaranteed to be within range
> > > and so a B43_WARN is not added there.
> > >
> > > Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
> >
> > ACK
> >
> > But I'd prefer if we had something like the following
> > and use that:
> >
> > #define bitrev4(x) (bitrev8(x) >> 4)
> >
> > This way the confusing (confusing to me :) ) shifts in the code would go away.
> > I have a hard time realizing that
> > bitrev8(x) >> 3
> > does actually mean
> > bitrev4(x) << 1
> > Maybe I'm just stupid, though. :)
> >
>
> You're not, this was only valid because x < 16....if bit 4 could be set
> this doesn't work anymore as bitrev8(x) >> 4 would truncate bit 4
> before shifting left. So there was some subtlety here that makes >> 3
> ok.
I don't understand. These are all 4 bit values.
The old flip helper enforced this with a B43_WARN_ON().
The >>3 actually is
((bitrev8(x) >> 4) << 1)
which is the same as
(bitrev4(x) << 1)
The <<1 is there, because the hardware wants is this way in the register.
The <<1 is not related to the actual flip operation.
> Do you want an incremental patch adding a bitrev4 to phy.c or are you
> going to add it?
Can you just respin this one instead of doing an incremental one?
--
Greetings Michael.
next prev parent reply other threads:[~2008-05-14 1:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 19:55 [PATCH] b43: use the bitrev helpers rather than rolling a private one Harvey Harrison
2008-05-13 23:24 ` Michael Buesch
2008-05-14 0:53 ` Harvey Harrison
2008-05-14 1:03 ` Michael Buesch [this message]
2008-05-14 1:13 ` [PATCHv2] " Harvey Harrison
2008-05-14 10:21 ` Michael Buesch
2008-05-14 10:26 ` Michael Buesch
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=200805140303.23590.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=akpm@linux-foundation.org \
--cc=harvey.harrison@gmail.com \
--cc=linux-wireless@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 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.