Hi Nick,
Nick Kossifidis schrieb:
> Thanks for catching this but the bug is elsewhere:
> So guess why the last 2 "invalid" power gain values have the same
> power levels for all rates ? They are for XR mode (they've put it
> there on the eeprom because XR mode also operates at 5GHz) and since
> XR stuff is stripped off Madwifi (at least the public HAL) that's why
> it only reads 8 of the piers.
>
> Now notice that the last 2 readings on your previous post start from a
> different frequency and most important that 5360 < 5825 and that
> makes sense since the idea is to have only 2 points to interpolate
> between them for the whole XR range. So we have 2 frequency "ranges"
> to search, the one is the 11a mode from 4920 to 5825 and the other
> one is for XR mode from 5360 to 5720. When the first range ends the
> other starts.
>
> The bug is here:
>
> ath5k_get_rate_pcal_data:
> 2704 max = ee->ee_rate_target_pwr_num[mode] - 1;
> [...]
> 2713 if (target > rpinfo[max].freq) {
> 2714 idx_l = idx_r = max;
> 2715 goto done;
> 2716 }
>
> So please instead of tweaking the EEPROM code just change
> max = ee->ee_rate_target_pwr_num[mode] - 1;
> to
> max = ee->ee_rate_target_pwr_num[mode] - 3;
> in case of AR5K_MODE_11A
The calibration data for 802.11a in the standard conform mode should
only consider 8 reads from the eeprom, thats why I introduced this new
define... a "-3" is from my view of readability not as traceable.
Any other non standard mode as you mentioned XR as one of, could just
ready its necessary lines of the eeprom ones it get supported in ath5k.
Greetings Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
