[PATCH 1/2] devices: Add Atheros AR9381

[Sergey Ryazanov]

On Wed, Jan 19, 2022 at 2:31 AM Hauke Mehrtens <hauke at 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 at 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 at 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 at 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 at 10000000/pcie at d900000/pcie at 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 at 10000000/pcie at d900000/pcie at 0/wifi at 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 at 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.

-- 
Sergey