Add support for Linksys EA6350 v3

If you want, I would like to work with you on this device.
Take a look at this PR

Hey again

I would rather use the original commits for the PR as this keeps the history intact - I can give you write access to the original repo so that the change can be attempted? I think @chunkeey's suggestion wrt the header file patch is the cleanest solution.

I've granted you access to repository along with this post.
I've also enabled email notifications for here again so if you need me I am available.


It would be cool to keep the history but:

  1. Your PR is closed and
  2. We need to rebase the code anyway

We can have a branch for keeping the history on your repo and rebase on my PR. Let's discuss this on GitHub.

When using @escalion's original PR there were two different issues reported:

  1. Wifi present but 5GHz is unstable
  2. Wifi is not present at all

As I understand it the new PR from @NoTengoBattery fixes issue 2, but does it also fix issue 1?

The original firmware has a lot of "board calibration" files, but I don't know how to know which one is it loading. Some hints?

Sometimes the OEM firmware copies the set it's using to /tmp/ (or a subdirectory of /tmp/).

I have no physical access to the serial console by the moment. If someone can grab those files and send them to, please do it. I already sent 2 board files, but those may be the wrong ones!

The board calibration that the stock firmware loads is dependent upon the value stored in eeprom. The board file that I extracted from the stock firmware is the EU version.

I'm not sure how the ath10k firmware actually handles the regions other than that it loads the board calibration data from the binary package - perhaps we should fire off the question to @chunkeey or @robimarko.

I will run tests on the 5Ghz with @NoTengoBattery's branch later today and go from there.

Only difference between most regions are the hardcoded power and frequency limits.
We usually use EU/ETSI or FCC since they cover most of the regulatory domains and then wireless regdb will take care of loading the limits per country


Can you help me with this? I can't figure it out and the device keeps bouncing between firmwares making my job harder hehe...

Before this thread dies:
I've doing some work on this and now it's working just fine for me. As I cannot actually meet the quality control of upstream, this device won't do it's way to upstream soon.
However, I will share the code we did with @escalion and some prebuilt images in my GitHub repo.
As I told you: this has been working good, smooth and stable for me from about 8 days or more, and 4 days in a long run without re-flashing or rebooting.
I'll upload some prebuilts till either my device dies or someone can make this device into upstream.
Take a look at this release. Keep track on the repo, I'll upload prebuilts constantly.

1 Like

Thanks @NoTengoBattery!
I started to wonder what happened to you PR since it was closed.
Just flashed my router using your build, have not run many tests yet but it seems to work fine!
Sad to hear that it will not make it's way upstream anytime soon, unfortunately I'm not much of a developer so not able to help out.

This device is such a pain!

I don't want to be noisy but...
I put a new release in GitHub. All of the releases I did before were using the FCC/EU (which are 99% the same, bitwise speaking).
I was investigating the original firmware and I found that they name the files like the board. So FCC/EU are using some Yxxxx board which is not this one.
The folder hw_1 (not a surprise that if you ls -Ral /lib/firmware you will find the hw.1 folder) does contain a 2 files with the name of the board. Those files were sent here but never used in the binaries till now. I ask you to give a try.
I'll schedule the release as this (as I don't want to be annoying to those who want to help me):
Jan22: using the files sent to infradead
Jan22+8: using the files in hw_1 called "board0" and "board1".
Jan22+15: using the files in hw_1 called like the Yxxxx board
Jan22+23: maybe some conclusions? I mean... I can try all the files but those are a good set to begin!

I appreciate every byte of feedback. BTW: read the message from the Jan22 release.

1 Like

First off I want to say thank you for your great work! Really appreciated. Then a question, should I run the sysupgrade.bin or the factory.bin? Ok, figured that out, sysupgrade.bin was the one I needed. Working like a charm!

Deleted. Nothing actually relevant.

you did meet the all the points. The issue was with this comment

I didn't know if the PR was now broken or not. So I waited for the release and positive response.
I put it into my staging tree to let it do a few rounds in the CI in the next days.


Thanks to you for reviewing the code and putting in your tree, it's nothing but good news!

The bug in the script and some minor but annoying bugs are fixed in the patches you used.

I'll keep my eye on this as I see that kernel 4.19 is on it's way! And I am sure it will be a challenge.

P.S. no more prebuilts from me.

Question: mac80211: ath: add extra 'regulatory domains' . It would be great if it could be posted on the linux-wireless ML. Please tell me whenever you want to do it or if I should have a go. Either way would be fine but there's no need to post it twice. :slight_smile: