| Message ID | 1361992172-4590-1-git-send-email-kazikcz@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Have you verified that the rest of the EEPROM contents are vailid? As long as the rest of the EEPROM has passed the checksum test, then yes, I'm happy with this. .. it's just that the F52N-PRO NICs are marketed as 4.9/5ghz NICs, and the world regulatory domain won't be any good for them... :) Adrian On 27 February 2013 11:09, Michal Kazior <kazikcz@gmail.com> wrote: > Apparently some Dbii F52N-PRO mini pci devices > have been intentionally programemd with a 0xFFFF > regdomain. This is incorrect and unsupported by > QCA. > > The patch sanitizes the 0xFFFF regdomain with 0x64 > which is the most restrictive custom world > regulatory domain in the ath module. > > This card has been reported to work on MikroTik's > RouterOS but failed on Linux with the following: > > [ 14.320000] ath: EEPROM regdomain: 0xffff > [ 14.320000] ath: EEPROM indicates we should expect a country code > [ 14.320000] ath: invalid regulatory domain/country code 0xbfff > [ 14.320000] ath: Invalid EEPROM contents > [ 14.320000] ath9k 0000:00:12.0: Failed to initialize device > [ 14.330000] ath9k: probe of 0000:00:12.0 failed with error -22 > > With the patch the device works fine. > > Signed-off-by: Michal Kazior <kazikcz@gmail.com> > --- > v2: updated commit message as suggested by Luis > > drivers/net/wireless/ath/regd.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c > index ccc4c71..48fb1b9 100644 > --- a/drivers/net/wireless/ath/regd.c > +++ b/drivers/net/wireless/ath/regd.c > @@ -533,10 +533,11 @@ ath_regd_init_wiphy(struct ath_regulatory *reg, > * but since we have more than one user with it we need > * a solution for them. We default to 0x64, which is the > * default Atheros world regulatory domain. > + * There is also at least one report of 0xFFFF being set. > */ > static void ath_regd_sanitize(struct ath_regulatory *reg) > { > - if (reg->current_rd != COUNTRY_ERD_FLAG) > + if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0xFFFF) > return; > printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n"); > reg->current_rd = 0x64; > -- > 1.8.1.4 > > -- > 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 -- 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 28 February 2013 03:43, Adrian Chadd <adrian@freebsd.org> wrote:
> Have you verified that the rest of the EEPROM contents are vailid?
I have not. How can I do that?
-- Michal
--
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 Wed, Feb 27, 2013 at 10:52 PM, Micha? Kazior <kazikcz@gmail.com> wrote: > On 28 February 2013 03:43, Adrian Chadd <adrian@freebsd.org> wrote: >> Have you verified that the rest of the EEPROM contents are vailid? > > I have not. How can I do that? The module would have done this upon initialization, this is done during hw init, prior to reg init. The EEPROM callback fill_eeprom() does this for the different families. To be clear ath9k_hw_init() gets called prior to ath_regd_init(). I'll note for the record that regardless of what is decided if the card came from a device designed as an AP the AP manufacturer intended for that card to stay with that AP, and as per our support team the AP design / manufacturer could end up programming whatever into the EEPROM / OTP, and their support for that device would be intended with their own solution. Supporting 0x64 for this regdomain that some random AP manufacturer used should be OK though but note that we can't support it. Luis -- 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/regd.c b/drivers/net/wireless/ath/regd.c index ccc4c71..48fb1b9 100644 --- a/drivers/net/wireless/ath/regd.c +++ b/drivers/net/wireless/ath/regd.c @@ -533,10 +533,11 @@ ath_regd_init_wiphy(struct ath_regulatory *reg, * but since we have more than one user with it we need * a solution for them. We default to 0x64, which is the * default Atheros world regulatory domain. + * There is also at least one report of 0xFFFF being set. */ static void ath_regd_sanitize(struct ath_regulatory *reg) { - if (reg->current_rd != COUNTRY_ERD_FLAG) + if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0xFFFF) return; printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n"); reg->current_rd = 0x64;
Apparently some Dbii F52N-PRO mini pci devices have been intentionally programemd with a 0xFFFF regdomain. This is incorrect and unsupported by QCA. The patch sanitizes the 0xFFFF regdomain with 0x64 which is the most restrictive custom world regulatory domain in the ath module. This card has been reported to work on MikroTik's RouterOS but failed on Linux with the following: [ 14.320000] ath: EEPROM regdomain: 0xffff [ 14.320000] ath: EEPROM indicates we should expect a country code [ 14.320000] ath: invalid regulatory domain/country code 0xbfff [ 14.320000] ath: Invalid EEPROM contents [ 14.320000] ath9k 0000:00:12.0: Failed to initialize device [ 14.330000] ath9k: probe of 0000:00:12.0 failed with error -22 With the patch the device works fine. Signed-off-by: Michal Kazior <kazikcz@gmail.com> --- v2: updated commit message as suggested by Luis drivers/net/wireless/ath/regd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)