ath5k: Port to new bitrate/channel API

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found on status descriptors, it's still buggy but we are getting closer (i think it improved stability a little).

Changes-licensed-under: 3-clause-BSD

Signed-off-by Nick Kossifidis <[email protected]>

---

drivers/net/wireless/ath5k/base.c +2 -5

@@ -898,25 +879,26 @@ ath5k_copy_channels(struct ath5k_hw *ah,
 	}
 
 	for (i = 0, count = 0; i < size && max > 0; i++) {
-		ch = all ? i + 1 : chans[i].chan;
-		f = ath5k_ieee2mhz(ch);
-		/* Check if channel is supported by the chipset */
-		if (!ath5k_channel_ok(ah, f, chfreq))
-			continue;
+		ch = i + 1 ;
+		freq = ath5k_ieee2mhz(ch);

drivers/net/wireless/ath5k/base.c +2 -2

-		if (!all && (chans[i].mode & map[mode].mask) != map[mode].mode)
-			continue;
+		/* Write channel info and increment counter */
+		channels[count].center_freq = freq;

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found on status descriptors, it's still buggy but we are getting closer (i think it improved stability a little).

Changes-licensed-under: 3-clause-BSD

Signed-off-by Nick Kossifidis <[email protected]>

Quoted 5 lines

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found on status descriptors, it's still buggy but we are getting closer (i think it improved stability a little).

Quoted 2 lines

Changes-licensed-under: 3-clause-BSD

Signed-off-by Nick Kossifidis <[email protected]>

My approach was little more extreme removing ath5k_rate struct and led stuff completely but well, its not done. Also we definitely still do dependent on mode stuff a lot and the whole capaibilty stuff is used inconsistantly. If anything I can base patches on this work.

Nick, just please review the license and files you've changed. Other than that it looks OK.

2008/1/31, Luis R. Rodriguez <[email protected]>:

Quoted 6 lines · Nick Kossifidis

Quoted 5 lines

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found on status descriptors, it's still buggy but we are getting closer (i think it improved stability a little).

Quoted 8 lines

Quoted 2 lines

Changes-licensed-under: 3-clause-BSD

Signed-off-by Nick Kossifidis <[email protected]>

My approach was little more extreme removing ath5k_rate struct and led stuff completely but well, its not done. Also we definitely still do dependent on mode stuff a lot and the whole capaibilty stuff is used inconsistantly. If anything I can base patches on this work.

I also wanted to make a bigger cleanup (i added some TODOs there about removing led stuff -i want to port them to mac80211 leds, not just remove- and most of rate tables -we still need rate code mapping-, other things can be ripped out also) but until i'm done with the exams i don't have much time. Also some cosmetic changes like Jiri noticed would be usefull and i intend to do more cleanups on that way also. I hope i can come back with more stuff quickly ;-)

Quoted 2 lines

Nick, just please review the license and files you've changed. Other than that it looks OK.

Ouch you are right !

for base.c/base.h
Changes-licensed-under: 3-clause-BSD

for hw.c/initvals.c/phy.c/ath5k.h
Changes-licensed-under: ISC

Quoted 32 lines

2008/1/31, Luis R. Rodriguez <[email protected]>:

Quoted 6 lines · Nick Kossifidis

Quoted 5 lines

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found on status descriptors, it's still buggy but we are getting closer (i think it improved stability a little).

Quoted 8 lines

Quoted 2 lines

Changes-licensed-under: 3-clause-BSD

Signed-off-by Nick Kossifidis <[email protected]>

My approach was little more extreme removing ath5k_rate struct and led stuff completely but well, its not done. Also we definitely still do dependent on mode stuff a lot and the whole capaibilty stuff is used inconsistantly. If anything I can base patches on this work.

I also wanted to make a bigger cleanup (i added some TODOs there about removing led stuff -i want to port them to mac80211 leds, not just remove- and most of rate tables -we still need rate code mapping-, other things can be ripped out also) but until i'm done with the exams i don't have much time. Also some cosmetic changes like Jiri noticed would be usefull and i intend to do more cleanups on that way also. I hope i can come back with more stuff quickly ;-)

Quoted 2 lines

Nick, just please review the license and files you've changed. Other than that it looks OK.

Ouch you are right !

for base.c/base.h
Changes-licensed-under: 3-clause-BSD

Quoted 2 lines

for hw.c/initvals.c/phy.c/ath5k.h
Changes-licensed-under: ISC

Thanks. Nick as Jiri pointed out, can you also re-send after checking the patch with checkpatch.pl?

Luis

Checkpatch shows up 40 points, most of them because it's over 80 lines and some of them because there are some missing spaces etc. I'm sure code is full of those so i believe we should better cleanup the whole code (also doing some sparse checking btw) once and for all (i told you in my previous mail that's what i want to do when i'm done with exams). It's really more easy for me to clean up the whole code after i'm done with exams than try to locate 40 places in this monster that might be fixed manually. I just need some time, i thought porting to the new API was urgent so i gave it full priority, cleanup can wait i guess (and we have to do it right and cautious).

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found on status descriptors, it's still buggy but we are getting closer (i think it improved stability a little).
[...]

drivers/net/wireless/ath5k/base.c +56 -0

