| Message ID | 1392345920-28891-1-git-send-email-sujith@msujith.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 2014-02-14 03:45, Sujith Manoharan wrote: > From: Sujith Manoharan <c_manoha@qca.qualcomm.com> > > The minimum CCA power threshold values have to be adjusted > for existing cards to be in compliance with new regulations. > Newer cards will make use of the values obtained from EEPROM, > support for this was added earlier. To make sure that cards > that are already in use and don't have proper values in EEPROM, > do not violate regulations, use the initvals instead. > > Cc: stable@vger.kernel.org > Reported-by: Jeang Daniel <dyjeong@qca.qualcomm.com> > Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Wouldn't it be better to do this for all AR93xx chipsets in ar9003_hw_apply_minccapwr_thresh instead of initvals? I'm pretty sure this patch will leave most other devices non-compliant. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Felix Fietkau wrote: > Wouldn't it be better to do this for all AR93xx chipsets in > ar9003_hw_apply_minccapwr_thresh instead of initvals? > I'm pretty sure this patch will leave most other devices non-compliant. The threshold values are adjusted for each chip and are not the same for all chips in the AR9003 family, so this is done in the initvals. ar9003_hw_apply_minccapwr_thresh() will be used only for chips which contain the new 'MinCCApwr' field in struct ar9300_BaseExtension_1. This is not present in almost all the AR9003-family chips. I believe it has been introduced in AR955x. Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-02-17 03:27, Sujith Manoharan wrote: > Felix Fietkau wrote: >> Wouldn't it be better to do this for all AR93xx chipsets in >> ar9003_hw_apply_minccapwr_thresh instead of initvals? >> I'm pretty sure this patch will leave most other devices non-compliant. > > The threshold values are adjusted for each chip and are not the same > for all chips in the AR9003 family, so this is done in the initvals. Almost all chips are using the same values in the initvals - the exceptions seem to be the ones that have had ETSI compliance fix attempts already. I'm pretty sure the new values (if adjusted for different bands) would be fully compatible. > ar9003_hw_apply_minccapwr_thresh() will be used only for chips which > contain the new 'MinCCApwr' field in struct ar9300_BaseExtension_1. > This is not present in almost all the AR9003-family chips. I believe it has > been introduced in AR955x. I know. What I meant is that in case the EEPROM does not have any values, we can make it use reasonable fixed defaults, thus overriding the values from the initvals. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Felix Fietkau wrote: > Almost all chips are using the same values in the initvals - the > exceptions seem to be the ones that have had ETSI compliance fix > attempts already. I'm pretty sure the new values (if adjusted for > different bands) would be fully compatible. For most of the chips, adjusting AR_PHY_CCA_MAX_GOOD_VAL_9300_2GHZ/5GHZ from the previous values to -60 is sufficient and the initvals don't need any changes to be compliant. For some chips, the change in the max. CCA threshold require adjustments in the minCCApwr_thr field - it is easier to do this via the initvals. This has been done for AR9485, AR9462 and AR9565 so far. AR9485: new value is -50 dB AR9565: new value is -92 dB AR9462: chain 0 : 2G: -91dB, 5G: -88dB chain 1 : 2G: -91dB, 5G: -90dB The SoC chips do not have any corresponding changes in minCCApwr_thr for the new CCA_MAX_GOOD_VAL. The only weird exception is AR9331 which has new minCCApwr_thr values in the internal PCOEM driver, but not in the SoC driver - not sure which one is correct. Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h b/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h index 1cc1356..1b6b4d0 100644 --- a/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h +++ b/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h @@ -57,7 +57,7 @@ static const u32 ar9462_2p0_baseband_postamble[][5] = { {0x00009e14, 0x37b95d5e, 0x37b9605e, 0x3236605e, 0x32365a5e}, {0x00009e18, 0x00000000, 0x00000000, 0x00000000, 0x00000000}, {0x00009e1c, 0x0001cf9c, 0x0001cf9c, 0x00021f9c, 0x00021f9c}, - {0x00009e20, 0x000003b5, 0x000003b5, 0x000003ce, 0x000003ce}, + {0x00009e20, 0x000003a5, 0x000003a5, 0x000003a5, 0x000003a5}, {0x00009e2c, 0x0000001c, 0x0000001c, 0x00000021, 0x00000021}, {0x00009e3c, 0xcf946220, 0xcf946220, 0xcfd5c782, 0xcfd5c282}, {0x00009e44, 0x62321e27, 0x62321e27, 0xfe291e27, 0xfe291e27}, @@ -96,7 +96,7 @@ static const u32 ar9462_2p0_baseband_postamble[][5] = { {0x0000ae04, 0x001c0000, 0x001c0000, 0x001c0000, 0x00100000}, {0x0000ae18, 0x00000000, 0x00000000, 0x00000000, 0x00000000}, {0x0000ae1c, 0x0000019c, 0x0000019c, 0x0000019c, 0x0000019c}, - {0x0000ae20, 0x000001b5, 0x000001b5, 0x000001ce, 0x000001ce}, + {0x0000ae20, 0x000001a6, 0x000001a6, 0x000001aa, 0x000001aa}, {0x0000b284, 0x00000000, 0x00000000, 0x00000550, 0x00000550}, };