Re: [RFC] 21.02.1 backports
On 10/21/21 1:01 AM, Paul Spooren wrote: Hi all, Hauke an me plan to tag 21.02.1 this Friday. Motivation is the recent breakage (and fix) of HTTPS secured by Let's Encrypt certificates. More information is available in the commit message[0] of the fix. Please post your backport requests here so we can determine what's possible to include in the next point release. Sunshine, Paul Hi, Wolfssl has some known security problems, see here: https://www.wolfssl.com/docs/security-vulnerabilities/ I think they are not really relevant for us. OpenWrt master uses version 3.8.1 and OpenWrt 21.02 uses version 3.7.0, should we upgrade the version used in OpenWrt 21.02 too? Here is already a patch: https://patchwork.ozlabs.org/project/openwrt/list/?series=262295 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
On Thu, 21 Oct 2021 at 22:54, Hauke Mehrtens wrote: > > On 10/21/21 6:52 PM, Robert Marko wrote: > > On Thu, 21 Oct 2021 at 18:30, Janusz Dziedzic > > wrote: > >> > >> czw., 21 paź 2021 o 17:54 Robert Marko napisał(a): > >>> > >>> For PCI/USB bus level support there are per target feature flags that are > >>> set and then you can check if those are set so that you cant even select > >>> usb wlan driver if the target doesnt even have usb support enabled. > >>> > >> OK I see. Seems I can select all required kernel parts except: > >> QCOM_QMI_HELPERS - which is slected when ath11k/mac80211 - and we get > >> this from backports :) > >> > >> ATH11K [=n] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && > >> MAC80211 [=n] && HAS_DMA [=y] && CRYPTO_MICHAEL_MIC [=y] > >> > >> Seems kernel patch required to choose it manaully. > > > > Yes, I had to add text to the tristate as otherwise its hidden. > > > > Regards, > > Robert > > You can create kmod packages for the kernel modules build by MHI_BUS, > QRTR, QCOM_QMI_HELPERS and whatever you need. Then the ath11k package in > OpenWrt selects them and it should build on all targets. Yeah, that is my plan to package it in a target agnostic way. Just lacking the time to do it. > > We already added a title text to other configuration symbols, see > target/linux/generic/hack-5.10/251-kconfig.patch > > The hard part is known which patches to backport in addition. ;-) I have identified a couple that are must have, but I am sure more will pop up. Regards, Robert > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Marvell EBU 32-bit performance benchmarks (VFPv3-D16 vs NEON builds, Turris Omnia).
On 2021-10-21 14:31, Rosen Penev wrote: On Thu, Oct 21, 2021 at 12:19 PM Kabuli Chana wrote: For me the argument was not about whether there should 2, but whether the change to vfpv3-d16 was the right choice as the 1. openssl is of course preordained to run NEON SIMD code so no change would be expected, but a benefit is seen on WG. I would suggest that is the result of 16 vs. 32 FP registers being available, and nothing to do with NEON; i.e. vfpv3-d16 vs. vfpv3. The result being smaller and faster due to more concise FP code generation due to less FP register rejigging. I call BS. WireGuard does not use floating point.Just fixed point arithmetic, like most crypto. WireGuard being faster probably has to do with its usage of NEON assembly. Careful now, the brit might take you to task for language violation. But yes, after I replied it dawned on me that it would be odd that some FP code found its way into a kernel module. I have never spent any time looking at the WG code, but it seems if it uses NEON it would make sense that it detected things, rather than having to have things enabled externally, but I do not know how rsalvaterra set things up for the build. But, I think that NEON as the target default is questionable, although others exist. On 2021-10-21 09:38, Rui Salvaterra wrote: Hi, guys, So, last meeting I proposed splitting the 32-bit mvebu target in vfpv3-d16 and neon subtargets. It seems this subject comes up every couple of years, or so. This time I hope to show solid evidence on why it would be an exercise in futility, closing the matter once and for all. In order to do so, I tested the performance of openssl speed (10 seconds time limit), cryptsetup benchmark and iperf3 over WireGuard. Here are the results for each build: VFPv3-D16: https://paste.debian.net/1216262/ NEON: https://paste.debian.net/1216261/ These are master builds from my stmvebu branch, running Linux 5.10.75. The configuration is custom, but each build differs only in the CPU_SUBTYPE (vfpv3-d16 vs neon). Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
On 10/21/21 6:52 PM, Robert Marko wrote: On Thu, 21 Oct 2021 at 18:30, Janusz Dziedzic wrote: czw., 21 paź 2021 o 17:54 Robert Marko napisał(a): For PCI/USB bus level support there are per target feature flags that are set and then you can check if those are set so that you cant even select usb wlan driver if the target doesnt even have usb support enabled. OK I see. Seems I can select all required kernel parts except: QCOM_QMI_HELPERS - which is slected when ath11k/mac80211 - and we get this from backports :) ATH11K [=n] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && MAC80211 [=n] && HAS_DMA [=y] && CRYPTO_MICHAEL_MIC [=y] Seems kernel patch required to choose it manaully. Yes, I had to add text to the tristate as otherwise its hidden. Regards, Robert You can create kmod packages for the kernel modules build by MHI_BUS, QRTR, QCOM_QMI_HELPERS and whatever you need. Then the ath11k package in OpenWrt selects them and it should build on all targets. We already added a title text to other configuration symbols, see target/linux/generic/hack-5.10/251-kconfig.patch The hard part is known which patches to backport in addition. ;-) Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Marvell EBU 32-bit performance benchmarks (VFPv3-D16 vs NEON builds, Turris Omnia).
On Thu, Oct 21, 2021 at 12:19 PM Kabuli Chana wrote: > > For me the argument was not about whether there should 2, but whether > the change to vfpv3-d16 was the right choice as the 1. openssl is of > course preordained to run NEON SIMD code so no change would be expected, > but a benefit is seen on WG. I would suggest that is the result of 16 > vs. 32 FP registers being available, and nothing to do with NEON; i.e. > vfpv3-d16 vs. vfpv3. The result being smaller and faster due to more > concise FP code generation due to less FP register rejigging. I call BS. WireGuard does not use floating point.Just fixed point arithmetic, like most crypto. WireGuard being faster probably has to do with its usage of NEON assembly. > > On 2021-10-21 09:38, Rui Salvaterra wrote: > > Hi, guys, > > > > So, last meeting I proposed splitting the 32-bit mvebu target in > > vfpv3-d16 and neon subtargets. It seems this subject comes up every > > couple of years, or so. This time I hope to show solid evidence on why > > it would be an exercise in futility, closing the matter once and for > > all. In order to do so, I tested the performance of openssl speed (10 > > seconds time limit), cryptsetup benchmark and iperf3 over WireGuard. > > Here are the results for each build: > > > > VFPv3-D16: > > https://paste.debian.net/1216262/ > > > > NEON: > > https://paste.debian.net/1216261/ > > > > These are master builds from my stmvebu branch, running Linux 5.10.75. > > The configuration is custom, but each build differs only in the > > CPU_SUBTYPE (vfpv3-d16 vs neon). > > > > Cheers, > > Rui > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] tools/isl: update the download URL
On 10/21/21 9:11 AM, Rui Salvaterra wrote: isl.gforge.inria.fr has been dead since early this month [1]. Switch to libisl.sourceforge.io for the time being. [1] https://groups.google.com/g/isl-development/c/JGaMo2VUu_8 Signed-off-by: Rui Salvaterra --- Acked-by: Paul Spooren Note: this needs to be backported to every supported OpenWrt version. tools/isl/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/isl/Makefile b/tools/isl/Makefile index be372fe2a8..32c3cda9a2 100644 --- a/tools/isl/Makefile +++ b/tools/isl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=isl PKG_VERSION:=0.24 -PKG_SOURCE_URL:=http://isl.gforge.inria.fr +PKG_SOURCE_URL:=https://libisl.sourceforge.io/ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_HASH:=043105cc544f416b48736fff8caf077fb0663a717d06b1113f16e391ac99ebad ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Marvell EBU 32-bit performance benchmarks (VFPv3-D16 vs NEON builds, Turris Omnia).
For me the argument was not about whether there should 2, but whether the change to vfpv3-d16 was the right choice as the 1. openssl is of course preordained to run NEON SIMD code so no change would be expected, but a benefit is seen on WG. I would suggest that is the result of 16 vs. 32 FP registers being available, and nothing to do with NEON; i.e. vfpv3-d16 vs. vfpv3. The result being smaller and faster due to more concise FP code generation due to less FP register rejigging. On 2021-10-21 09:38, Rui Salvaterra wrote: Hi, guys, So, last meeting I proposed splitting the 32-bit mvebu target in vfpv3-d16 and neon subtargets. It seems this subject comes up every couple of years, or so. This time I hope to show solid evidence on why it would be an exercise in futility, closing the matter once and for all. In order to do so, I tested the performance of openssl speed (10 seconds time limit), cryptsetup benchmark and iperf3 over WireGuard. Here are the results for each build: VFPv3-D16: https://paste.debian.net/1216262/ NEON: https://paste.debian.net/1216261/ These are master builds from my stmvebu branch, running Linux 5.10.75. The configuration is custom, but each build differs only in the CPU_SUBTYPE (vfpv3-d16 vs neon). Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools/isl: update the download URL
isl.gforge.inria.fr has been dead since early this month [1]. Switch to libisl.sourceforge.io for the time being. [1] https://groups.google.com/g/isl-development/c/JGaMo2VUu_8 Signed-off-by: Rui Salvaterra --- Note: this needs to be backported to every supported OpenWrt version. tools/isl/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/isl/Makefile b/tools/isl/Makefile index be372fe2a8..32c3cda9a2 100644 --- a/tools/isl/Makefile +++ b/tools/isl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=isl PKG_VERSION:=0.24 -PKG_SOURCE_URL:=http://isl.gforge.inria.fr +PKG_SOURCE_URL:=https://libisl.sourceforge.io/ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_HASH:=043105cc544f416b48736fff8caf077fb0663a717d06b1113f16e391ac99ebad -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
LUCI behaviour
If I use js e.g. :
o = ss.option(form.TextValue, 'blah', _('blah'), _('blah.'));
o.optional = true;
o.monospace = true;
And add either:
o.width = "500px";
or:
o.width = "60ch";
I do not get the desired effect. Is this normal?
Here ( https://openwrt.github.io/luci/jsapi/LuCI.form.TextValue.html )
it says about width:
==
When the property is set to a string value, it is applied as-is to the
CSS width property.
This property has no effect on options that are not children of grid or
table section elements.
==
How does one know that it's a child of said element? ( Is it talking
about HTML elements? Or LUCI? Also, which 'options'? )
If it is, is this a bug? The width always seems to be "100%".
HTML produced never has px or ch width. As soon as I set 'o.cols' then
the element aligns with other form elements. e.g. ~210px width.
So damned if I do, damned if I don't. How can one constrain width?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
On Thu, 21 Oct 2021 at 18:30, Janusz Dziedzic wrote: > > czw., 21 paź 2021 o 17:54 Robert Marko napisał(a): > > > > For PCI/USB bus level support there are per target feature flags that are > > set and then you can check if those are set so that you cant even select > > usb wlan driver if the target doesnt even have usb support enabled. > > > OK I see. Seems I can select all required kernel parts except: > QCOM_QMI_HELPERS - which is slected when ath11k/mac80211 - and we get > this from backports :) > > ATH11K [=n] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && > MAC80211 [=n] && HAS_DMA [=y] && CRYPTO_MICHAEL_MIC [=y] > > Seems kernel patch required to choose it manaully. Yes, I had to add text to the tristate as otherwise its hidden. Regards, Robert > > Thanks for help. > > BR > Janusz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
czw., 21 paź 2021 o 17:54 Robert Marko napisał(a): > > For PCI/USB bus level support there are per target feature flags that are set > and then you can check if those are set so that you cant even select usb wlan > driver if the target doesnt even have usb support enabled. > OK I see. Seems I can select all required kernel parts except: QCOM_QMI_HELPERS - which is slected when ath11k/mac80211 - and we get this from backports :) ATH11K [=n] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && MAC80211 [=n] && HAS_DMA [=y] && CRYPTO_MICHAEL_MIC [=y] Seems kernel patch required to choose it manaully. Thanks for help. BR Janusz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Marvell EBU 32-bit performance benchmarks (VFPv3-D16 vs NEON builds, Turris Omnia).
Hi, guys, So, last meeting I proposed splitting the 32-bit mvebu target in vfpv3-d16 and neon subtargets. It seems this subject comes up every couple of years, or so. This time I hope to show solid evidence on why it would be an exercise in futility, closing the matter once and for all. In order to do so, I tested the performance of openssl speed (10 seconds time limit), cryptsetup benchmark and iperf3 over WireGuard. Here are the results for each build: VFPv3-D16: https://paste.debian.net/1216262/ NEON: https://paste.debian.net/1216261/ These are master builds from my stmvebu branch, running Linux 5.10.75. The configuration is custom, but each build differs only in the CPU_SUBTYPE (vfpv3-d16 vs neon). Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
czw., 21 paź 2021 o 16:54 Robert Marko napisał(a): > > On Thu, 21 Oct 2021 at 16:53, Janusz Dziedzic > wrote: > > > > czw., 21 paź 2021 o 16:43 Robert Marko napisał(a): > > > > > > On Thu, 21 Oct 2021 at 16:40, Janusz Dziedzic > > > wrote: > > > > > > > > Hello, > > > > > > > > Hit some issue with my ath11k card, so maybe someone already fix > > > > it/know what I missed? > > > > > > > > My card (pcie): > > > > root@OpenWrt:~# lspci > > > > :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 > > > > :01:00.0 Unassigned class [ff00]: Qualcomm QCA6390 Wireless > > > > Network Adapter [AX500-DBS (2x2)] > > > > > > > > I have this card in my banana-pi-r64 board in pcie slot. > > > > > > > > Checked with current/latest backports (v5.10/v5.15) > > > > On top added patch (added some changes, attached) based on: > > > > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=0b115adb1b0cc9c19c7c780f3a9e6437fa0398a5 > > > > Simple choose kmod-ath11k from menuconfig. > > > > > > > > Check it little bit (Makefile) and after: > > > > $(SH_FUNC) var2file "$(call shvar,mac80211_config)" > > > > $(PKG_BUILD_DIR)/.config > > > > Have correct backports/.config (ATH11K included) > > > > And next we call: > > > > $(MAKE) $(MAKE_OPTS) allnoconfig > > > > After this step we remove ATH11K option(s) from backports/.config > > > > > > > > Any idea, did I miss something? > > > > > > Your kernel must also have MHI and QRTR enabled, but it wont work with > > > the 5.10 QRTR > > > directly, you need to backport support for it starting the MHI interface. > > > > > > You can find those patches and some other clues in my WIP branch: > > > https://github.com/robimarko/openwrt/tree/IPQ807x-5.10-backports > > > > > OK, so this is removed from .config because of this? > > depends on MHI_BUS > > depends on QRTR > > depends on QRTR_MHI > > Yes as backports cannot just select stuff like the in-tree driver can. > Sounds good, But we also have smth like this in backports: depends on PCI/USB I suspect we don't have pci/usb drivers in backports also (using 'current' kernel for that) - and works somehow - do we hack it? BR Janusz -- Janusz Dziedzic ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd: ubus inteface crashes hostapd?
Hi Nick, On 10/21/21 11:31, Nick wrote: Is someone massively utilizing the ubus interface from hostapd? I'm doing this with dawn and I saw that blocktrron already fixed some infinity loop. However, currently DAWN is crashing the hostapd. I make extensive use of the get_clients, all subscriptions, disassoc_immidient calls. This is most likely caused by my transition-report patch some days ago. Please check out the latest master. It should be resolved. Best David Of course I don't want to exclude that the error is on my side. I just wanted to ask if someone is doing something similar. It is just weird for me that dawn can crash hostapd since it is only connecting via ubus and uses iwinfo library to get signal strength and channel utilization from wifi interfaces. See: https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-948192240 Bests Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
On Thu, 21 Oct 2021 at 16:53, Janusz Dziedzic wrote: > > czw., 21 paź 2021 o 16:43 Robert Marko napisał(a): > > > > On Thu, 21 Oct 2021 at 16:40, Janusz Dziedzic > > wrote: > > > > > > Hello, > > > > > > Hit some issue with my ath11k card, so maybe someone already fix > > > it/know what I missed? > > > > > > My card (pcie): > > > root@OpenWrt:~# lspci > > > :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 > > > :01:00.0 Unassigned class [ff00]: Qualcomm QCA6390 Wireless > > > Network Adapter [AX500-DBS (2x2)] > > > > > > I have this card in my banana-pi-r64 board in pcie slot. > > > > > > Checked with current/latest backports (v5.10/v5.15) > > > On top added patch (added some changes, attached) based on: > > > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=0b115adb1b0cc9c19c7c780f3a9e6437fa0398a5 > > > Simple choose kmod-ath11k from menuconfig. > > > > > > Check it little bit (Makefile) and after: > > > $(SH_FUNC) var2file "$(call shvar,mac80211_config)" > > > $(PKG_BUILD_DIR)/.config > > > Have correct backports/.config (ATH11K included) > > > And next we call: > > > $(MAKE) $(MAKE_OPTS) allnoconfig > > > After this step we remove ATH11K option(s) from backports/.config > > > > > > Any idea, did I miss something? > > > > Your kernel must also have MHI and QRTR enabled, but it wont work with > > the 5.10 QRTR > > directly, you need to backport support for it starting the MHI interface. > > > > You can find those patches and some other clues in my WIP branch: > > https://github.com/robimarko/openwrt/tree/IPQ807x-5.10-backports > > > OK, so this is removed from .config because of this? > depends on MHI_BUS > depends on QRTR > depends on QRTR_MHI Yes as backports cannot just select stuff like the in-tree driver can. Robert > > BR > Janusz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
czw., 21 paź 2021 o 16:43 Robert Marko napisał(a): > > On Thu, 21 Oct 2021 at 16:40, Janusz Dziedzic > wrote: > > > > Hello, > > > > Hit some issue with my ath11k card, so maybe someone already fix > > it/know what I missed? > > > > My card (pcie): > > root@OpenWrt:~# lspci > > :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 > > :01:00.0 Unassigned class [ff00]: Qualcomm QCA6390 Wireless > > Network Adapter [AX500-DBS (2x2)] > > > > I have this card in my banana-pi-r64 board in pcie slot. > > > > Checked with current/latest backports (v5.10/v5.15) > > On top added patch (added some changes, attached) based on: > > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=0b115adb1b0cc9c19c7c780f3a9e6437fa0398a5 > > Simple choose kmod-ath11k from menuconfig. > > > > Check it little bit (Makefile) and after: > > $(SH_FUNC) var2file "$(call shvar,mac80211_config)" $(PKG_BUILD_DIR)/.config > > Have correct backports/.config (ATH11K included) > > And next we call: > > $(MAKE) $(MAKE_OPTS) allnoconfig > > After this step we remove ATH11K option(s) from backports/.config > > > > Any idea, did I miss something? > > Your kernel must also have MHI and QRTR enabled, but it wont work with > the 5.10 QRTR > directly, you need to backport support for it starting the MHI interface. > > You can find those patches and some other clues in my WIP branch: > https://github.com/robimarko/openwrt/tree/IPQ807x-5.10-backports > OK, so this is removed from .config because of this? depends on MHI_BUS depends on QRTR depends on QRTR_MHI BR Janusz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath11k - pci - backports/.config issue
On Thu, 21 Oct 2021 at 16:40, Janusz Dziedzic wrote: > > Hello, > > Hit some issue with my ath11k card, so maybe someone already fix > it/know what I missed? > > My card (pcie): > root@OpenWrt:~# lspci > :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 > :01:00.0 Unassigned class [ff00]: Qualcomm QCA6390 Wireless > Network Adapter [AX500-DBS (2x2)] > > I have this card in my banana-pi-r64 board in pcie slot. > > Checked with current/latest backports (v5.10/v5.15) > On top added patch (added some changes, attached) based on: > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=0b115adb1b0cc9c19c7c780f3a9e6437fa0398a5 > Simple choose kmod-ath11k from menuconfig. > > Check it little bit (Makefile) and after: > $(SH_FUNC) var2file "$(call shvar,mac80211_config)" $(PKG_BUILD_DIR)/.config > Have correct backports/.config (ATH11K included) > And next we call: > $(MAKE) $(MAKE_OPTS) allnoconfig > After this step we remove ATH11K option(s) from backports/.config > > Any idea, did I miss something? Your kernel must also have MHI and QRTR enabled, but it wont work with the 5.10 QRTR directly, you need to backport support for it starting the MHI interface. You can find those patches and some other clues in my WIP branch: https://github.com/robimarko/openwrt/tree/IPQ807x-5.10-backports Regards, Robert > > BR > Janusz > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ath11k - pci - backports/.config issue
Hello, Hit some issue with my ath11k card, so maybe someone already fix it/know what I missed? My card (pcie): root@OpenWrt:~# lspci :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258 :01:00.0 Unassigned class [ff00]: Qualcomm QCA6390 Wireless Network Adapter [AX500-DBS (2x2)] I have this card in my banana-pi-r64 board in pcie slot. Checked with current/latest backports (v5.10/v5.15) On top added patch (added some changes, attached) based on: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=0b115adb1b0cc9c19c7c780f3a9e6437fa0398a5 Simple choose kmod-ath11k from menuconfig. Check it little bit (Makefile) and after: $(SH_FUNC) var2file "$(call shvar,mac80211_config)" $(PKG_BUILD_DIR)/.config Have correct backports/.config (ATH11K included) And next we call: $(MAKE) $(MAKE_OPTS) allnoconfig After this step we remove ATH11K option(s) from backports/.config Any idea, did I miss something? BR Janusz diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk index ba03ae11a6..e0b8f4a4fb 100644 --- a/package/kernel/mac80211/ath.mk +++ b/package/kernel/mac80211/ath.mk @@ -1,5 +1,5 @@ PKG_DRIVERS += \ - ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc ath10k \ + ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc ath10k ath11k \ carl9170 owl-loader ar5523 wil6210 PKG_CONFIG_DEPENDS += \ @@ -19,6 +19,7 @@ ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS ATH9K_DEBUGFS \ ATH9K_HTC_DEBUGFS \ ATH10K_DEBUGFS \ + ATH11K_DEBUGFS \ CARL9170_DEBUGFS \ ATH5K_DEBUG \ ATH6KL_DEBUG \ @@ -27,7 +28,9 @@ endif ifdef CONFIG_PACKAGE_MAC80211_TRACING config-y += \ + ATH11K_TRACING \ ATH10K_TRACING \ + ATH11K_TRACING \ ATH6KL_TRACING \ ATH_TRACEPOINTS \ ATH5K_TRACER \ @@ -35,7 +38,7 @@ ifdef CONFIG_PACKAGE_MAC80211_TRACING endif config-$(call config_package,ath) += ATH_CARDS ATH_COMMON -config-$(CONFIG_PACKAGE_ATH_DEBUG) += ATH_DEBUG ATH10K_DEBUG ATH9K_STATION_STATISTICS +config-$(CONFIG_PACKAGE_ATH_DEBUG) += ATH_DEBUG ATH10K_DEBUG ATH11K_DEBUG ATH9K_STATION_STATISTICS config-$(CONFIG_PACKAGE_ATH_DFS) += ATH9K_DFS_CERTIFIED ATH10K_DFS_CERTIFIED config-$(CONFIG_PACKAGE_ATH_SPECTRAL) += ATH9K_COMMON_SPECTRAL ATH10K_SPECTRAL config-$(CONFIG_PACKAGE_ATH_DYNACK) += ATH9K_DYNACK @@ -55,6 +58,7 @@ config-$(CONFIG_ATH10K_THERMAL) += ATH10K_THERMAL config-$(call config_package,ath9k-htc) += ATH9K_HTC config-$(call config_package,ath10k) += ATH10K ATH10K_PCI +config-$(call config_package,ath11k) += ATH11K ATH11K_PCI config-$(call config_package,ath5k) += ATH5K ifdef CONFIG_TARGET_ath25 @@ -281,6 +285,22 @@ define KernelPackage/ath10k/config endef +define KernelPackage/ath11k + $(call KernelPackage/mac80211/Default) + TITLE:=Qualcomm 802.11ax wireless chipset support + URL:=https://wireless.wiki.kernel.org/en/users/drivers/ath11k + DEPENDS+= @PCI_SUPPORT +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT + FILES:= \ + $(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath11k/ath11k.ko \ + $(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath11k/ath11k_pci.ko + AUTOLOAD:=$(call AutoProbe,ath11k) +endef + +define KernelPackage/ath11k/description +This module adds support for Qualcomm Technologies 802.11ax family of +chipsets. +endef + define KernelPackage/carl9170 $(call KernelPackage/mac80211/Default) TITLE:=Driver for Atheros AR9170 USB sticks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd: ubus inteface crashes hostapd?
On 2021-10-21 11:31, Nick wrote: Is someone massively utilizing the ubus interface from hostapd? I'm doing this with dawn and I saw that blocktrron already fixed some infinity loop. However, currently DAWN is crashing the hostapd. I make extensive use of the get_clients, all subscriptions, disassoc_immidient calls. Of course I don't want to exclude that the error is on my side. I just wanted to ask if someone is doing something similar. It is just weird for me that dawn can crash hostapd since it is only connecting via ubus and uses iwinfo library to get signal strength and channel utilization from wifi interfaces. See: https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-948192240 Please make some coredumps and send me gdb backtrace info, so that I can look into this. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/6] mac80211: Update to version 5.15-rc6
wt., 19 paź 2021 o 22:50 Hauke Mehrtens napisał(a):
>
> This updates the wireless drivers to the code from kernel 5.15.
> This is updating the wifi drivers to test versions of the wireless
> backports. If there are no serious problems found I will also release
> official versions and update the versions used in OpenWrt.
>
> I need some more testing, please try this code in your environments and
> report back if you see any regressions. I intentionally added the
> version steps, it should be easy to see which version caused a problem.
>
> This depends on the patch "iw: sync nl80211 with kernel backports"
>
> These patches are also in my feature branch, see here:
> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mac80211-5.15
>
> The wireless backports tar.xz files were created from this code:
> https://github.com/hauke/backports/tree/devel-5.15-2
>
So far checked tplink archer c7v5 (ath9k/ath10k) and banana-pi-r64
with mt7622-wmac/mt7915e-pci
Run sanity test cases (wpa2/3, multi_ap connectivity and datapath
check) and looks good - no issues compare to old backports.
root@a1:~# ubus call system board
{
"kernel": "5.4.155",
"hostname": "a1",
"system": "Qualcomm Atheros QCA956X ver 1 rev 0",
"model": "TP-Link Archer C7 v5",
"board_name": "tplink,archer-c7-v5",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r17801-caf34d0f5d",
"target": "ath79/generic",
"description": "OpenWrt SNAPSHOT r17801-caf34d0f5d"
}
}
root@a1:~# dmesg|grep back
[0.00] Readback ErrCtl register=
[7.288147] urandom_read: 4 callbacks suppressed
[ 13.575090] Loading modules backported from Linux version
v5.15-rc6-0-g519d81956ee2
[ 13.583046] Backport generated by backports.git v5.10.68-1-63-gd44432d6
root@a1:~#
root@OpenWrt:~# ubus call system board
{
"kernel": "5.10.75",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 4",
"model": "Bananapi BPI-R64",
"board_name": "bananapi,bpi-r64",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r17801-caf34d0f5d",
"target": "mediatek/mt7622",
"description": "OpenWrt SNAPSHOT r17801-caf34d0f5d"
}
}
root@OpenWrt:~# dmesg |grep backp
[9.683509] Loading modules backported from Linux version
v5.15-rc6-0-g519d81956ee2
[9.691205] Backport generated by backports.git v5.10.68-1-63-gd44432d6
root@OpenWrt:~#
>
> Hauke Mehrtens (6):
> mac80211: Update to version 5.10.70-test12
> mac80211: Update to version 5.11.22-test12
> mac80211: Update to version 5.12.19-test12
> mac80211: Update to version 5.13.19-test12
> mac80211: Update to version 5.14.13-test12
> mac80211: Update to version 5.15-rc6-test13
>
> package/kernel/mac80211/Makefile | 21 +-
> .../patches/ath/402-ath_regd_optional.patch |8 +-
> .../patches/ath/404-regd_no_assoc_hints.patch |4 +-
> .../ath/406-ath_relax_default_regd.patch |2 +-
> .../ath10k/080-ath10k_thermal_config.patch|2 +-
> ...21-ath10k_init_devices_synchronously.patch |2 +-
> ...h10k-increase-rx-buffer-size-to-2048.patch | 37 -
> .../930-ath10k_add_tpt_led_trigger.patch |4 +-
> ...rolling-support-for-various-chipsets.patch | 20 +-
> ...75-ath10k-use-tpt-trigger-by-default.patch |8 +-
> ...980-ath10k-fix-max-antenna-gain-unit.patch |6 +-
> ...-power-reduction-for-US-regulatory-d.patch |8 +-
> ...h10k-Try-to-get-mac-address-from-dts.patch |2 +-
> .../ath5k/411-ath5k_allow_adhoc_and_ap.patch |6 +-
> .../ath5k/440-ath5k_channel_bw_debugfs.patch |2 +-
> ...w-reset-AHB-WMAC-interface-on-AR91xx.patch |2 +-
> ..._hw-issue-external-reset-for-QCA955x.patch |4 +-
> ...erpret-requested-txpower-in-EIRP-dom.patch |4 +-
> ...power-reduction-for-US-regulatory-do.patch |2 +-
> .../ath9k/401-ath9k_blink_default.patch |2 +-
> .../ath9k/410-ath9k_allow_adhoc_and_ap.patch |4 +-
> ...abled-MFP-capability-unconditionally.patch |4 +-
> .../patches/ath9k/501-ath9k_ahb_init.patch|2 +-
> .../510-ath9k_intr_mitigation_tweak.patch |2 +-
> .../patches/ath9k/513-ath9k_add_pci_ids.patch |2 +-
> .../patches/ath9k/530-ath9k_extra_leds.patch |8 +-
> .../ath9k/542-ath9k_debugfs_diag.patch|4 +-
> .../ath9k/543-ath9k_entropy_from_adc.patch| 10 +-
> ...544-ath9k-ar933x-usb-hang-workaround.patch | 10 +-
> .../ath9k/545-ath9k_ani_ws_detect.patch |2 +-
> .../ath9k/548-ath9k_enable_gpio_chip.patch|4 +-
> .../ath9k/549-ath9k_enable_gpio_buttons.patch |2 +-
> .../550-ath9k-disable-bands-via-dt.patch |2 +-
> .../ath9k/551-ath9k_ubnt_uap_plus_hsr.patch |2 +-
> .../patches/ath9k/552-ath9k-ahb_of.patch |2 +-
> .../ath9k/553-ath9k_of_gpio_mask.patch|4 +-
> .../brcm/812-b43-add-antenna-control.patch|8 +-
> ...-register-wiphy-s-during-module_init.patch | 18 +-
>
hostapd: ubus inteface crashes hostapd?
Is someone massively utilizing the ubus interface from hostapd? I'm doing this with dawn and I saw that blocktrron already fixed some infinity loop. However, currently DAWN is crashing the hostapd. I make extensive use of the get_clients, all subscriptions, disassoc_immidient calls. Of course I don't want to exclude that the error is on my side. I just wanted to ask if someone is doing something similar. It is just weird for me that dawn can crash hostapd since it is only connecting via ubus and uses iwinfo library to get signal strength and channel utilization from wifi interfaces. See: https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-948192240 Bests Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
