Forgive my gross ignorance of code and 802.11, but somethign still
does not seem right. Yes, I can see how it's beautifully optimized,
what with the fall through and all, but it begs for a closer look.

If we're using 802.11a, all the bitrates are set. Ok, I don't know
much about 802.11a, but let's assume that's right.

if we're using 802.11g, all the bit rates get set. Definetly good.

However, the problem appears to come if we're using 802.11b, because
instead of the standard 1,2,5,11, 802.11b gets 6,9,12, etc. Those are
the g standards.

>From my read of the snippet, the blocks beneath case BCM43xx_PHYTYPE_g
and case BCM43xx_PHYTYPE_b should be swapped, so that 11b gets only
1,2,5,11 and not 6,9,etc

Unless of course, I completely misunderstand how this is supposed to
work. Which is entirely possible.

I look forward to using the bcm43xx on my laptop, particularly in
monitor mode. Speaking of, what is the status of monitor?


On 1/10/06, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 10, 2006 at 02:43:10PM -0600, Larry Finger wrote:
> > While reviewing the softmac version of r0utine bcm43xx_wx_get_rangeparams,
> > I found the following code snippit:
> >
> >         switch (bcm->current_core->phy->type) {
> >         case BCM43xx_PHYTYPE_A:
> >         case BCM43xx_PHYTYPE_G:
> >                 range->num_bitrates += 4;
> >                 range->bitrate[i++] = IEEE80211_CCK_RATE_1MB;
> >                 range->bitrate[i++] = IEEE80211_CCK_RATE_2MB;
> >                 range->bitrate[i++] = IEEE80211_CCK_RATE_5MB;
> >                 range->bitrate[i++] = IEEE80211_CCK_RATE_11MB;
> >         case BCM43xx_PHYTYPE_B:
> >                 range->num_bitrates += 8;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_6MB;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_9MB;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_12MB;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_18MB;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_24MB;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_36MB;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_48MB;
> >                 range->bitrate[i++] = IEEE80211_OFDM_RATE_54MB;
> >         }
> >
> > The code is correct for a and g PHY's, but is it right for b-type PHY's?
> > For them, I would have expected 1, 2, 5 and 11 MB rates, not 6, ..., 54 MB.
> > I think the attached patch fixes the situation.
>
> I think the code is indeed correct; if you take into consideration that is
> using a switch/case fallthrough structure (no breaks), and so the logic
> "seems" inverted to begin with.
>
> It might be a good idea to put a comment on top of it though, as I have to
> admit it got me by surprise also the first time i saw it, and before i enjoyed
> the beauty of it, and how nicely it optimizes out the unneeded JMP calls.  oh
> how i miss those old times of 6502 assembler programming :)
>
> Carlo
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Reply via email to