| Message ID | 1361648055-15871-1-git-send-email-kazikcz@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 2013-02-23 20:34 +0100, Michal Kazior wrote linux-wireless@vger.kernel.o...:
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 <kazikcz@gmail.com>
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: GHhost@icf.org.ru JID: GHhost@icf.org.ru
YG129-RIPE YG129-RIPE
On 23 February 2013 20:45, Georgiewskiy Yuriy <bottleman@icf.org.ru> 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? -- 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 2013-02-26 18:49 +0100, Micha? Kazior wrote Georgiewskiy Yuriy: MK>On 23 February 2013 20:45, Georgiewskiy Yuriy <bottleman@icf.org.ru> 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: GHhost@icf.org.ru JID: GHhost@icf.org.ru YG129-RIPE YG129-RIPE
On Sat, Feb 23, 2013 at 11:34 AM, Michal Kazior <kazikcz@gmail.com> 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 <kazikcz@gmail.com> 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 -- 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 26 February 2013 19:29, Luis R. Rodriguez <mcgrof@qca.qualcomm.com> 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. -- 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 Tue, Feb 26, 2013 at 11:28 AM, Micha? Kazior <kazikcz@gmail.com> wrote: > On 26 February 2013 19:29, Luis R. Rodriguez <mcgrof@qca.qualcomm.com> 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 <mcgrof@qca.qualcomm.com> 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 -- 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 Tue, Feb 26, 2013 at 12:01 PM, Luis R. Rodriguez <mcgrof@qca.qualcomm.com> wrote: > Apologies again and then (unless I hear otherwise from David Quan): > > Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> I did hear back from David and it seems that we would never support this. John please do not apply this just yet. 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;
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 <kazikcz@gmail.com> --- drivers/net/wireless/ath/regd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)