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 <[email protected]>
---
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
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 <[email protected]> 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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 28 February 2013 03:43, Adrian Chadd <[email protected]> wrote:
> Have you verified that the rest of the EEPROM contents are vailid?
I have not. How can I do that?
-- Michal
On Wed, Feb 27, 2013 at 10:52 PM, Michał Kazior <[email protected]> wrote:
> On 28 February 2013 03:43, Adrian Chadd <[email protected]> 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