The /etc/rc.local or KONG's nss.qos methods are pretty much the same behind the scene since nss.qos also uses tc to configure nss fq_codel.
I also use the latest ath10k firmware version 157.
Yes, it's much better with the new Wi-Fi commits. I've always had a little lag over Wi-Fi, it's all gone now.
Hello, even though I edited this patch in the current snapshot version, it doesn't work. Do you have a new patch for the 80P80? What do I need to do for it to work?
Why don’t you post what you edited and I’ll take a look?
I just had a quick look at master and while the area of code has been significantly rearranged, it still looks possible to apply the same idea.
--- a/lib/netifd/wireless/mac80211.sh
+++ b/lib/netifd/wireless/mac80211.sh
@@ -69,6 +69,7 @@ drv_mac80211_init_device_config() {
short_gi_40 \
max_amsdu \
dsss_cck_40
+ config_add_string channel2
}
drv_mac80211_init_iface_config() {
@@ -137,7 +138,7 @@ mac80211_hostapd_setup_base() {
[ -n "$acs_exclude_dfs" ] && [ "$acs_exclude_dfs" -gt 0 ] &&
append base_cfg "acs_exclude_dfs=1" "$N"
- json_get_vars noscan ht_coex min_tx_power:0
+ json_get_vars noscan ht_coex channel2 min_tx_power:0
json_get_values ht_capab_list ht_capab tx_burst
json_get_values channel_list channels
@@ -158,7 +159,7 @@ mac80211_hostapd_setup_base() {
ht_capab=
case "$htmode" in
VHT20|HT20|HE20) ;;
- HT40*|VHT40|VHT80|VHT160|HE40|HE80|HE160)
+ HT40*|VHT40|VHT80|VHT160|VHT80P80|HE40|HE80|HE160)
case "$hwmode" in
a)
case "$(( (($channel / 4) + $chan_ofs) % 2 ))" in
@@ -232,6 +233,7 @@ mac80211_hostapd_setup_base() {
vht_center_seg0=
idx="$channel"
+ idx2="$channel2"
case "$htmode" in
VHT20|HE20) enable_ac=1;;
VHT40|HE40)
@@ -274,6 +276,24 @@ mac80211_hostapd_setup_base() {
vht_oper_chwidth=2
vht_center_seg0=$idx
;;
+ VHT80P80)
+ case "$(( ($channel / 4) % 4 ))" in
+ 1) idx=$(($channel + 6));;
+ 2) idx=$(($channel + 2));;
+ 3) idx=$(($channel - 2));;
+ 0) idx=$(($channel - 6));;
+ esac
+ case "$(( ($channel2 / 4) % 4 ))" in
+ 1) idx2=$(($channel2 + 6));;
+ 2) idx2=$(($channel2 + 2));;
+ 3) idx2=$(($channel2 - 2));;
+ 0) idx2=$(($channel2 - 6));;
+ esac
+ enable_ac=1
+ append base_cfg "vht_oper_chwidth=3" "$N"
+ append base_cfg "vht_oper_centr_freq_seg0_idx=$idx" "$N"
+ append base_cfg "vht_oper_centr_freq_seg1_idx=$idx2" "$N"
+ ;;
esac
[ "$band" = "5g" ] && {
json_get_vars background_radar:0
The patch is like this, what should its name be? And where should I copy it when compiling? Sorry, I don't know much about these matters.
You needed to modify the patch more than that, like i said the code around it has changed and it needs to match the new way of doing things.
--- a/lib/netifd/wireless/mac80211.sh
+++ b/lib/netifd/wireless/mac80211.sh
@@ -69,6 +69,7 @@ drv_mac80211_init_device_config() {
short_gi_40 \
max_amsdu \
dsss_cck_40
+ config_add_string channel2
}
drv_mac80211_init_iface_config() {
@@ -137,7 +138,7 @@ mac80211_hostapd_setup_base() {
[ -n "$acs_exclude_dfs" ] && [ "$acs_exclude_dfs" -gt 0 ] &&
append base_cfg "acs_exclude_dfs=1" "$N"
- json_get_vars noscan ht_coex min_tx_power:0
+ json_get_vars noscan ht_coex min_tx_power:0 channel2
json_get_values ht_capab_list ht_capab tx_burst
json_get_values channel_list channels
@@ -158,7 +159,7 @@
ht_capab=
case "$htmode" in
VHT20|HT20|HE20) ;;
- HT40*|VHT40|VHT80|VHT160|HE40|HE80|HE160)
+ HT40*|VHT40|VHT80|VHT160|VHT80P80|HE40|HE80|HE160|HE80P80)
case "$hwmode" in
a)
case "$(( (($channel / 4) + $chan_ofs) % 2 ))" in
@@ -230,8 +231,10 @@
enable_ac=0
vht_oper_chwidth=0
vht_center_seg0=
+ vht_center_seg1=
idx="$channel"
+ idx2="$channel2"
case "$htmode" in
VHT20|HE20) enable_ac=1;;
VHT40|HE40)
@@ -253,6 +256,24 @@
vht_oper_chwidth=1
vht_center_seg0=$idx
;;
+ VHT80P80|HE80P80)
+ case "$(( (($channel / 4) + $chan_ofs) % 4 ))" in
+ 1) idx=$(($channel + 6));;
+ 2) idx=$(($channel + 2));;
+ 3) idx=$(($channel - 2));;
+ 0) idx=$(($channel - 6));;
+ esac
+ case "$(( (($channel2 / 4) + $chan_ofs) % 4 ))" in
+ 1) idx2=$(($channel2 + 6));;
+ 2) idx2=$(($channel2 + 2));;
+ 3) idx2=$(($channel2 - 2));;
+ 0) idx2=$(($channel2 - 6));;
+ esac
+ enable_ac=1
+ vht_oper_chwidth=3
+ vht_center_seg0=$idx
+ vht_center_seg1=$idx2
+ ;;
VHT160|HE160)
if [ "$band" = "6g" ]; then
case "$channel" in
@@ -321,6 +342,7 @@
append base_cfg "vht_oper_chwidth=$vht_oper_chwidth" "$N"
append base_cfg "vht_oper_centr_freq_seg0_idx=$vht_center_seg0" "$N"
+ append base_cfg "vht_oper_centr_freq_seg1_idx=$vht_center_seg1" "$N"
cap_rx_stbc=$((($vht_cap >> 8) & 7))
[ "$rx_stbc" -lt "$cap_rx_stbc" ] && cap_rx_stbc="$rx_stbc"
@@ -429,6 +451,7 @@
[ "$hwmode" = "a" ] && {
append base_cfg "he_oper_chwidth=$vht_oper_chwidth" "$N"
append base_cfg "he_oper_centr_freq_seg0_idx=$vht_center_seg0" "$N"
+ append base_cfg "he_oper_centr_freq_seg1_idx=$vht_center_seg1" "$N"
}
set_default he_bss_color 128
Try that, i've modified it to include HE80P80 as well. The patch is written to allow you to manually make the necessary changes to a running system. If you want to patch a build system apply it to package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh instead.
Note that i typed the patch out by hand rather than using a diff so it's likely got some whitespace/garbage that won't apply.
1 Like
It worked with this patch, thank you. But the speed was not what I expected. I have the same low speed issue I had with 160 Mhz. I was hoping maybe 80+80 Mhz would be faster. 80 MHz is much faster. I can reach 800 megabit upload and 600 megabit download speed with 80 Mhz. But what is the reason for lower speed with 160 and 80+80 Mhz?
Maybe number of streams. This device switches back to 1SS in 160/80+80 mode whereas 80 can use 3 maybe 4SS.
But your speeds don’t really line up with that.
I wonder if someone can test this pr
@hnyman can you help me with this?
I need to make sure this doesn't cause regression of some sort.
1 Like
Yes, I can do a test build.
(I have apparently done the last 5.15 test build in March... The 5.15 jump for ipq806x has really taken long 
)
1 Like
Is taking so long as we still need to understand if we can switch it to DSA or not. Wonder if now it's a good time as we have the LRU patch that should give improved perf.
Also 6.1 is incoming in some month....
1 Like
Haven't yet debugged, but I get this patch error
Applying /Openwrt/r7800/target/linux/ipq806x/patches-5.15/106-02-ARM-dts-qcom-ipq8064-add-ipq8062-variant.patch using plaintext:
patching file arch/arm/boot/dts/qcom-ipq8062-smb208.dtsi
The next patch would create the file arch/arm/boot/dts/qcom-ipq8062.dtsi,
which already exists! Applying it anyway.
patching file arch/arm/boot/dts/qcom-ipq8062.dtsi
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file arch/arm/boot/dts/qcom-ipq8062.dtsi.rej
1 Like
fixed! forgot to remove a file!
1 Like
A small fix that I can apply by hand? (instead of cleaning and reapplying the whole series?)
By a quick look compared to the previous one, I just remove target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8062.dtsi ????
@hnyman ok sorry i refreshed all and now they all compile/build correctly. (think you have to revert the changes as there are many dts changes)
1 Like
I still got this:
Applying /Openwrt/r7800/target/linux/ipq806x/patches-5.15/117-v6.0-02-clk-qcom-clk-krait-unlock-spin-after-mux-completion.patch using plaintext:
patching file drivers/clk/qcom/clk-krait.c
Hunk #1 FAILED at 32.
1 out of 1 hunk FAILED -- saving rejects to file drivers/clk/qcom/clk-krait.c.rej
Patch failed! Please fix /Openwrt/r7800/target/linux/ipq806x/patches-5.15/117-v6.0-02-clk-qcom-clk-krait-unlock-spin-after-mux-completion.patch!
make[3]: *** [Makefile:37: /Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.15.67/.prepared_3ebe8393afaba762f9f4ce98daf61d9d] Error 1
$ cat build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.15.67/drivers/clk/qcom/clk-krait.c.rej
--- drivers/clk/qcom/clk-krait.c
+++ drivers/clk/qcom/clk-krait.c
@@ -32,11 +32,16 @@ static void __krait_mux_set_sel(struct k
regval |= (sel & mux->mask) << (mux->shift + LPL_SHIFT);
}
krait_set_l2_indirect_reg(mux->offset, regval);
- spin_unlock_irqrestore(&krait_clock_reg_lock, flags);
/* Wait for switch to complete. */
mb();
udelay(1);
+
+ /*
+ * Unlock now to make sure the mux register is not
+ * modified while switching to the new parent.
+ */
+ spin_unlock_irqrestore(&krait_clock_reg_lock, flags);
}
static int krait_mux_set_parent(struct clk_hw *hw, u8 index)
guess that patch got backported... i have an old kernel on my repo
You patch is apparently upstreamed in the newest linux.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/clk/qcom/clk-krait.c?h=v5.15.67&id=9ed2640eb88374a234949198651775c3f2d26917
So it looks like
and also the errata patch