[OpenWrt-Devel] Broken WiFi on QCA9533 rev. 2

Adrian Schmutzler mail at adrianschmutzler.de
Tue Nov 5 11:14:27 EST 2019

Hi David,

thanks for your response. 

To me it looks like qca953x already uses 25 MHz clock, or am I looking at the wrong value:




On 5 November 2019 16:46:59 CET, David Bauer <mail at david-bauer.net> wrote:
>Hello Adrian,
>during the CPE210v2 bringup it was discovered that the CPE210 has the
>wrong bootstrap option set
>for it's 25 MHz reference clock. Because of this, the device was
>originally not even booting with ar71xx.
>On ath79, the reference clock is not detected based on the bootstrap
>option, but set by the DTS.
>The twist however is the ath9k driver, whose OF patch still reads this
>register. [0]
>On ar71xx, the platform data was always set to true for the QCA9533 [1]
>So you can try to force the settings for 25MHz reference clock for all
>QCA953x regardless of the bootstrap
>settings to keep the behavior in line with ar71xx.
>I have no device to verify this, however it's a good candidate for the
>root cause. ;)
>Best wishes
>On 11/5/19 3:05 PM, Adrian Schmutzler wrote:
>> Hi,
>> for quite some time already we are struggling with broken WiFi on
>some TP-Link CPE devices having QCA9533 rev. 2 (QCA9533-BL3A SOC) in
>> I'd be happy on some help here, since I've exhausted my debugging
>> 1. Symptoms: WiFi looks up on the device, some TX traffic is shown in
>ifconfig, RX is zero. The AP cannot be found by clients. "iw dev wlan0
>scan" returns nothing.
>> 2. Affected devices: TP-Link CPE210 v2/v3, CPE220 v3 (all QCA9533
>rev. 2?); no other QCA9533 devices known to be affected (specific to
>CPE or to QCA9533 rev. 2?)
>> 3. For a certain model, there are devices which are working correctly
>and others which don't. There is no known indicator to find out whether
>a device works or not. The state of a device does not change as far as
>we know (always working or never working).
>> 4. So far, only 2.4 GHZ-only devices were affected
>> 5. There is no diagnostic output that indicates a WiFi problem.
>dmesg/logread look normal, there is no difference when compared between
>working and not-working devices (despite RX=0/scan as stated above)
>> 6. The problem seems to be present from the beginning (device support
>patches), it just has been overlooked since it's not occurring on every
>> 7. The ar71xx firmware for all devices works flawlessly, so it is an
>ath79-specific problem.
>> Other findings that might be connected or not:
>> a. On ath79 phy0 uses irq=11/irq=12 and on ar71xx irq=47. eth0 uses
>irq=4 on both targets.
>> b. The following gpio is only found on ar71xx: gpio-495 ( |ath9k-phy0
>) in lo
>> I currently own a CPE210v2 with the bug and can test suggestions (if
>I'm capable of implementing them).
>> There is a device support PR for the CPE220 v3 suffering from the
>same problem: https://github.com/openwrt/openwrt/pull/2514
>> Despite, further reading may be found in forum discussion and bug
>> https://bugs.openwrt.org/index.php?do=details&task_id=2333
>> https://bugs.openwrt.org/index.php?do=details&task_id=2478
>> Initial support for CPE210 v2/v3 was done by me and bluelineXY, both
>already involved in the discussion. ;-)
>> Thanks for any hints!
>> Adrian
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20191105/a3972613/attachment.htm>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list