+/*
+ * Match the hw provided rate index (through descriptors)
+ * to an index for sc->curband->bitrates, so it can be used
+ * by the stack.
+ *
+ * This one is a little bit tricky but i think i'm right
+ * about this...
+ *
+ * We have 4 rate tables in the following order:
+ * XR (4 rates)
+ * 802.11a (8 rates)
+ * 802.11b (4 rates)
+ * 802.11g (12 rates)
+ * that make the hw rate table.
+ *
+ * Lets take a 5211 for example that supports a and b modes only.
+ * First comes the 802.11a table and then 802.11b (total 12 rates).
+ * When hw returns eg. 11 it points to the last 802.11b rate (11Mbit),
+ * if it returns 2 it points to the second 802.11a rate etc.
+ *
+ * Same goes for 5212 who has xr/a/b/g support (total 28 rates).
+ * First comes the XR table, then 802.11a, 802.11b and 802.11g.
+ * When hw returns eg. 27 it points to the last 802.11g rate (54Mbits) etc
+ */
+static void
+ath5k_set_total_hw_rates(struct ath5k_softc *sc){
+
+	struct ath5k_hw *ah = sc->ah;
+
+	if(test_bit(AR5K_MODE_11A, ah->ah_modes))
+		sc->a_rates = 8;
+
+	if(test_bit(AR5K_MODE_11B, ah->ah_modes))
+		sc->b_rates = 4;
+
+	if(test_bit(AR5K_MODE_11G, ah->ah_modes))
+		sc->g_rates = 12;
+
+	/* XXX: Need to see what what happens when
+		xr disable bits in eeprom are set */
+	if(ah->ah_version >= AR5K_AR5212)
+		sc->xr_rates = 4;
+
+}
+
+static inline int
+ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix){
+
+	int mac80211_rix;
+
+	if(sc->curband->band == IEEE80211_BAND_2GHZ){
+		/* We setup a g ratetable for both b/g modes */
+		mac80211_rix = hw_rix - sc->b_rates - sc->a_rates - sc->xr_rates;
+	} else {
+		mac80211_rix = hw_rix - sc->xr_rates;
+	}

Quoted 62 lines

Tested on 5211, 5213+5112, 5213A+2112A and it wors fine.

Also i figured out a way to process rate vallue found on status descriptors, it's still buggy but we are getting closer (i think it improved stability a little).
[...]

drivers/net/wireless/ath5k/base.c +56 -0

+/*
+ * Match the hw provided rate index (through descriptors)
+ * to an index for sc->curband->bitrates, so it can be used
+ * by the stack.
+ *
+ * This one is a little bit tricky but i think i'm right
+ * about this...
+ *
+ * We have 4 rate tables in the following order:
+ * XR (4 rates)
+ * 802.11a (8 rates)
+ * 802.11b (4 rates)
+ * 802.11g (12 rates)
+ * that make the hw rate table.
+ *
+ * Lets take a 5211 for example that supports a and b modes only.
+ * First comes the 802.11a table and then 802.11b (total 12 rates).
+ * When hw returns eg. 11 it points to the last 802.11b rate (11Mbit),
+ * if it returns 2 it points to the second 802.11a rate etc.
+ *
+ * Same goes for 5212 who has xr/a/b/g support (total 28 rates).
+ * First comes the XR table, then 802.11a, 802.11b and 802.11g.
+ * When hw returns eg. 27 it points to the last 802.11g rate (54Mbits) etc
+ */
+static void
+ath5k_set_total_hw_rates(struct ath5k_softc *sc){
+
+     struct ath5k_hw *ah = sc->ah;
+
+     if(test_bit(AR5K_MODE_11A, ah->ah_modes))
+             sc->a_rates = 8;
+
+     if(test_bit(AR5K_MODE_11B, ah->ah_modes))
+             sc->b_rates = 4;
+
+     if(test_bit(AR5K_MODE_11G, ah->ah_modes))
+             sc->g_rates = 12;
+
+     /* XXX: Need to see what what happens when
+             xr disable bits in eeprom are set */
+     if(ah->ah_version >= AR5K_AR5212)
+             sc->xr_rates = 4;
+
+}
+
+static inline int
+ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix){
+
+     int mac80211_rix;
+
+     if(sc->curband->band == IEEE80211_BAND_2GHZ){
+             /* We setup a g ratetable for both b/g modes */
+             mac80211_rix = hw_rix - sc->b_rates - sc->a_rates - sc->xr_rates;
+     } else {
+             mac80211_rix = hw_rix - sc->xr_rates;
+     }

drivers/net/wireless/ath5k/base.c ath5k_mode_setup(struct ath5k_softc *sc) · line 1201

Quoted 10 lines

drivers/net/wireless/ath5k/base.c +10 -0

+
+     /* Something went wrong, fallback to basic rate for this band */
+     if((mac80211_rix >= sc->curband->n_bitrates) ||
+     (mac80211_rix <= 0 )){
+             mac80211_rix = 1;
+     }
+
+     return mac80211_rix;
+}
+

hi nick!

i don't think that works (for me / right now)... the reported rate on received frames is just all wrong. receiving a frame which was sent with 6Mbps (5GHz band) the hw rix is 0xb which translates to mac80211 rate index 7 = 54Mbps. looking at the dumped rate table it seems the hardware reports rates with a hw value which don't directly translate into indices (at least i can't see any pattern right now).

Band 5 GHz: channels 194, rates 8
rates:
( rate hw )

    60 000b 0000 0000
    90 000f 0000 0000

120 000a 0000 0000
180 000e 0000 0000
240 0009 0000 0000
360 000d 0000 0000
480 0008 0000 0000
540 000c 0000 0000

i have verified that ds->ds_rxstat.rs_rate matches this table in 5GHz band on a AR5213 (meaning rs_rate 0xb == 6Mbps, 0xf == 9Mbps, etc...). i haven't done this on the 2GHz band, because it's just too noisy here.

bruno