| Message ID | 20220116213025.1379508-1-hauke@hauke-m.de |
|---|---|
| State | Needs Review / ACK |
| Delegated to: | Hauke Mehrtens |
| Headers | show |
| Series | [1/2] devices: Add Atheros AR9381 | expand |
Hello Hauke, On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens <hauke@hauke-m.de> 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 <hauke@hauke-m.de> > --- > 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
On 1/18/22 23:38, Sergey Ryazanov wrote: > Hello Hauke, > > On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens <hauke@hauke-m.de> 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 <hauke@hauke-m.de> >> --- >> 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 -------- Hauke
On Wed, Jan 19, 2022 at 2:31 AM Hauke Mehrtens <hauke@hauke-m.de> wrote: > On 1/18/22 23:38, Sergey Ryazanov wrote: >> On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens <hauke@hauke-m.de> 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 <hauke@hauke-m.de> >>> --- >>> 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 <john@openwrt.org> 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.
On 1/19/22 01:33, Sergey Ryazanov wrote: > On Wed, Jan 19, 2022 at 2:31 AM Hauke Mehrtens <hauke@hauke-m.de> wrote: >> On 1/18/22 23:38, Sergey Ryazanov wrote: >>> On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens <hauke@hauke-m.de> 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 <hauke@hauke-m.de> >>>> --- >>>> 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 <john@openwrt.org> > 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
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" 0x1814 0x3050 0x1814 0x0005 0 0 "Ralink" "Rt3050" 0x1814 0x3051 0x1814 0x0007 0 0 "Ralink" "Rt3051" 0x1814 0x3052 0x1814 0x0008 0 0 "Ralink" "Rt3052"
This adds the Atheros AR9381 to the devices list. This card was found in the TP-LINK TD-W8970. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- devices.txt | 1 + 1 file changed, 1 insertion(+)