Dbii F52N-PRO mini pci device reports an invalid
regdomain. This card has been reported to work on
MikroTik's RouterOS but failed on Linux:
[ 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]>
---
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.7.12.4
On Sat, Feb 23, 2013 at 11:34 AM, Michal Kazior <[email protected]> wrote:
> Dbii F52N-PRO mini pci device reports an invalid
> regdomain. This card has been reported to work on
> MikroTik's RouterOS but failed on Linux:
>
> [ 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]>
NACK. This comes up every now and then and this is not a valid device
ID, this is an issue with the card, so what you can do is adjust the
device ID post bootup. Not sure if distros have an easy way to set
this up, if not perhaps this should be considered as this has come up
twice before.
Luis
On Tue, Feb 26, 2013 at 12:01 PM, Luis R. Rodriguez
<[email protected]> wrote:
> Apologies again and then (unless I hear otherwise from David Quan):
>
> Acked-by: Luis R. Rodriguez <[email protected]>
I did hear back from David and it seems that we would never support
this. John please do not apply this just yet.
Luis
On 2013-02-23 20:34 +0100, Michal Kazior wrote [email protected]...:
hm, strange, i have this cards, and it's works fine, exactly not fine, but works,
and as i known it's EOS since 2012.
MK>Dbii F52N-PRO mini pci device reports an invalid
MK>regdomain. This card has been reported to work on
MK>MikroTik's RouterOS but failed on Linux:
MK>
MK>[ 14.320000] ath: EEPROM regdomain: 0xffff
MK>[ 14.320000] ath: EEPROM indicates we should expect a country code
MK>[ 14.320000] ath: invalid regulatory domain/country code 0xbfff
MK>[ 14.320000] ath: Invalid EEPROM contents
MK>[ 14.320000] ath9k 0000:00:12.0: Failed to initialize device
MK>[ 14.330000] ath9k: probe of 0000:00:12.0 failed with error -22
MK>
MK>With the patch the device works fine.
MK>
MK>Signed-off-by: Michal Kazior <[email protected]>
MK>---
MK> drivers/net/wireless/ath/regd.c | 3 ++-
MK> 1 file changed, 2 insertions(+), 1 deletion(-)
MK>
MK>diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
MK>index ccc4c71..48fb1b9 100644
MK>--- a/drivers/net/wireless/ath/regd.c
MK>+++ b/drivers/net/wireless/ath/regd.c
MK>@@ -533,10 +533,11 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
MK> * but since we have more than one user with it we need
MK> * a solution for them. We default to 0x64, which is the
MK> * default Atheros world regulatory domain.
MK>+ * There is also at least one report of 0xFFFF being set.
MK> */
MK> static void ath_regd_sanitize(struct ath_regulatory *reg)
MK> {
MK>- if (reg->current_rd != COUNTRY_ERD_FLAG)
MK>+ if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0xFFFF)
MK> return;
MK> printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
MK> reg->current_rd = 0x64;
MK>
C ????????? With Best Regards
???????????? ????. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
???? +7 4872 711143 fax +7 4872 711143
???????? ??? "?? ?? ??????" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On 26 February 2013 19:29, Luis R. Rodriguez <[email protected]> wrote:
> NACK. This comes up every now and then and this is not a valid device
> ID, this is an issue with the card, so what you can do is adjust the
> device ID post bootup. Not sure if distros have an easy way to set
> this up, if not perhaps this should be considered as this has come up
> twice before.
The erroneous 0xFFFF value comes from using one of eeprom_ops
implementations. Do you suggest I should fool ath regd code to think
this is a different card so it picks a different (perhaps correct, if
at all) eeprom_ops variant? How do I do that?
>From what I can tell this is in the pci probing and I can't see any
way to skip the regd initialisation. I don't see how current_rd can
have a value other than 0xFFFF for this device in this code path.
Or am I missing something?
-- Michal.
On Tue, Feb 26, 2013 at 11:28 AM, Michał Kazior <[email protected]> wrote:
> On 26 February 2013 19:29, Luis R. Rodriguez <[email protected]> wrote:
>> NACK. This comes up every now and then and this is not a valid device
>> ID, this is an issue with the card, so what you can do is adjust the
>> device ID post bootup. Not sure if distros have an easy way to set
>> this up, if not perhaps this should be considered as this has come up
>> twice before.
>
> The erroneous 0xFFFF value comes from using one of eeprom_ops
> implementations.
Apologies I quickly read this as an issue with 0xFFFF device ID and
not a regulatory domain ID being set to 0xFFFF. Just to clarify for
the reader / record then given I may have mislead folks with my
comments -- the issue you are reporting is regarding an 0xFFFF
regulatory domain, not the PCI device ID being set to 0xFFFF (which
was also reported at times).
Given I NACK'd assuming this was a PCI device ID issue let me
elaborate on that possible issue for future's and record's sake and
also on your issue.
The eeprom_ops are a set of ops for different set of family of cards
we support. The correct eeprom_ops family of functions your card would
end up using will vary depending not only the PCI device ID to load
the driver but more importantly on the family ID on the EEPROM, see
ath9k_hw_eeprom_init() and ath9k_hw_read_revisions(), essentially
obtained through PCI iomem reads. If the EEPROM is messed up then the
wrong family of device would be set and there no point to support
these type of devices in kernel code, the way to work around these
issues would be at post load using sysfs, and that is why I jumped the
gun and NACKed thinking it was this type of issue.
In your case though you claim that only the EEPROM regulatory domain
is not being recognized as valid by the ath regd code, granted that
the driver does an EEPROM checksum check so if indeed that was the
intended EEPROM regd value programmed then the regd value was intended
to be that. Now, 0xFFFF is simply not a known regulatory domain that
we support and why it would be programmed as such is beyond me. It is
not something we support! Given that your card exists and likely
perhaps others (whoever programmed that card, not sure)... we can
indeed add support as you suggest by using the most restrictive world
regulatory domain as you have amended.
Apologies again and then (unless I hear otherwise from David Quan):
Acked-by: Luis R. Rodriguez <[email protected]>
But please re-post and amend the commit log entry with information
that explain that given that your EEPROM must have been intentionally
programmed to 0xFFFF given that the EEPROM checksum is valid, but that
QCA does not support 0xFFFF as a valid regulatory domain value you are
adding support by using the 0x64 regulatory domain, the most
restrictive custom world regulatory domain by the ath module.
Luis
On 23 February 2013 20:45, Georgiewskiy Yuriy <[email protected]> wrote:
> hm, strange, i have this cards, and it's works fine, exactly not fine, but works,
> and as i known it's EOS since 2012.
Apparently some of them have their EEPROM programmed incorrectly.
Perhaps different revisions? Beats me.
The one in question has "F52N/F50N/F20N V7" printed on the board and
"FCC ID:VKV-Ff52N" on a sticker. Is yours any different?
On 2013-02-26 18:49 +0100, Micha? Kazior wrote Georgiewskiy Yuriy:
MK>On 23 February 2013 20:45, Georgiewskiy Yuriy <[email protected]> wrote:
MK>> hm, strange, i have this cards, and it's works fine, exactly not fine, but works,
MK>> and as i known it's EOS since 2012.
MK>
MK>Apparently some of them have their EEPROM programmed incorrectly.
MK>Perhaps different revisions? Beats me.
MK>
MK>The one in question has "F52N/F50N/F20N V7" printed on the board and
MK>"FCC ID:VKV-Ff52N" on a sticker. Is yours any different?
hm, may be, have f52n/f50n/f20n next line
1132 v6 он the board, and have no any FCC on sticker, seems only serial
number or something like this on it.
C уважением With Best Regards
Георгиевский Юрий. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
факс +7 4872 711143 fax +7 4872 711143
Компания ООО "Ай Ти Сервис" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE