Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mac80211: ath10k: avoid system bootloops with qca9880 v1 #2435

Closed
wants to merge 1 commit into from

Conversation

psyborg55
Copy link
Contributor

Booting released images on Archer C7 v1 or TL-WDR7500 v2 always resulted in crash and reboot followed by the same
on next boot with presence of both kmod-ath10k and default qca9880-ar1a card.
This change is about getting system to boot, so users can then decide whether to remove kmod-ath10k only or go
open the case (not quite easy) and pull the card out/replace it...
Since QCA986X and both QCA988X versions use same device id it was necessary to make differentiations based on
chip id. To make QCA9880 v1 more stable during boot, CDC workaround for copy engine was added back and cold
reset (commit ath10k: delay device access after cold reset) was reverted.
Reading chip id is moved before chip reset since it is needed to specify QCA9880 v1 cold reset, for which
qca99x0 chip reset needs to be used since it doesn't involve warm reset, as warm reset doesn't work with
v1 card. There are still occasional crashes, especially with latest kernels/drivers, but when there is no
crash system boots as expected. During 20 minute rebooting test on ar71xx v4.9.111 the system crashed 3 times.
These changes do not affect QCA9880 v2 which boots and operates as expected.

Signed-off-by: Tomislav Požega pozega.tomislav@gmail.com

Booting released images on Archer C7 v1 or TL-WDR7500 v2 always resulted in crash and reboot followed by the same
on next boot with presence of both kmod-ath10k and default qca9880-ar1a card.
This change is about getting system to boot, so users can then decide whether to remove kmod-ath10k only or go
open the case (not quite easy) and pull the card out/replace it...
Since QCA986X and both QCA988X versions use same device id it was necessary to make differentiations based on
chip id. To make QCA9880 v1 more stable during boot, CDC workaround for copy engine was added back and cold
reset (commit ath10k: delay device access after cold reset) was reverted.
Reading chip id is moved before chip reset since it is needed to specify QCA9880 v1 cold reset, for which
qca99x0 chip reset needs to be used since it doesn't involve warm reset, as warm reset doesn't work with
v1 card. There are still occasional crashes, especially with latest kernels/drivers, but when there is no
crash system boots as expected. During 20 minute rebooting test on ar71xx v4.9.111 the system crashed 3 times.
These changes do not affect QCA9880 v2 which boots and operates as expected.

Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
psyborg55 added a commit to psyborg55/openwrt that referenced this pull request Sep 22, 2019
ath10k driver/firmware packages were removed due to bootloop issues
which are now mitigated, so these can be included back.
Depends on openwrt#2435

Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
@ynezz
Copy link
Member

ynezz commented Sep 23, 2019

There are still occasional crashes, especially with latest kernels/drivers, but when there is no
crash system boots as expected. During 20 minute rebooting test on ar71xx v4.9.111 the system crashed 3 times.

Wonderful.

Quotting @kvalo

there's no plan to support QCA988X hw1.0.

I think, that this is a good enough reason to not waste time on this.

@ynezz ynezz closed this Sep 23, 2019
@psyborg55
Copy link
Contributor Author

As I've said, there are fw sources that could be used for custom built fw for hw1.0. The differences between ath10k and qca driver/fw are not that significant and hw1.0 could be easily supported. Please reopen this PR as it's a prerequisite for the further driver fixes.

@981213
Copy link
Member

981213 commented Sep 23, 2019

@psyborg55 You could have multiple commits in one pull request so please create a complete pull request with support for qca988xv1 and two PRs together if you could really somehow get qca988xv1 working. "Someone may get it working in the future" isn't quite a strong reason for adding currently useless packages/patches and we won't apply these two PRs alone without an actual working driver anyway.

@psyborg55
Copy link
Contributor Author

this was added before the support is complete with purpose: so users can test whether changes related to workaround and cold reset would cause any kind of regression on other systems e.g. qca99x0

@981213
Copy link
Member

981213 commented Sep 23, 2019

You should ask explicitly for a test if you want a test for it, then. A patch to mailing list with [RFT] prefix in title and details on what you want to test in patch body is the preferred way to ask for testing and obtain feedbacks.

In case I didn't make it clear enough:

  1. patches that doesn't make sense alone won't be applied alone.
  2. commits that serves for the same purpose go into one pull request/patchset, instead of having multiple PRs, one depending on the other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants