On 1/19/22 01:33, Sergey Ryazanov wrote:
On Wed, Jan 19, 2022 at 2:31 AM Hauke Mehrtens <[email protected]> wrote:
On 1/18/22 23:38, Sergey Ryazanov wrote:
On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens <[email protected]> wrote:
This adds the Atheros AR9381 to the devices list. This card was found in
the TP-LINK TD-W8970.
Signed-off-by: Hauke Mehrtens <[email protected]>
---
devices.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/devices.txt b/devices.txt
index e6c18e6..3cec45a 100644
--- a/devices.txt
+++ b/devices.txt
@@ -172,6 +172,7 @@
0x168c 0x0046 0x168c 0xcafe 0 0 "Qualcomm Atheros" "QCA9984"
0x168c 0x0050 0x0000 0x0000 0 0 "Qualcomm Atheros" "QCA9887"
0x168c 0x0056 0x0000 0x0000 0 0 "Qualcomm Atheros" "QCA9886"
+0x168c 0xabcd 0x0000 0x0000 0 0 "Atheros" "AR9381"
I am just curious, is this a normal device ID for AR9381 chips or is
this some kind of wrongly programmed EEPROM of TD-W8970?
ath9k driver knows nothing about the 0xABCD device. And according to
wikidevi [1], the normal DevID for AR9381 based devices is 0x0030.
1. https://wikidevi.wi-cat.ru/Alpha_Networks_WMC-N02
Hi,
Thanks for pointing this out.
It could be that I broke something in the EEPROM on this device
accidentally, I use it for testing since some time. It could also be
that the PCIe controller driver is broken, it is not upstream and not
looking nice.
Hauke
Here is the output:
-------------------
root@OpenWrt:/# lspci -v -n
00:00.0 0604: 1bef:0011 (rev 01) (prog-if 00 [Normal decode])
Device tree node:
/sys/firmware/devicetree/base/fpi@10000000/pcie@d900000/pcie@0
Flags: bus master, fast devsel, latency 0, IRQ 144
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 1c000000-1c0fffff [size=1M]
Prefetchable memory behind bridge: 1c100000-1c1fffff [size=1M]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [70] Express Root Port (Slot-), MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Power Budgeting <?>
Kernel driver in use: pcieport
lspci: Unable to load libkmod resources: error -12
01:00.0 0200: 168c:abcd (rev 01)
Device tree node:
/sys/firmware/devicetree/base/fpi@10000000/pcie@d900000/pcie@0/wifi@168c,002e
Flags: bus master, fast devsel, latency 0, IRQ 144
Memory at 1c000000 (64-bit, non-prefetchable) [size=128K]
Expansion ROM at 1c100000 [virtual] [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: ath9k
-------------------
This is the kernel log:
--------
[ 23.735405] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1
[ 23.740723] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned
[ 23.746963] ath9k 0000:01:00.0: enabling device (0000 -> 0002)
[ 23.753378] ath9k 0000:01:00.0: Direct firmware load for
ath9k-eeprom-pci-0000:01:00.0.bin failed with error -2
[ 23.762891] ath9k 0000:01:00.0: Falling back to sysfs fallback for:
ath9k-eeprom-pci-0000:01:00.0.bin
[ 24.599413] ieee80211 phy0: Atheros AR9300 Rev:3 mem=0xbc000000, irq=144
--------
Most probably the chip calibration data is Ok, the chip just has no
access to it and utilizes the default DevID value.
Upstream ath9k knows nothing about the 0xABCD device, but our mac80211
package has a special patch for this case:
mac80211 $ grep -rni abcd *
patches/ath9k/513-ath9k_add_pci_ids.patch:17:+#define
AR9300_DEVID_INVALID 0xabcd
patches/ath9k/513-ath9k_add_pci_ids.patch:27:+ { PCI_VDEVICE(ATHEROS,
0xabcd) }, /* PCI-E internal chip default ID */
Commit that introduced the patch has no additional evidences:
mac80211 $ git log -n1 3251cddf31e
commit 3251cddf31efc23089da6f25f97655beaa1f5950
Author: John Crispin <[email protected]>
Date: Thu Jul 25 20:28:45 2013 +0000
mac8021: add ath9k pcie id for AR9381
So I am in doubt. On one hand, 0xABCD is a real ID that is returned by
the AR9381 chip when it has no attached EEPROM or the OTP data. On the
other hand, this is an ID of an invalid state. And I do not know how
many other Atheros chip models return it. Most probably your patch is
the best solution which we can implement at the moment. Since it is
better to have an almost accurate description than "Unknown device" :)
Could you just add some notes to the commit message to clarify that
0xABCD is the unusual Device ID that appears if a chip has no
programmed IDs? This will provide some clues for further readers.
BTW, AR54xx/AR92xx chips have the similar issue with unprogrammed IDs,
they appear on a PCI bus with a special identifier 0xFF1C or 0xFF1D.
But they are using another approach to solve the issue. A tiny
ath9k-owl-loader (see kmod-owl-loader package) driver loads first,
reads IDs from a flash file, (re-)initializes chip ID register with a
correct value and then hands off control to the regular ath9k driver.
Hi Sergey,
Thank you for this detailed analysis.
I would probably leave this patch out for now. 0xabcd could also be a
different wifi card, it is better to show unknown instead of the wrong
name. We could show something like "Qualcomm Atheros" "Generic" to at
least show the vendor name.
Hauke
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
