[PR] Ipq806x: kernel 5.4 bump code propose

I already have that version of the patchset in my repo. No luck, same problem.

Ok some news about this... FINALLY THE WIRED CONNECTION WORKS... But here the fun part...

It's like 7 days that i'm messing with the gmac driver as that could be the only cause of the problem. Since devs confirmed me that there were no problem in the kernel patchset.

As a last hope this night i decided to backport (or post(?)port) the entire stmmac driver from 4.19 to 5.4.
Same problem. Driver can send but can't receive nothing.

With a crazy and anger move i decided to remove ANY network patch from the generic dir and....
Nothing... Same problem but WAIT... with a ifconfig log i notice that this time the driver was actually receiving something (AND THIS IS WITH THE UPSTREAM DRIVER NO BACKPORT)

A quick edit to the network file... change eth1.1 to eth1 to remove any vlan inizialization and surprise surprise... Everything works as excepted.

So there is definitely a problem in the generic patchset. And i think is related to the bridge patch since in all this time i notice that the only interface that was receiving and sending data (the same data actually) was the loopback, other could not receive anything.)

Finally i know where to search... A big journey ahahahh

Think this should be reported to devs. Will find the culprit...

@robimarko @anon98444528

2 Likes

fwiw, i can get a 5.4 build for the r7500v2... just haven't had a chance to test it.

Fiddling with ath10k-ct driver which for some reason does not want to build even with cherry picking the "5.2" patch. buts that's an issue for later I think

mh on my side ath10k-ct with path 5.2 compiled correctly

as module or "built in?" I build it in and I suspect my troubles are related to that choice. Also I have to pick the new kernel configs by "hand" - I can fix that but I'd like to know what your kernel .config looks like when you get a minute - nothing urgent tho.

Nice catch @Ansuel, does 5.2 version of ath10k-ct work for you?
It used to cause crash for me before
For ath10k-ct Makefile needs to be edited and SUBDIRS replaced with M
Similar to this
https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=blobdiff;f=package/kernel/kmod-sched-cake/Makefile;h=f7b079b58743de45eea6ec06460e62c2ae3c37f1;hp=7778d48041e79f5eb62c27deeb6655c9dbf10782;hb=85703f8e262d16ba4f91ad8801815067eb0ce383;hpb=4f52e3ad4c60fa8d18c05dcaa49ddc635b36fd44

1 Like

Will check wifi problem later guys. Now priority is get wired connection work and find the patch that cause all this mess...

Anyway on my full build i had no problem with building ath10k-ct
I builded it as module. In the makefile i had to modify it to use 5.2 version and use M instead of SUBDIRS. That's all...
About runtime test, it crashed as soon as it was loaded if i remember correctly.

ok i think there are some problem in

hack
700
702
721

And probably in the related swconfig driver ar8216
With this driver can't receive any data
Without this and by using the direct eth1 interface the wired connection works good. Think this is related to phylink conversion and ar driver needs to use the new api... Will check it...

Most likely all of those drivers need to be migrated to linkmode and ksettings API, but they would not compile at all if old API is used as it was removed in 5.3 kernel.
I see that they are already migrated
I had to migrate ESSEDMA for IPQ40xx that way.

then something went wrong in the migration... or something changed

Easily possible, can you check with ethtool if advertised/supported speeds and features are correct?
But why is it causing issues even for targets that dont use any of those phy/switch drivers

1 Like

same symptoms present with 4.19 and DSA patch... likely switch level conflict ( stmac/dsa/swconfig or thereabouts )

wait what? now wired connection is broken also on 4.19 ?

I'm not talking about the dst underflow

I know, but like I said.
You can easily see if linkmode conversion is correct via ethtool

what should i check exactly ?

Check what ethtool reports on supported and advertised fields for a interface that is up.
If they converted it correctly you should see it populated properly

1 Like

can ethtool be used on eth1.1 for example ?

Yes, but it may not be identified as physical interface so info may be missing.
But you should really use it on physical interfaces only

on physical they were very similar... will check them...