I haven't tried to switch to 4.9, but I've faced 2 problems switching to k4.9 drivers - nand and pci - both of them lead to a boot failure that I cannot check without serial.
Other than that doesn't seem to make any problems actually, because I've already backported a lot of stuff from upstream kernel.
No, I'm not wrong, as you can see in the attached screenshot the main R7800's page says:
I know this model doesn't support ADSL of course, my question is related to 5GHz.
Thanks!
That is the general device-independent help text table "Conventions per characteristic" at the bottom of each device page explaining what kind of values should be in each field...
Nothing to do with R7800
But in any case, wifi 5GHZ works.
I've rebased patches for 4.9 kernel, it compiles ok. I'll add some device tree changes and post a link to the repo. Hope it will boot up and function properly
Interesting, I started the same yesterday. But didn't quite get it compiled (and I hopped over the pcie patches). I had also trouble with some of the clock patches and have not finalized things.
I have not uploaded things to Github, but I can compare my patches to yours.
(I noticed that your 49-1 branch does not included config-4.9. I coped config-4.4 and did "make kernel_oldconfig" to get the new options in.)
I don't understand, last hunk in patch 172 in my tree doesn't apply for some reason, so I get an error for undefined call during compilation.... there're no errors during patch application
I took your patches from "49-1" and they apply nicely, but in the install phase there is error, likely the same as you get:
drivers/cpufreq/cpufreq-dt.c: In function 'cpufreq_init':
drivers/cpufreq/cpufreq-dt.c:342:3: error: label 'out_unregister_nb' used but not defined
goto out_unregister_nb;
^
scripts/Makefile.build:293: recipe for target 'drivers/cpufreq/cpufreq-dt.o' failed
make[6]: *** [drivers/cpufreq/cpufreq-dt.o] Error 1
Likely the upstream code has changed somewhat. There may not be the goto target any more.
The goto target is in the last hunk of 172 patch, that's the reason
Check the cpufreq-dt.c in the build_dir, you'll notice that
+out_unregister_nb:
- srcu_notifier_chain_unregister(opp_srcu_head, &priv->opp_nb);
isn't there, though it should have been applied with patch 172
No answer to that yet, but here is link to comparison of my patches from yesterday to your 49-1.
https://gist.github.com/hnyman/e854f3e3154e892d205a605c91d4c198
I have run "refresh" for the patches, so there is some difference to the line numbers and @@ function names. Plus some git lines "index" etc. have been removed. But refresh may also change line numbers wrongly when trying to find the correct spot with the current sources, so I don't guarantee that the differences highlighted below are significant.
I skipped yesterday over the pcie 112-115 and cpufreq 172-174.
I also left 711 out as the "aal" stuff was mostly done upstream. (But I noticed that you edited that patch.)
Some files that we may need to check more closely:
- 023 large difference in line numbers and patch is applied to different functions.
- 136 has differences. My version is from 4.4, you have probably a newer upstream version.
- 157 tries to apply the patch to a different place
- 164 large difference in line numbers
- 169-3 might be just context change shown strangely on diff
- 708 one large line number difference
I will look into that 172 thing.
There is likely some kind of whitespace error, or something like that.
There are 6 hunks in the patch, but only 5 are applied:
@@ -31,6 +31,9 @@ struct private_data {
@@ -42,9 +45,16 @@ static struct freq_attr *cpufreq_dt_attr[] = {
@@ -85,6 +95,39 @@ node_put:
@@ -151,6 +194,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
@@ -236,12 +280,28 @@ static int cpufreq_init(struct cpufreq_policy *policy)
@@ -280,6 +340,8 @@ static int cpufreq_init(struct cpufreq_policy *policy)
Applying /Openwrt/r7800/target/linux/ipq806x/patches-4.9/172-cpufreq-dt-Handle-OPP-voltage-adjust-events.patch using plaintext:
patching file drivers/cpufreq/cpufreq-dt.c
Hunk #1 succeeded at 32 (offset 1 line).
Hunk #2 succeeded at 46 (offset 1 line).
Hunk #3 succeeded at 96 (offset 1 line).
Hunk #4 succeeded at 196 (offset 2 lines).
Hunk #5 succeeded at 283 with fuzz 1 (offset 3 lines).
The last hunk is ignored.
I found it.
Line count error in hunk 5, which causes patch to think that the rest of the file is comments / garbage, as the next line to be parsed is " priv->cpu_dev = cpu_dev;" instead of a line starting with @@
@@ -236,12 +280,28 @@
should be
@@ -236,13 +280,29 @@
Applying /Openwrt/r7800/target/linux/ipq806x/patches-4.9/172-cpufreq-dt-Handle-OPP-voltage-adjust-events.patch using plaintext:
patching file drivers/cpufreq/cpufreq-dt.c
Hunk #1 succeeded at 32 (offset 1 line).
Hunk #2 succeeded at 46 (offset 1 line).
Hunk #3 succeeded at 96 (offset 1 line).
Hunk #4 succeeded at 196 (offset 2 lines).
Hunk #5 succeeded at 283 (offset 3 lines).
Hunk #6 succeeded at 344 (offset 4 lines).Thanks for investigation!
Go for 49-2, I've added nand DT and missing qcom-cpufreq patch. Compiling.
Next stop is smem mtd parser
I suppose patch 711 should be removed, because there's alternative version upstream
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c?id=afea03656add70a0e00f5b0039f87288c7af8b9f
I deleted it yesterday from my own version, as I found that upstream thing.
I've also modified pci compatibility property in Dts.
Do you know how to cope with smem mtd parser? Other than that it now compiles ok off my tree.
Not yet. I have not done much stuff with these hardware related patches, so I have no context for understanding the relations of the patches.
I'll test it tomorrow 
Meanwhile if you are interested here are some nand and pci patches we can use
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/log/drivers/mtd/nand?h=release/dandelion_preview
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/log/drivers/pci/host?h=release/dandelion_preview
These are based on upstream driver
There is a difference between 4.4 and 4.9. In 4.4 that struct was also defined / modified in 162 and of_node was defined there.
patches-4.9$ grep mtd_part_parser_data *
037-mtd-add-SMEM-parser-for-QCOM-platforms.patch:+ struct mtd_part_parser_data *data)
$ grep mtd_part_parser_data ../patches-4.4/*
../patches-4.4/037-mtd-add-SMEM-parser-for-QCOM-platforms.patch:+ struct mtd_part_parser_data *data)
../patches-4.4/162-mtd-nand-Qualcomm-NAND-controller-driver.patch:+ struct mtd_part_parser_data ppdata = { .of_node = np };
1823 +static int qcom_nandc_init(struct qcom_nandc_data *this)
1824 +{
1825 + struct mtd_info *mtd = &this->mtd;
1826 + struct nand_chip *chip = &this->chip;
1827 + struct device_node *np = this->dev->of_node;
1828 + struct mtd_part_parser_data ppdata = { .of_node = np };
1829 + int r;