[PATCH 1/2] devices: Add Atheros AR9381
Hauke Mehrtens
hauke at hauke-m.de
Wed Jan 19 14:57:41 PST 2022
On 1/19/22 01:33, Sergey Ryazanov wrote:
> 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.
>
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
More information about the openwrt-devel
mailing list