[OpenWrt-Devel] [PATCH 0/1] toolchain: remove gcc libssp and use libc variant
Gcc's libssp is a standalone userspace implementation of SSP that makes gcc incompatible with kernel stack protection. Builds using libssp cannot enable kernel stack protection due to the insertion of an incompatible stack canary by libssp-enabled gcc. All three C libraries supported by OpenWrt have native stack smashing protection and this should be used in preference. This patch removes gcc's libssp, enables native ssp for glibc and uses the existing, already-configured, native ssp for uClibc. It also enables kernel stack smashing protection for non-musl libc toolchains and creates a uniform configuration interface for both userspace and kernel stack protection options across all C library variants supported by OpenWrt. Kernel stack smashing protection is architecture dependent and only available for a few architectures. The setting will be ignored by the kernel if the architecture does not support it. A minor semantic change is introduced to the config symbol SSP_SUPPORT. Four packages rely on the SSP_SUPPORT symbol: avahi, tor, openssh and cjdns. Of these, all will continue to compile correctly in all cases except for avahi with glibc when stack smashing protection is enabled. The avahi Makefile will require a patch to remove an explicit link of libssp_nonshared.a triggered by a dependency on SSP_SUPPORT. Musl needs to link this library, however it is part of the ALL_LIBS symbol and is automatically linked, so the line can be safely removed from the avahi Makefile. The other packages should be patched sometime to remove the dependency on this ambiguous symbol (see commit 241e6dd3e) and instead refer to PKG_CC_STACKPROTECTOR_NONE, after which the symbol CONFIG_SSP_SUPPORT can be removed from the build configuration. All packages referring to the symbol GCC_LIBSSP will continue to compile as before, as the symbol is retained, made non- configurable and set to a default of 'n'. This patch has been compile tested on musl, glibc and uclibc with mips, arc and x86_64 architectures, both with and without stack smashing protection and run tested on x86_64 glibc with both. Compiled kernels for x86_64 are verified to contain stack smashing protection via the relevant symbols in /proc/config.gz root@openwrt:~# zcat /proc/config.gz | grep STACKPROTECTOR CONFIG_CC_HAS_SANE_STACKPROTECTOR=y CONFIG_HAVE_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_STACKPROTECTOR=y CONFIG_STACKPROTECTOR_STRONG=y Binaries linked to uClibc and glibc are verified to contain stack canaries. The userspace stack smashing protection is run-tested on glibc, however I don't have access to an arc- based machine, so cannot run-test it for uClibc. If anyone else has access and can run-test it on arc, then please do. uClibc: nm dropbearconvert | grep stack_chk U __stack_chk_fail U __stack_chk_guard glibc: nm dropbearconvert | grep stack_chk U __stack_chk_fail@@GLIBC_2.4 root@openwrt:~# check-stack-protector this input string is much too long for the buffer *** stack smashing detected ***: terminated Aborted The musl implementation remains unmodified. Ian Cooper (1): toolchain: remove gcc libssp and use libc variant config/Config-build.in | 4 toolchain/Config.in | 2 +- toolchain/binutils/Makefile | 8 toolchain/gcc/Config.in | 6 +- toolchain/glibc/common.mk | 3 ++- 5 files changed, 4 insertions(+), 19 deletions(-) -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] toolchain: remove gcc libssp and use libc variant
Removes the standalone implementation of stack smashing protection in gcc's libssp in favour of the native implementation in musl, glibc and uClibc and introduces a uniform configuration interface. This also makes kernel-level stack smashing protection available for builds using non-musl libc (subject to architecture support). Signed-off-by: Ian Cooper --- config/Config-build.in | 4 toolchain/Config.in | 2 +- toolchain/binutils/Makefile | 8 toolchain/gcc/Config.in | 6 +- toolchain/glibc/common.mk | 3 ++- 5 files changed, 4 insertions(+), 19 deletions(-) diff --git a/config/Config-build.in b/config/Config-build.in index 61a9265ad7..ac1e05d2ff 100644 --- a/config/Config-build.in +++ b/config/Config-build.in @@ -249,7 +249,6 @@ menu "Global build settings" choice prompt "User space Stack-Smashing Protection" - depends on USE_MUSL default PKG_CC_STACKPROTECTOR_REGULAR help Enable GCC Stack Smashing Protection (SSP) for userspace applications @@ -257,18 +256,15 @@ menu "Global build settings" bool "None" config PKG_CC_STACKPROTECTOR_REGULAR bool "Regular" - select GCC_LIBSSP if !USE_MUSL depends on KERNEL_CC_STACKPROTECTOR_REGULAR config PKG_CC_STACKPROTECTOR_STRONG bool "Strong" - select GCC_LIBSSP if !USE_MUSL depends on KERNEL_CC_STACKPROTECTOR_STRONG endchoice choice prompt "Kernel space Stack-Smashing Protection" default KERNEL_CC_STACKPROTECTOR_REGULAR - depends on USE_MUSL || !(x86_64 || i386) help Enable GCC Stack-Smashing Protection (SSP) for the kernel config KERNEL_CC_STACKPROTECTOR_NONE diff --git a/toolchain/Config.in b/toolchain/Config.in index 762f4e10d7..cb557d4ad3 100644 --- a/toolchain/Config.in +++ b/toolchain/Config.in @@ -284,7 +284,7 @@ config USE_MUSL bool config SSP_SUPPORT - default y if USE_MUSL || GCC_LIBSSP + default y if !PKG_CC_STACKPROTECTOR_NONE bool config USE_EXTERNAL_LIBC diff --git a/toolchain/binutils/Makefile b/toolchain/binutils/Makefile index c5c8bf588c..6eee77eaa9 100644 --- a/toolchain/binutils/Makefile +++ b/toolchain/binutils/Makefile @@ -54,14 +54,6 @@ HOST_CONFIGURE_ARGS = \ $(SOFT_FLOAT_CONFIG_OPTION) \ $(call qstrip,$(CONFIG_EXTRA_BINUTILS_CONFIG_OPTIONS)) -ifneq ($(CONFIG_SSP_SUPPORT),) - HOST_CONFIGURE_ARGS+= \ - --enable-libssp -else - HOST_CONFIGURE_ARGS+= \ - --disable-libssp -endif - ifneq ($(CONFIG_EXTRA_TARGET_ARCH),) HOST_CONFIGURE_ARGS+= \ --enable-targets=$(call qstrip,$(CONFIG_EXTRA_TARGET_ARCH_NAME))-linux-$(TARGET_SUFFIX) diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in index 7d7f34210a..c481af88d0 100644 --- a/toolchain/gcc/Config.in +++ b/toolchain/gcc/Config.in @@ -49,11 +49,7 @@ config GCC_DEFAULT_SSP config GCC_LIBSSP bool - prompt "Build gcc libssp" if TOOLCHAINOPTS - depends on !USE_MUSL - default y if !USE_MUSL - help - Enable Stack-Smashing Protection support + default n config SJLJ_EXCEPTIONS bool diff --git a/toolchain/glibc/common.mk b/toolchain/glibc/common.mk index 768ff19060..b908afc50f 100644 --- a/toolchain/glibc/common.mk +++ b/toolchain/glibc/common.mk @@ -39,7 +39,6 @@ ifeq ($(ARCH),mips64) endif endif - # -Os miscompiles w. 2.24 gcc5/gcc6 # only -O2 tested by upstream changeset # "Optimize i386 syscall inlining for GCC 5" @@ -61,6 +60,8 @@ GLIBC_CONFIGURE:= \ --without-cvs \ --enable-add-ons \ --$(if $(CONFIG_SOFT_FLOAT),without,with)-fp \ + $(if $(CONFIG_PKG_CC_STACKPROTECTOR_REGULAR),--enable-stack-protector=yes,) \ + $(if $(CONFIG_PKG_CC_STACKPROTECTOR_STRONG),--enable-stack-protector=strong,) \ --enable-kernel=4.14.0 export libc_cv_ssp=no -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v7] ramips: add support for TRENDnet TEW-810DR
* MediaTek MT7620A (580 Mhz)
* 8 MB of FLASH * 64 MB of RAM
* 2.4Ghz and 5.0Ghz radios both now functional
* 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
* UART header on PCB (57600 8n1)
* Green/Orange Power LEDs illuminating a Power-Button Lens
Green/Orange Internet LEDs GPIO controlled illuminating a Globe/Internet Lens
* 3x button - wps, power and reset
* U-boot bootloader
Installation:
The sysupgrade.bin image is reported to be OEM web flashed with an ncc_att_hwid
appended. ncc_att_hwid is a 32bit binary in the GPL Source download for either
the TEW-810DR or DIR-810L and is located at
source/user/wolf/cameo/ncc/hostTools.
The invocation is: ncc_att_hwid
-f tew-810dr-squashfs-factory.bin -a -m "TEW-810DR" -H "1.0R" -r "WW" -c "1.0"
This may need to be altered if your hardware version is "1.1R".
The image can also be directly flashed via serial tftp.
1. Load *.sysupgrade.bin to your tftp server directory and rename for
convenience.
2. Set a static ip 192.168.10.100.
3. NIC cable to a lan port.
4. Serial connection parameters 57600,8N1
5. Power on the TEW-810 and press 4 for a u-boot command line prompt.
6. Verify IP's with U-Boot command "printenv".
7. Adjust tftp settings if needed per the tftp documentation
8. Boot the tftp image to test the build.
9. If the image loads, reset your server ip to 192.168.1.10 and restart
network.
10. Log in to Luci, 192.168.1.1, and flash the *sysupgrade.bin image.
Summary v4 -> v5 -> v6
1. Enumerated installation steps and corrected grammar.
2. Added SPDX License Identifier to *.dts.
3. gpio-keys-polled -> gpio-keys in *.dts.
4. gpio2 0 is actually behind a Globe/Internet lens - changed to wan.
5. Increased spi-max-frequency 1000 -> 5000
6. jffs2 partition 0xe -> 0xf.
7. _default groups dropped mdio, rgmii1, wled.
8. MAC assignments mirror DIR-810L and verify in Luci. Unchanged
02_network and *.dts.
9. 01_leds changed consistent with #4.
10. Removed SUPPORTED_DEVICES from image/mt7620.mk. Note: the D-Link
DIR-810L has the same SUPPORTED_DEVICES entry in image/mt7620.mk.
11. Builds/Runs on my test Device.
Summary v6 -> v7
1. White space issues in *.dts, image/mt7620.mk, 01_leds and 02_network;
spaces replaced with tabs
Signed-off-by: J. Scott Heppler
---
.../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 166 ++
target/linux/ramips/image/mt7620.mk | 9 +
.../mt7620/base-files/etc/board.d/01_leds | 3 +
.../mt7620/base-files/etc/board.d/02_network | 4 +-
4 files changed, 181 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
new file mode 100644
index 00..2873b5d780
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
@@ -0,0 +1,166 @@
+//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
+ model = "TRENDnet TEW-810DR";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ label-mac-device =
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 2 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power_green: power_green {
+ label = "tew-810dr:green:power";
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_orange: wan_orange {
+ label = "tew-810dr:orange:wan";
+ gpios = < 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_green: wan_green {
+ label = "tew-810dr:green:wan";
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led_power_orange {
+ label = "tew-810dr:orange:power";
+ gpios = < 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label
Re: [OpenWrt-Devel] [PATCH v5] ramips: add support for Trendnet TEW-810DR
On Mon, May 25, 2020 at 04:57:36PM -0700, Heppler, J. Scott wrote:
>
> * MediaTek MT7620A (580 Mhz)
> * 8 MB of FLASH
> * 64 MB of RAM
> * 2.4Ghz and 5.0Ghz radios both now functional
> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> * UART header on PCB (57600 8n1)
> * Green/Orange Power LEDs illuminating a Power-Button Lens
> Green/Orange Internet LEDs GPIO controlled illuminating a Globe/Internet
> Lens
> * 3x button - wps, power and reset
> * U-boot bootloader
>
> Installation:
>
> The sysupgrade.bin image is reported to be OEM web flashed with an
> ncc_att_hwid
> appended. ncc_att_hwid is a 32bit binary in the GPL Source download for
> either
> the TEW-810DR or DIR-810L and is located at
> source/user/wolf/cameo/ncc/hostTools.
> The invocation is: ncc_att_hwid
> -f tew-810dr-squashfs-factory.bin -a -m "TEW-810DR" -H "1.0R" -r "WW" -c "1.0"
> This may need to be altered if your hardware version is "1.1R".
> The image can also be directly flashed via serial tftp.
> 1. Load *.sysupgrade.bin to your tftp server directory and rename for
> convenience.
> 2. Set a static ip 192.168.10.100.
> 3. NIC cable to a lan port.
> 4. Serial connection parameters 57600,8N1
> 5. Power on the TEW-810 and press 4 for a u-boot command line prompt.
> 6. Verify IP's with U-Boot command "printenv".
> 7. Adjust tftp settings if needed per the tftp documentation
> 8. Boot the tftp image to test the build.
> 9. If the image loads, reset your server ip to 192.168.1.10 and restart
> network.
> 10. Log in to Luci, 192.168.1.1, and flash the *sysupgrade.bin image.
>
> Signed-off-by: J. Scott Heppler
>
> Summary v4 -> v5
> 1. Enumerated installation steps and corrected grammar.
> 2. Added SPDX License Identifier to *.dts.
> 3. gpio-keys-polled -> gpio-keys in *.dts.
> 4. gpio2 0 is actually behind a Globe/Internet lens - changed to wan.
> 5. Increased spi-max-frequency 1000 -> 5000
> 6. jffs2 partition 0xe -> 0xf.
> 7. _default groups; dropped mdio, rgmii1, wled.
> 8. MAC assignments mirror DIR-810L code and verify in Luci. Unchanged
> 02_network and *.dts.
> 9. 01_leds changed consistent with #4.
> 10. Removed SUPPORTED_DEVICES from image/mt7620.mk. Note: the D-Link
> DIR-810L has the same SUPPORTED_DEVICES entry in image/mt7620.mk.
> 11. Builds/Runs on my test Device.
> ---
> .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 166 ++
> target/linux/ramips/image/mt7620.mk | 9 +
> .../mt7620/base-files/etc/board.d/01_leds | 3 +
> .../mt7620/base-files/etc/board.d/02_network | 8 +-
> 4 files changed, 183 insertions(+), 3 deletions(-)
> create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
>
> diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> new file mode 100644
> index 00..5012d39b51
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> @@ -0,0 +1,166 @@
> +//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
> + model = "TRENDnet TEW-810DR";
> +
> + aliases {
> + led-boot = _power_green;
> + led-failsafe = _power_green;
> + led-running = _power_green;
> + led-upgrade = _power_green;
> + label-mac-device =
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wps {
> + label = "wps";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power_green: power_green {
> + label = "tew-810dr:green:power";
> + gpios = < 9 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wan_orange: wan_orange {
> + label = "tew-810dr:orange:wan";
> + gpios = < 12 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wan_green: wan_green {
> + label = "tew-810dr:green:wan";
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_power_orange {
> + label = "tew-810dr:orange:power";
> + gpios = < 13 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
What kind of chip is doing 5GHz wifi? Are you sure you don't need to
define EEPROM and/or mac-adress from MTD in the device-tree as well?
The patch was cut here misses the other files, only the DTS was
partially sent :(
Cheers
Daniel
Re: [OpenWrt-Devel] [PATCH v6] ramips: add support for Trendnet TEW-810DR
On Mon, May 25, 2020 at 05:05:16PM -0700, Heppler, J. Scott wrote:
>
> * MediaTek MT7620A (580 Mhz)
> * 8 MB of FLASH
> * 64 MB of RAM
> * 2.4Ghz and 5.0Ghz radios both now functional
> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> * UART header on PCB (57600 8n1)
> * Green/Orange Power LEDs illuminating a Power-Button Lens
> Green/Orange Internet LEDs GPIO controlled illuminating a Globe/Internet
> Lens
> * 3x button - wps, power and reset
> * U-boot bootloader
>
> Installation:
>
> The sysupgrade.bin image is reported to be OEM web flashed with an
> ncc_att_hwid
> appended. ncc_att_hwid is a 32bit binary in the GPL Source download for
> either
> the TEW-810DR or DIR-810L and is located at
> source/user/wolf/cameo/ncc/hostTools.
> The invocation is: ncc_att_hwid
> -f tew-810dr-squashfs-factory.bin -a -m "TEW-810DR" -H "1.0R" -r "WW" -c "1.0"
> This may need to be altered if your hardware version is "1.1R".
> The image can also be directly flashed via serial tftp.
> 1. Load *.sysupgrade.bin to your tftp server directory and rename for
> convenience.
> 2. Set a static ip 192.168.10.100.
> 3. NIC cable to a lan port.
> 4. Serial connection parameters 57600,8N1
> 5. Power on the TEW-810 and press 4 for a u-boot command line prompt.
> 6. Verify IP's with U-Boot command "printenv".
> 7. Adjust tftp settings if needed per the tftp documentation
> 8. Boot the tftp image to test the build.
> 9. If the image loads, reset your server ip to 192.168.1.10 and restart
> network.
> 10. Log in to Luci, 192.168.1.1, and flash the *sysupgrade.bin image.
>
> Signed-off-by: J. Scott Heppler
>
> Summary v4 -> v5
> 1. Enumerated installation steps and corrected grammar.
> 2. Added SPDX License Identifier to *.dts.
> 3. gpio-keys-polled -> gpio-keys in *.dts.
> 4. gpio2 0 is actually behind a Globe/Internet lens - changed to wan.
> 5. Increased spi-max-frequency 1000 -> 5000
> 6. jffs2 partition 0xe -> 0xf.
> 7. _default groups dropped mdio, rgmii1, wled.
> 8. MAC assignments mirror DIR-810L and verify in Luci. Unchanged
> 02_network and *.dts.
> 9. 01_leds changed consistent with #4.
> 10. Removed SUPPORTED_DEVICES from image/mt7620.mk. Note: the D-Link
> DIR-810L has the same SUPPORTED_DEVICES entry in image/mt7620.mk.
> 11. Builds/Runs on my test Device.
> ---
> .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 166 ++
> target/linux/ramips/image/mt7620.mk | 9 +
> .../mt7620/base-files/etc/board.d/01_leds | 3 +
> .../mt7620/base-files/etc/board.d/02_network | 8 +-
> 4 files changed, 183 insertions(+), 3 deletions(-)
> create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
>
> diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> new file mode 100644
> index 00..5012d39b51
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> @@ -0,0 +1,166 @@
> +//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
> + model = "TRENDnet TEW-810DR";
> +
> + aliases {
> + led-boot = _power_green;
> + led-failsafe = _power_green;
> + led-running = _power_green;
> + led-upgrade = _power_green;
> + label-mac-device =
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wps {
> + label = "wps";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power_green: power_green {
> + label = "tew-810dr:green:power";
> + gpios = < 9 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wan_orange: wan_orange {
> + label = "tew-810dr:orange:wan";
> + gpios = < 12 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wan_green: wan_green {
> + label = "tew-810dr:green:wan";
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_power_orange {
> + label = "tew-810dr:orange:power";
> + gpios = < 13 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <5000>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells =
[OpenWrt-Devel] [PATCH v6] ramips: add support for Trendnet TEW-810DR
* MediaTek MT7620A (580 Mhz)
* 8 MB of FLASH
* 64 MB of RAM
* 2.4Ghz and 5.0Ghz radios both now functional
* 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
* UART header on PCB (57600 8n1)
* Green/Orange Power LEDs illuminating a Power-Button Lens
Green/Orange Internet LEDs GPIO controlled illuminating a Globe/Internet Lens
* 3x button - wps, power and reset
* U-boot bootloader
Installation:
The sysupgrade.bin image is reported to be OEM web flashed with an ncc_att_hwid
appended. ncc_att_hwid is a 32bit binary in the GPL Source download for either
the TEW-810DR or DIR-810L and is located at
source/user/wolf/cameo/ncc/hostTools.
The invocation is: ncc_att_hwid
-f tew-810dr-squashfs-factory.bin -a -m "TEW-810DR" -H "1.0R" -r "WW" -c "1.0"
This may need to be altered if your hardware version is "1.1R".
The image can also be directly flashed via serial tftp.
1. Load *.sysupgrade.bin to your tftp server directory and rename for
convenience.
2. Set a static ip 192.168.10.100.
3. NIC cable to a lan port.
4. Serial connection parameters 57600,8N1
5. Power on the TEW-810 and press 4 for a u-boot command line prompt.
6. Verify IP's with U-Boot command "printenv".
7. Adjust tftp settings if needed per the tftp documentation
8. Boot the tftp image to test the build.
9. If the image loads, reset your server ip to 192.168.1.10 and restart
network.
10. Log in to Luci, 192.168.1.1, and flash the *sysupgrade.bin image.
Signed-off-by: J. Scott Heppler
Summary v4 -> v5
1. Enumerated installation steps and corrected grammar.
2. Added SPDX License Identifier to *.dts.
3. gpio-keys-polled -> gpio-keys in *.dts.
4. gpio2 0 is actually behind a Globe/Internet lens - changed to wan.
5. Increased spi-max-frequency 1000 -> 5000
6. jffs2 partition 0xe -> 0xf.
7. _default groups dropped mdio, rgmii1, wled.
8. MAC assignments mirror DIR-810L and verify in Luci. Unchanged
02_network and *.dts.
9. 01_leds changed consistent with #4.
10. Removed SUPPORTED_DEVICES from image/mt7620.mk. Note: the D-Link
DIR-810L has the same SUPPORTED_DEVICES entry in image/mt7620.mk.
11. Builds/Runs on my test Device.
---
.../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 166 ++
target/linux/ramips/image/mt7620.mk | 9 +
.../mt7620/base-files/etc/board.d/01_leds | 3 +
.../mt7620/base-files/etc/board.d/02_network | 8 +-
4 files changed, 183 insertions(+), 3 deletions(-)
create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
new file mode 100644
index 00..5012d39b51
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
@@ -0,0 +1,166 @@
+//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
+ model = "TRENDnet TEW-810DR";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ label-mac-device =
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 2 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power_green: power_green {
+ label = "tew-810dr:green:power";
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_orange: wan_orange {
+ label = "tew-810dr:orange:wan";
+ gpios = < 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_green: wan_green {
+ label = "tew-810dr:green:wan";
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led_power_orange {
+ label = "tew-810dr:orange:power";
+ gpios = < 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+
[OpenWrt-Devel] [PATCH v5] ramips: add support for Trendnet TEW-810DR
* MediaTek MT7620A (580 Mhz)
* 8 MB of FLASH
* 64 MB of RAM
* 2.4Ghz and 5.0Ghz radios both now functional
* 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
* UART header on PCB (57600 8n1)
* Green/Orange Power LEDs illuminating a Power-Button Lens
Green/Orange Internet LEDs GPIO controlled illuminating a Globe/Internet Lens
* 3x button - wps, power and reset
* U-boot bootloader
Installation:
The sysupgrade.bin image is reported to be OEM web flashed with an ncc_att_hwid
appended. ncc_att_hwid is a 32bit binary in the GPL Source download for either
the TEW-810DR or DIR-810L and is located at
source/user/wolf/cameo/ncc/hostTools.
The invocation is: ncc_att_hwid
-f tew-810dr-squashfs-factory.bin -a -m "TEW-810DR" -H "1.0R" -r "WW" -c "1.0"
This may need to be altered if your hardware version is "1.1R".
The image can also be directly flashed via serial tftp.
1. Load *.sysupgrade.bin to your tftp server directory and rename for
convenience.
2. Set a static ip 192.168.10.100.
3. NIC cable to a lan port.
4. Serial connection parameters 57600,8N1
5. Power on the TEW-810 and press 4 for a u-boot command line prompt.
6. Verify IP's with U-Boot command "printenv".
7. Adjust tftp settings if needed per the tftp documentation
8. Boot the tftp image to test the build.
9. If the image loads, reset your server ip to 192.168.1.10 and restart
network.
10. Log in to Luci, 192.168.1.1, and flash the *sysupgrade.bin image.
Signed-off-by: J. Scott Heppler
Summary v4 -> v5
1. Enumerated installation steps and corrected grammar.
2. Added SPDX License Identifier to *.dts.
3. gpio-keys-polled -> gpio-keys in *.dts.
4. gpio2 0 is actually behind a Globe/Internet lens - changed to wan.
5. Increased spi-max-frequency 1000 -> 5000
6. jffs2 partition 0xe -> 0xf.
7. _default groups; dropped mdio, rgmii1, wled.
8. MAC assignments mirror DIR-810L code and verify in Luci. Unchanged
02_network and *.dts.
9. 01_leds changed consistent with #4.
10. Removed SUPPORTED_DEVICES from image/mt7620.mk. Note: the D-Link
DIR-810L has the same SUPPORTED_DEVICES entry in image/mt7620.mk.
11. Builds/Runs on my test Device.
---
.../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 166 ++
target/linux/ramips/image/mt7620.mk | 9 +
.../mt7620/base-files/etc/board.d/01_leds | 3 +
.../mt7620/base-files/etc/board.d/02_network | 8 +-
4 files changed, 183 insertions(+), 3 deletions(-)
create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
new file mode 100644
index 00..5012d39b51
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
@@ -0,0 +1,166 @@
+//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
+ model = "TRENDnet TEW-810DR";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ label-mac-device =
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 2 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power_green: power_green {
+ label = "tew-810dr:green:power";
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_orange: wan_orange {
+ label = "tew-810dr:orange:wan";
+ gpios = < 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_green: wan_green {
+ label = "tew-810dr:green:wan";
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led_power_orange {
+ label = "tew-810dr:orange:power";
+ gpios = < 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
--
J. Scott Heppler
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: per-interface MTU settings vs per-route MTU settings?
On Mon, May 25, 2020 at 8:00 AM Aleksander Morgado
wrote:
> Other protocol handlers, like uqmi, are also able to setup the MTU,
> and instead of doing it via proto_send_update, they just do it like
> this:
>
> [ -n "$mtu" ] && {
> echo "Setting MTU to $mtu"
> /sbin/ip link set dev $ifname mtu $mtu
> }
>
> I guess we can do the same in the ModemManager protocol handler.
>
>
That does seem like it would work, but I'm wary of race conditions with the
message sent to netifd via ubus, and further feel like it would be better
to have netifd learn how to set the mtu directly, if it doesn't already
know how.
Are any of the netifd project's contributors able to comment on this?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox 2/3] blobmsg: simplify and fix name length checks in blobmsg_check_name
On 25.05.2020 17:19, Felix Fietkau wrote: blobmsg_hdr_valid_namelen was omitted when name==false The blob_len vs blobmsg_namelen changes were not taking into account potential padding between name and data Signed-off-by: Felix Fietkau Tested-by: Rafał Miłecki ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox 3/3] blobmsg: fix missing length checks
On 25.05.2020 17:19, Felix Fietkau wrote: blobmsg_check_attr_len was calling blobmsg_check_data for some, but not all attribute types. These checks was missing for arrays and tables. Additionally, the length check in blobmsg_check_data was a bit off, since it was comparing the blobmsg data length against the raw blob attr length. Fix this by checking the raw blob length against the buffer length in blobmsg_hdr_from_blob Signed-off-by: Felix Fietkau Tested-by: Rafał Miłecki ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox 1/3] blobmsg: fix length in blobmsg_check_array
On 25.05.2020 17:19, Felix Fietkau wrote: blobmsg_check_array_len expects the length of the full attribute buffer, not just the data length. Due to other missing length checks (fixed in the next commit), this did not show up as a test failure Signed-off-by: Felix Fietkau Tested-by: Rafał Miłecki ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
On Monday, 25 May 2020 11:22:13 CEST Sven Eckelmann wrote:
[...]
> And it still can with this OpenWrt version. But it doesn't seem to happen
> with
> the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000
> commits inbetween. So no idea what changed (just a timing thing or an actual
> fix - no idea).
Seems like there is a fix which solves some lost interrupt problems for
IPQ40xx. Without this change, I see the reported problem. And with the patch,
it is gone. Or in commits:
* creates timeout problems: 46b949a067e5 ("ipq40xx: enlarge PCIe BAR size")
* works fine: 18e942b6c4e5 ("ipq40xx: fix pcie msi IRQ trigger level")
If you look in the git logs [1], you can see that the working commit is a
child of the broken one. So at least from my point of view, my initial report
is no blocker anymore for Sebastian's patch (or Kalle's version of it).
Btw. OpenWrt is automatically assigning a trigger (phy*tpt) for these LEDs.
Kind regards,
Sven
[1]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=log;h=18e942b6c4e51a5a717a121697a63f3f98d93b19
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 2/3] blobmsg: simplify and fix name length checks in blobmsg_check_name
blobmsg_hdr_valid_namelen was omitted when name==false
The blob_len vs blobmsg_namelen changes were not taking into account
potential padding between name and data
Signed-off-by: Felix Fietkau
---
blobmsg.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/blobmsg.c b/blobmsg.c
index daaa9fc8444b..308bef7bc6b0 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -48,8 +48,8 @@ static bool blobmsg_hdr_valid_namelen(const struct
blobmsg_hdr *hdr, size_t len)
static bool blobmsg_check_name(const struct blob_attr *attr, size_t len, bool
name)
{
- char *limit = (char *) attr + len;
const struct blobmsg_hdr *hdr;
+ uint16_t namelen;
hdr = blobmsg_hdr_from_blob(attr, len);
if (!hdr)
@@ -58,16 +58,11 @@ static bool blobmsg_check_name(const struct blob_attr
*attr, size_t len, bool na
if (name && !hdr->namelen)
return false;
- if (name && !blobmsg_hdr_valid_namelen(hdr, len))
- return false;
-
- if ((char *) hdr->name + blobmsg_namelen(hdr) + 1 > limit)
- return false;
-
- if (blobmsg_namelen(hdr) > (blob_len(attr) - sizeof(struct
blobmsg_hdr)))
+ namelen = blobmsg_namelen(hdr);
+ if (blob_len(attr) < (size_t)blobmsg_hdrlen(namelen))
return false;
- if (hdr->name[blobmsg_namelen(hdr)] != 0)
+ if (hdr->name[namelen] != 0)
return false;
return true;
--
2.24.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 3/3] blobmsg: fix missing length checks
blobmsg_check_attr_len was calling blobmsg_check_data for some, but not all
attribute types. These checks was missing for arrays and tables.
Additionally, the length check in blobmsg_check_data was a bit off, since
it was comparing the blobmsg data length against the raw blob attr length.
Fix this by checking the raw blob length against the buffer length in
blobmsg_hdr_from_blob
Signed-off-by: Felix Fietkau
---
blobmsg.c | 66 +--
1 file changed, 20 insertions(+), 46 deletions(-)
diff --git a/blobmsg.c b/blobmsg.c
index 308bef7bc6b0..7da418380299 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -30,31 +30,18 @@ bool blobmsg_check_attr(const struct blob_attr *attr, bool
name)
return blobmsg_check_attr_len(attr, name, blob_raw_len(attr));
}
-static const struct blobmsg_hdr* blobmsg_hdr_from_blob(const struct blob_attr
*attr, size_t len)
-{
- if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
- return NULL;
-
- return blob_data(attr);
-}
-
-static bool blobmsg_hdr_valid_namelen(const struct blobmsg_hdr *hdr, size_t
len)
-{
- if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr) +
blobmsg_namelen(hdr) + 1)
- return false;
-
- return true;
-}
-
-static bool blobmsg_check_name(const struct blob_attr *attr, size_t len, bool
name)
+static bool blobmsg_check_name(const struct blob_attr *attr, bool name)
{
const struct blobmsg_hdr *hdr;
uint16_t namelen;
- hdr = blobmsg_hdr_from_blob(attr, len);
- if (!hdr)
+ if (!blob_is_extended(attr))
+ return !name;
+
+ if (blob_len(attr) < sizeof(struct blobmsg_hdr))
return false;
+ hdr = (const struct blobmsg_hdr *)blob_data(attr);
if (name && !hdr->namelen)
return false;
@@ -68,29 +55,20 @@ static bool blobmsg_check_name(const struct blob_attr
*attr, size_t len, bool na
return true;
}
-static const char* blobmsg_check_data(const struct blob_attr *attr, size_t
len, size_t *data_len)
-{
- char *limit = (char *) attr + len;
- const char *data;
-
- *data_len = blobmsg_data_len(attr);
- if (*data_len > blob_raw_len(attr))
- return NULL;
-
- data = blobmsg_data(attr);
- if (data + *data_len > limit)
- return NULL;
-
- return data;
-}
-
bool blobmsg_check_attr_len(const struct blob_attr *attr, bool name, size_t
len)
{
const char *data;
size_t data_len;
int id;
- if (!blobmsg_check_name(attr, len, name))
+ if (len < sizeof(struct blob_attr))
+ return false;
+
+ data_len = blob_raw_len(attr);
+ if (data_len < sizeof(struct blob_attr) || data_len > len)
+ return false;
+
+ if (!blobmsg_check_name(attr, name))
return false;
id = blob_id(attr);
@@ -100,9 +78,8 @@ bool blobmsg_check_attr_len(const struct blob_attr *attr,
bool name, size_t len)
if (!blob_type[id])
return true;
- data = blobmsg_check_data(attr, len, _len);
- if (!data)
- return false;
+ data = blobmsg_data(attr);
+ data_len = blobmsg_data_len(attr);
return blob_check_type(data, data_len, blob_type[id]);
}
@@ -206,13 +183,13 @@ int blobmsg_parse(const struct blobmsg_policy *policy,
int policy_len,
}
__blob_for_each_attr(attr, data, len) {
- hdr = blobmsg_hdr_from_blob(attr, len);
- if (!hdr)
+ if (!blobmsg_check_attr_len(attr, false, len))
return -1;
- if (!blobmsg_hdr_valid_namelen(hdr, len))
- return -1;
+ if (!blob_is_extended(attr))
+ continue;
+ hdr = blob_data(attr);
for (i = 0; i < policy_len; i++) {
if (!policy[i].name)
continue;
@@ -224,9 +201,6 @@ int blobmsg_parse(const struct blobmsg_policy *policy, int
policy_len,
if (blobmsg_namelen(hdr) != pslen[i])
continue;
- if (!blobmsg_check_attr_len(attr, true, len))
- return -1;
-
if (tb[i])
continue;
--
2.24.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 1/3] blobmsg: fix length in blobmsg_check_array
blobmsg_check_array_len expects the length of the full attribute buffer,
not just the data length.
Due to other missing length checks (fixed in the next commit), this did
not show up as a test failure
Signed-off-by: Felix Fietkau
---
blobmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/blobmsg.c b/blobmsg.c
index 59045e1672c8..daaa9fc8444b 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -114,7 +114,7 @@ bool blobmsg_check_attr_len(const struct blob_attr *attr,
bool name, size_t len)
int blobmsg_check_array(const struct blob_attr *attr, int type)
{
- return blobmsg_check_array_len(attr, type, blob_len(attr));
+ return blobmsg_check_array_len(attr, type, blob_raw_len(attr));
}
int blobmsg_check_array_len(const struct blob_attr *attr, int type,
--
2.24.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] hostapd: add support for wifi-station and wifi-vlan sections
This patch adds support for 2 new uci sections.
config wifi-vlan
# iface is optional. if it is not defined the vlan will apply
# to all interfaces
option ifacedefault_radio0
option name guest
option vid 100
option network guest
config wifi-station
# iface is optional. if it is not defined the station will apply
# to all interfaces
option ifacedefault_radio0
# mac is optional. if it is not defined it will be a catch all
# for any sta using this key
option mac '00:11:22:33:44:55'
# vid is optional. if it is not defined, the sta will be part of
# the primary iface.
option vid 100
option key testtest
With this patch applied it is possible to use multiple PSKs and VIDs on a
single BSS.
Signed-off-by: John Crispin
---
.../files/lib/netifd/wireless/mac80211.sh | 8 +++-
.../network/services/hostapd/files/hostapd.sh | 37 +++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 7ca138c68c..19d05cb6dc 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -506,7 +506,7 @@ mac80211_iw_interface_add() {
mac80211_prepare_vif() {
json_select config
- json_get_vars ifname mode ssid wds powersave macaddr enable
+ json_get_vars ifname mode ssid wds powersave macaddr enable
wpa_psk_file vlan_file
[ -n "$ifname" ] || ifname="wlan${phy#phy}${if_idx:+-$if_idx}"
if_idx=$((${if_idx:-0} + 1))
@@ -524,6 +524,12 @@ mac80211_prepare_vif() {
json_add_object data
json_add_string ifname "$ifname"
json_close_object
+
+ [ "$mode" == "ap" ] && {
+ [ -z "$wpa_psk_file" ] && hostapd_set_psk "$ifname"
+ [ -z "$vlan_file" ] && hostapd_set_vlan "$ifname"
+ }
+
json_select config
# It is far easier to delete and create the desired interface
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 637f298ad9..a3554b6451 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -262,6 +262,39 @@ hostapd_common_add_bss_config() {
config_add_string 'owe_transition_bssid:macaddr'
'owe_transition_ssid:string'
}
+hostapd_set_vlan_file() {
+ local ifname="$1"
+ local vlan="$2"
+ json_get_vars name vid
+ echo "${vid} ${ifname}-${name}" >> /var/run/hostapd-${ifname}.vlan
+ wireless_add_vlan "${vlan}" "${ifname}-${name}"
+}
+
+hostapd_set_vlan() {
+ local ifname="$1"
+
+ rm /var/run/hostapd-${ifname}.vlan
+ for_each_vlan hostapd_set_vlan_file ${ifname}
+}
+
+hostapd_set_psk_file() {
+ local ifname="$1"
+ local vlan="$2"
+ local vlan_id=""
+
+ json_get_vars mac vid key
+ set_default isolate "00:00:00:00:00:00"
+ [ -n "$vid" ] && vlan_id="vlanid=$vid "
+ echo "${vlan_id} ${mac} ${key}" >> /var/run/hostapd-${ifname}.psk
+}
+
+hostapd_set_psk() {
+ local ifname="$1"
+
+ rm /var/run/hostapd-${ifname}.psk
+ for_each_station hostapd_set_psk_file ${ifname}
+}
+
hostapd_set_bss_options() {
local var="$1"
local phy="$2"
@@ -377,12 +410,15 @@ hostapd_set_bss_options() {
else
append bss_conf "wpa_passphrase=$key" "$N"
fi
+ [ -z "$wpa_psk_file" ] && set_default wpa_psk_file
/var/run/hostapd-$ifname.psk
[ -n "$wpa_psk_file" ] && {
[ -e "$wpa_psk_file" ] || touch "$wpa_psk_file"
append bss_conf "wpa_psk_file=$wpa_psk_file"
"$N"
}
[ "$eapol_version" -ge "1" -a "$eapol_version" -le "2"
] && append bss_conf "eapol_version=$eapol_version" "$N"
+ set_default dynamic_vlan 0
+ vlan_possible=1
wps_possible=1
;;
eap|eap192|eap-eap192)
@@ -639,6 +675,7 @@ hostapd_set_bss_options() {
[ -n "$vlan_possible" -a -n "$dynamic_vlan" ] && {
json_get_vars vlan_naming vlan_tagged_interface vlan_bridge
vlan_file
set_default vlan_naming 1
+ [ -z "$vlan_file" ] && set_default vlan_file
/var/run/hostapd-$ifname.vlan
append bss_conf "dynamic_vlan=$dynamic_vlan" "$N"
append bss_conf "vlan_naming=$vlan_naming" "$N"
[ -n "$vlan_bridge" ] && \
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] Fix for missing kernel stack-protector in x86_64 glibc builds
Yes, it appears we can handle uclibc the same way Uclibc-ng supports SSP in the library itself, so use of GCC_LIBSSP can eliminated. I'll do some testing ... config UCLIBC_HAS_SSP bool "Support for GCC stack smashing protector" depends on !HAVE_NO_SSP help Add code to support GCC's -fstack-protector[-all] option to uClibc. This requires GCC 4.1 or newer. GCC does not have to provide libssp, the needed functions are added to ldso/libc instead. GCC's stack protector is a reimplementation of IBM's propolice. See http://www.trl.ibm.com/projects/security/ssp/ and http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt for details. Note that NOEXECSTACK on a kernel with address space randomization is generally sufficient to prevent most buffer overflow exploits without increasing code size. This option essentially adds debugging code to catch them. > -Original Message- > From: Hauke Mehrtens [mailto:ha...@hauke-m.de] > Sent: 24 May 2020 13:33 > To: Ian Cooper ; openwrt- > de...@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] Fix for missing kernel stack-protector in > x86_64 glibc builds > > > Does anyone know if we can handle uclibc the same way? It would be nice to > reduce the special handling in general. > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4
On 4/13/20 12:33 PM, Adrian Schmutzler wrote: > Update config with make kernel_oldconfig and copy patch. > > Directly switch to kernel 5.4. > > Signed-off-by: Adrian Schmutzler > > --- > > I just stupidly copied/refreshed the patch and the config. > > Build-tested, run-test required as I have no hardware. Hi Evgeniy and Alexey, Could you please test, if this patch works? We would like to get all targets to kernel 5.4 for the next release and this is one of the targets still at an older kernel. Adrian and I do not have any hardware to test this. You can find this patch also on patchwork: https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429-1-freif...@adrianschmutzler.de/ Hauke > > --- > target/linux/arc770/Makefile | 2 +- > target/linux/arc770/config-5.4| 198 ++ > ...c-Disable-frame-filtering-completely.patch | 31 +++ > 3 files changed, 230 insertions(+), 1 deletion(-) > create mode 100644 target/linux/arc770/config-5.4 > create mode 100644 > target/linux/arc770/patches-5.4/700-stmmac-Disable-frame-filtering-completely.patch > > diff --git a/target/linux/arc770/Makefile b/target/linux/arc770/Makefile > index 8150f147c5..a182ef16a5 100644 > --- a/target/linux/arc770/Makefile > +++ b/target/linux/arc770/Makefile > @@ -11,7 +11,7 @@ BOARD:=arc770 > BOARDNAME:=Synopsys DesignWare ARC 770D > SUBTARGETS:=generic > > -KERNEL_PATCHVER:=4.14 > +KERNEL_PATCHVER:=5.4 > > DEVICE_TYPE:=developerboard > > diff --git a/target/linux/arc770/config-5.4 b/target/linux/arc770/config-5.4 > new file mode 100644 > index 00..ce712b4c34 > --- /dev/null > +++ b/target/linux/arc770/config-5.4 > @@ -0,0 +1,198 @@ > +# CONFIG_16KSTACKS is not set > +CONFIG_ARC=y > +CONFIG_ARCH_32BIT_OFF_T=y > +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > +CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y > +CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y > +CONFIG_ARCH_HAS_PTE_SPECIAL=y > +CONFIG_ARCH_HAS_SETUP_DMA_OPS=y > +CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y > +CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y > +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y > +CONFIG_ARC_BUILTIN_DTB_NAME="" > +CONFIG_ARC_CACHE=y > +CONFIG_ARC_CACHE_LINE_SHIFT=5 > +CONFIG_ARC_CACHE_PAGES=y > +# CONFIG_ARC_CACHE_VIPT_ALIASING is not set > +# CONFIG_ARC_COMPACT_IRQ_LEVELS is not set > +# CONFIG_ARC_CPU_750D is not set > +CONFIG_ARC_CPU_770=y > +CONFIG_ARC_CURR_IN_REG=y > +CONFIG_ARC_DBG=y > +# CONFIG_ARC_DBG_TLB_PARANOIA is not set > +CONFIG_ARC_DW2_UNWIND=y > +CONFIG_ARC_EMUL_UNALIGNED=y > +# CONFIG_ARC_FPU_SAVE_RESTORE is not set > +CONFIG_ARC_HAS_DCACHE=y > +# CONFIG_ARC_HAS_DCCM is not set > +CONFIG_ARC_HAS_ICACHE=y > +# CONFIG_ARC_HAS_ICCM is not set > +CONFIG_ARC_HAS_LLSC=y > +CONFIG_ARC_HAS_SWAPE=y > +CONFIG_ARC_KVADDR_SIZE=256 > +# CONFIG_ARC_METAWARE_HLINK is not set > +# CONFIG_ARC_MMU_V1 is not set > +# CONFIG_ARC_MMU_V2 is not set > +CONFIG_ARC_MMU_V3=y > +# CONFIG_ARC_PAGE_SIZE_16K is not set > +# CONFIG_ARC_PAGE_SIZE_4K is not set > +CONFIG_ARC_PAGE_SIZE_8K=y > +CONFIG_ARC_PLAT_AXS10X=y > +# CONFIG_ARC_PLAT_EZNPS is not set > +# CONFIG_ARC_PLAT_TB10X is not set > +CONFIG_ARC_TIMERS=y > +CONFIG_AXS101=y > +CONFIG_CC_HAS_KASAN_GENERIC=y > +# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3 is not set > +CONFIG_CLKDEV_LOOKUP=y > +CONFIG_CLONE_BACKWARDS=y > +CONFIG_COMMON_CLK=y > +CONFIG_COMPAT_32BIT_TIME=y > +CONFIG_CPU_NO_EFFICIENT_FFS=y > +CONFIG_CRC16=y > +CONFIG_CRYPTO_CRC32C=y > +CONFIG_CRYPTO_HASH=y > +CONFIG_CRYPTO_HASH2=y > +CONFIG_CRYPTO_RNG2=y > +CONFIG_DMA_DIRECT_REMAP=y > +CONFIG_DMA_REMAP=y > +CONFIG_DTC=y > +CONFIG_DWMAC_ANARION=y > +CONFIG_DWMAC_GENERIC=y > +CONFIG_DW_APB_ICTL=y > +CONFIG_EXT4_FS=y > +# CONFIG_EZNPS_GIC is not set > +CONFIG_FIXED_PHY=y > +CONFIG_FS_IOMAP=y > +CONFIG_FS_MBCACHE=y > +CONFIG_FW_LOADER_PAGED_BUF=y > +CONFIG_GENERIC_ALLOCATOR=y > +CONFIG_GENERIC_ATOMIC64=y > +CONFIG_GENERIC_CLOCKEVENTS=y > +CONFIG_GENERIC_CSUM=y > +CONFIG_GENERIC_FIND_FIRST_BIT=y > +CONFIG_GENERIC_IRQ_CHIP=y > +CONFIG_GENERIC_IRQ_SHOW=y > +CONFIG_GENERIC_PCI_IOMAP=y > +CONFIG_GENERIC_SCHED_CLOCK=y > +CONFIG_GENERIC_SMP_IDLE_THREAD=y > +CONFIG_GPIOLIB=y > +CONFIG_GPIO_DWAPB=y > +CONFIG_GPIO_GENERIC=y > +# CONFIG_GPIO_SNPS_CREG is not set > +CONFIG_HANDLE_DOMAIN_IRQ=y > +CONFIG_HAS_DMA=y > +CONFIG_HAS_IOMEM=y > +CONFIG_HAVE_ARCH_KGDB=y > +CONFIG_HAVE_ARCH_TRACEHOOK=y > +CONFIG_HAVE_CLK=y > +CONFIG_HAVE_CLK_PREPARE=y > +CONFIG_HAVE_DEBUG_STACKOVERFLOW=y > +CONFIG_HAVE_FUTEX_CMPXCHG=y > +CONFIG_HAVE_IOREMAP_PROT=y > +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y > +CONFIG_HAVE_NET_DSA=y > +CONFIG_HAVE_OPROFILE=y > +CONFIG_HAVE_PCI=y > +CONFIG_HAVE_PERF_EVENTS=y > +CONFIG_HZ=100 > +CONFIG_HZ_PERIODIC=y > +CONFIG_INITRAMFS_SOURCE="" > +CONFIG_IRQCHIP=y > +CONFIG_IRQ_DOMAIN=y > +CONFIG_IRQ_WORK=y > +CONFIG_ISA_ARCOMPACT=y > +# CONFIG_ISA_ARCV2 is not set > +CONFIG_JBD2=y > +CONFIG_KALLSYMS=y > +CONFIG_KERNEL_GZIP=y > +CONFIG_LIBFDT=y > +CONFIG_LINUX_LINK_BASE=0x8000 > +CONFIG_LINUX_RAM_BASE=0x8000 >
Re: [OpenWrt-Devel] netifd: per-interface MTU settings vs per-route MTU settings?
Hey,
> >> There's an ongoing discussion in the ModemManager package in github
> >> related to how the MTU may be configured in the network interface
> >> based on what the MM bearer object reports:
> >> https://github.com/openwrt/packages/issues/11383
> >>
> >> E.g.:
> >>
> >> $ ip route show
> >> default via 25.225.105.222 dev wwan0 proto static src 25.225.105.221 mtu
> >> 1430
> >>
> >> Looks like the protocol handler implementation for netifd may allow
> >> setting the MTU to the routes associated with the network interface,
> >> instead of assigning the MTU value to the interface itself. Are both
> >> methods completely equivalent? Is there any reason to avoid setting
> >> the MTU in the interface when using netifd, or just not implemented
> >> yet?
> >>
> >> Cheers!
> >>
> >> --
> >> Aleksander
> >> https://aleksander.es
> >
> >
> >
> >
> > I'm actually not aware of any method to set the interface MTU via netifd
> > that isn't a UCI setting.
> >
>
> While running as a protocol handler under netifd, we can do this while
> setting up the default route:
> proto_add_ipv4_route "0.0.0.0" "0" "${gateway}" "${address}"
> "${metric}" "${mtu}"
> And the given ${mtu} will be set for the route created.
>
> What we're looking for is a way to setup the MTU for the whole network
> interface from within the protocol handler automatically.
>
Other protocol handlers, like uqmi, are also able to setup the MTU,
and instead of doing it via proto_send_update, they just do it like
this:
[ -n "$mtu" ] && {
echo "Setting MTU to $mtu"
/sbin/ip link set dev $ifname mtu $mtu
}
I guess we can do the same in the ModemManager protocol handler.
--
Aleksander
https://aleksander.es
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: always use -minterlink-mips16 if USE_MIPS16
On Mon, May 25, 2020 at 5:06 AM Felix Fietkau wrote: > > On 2020-05-25 02:19, Eneas U de Queiroz wrote: > > Individual packages may turn off MIPS16 ISA individually with > > PKG_USE_MIPS16. However, they may link to a library compiled with > > MIPS16. In such cases, the -minterlink-mips16 is needed to ensure there > > are no direct jumps to code compiled with a different ISA. > > > > Instead of adding -minterlink-mips16 only when PKG_USE_MIPS16 is on, add > > it when global USE_MIPS16 is on. > > > > Signed-off-by: Eneas U de Queiroz > > --- > > Tested by compiling all packages in base, packages, routing and > > telephony feeds for mips_74kc, with MIPS16 enabled. > > > > This was discovered while working on lxc fixes > > (https://github.com/openwrt/packages/pull/12241), where compilation with > > mips16 would fail because of '-fstack-check=specific not implemented for > > MIPS16', and it would fail with PKG_USE_MIPS16=0 because of jumping to a > > different ISA mode: > > > > lxc-4.0.2/src/lxc/caps.c:24:(.text+0xa4): unsupported jump between ISA > > modes; consider recompiling with interlinking enabled > > > > In theory this could happen in more places, so set interlinking on > > whenever MIPS16 is turned on globally. > I think there needs be a way to opt-out of this behavior. > The -minterlink-mips16 flag affects the performance and code size of > generated code, so libraries that disable MIPS16 for performance reasons > and don't depend on other MIPS16 enabled libraries should not be > compiled with this flag. > > - Felix Let's leave it as is, then. Right now this failure appears to be an exception, not a rule. Packages can opt-in by adding the -minterlink-mips16 flag themselves, as was done with lxc. Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Targets without 5.4 support yet
On 25.05.20 13:11, Zoltan HERPAI wrote: Hi, On 5/25/2020 12:42, m...@adrianschmutzler.de wrote: Hi all, while there has been a lot of progress during the last months, there are still a few target that have not been updated to 5.4 (at least as testing kernel) yet: 4.19: cns3xxx 4.14: ar71xx (to be removed) arc770 (RFT patch: https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429-1-freif...@adrianschmutzler.de/) at91 ath25 (patchset crashing at Ethernet init: https://patchwork.ozlabs.org/project/openwrt/list/?series=169991) pistachio rb532 samsung uml This is meant as an invitation for those caring about/using these targets to consider updating them; in best case they should receive some testing before a 5.4 stable branch is made (whenever that might be). At least for the 4.14 targets, I expect them to be archived if there is no update until after the next release (or at the latest after the one following it). I'm working on bringing pistachio up to 5.4, apart from the spi-nand (which is quite a core item obviously, so I thought about reaching out to Boris for some guidance) it's looking good so far. If anyone's interested in helping, I'll share what I have. Also, if there is no one else interested in cns3xxx, I'm happy to take a look at that, I've got two devboards in the shed for that. Regards, Zoltan H ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel cns3xxx is scheduled later this week, but help is certainly welcome. I managed to do most of the required changes, but was stuck currently on the new "GPIO descriptor" stuff. (for GPS PPS) Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Targets without 5.4 support yet
Hi, On 5/25/2020 12:42, m...@adrianschmutzler.de wrote: Hi all, while there has been a lot of progress during the last months, there are still a few target that have not been updated to 5.4 (at least as testing kernel) yet: 4.19: cns3xxx 4.14: ar71xx (to be removed) arc770 (RFT patch: https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429-1-freif...@adrianschmutzler.de/) at91 ath25 (patchset crashing at Ethernet init: https://patchwork.ozlabs.org/project/openwrt/list/?series=169991) pistachio rb532 samsung uml This is meant as an invitation for those caring about/using these targets to consider updating them; in best case they should receive some testing before a 5.4 stable branch is made (whenever that might be). At least for the 4.14 targets, I expect them to be archived if there is no update until after the next release (or at the latest after the one following it). I'm working on bringing pistachio up to 5.4, apart from the spi-nand (which is quite a core item obviously, so I thought about reaching out to Boris for some guidance) it's looking good so far. If anyone's interested in helping, I'll share what I have. Also, if there is no one else interested in cns3xxx, I'm happy to take a look at that, I've got two devboards in the shed for that. Regards, Zoltan H ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Targets without 5.4 support yet
Hi all, while there has been a lot of progress during the last months, there are still a few target that have not been updated to 5.4 (at least as testing kernel) yet: 4.19: cns3xxx 4.14: ar71xx (to be removed) arc770 (RFT patch: https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429-1-freif...@adrianschmutzler.de/) at91 ath25 (patchset crashing at Ethernet init: https://patchwork.ozlabs.org/project/openwrt/list/?series=169991) pistachio rb532 samsung uml This is meant as an invitation for those caring about/using these targets to consider updating them; in best case they should receive some testing before a 5.4 stable branch is made (whenever that might be). At least for the 4.14 targets, I expect them to be archived if there is no update until after the next release (or at the latest after the one following it). Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase CMA buffer size from 16 to 32MB
> -Original Message- > From: Linus Lüssing [mailto:l...@simonwunderlich.de] > Sent: Montag, 25. Mai 2020 12:14 > To: m...@adrianschmutzler.de; 'Linus Lüssing' ; > openwrt-devel@lists.openwrt.org > Cc: 'Sven Eckelmann' > Subject: Re: [OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase > CMA buffer size from 16 to 32MB > > On 25/05/2020 11:25, m...@adrianschmutzler.de wrote: > [...] > > Despite, armv7 uses 64 MB ? > > Hm, you're right. Not sure, I wouldn't increase the CMA buffer more as > needed though, as any unused CMA space is basically wasted, it can't be > used for caches etc right now. > > But I can increase it to 64 MB to not divert from armv7 if that's preferred. > As > all layerscape boards usually come with a large amount of RAM, I assume? Unfortunately, I cannot comment on this architecture at all, I just made the observation when looking at it. Maybe somebody else can comment on that. Note that we just removed 4.14 support completely for this target, so you will only have to touch 5.4 now. Best Adrian > > Regards, Linus openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] bcm47xx: remove support for kernel 4.14
We currently support three kernel versions on this target, let's just get rid of the oldest one. Cc: Rafał Miłecki Signed-off-by: Adrian Schmutzler --- target/linux/bcm47xx/config-4.14 | 215 ...-Add-Luxul-XAP1500-XWR1750-WiFi-LEDs.patch | 86 --- ...X-Add-support-for-Netgear-WNR1000-V3.patch | 96 ..._nvram-support-small-0x6000-B-NVRAM-.patch | 24 - ...able-USB-power-on-Netgear-WNDR3400v2.patch | 34 -- .../bcm47xx/patches-4.14/159-cpu_fixes.patch | 510 -- .../patches-4.14/160-kmap_coherent.patch | 78 --- .../209-b44-register-adm-switch.patch | 121 - .../patches-4.14/210-b44_phy_fix.patch| 54 -- .../280-activate_ssb_support_in_usb.patch | 25 - .../patches-4.14/300-fork_cacheflush.patch| 21 - .../patches-4.14/310-no_highpage.patch| 74 --- ...47XX-Devices-database-update-for-4.x.patch | 185 --- .../400-mtd-bcm47xxpart-get-nvram.patch | 34 -- .../patches-4.14/610-pci_ide_fix.patch| 41 -- .../patches-4.14/791-tg3-no-pci-sleep.patch | 17 - ...f-serial-flashes-with-smaller-blocks.patch | 73 --- .../patches-4.14/820-wgt634u-nvram-fix.patch | 304 --- .../830-huawei_e970_support.patch | 101 .../patches-4.14/831-old_gpio_wdt.patch | 360 - ...rites-setting-CardBus-bridge-resourc.patch | 30 -- ...ch-GPIO-portions-to-use-GPIOLIB_IRQC.patch | 233 .../patches-4.14/940-bcm47xx-yenta.patch | 46 -- .../976-ssb_increase_pci_delay.patch | 11 - .../bcm47xx/patches-4.14/999-wl_exports.patch | 22 - 25 files changed, 2795 deletions(-) delete mode 100644 target/linux/bcm47xx/config-4.14 delete mode 100644 target/linux/bcm47xx/patches-4.14/031-MIPS-BCM47XX-Add-Luxul-XAP1500-XWR1750-WiFi-LEDs.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/032-MIPS-BCM47XX-Add-support-for-Netgear-WNR1000-V3.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/033-firmware-bcm47xx_nvram-support-small-0x6000-B-NVRAM-.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/035-v5.1-mips-bcm47xx-Enable-USB-power-on-Netgear-WNDR3400v2.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/159-cpu_fixes.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/160-kmap_coherent.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/209-b44-register-adm-switch.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/210-b44_phy_fix.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/280-activate_ssb_support_in_usb.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/300-fork_cacheflush.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/310-no_highpage.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/320-MIPS-BCM47XX-Devices-database-update-for-4.x.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/400-mtd-bcm47xxpart-get-nvram.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/610-pci_ide_fix.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/791-tg3-no-pci-sleep.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/800-bcma-add-table-of-serial-flashes-with-smaller-blocks.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/820-wgt634u-nvram-fix.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/830-huawei_e970_support.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/831-old_gpio_wdt.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/900-ssb-reject-PCI-writes-setting-CardBus-bridge-resourc.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/901-Revert-bcma-switch-GPIO-portions-to-use-GPIOLIB_IRQC.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/940-bcm47xx-yenta.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/976-ssb_increase_pci_delay.patch delete mode 100644 target/linux/bcm47xx/patches-4.14/999-wl_exports.patch diff --git a/target/linux/bcm47xx/config-4.14 b/target/linux/bcm47xx/config-4.14 deleted file mode 100644 index d26ef6426f..00 --- a/target/linux/bcm47xx/config-4.14 +++ /dev/null @@ -1,215 +0,0 @@ -CONFIG_ADM6996_PHY=y -CONFIG_ARCH_BINFMT_ELF_STATE=y -CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_DISCARD_MEMBLOCK=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -# CONFIG_ARCH_HAS_GCOV_PROFILE_ALL is not set -# CONFIG_ARCH_HAS_SG_CHAIN is not set -# CONFIG_ARCH_HAS_STRICT_KERNEL_RWX is not set -# CONFIG_ARCH_HAS_STRICT_MODULE_RWX is not set -CONFIG_ARCH_HIBERNATION_POSSIBLE=y -CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y -CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y -CONFIG_ARCH_MMAP_RND_BITS_MAX=15 -CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 -# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set -# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set -CONFIG_ARCH_SUPPORTS_UPROBES=y -CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_QUEUED_RWLOCKS=y -CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y -CONFIG_BCM47XX=y
Re: [OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase CMA buffer size from 16 to 32MB
On 25/05/2020 11:25, m...@adrianschmutzler.de wrote: [...] Despite, armv7 uses 64 MB ? Hm, you're right. Not sure, I wouldn't increase the CMA buffer more as needed though, as any unused CMA space is basically wasted, it can't be used for caches etc right now. But I can increase it to 64 MB to not divert from armv7 if that's preferred. As all layerscape boards usually come with a large amount of RAM, I assume? Regards, Linus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC libubox] blobmsg: another attrs iteration fix for blobmsg_check_array_len()
Rafał Miłecki [2020-05-25 10:31:06]:
Hi,
> From: Rafał Miłecki
>
> After more reviews is seems that blobmsg_for_each_attr() should not be
> used when dealing with untrusted data as it reads length from blob data
> itself. It means it can't be used in the blobmsg_check_array_len().
>
> Switch back to using __blobmsg_for_each_attr() BUT pass correct length
> to it. Calculate it by subtracting header length from blob length.
>
> Signed-off-by: Rafał Miłecki
> ---
> blobmsg.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/blobmsg.c b/blobmsg.c
> index 59045e1..2295aaa 100644
> --- a/blobmsg.c
> +++ b/blobmsg.c
> @@ -142,7 +142,8 @@ int blobmsg_check_array_len(const struct blob_attr *attr,
> int type,
> return -1;
> }
>
> - blobmsg_for_each_attr(cur, attr, rem) {
> + rem = blob_len - ((uint8_t *)blobmsg_data(attr) - (uint8_t
> *)blob_data(attr));
looks like blobmsg_data_len()?
> + __blobmsg_for_each_attr(cur, attr, rem) {
> if (type != BLOBMSG_TYPE_UNSPEC && blobmsg_type(cur) != type)
> return -1;
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC libubox] blobmsg: another attrs iteration fix for blobmsg_check_array_len()
Felix Fietkau [2020-05-25 10:51:36]: Hi, > I think your previous fix is completely fine as-is. just FYI Rafał's fix triggered fuzzer CI failure[1], regression, I'm able to reproduce it localy so it's not false positive. So perhaps there's some additional check missing somewhere? $ echo AQQBAAA1JQ== | base64 -d > ./tests/fuzz/corpus/crash-e0f8ecc694d96a09a1fced27b2a0838b670d34a0 $ xxd ./tests/fuzz/corpus/crash-e0f8ecc694d96a09a1fced27b2a0838b670d34a0 : 0104 0001 3525 5% $ gdb --args ./build/tests/fuzz/test-fuzz ./tests/fuzz/corpus/crash-e0f8ecc694d96a09a1fced27b2a0838b670d34a0 Reading symbols from ./build/tests/fuzz/test-fuzz...done. (gdb) r Thread 1 "test-fuzz" received signal SIGSEGV, Segmentation fault. 0x770be2fc in blob_len (attr=0x602100d4) at libubox/blob.h:102 102 return (be32_to_cpu(attr->id_len) & BLOB_ATTR_LEN_MASK) - sizeof(struct blob_attr); (gdb) bt #0 0x770be2fc in blob_len (attr=0x602100d4) at /libubox/blob.h:102 #1 0x770bde65 in blob_raw_len (attr=0x602100d4) at /libubox/blob.h:111 #2 0x770be485 in blob_pad_len (attr=0x602100d4) at /libubox/blob.h:120 #3 0x770be22b in blobmsg_check_array_len (attr=0x602000d0, type=0, blob_len=10) at /libubox/blobmsg.c:145 #4 0x0054f6b6 in fuzz_blobmsg_parse (data=0x602000d0 "\001\004", size=10) at /libubox/tests/fuzz/test-fuzz.c:57 #5 0x0054f3c8 in LLVMFuzzerTestOneInput (input=, size=10) at /libubox/tests/fuzz/test-fuzz.c:104 #6 0x00459fc2 in ExecuteCallback () at /tmp/final/llvm.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:553 #7 0x004448e2 in RunOneTest () at /tmp/final/llvm.src/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:292 #8 0x0044a4af in FuzzerDriver () at /tmp/final/llvm.src/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:775 #9 0x004739f3 in main () at /tmp/final/llvm.src/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19 1. https://gitlab.com/openwrt/project/libubox/-/jobs/565328935 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] netifd: wireless: add support for tracking wifi-vlann sections
This new section allows us to create apvlan settings for hostapd.
Signed-off-by: John Crispin
---
config.c | 42 ++-
scripts/netifd-wireless.sh | 42 ++-
wireless.c | 247 +++--
wireless.h | 23 +++-
4 files changed, 337 insertions(+), 17 deletions(-)
diff --git a/config.c b/config.c
index 843c53f..1bb3737 100644
--- a/config.c
+++ b/config.c
@@ -338,7 +338,7 @@ config_parse_wireless_device(struct uci_section *s)
wireless_device_create(drv, s->e.name, b.head);
}
-static void
+static struct wireless_interface*
config_parse_wireless_interface(struct wireless_device *wdev, struct
uci_section *s)
{
char *name;
@@ -348,7 +348,20 @@ config_parse_wireless_interface(struct wireless_device
*wdev, struct uci_section
blob_buf_init(, 0);
uci_to_blob(, s, wdev->drv->interface.config);
- wireless_interface_create(wdev, b.head, s->anonymous ? name :
s->e.name);
+ return wireless_interface_create(wdev, b.head, s->anonymous ? name :
s->e.name);
+}
+
+static void
+config_parse_wireless_vlan(struct wireless_device *wdev, char *vif, struct
uci_section *s)
+{
+ char *name;
+
+ name = alloca(strlen(s->type) + 16);
+ sprintf(name, "@%s[%d]", s->type, config_section_idx(s));
+
+ blob_buf_init(, 0);
+ uci_to_blob(, s, wdev->drv->vlan.config);
+ wireless_vlan_create(wdev, vif, b.head, s->anonymous ? name :
s->e.name);
}
static void
@@ -378,10 +391,14 @@ config_init_wireless(void)
vlist_for_each_element(_devices, wdev, node) {
wdev->vif_idx = 0;
vlist_update(>interfaces);
+ wdev->vlan_idx = 0;
+ vlist_update(>vlans);
}
uci_foreach_element(_wireless->sections, e) {
struct uci_section *s = uci_to_section(e);
+ struct wireless_interface *vif;
+ struct uci_element *f;
if (strcmp(s->type, "wifi-iface") != 0)
continue;
@@ -396,11 +413,28 @@ config_init_wireless(void)
continue;
}
- config_parse_wireless_interface(wdev, s);
+ vif = config_parse_wireless_interface(wdev, s);
+
+ if (!vif || s->anonymous)
+ continue;
+ uci_foreach_element(_wireless->sections, f) {
+ struct uci_section *s = uci_to_section(f);
+ const char *vif_name;
+
+ if (strcmp(s->type, "wifi-vlan") != 0)
+ continue;
+
+ vif_name = uci_lookup_option_string(uci_ctx, s,
"iface");
+ if (vif_name && strcmp(e->name, vif_name))
+ continue;
+ config_parse_wireless_vlan(wdev, vif->name, s);
+ }
}
- vlist_for_each_element(_devices, wdev, node)
+ vlist_for_each_element(_devices, wdev, node) {
vlist_flush(>interfaces);
+ vlist_flush(>vlans);
+ }
}
int
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index 6bc48c6..41e380f 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -108,12 +108,13 @@ _wdev_wrapper() {
_wdev_notify_init() {
local command="$1"
- local interface="$2"
+ local name="$2"
+ local value="$3"
json_init
json_add_int "command" "$command"
json_add_string "device" "$__netifd_device"
- [ -n "$interface" ] && json_add_string "interface" "$interface"
+ [ -n "$name" -a -n "$value" ] && json_add_string "$name" "$value"
json_add_object "data"
}
@@ -139,7 +140,17 @@ _wireless_add_vif() {
local name="$1"; shift
local ifname="$1"; shift
- _wdev_notify_init $CMD_SET_DATA "$name"
+ _wdev_notify_init $CMD_SET_DATA "interface" "$name"
+ json_add_string "ifname" "$ifname"
+ _wdev_add_variables "$@"
+ _wdev_notify
+}
+
+_wireless_add_vlan() {
+ local name="$1"; shift
+ local ifname="$1"; shift
+
+ _wdev_notify_init $CMD_SET_DATA "vlan" "$name"
json_add_string "ifname" "$ifname"
_wdev_add_variables "$@"
_wdev_notify
@@ -182,6 +193,7 @@ _wireless_set_retry() {
_wdev_wrapper \
wireless_add_vif \
+ wireless_add_vlan \
wireless_set_up \
wireless_set_data \
wireless_add_process \
@@ -306,6 +318,21 @@ for_each_interface() {
json_select ..
}
+for_each_vlan() {
+ local _w_vlans _w_vlan
+
+ json_get_keys _w_vlans vlans
+ json_select vlans
+ for _w_vlan in $_w_vlans; do
+ json_select "$_w_vlan"
+ json_select config
+ "$@" "$_w_vlan"
+ json_select ..
+ json_select ..
+ done
+ json_select ..
+}
+
[OpenWrt-Devel] [PATCH 2/2] netifd: wireless: add support for tracking wifi-station sections
This new section allows us to assign mac specific key/vid settings to a
station.
Signed-off-by: John Crispin
---
config.c | 29
scripts/netifd-wireless.sh | 24 +++
wireless.c | 134 -
wireless.h | 17 -
4 files changed, 200 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index 1bb3737..b1b4bf3 100644
--- a/config.c
+++ b/config.c
@@ -364,6 +364,19 @@ config_parse_wireless_vlan(struct wireless_device *wdev,
char *vif, struct uci_s
wireless_vlan_create(wdev, vif, b.head, s->anonymous ? name :
s->e.name);
}
+static void
+config_parse_wireless_station(struct wireless_device *wdev, char *vif, struct
uci_section *s)
+{
+ char *name;
+
+ name = alloca(strlen(s->type) + 16);
+ sprintf(name, "@%s[%d]", s->type, config_section_idx(s));
+
+ blob_buf_init(, 0);
+ uci_to_blob(, s, wdev->drv->station.config);
+ wireless_station_create(wdev, vif, b.head, s->anonymous ? name :
s->e.name);
+}
+
static void
config_init_wireless(void)
{
@@ -393,6 +406,8 @@ config_init_wireless(void)
vlist_update(>interfaces);
wdev->vlan_idx = 0;
vlist_update(>vlans);
+ wdev->sta_idx = 0;
+ vlist_update(>stations);
}
uci_foreach_element(_wireless->sections, e) {
@@ -429,11 +444,25 @@ config_init_wireless(void)
continue;
config_parse_wireless_vlan(wdev, vif->name, s);
}
+
+ uci_foreach_element(_wireless->sections, f) {
+ struct uci_section *s = uci_to_section(f);
+ const char *vif_name;
+
+ if (strcmp(s->type, "wifi-station") != 0)
+ continue;
+
+ vif_name = uci_lookup_option_string(uci_ctx, s,
"iface");
+ if (vif_name && strcmp(e->name, vif_name))
+ continue;
+ config_parse_wireless_station(wdev, vif->name, s);
+ }
}
vlist_for_each_element(_devices, wdev, node) {
vlist_flush(>interfaces);
vlist_flush(>vlans);
+ vlist_flush(>stations);
}
}
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index 41e380f..d51380d 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -333,6 +333,21 @@ for_each_vlan() {
json_select ..
}
+for_each_station() {
+ local _w_stas _w_sta
+
+ json_get_keys _w_stas stas
+ json_select stas
+ for _w_sta in $_w_stas; do
+ json_select "$_w_sta"
+ json_select config
+ "$@" "$_w_sta"
+ json_select ..
+ json_select ..
+ done
+ json_select ..
+}
+
_wdev_common_device_config() {
config_add_string channel hwmode htmode noscan
}
@@ -345,6 +360,10 @@ _wdev_common_vlan_config() {
config_add_string name vid iface
}
+_wdev_common_station_config() {
+ config_add_string mac key vid iface
+}
+
init_wireless_driver() {
name="$1"; shift
cmd="$1"; shift
@@ -372,6 +391,11 @@ init_wireless_driver() {
eval "drv_$1_init_vlan_config"
json_close_array
+ json_add_array station
+ _wdev_common_station_config
+ eval "drv_$1_init_station_config"
+ json_close_array
+
json_dump
}
;;
diff --git a/wireless.c b/wireless.c
index b0b35a1..efb7992 100644
--- a/wireless.c
+++ b/wireless.c
@@ -82,6 +82,20 @@ static const struct uci_blob_param_list vlan_param = {
.params = vlan_policy,
};
+enum {
+ STA_ATTR_DISABLED,
+ __STA_ATTR_MAX,
+};
+
+static const struct blobmsg_policy sta_policy[__STA_ATTR_MAX] = {
+ [STA_ATTR_DISABLED] = { .name = "disabled", .type = BLOBMSG_TYPE_BOOL },
+};
+
+static const struct uci_blob_param_list station_param = {
+ .n_params = ARRAY_SIZE(sta_policy),
+ .params = sta_policy,
+};
+
static void
wireless_handler_stop(struct wireless_device *wdev)
{
@@ -144,6 +158,7 @@ prepare_config(struct wireless_device *wdev, struct
blob_buf *buf, bool up)
{
struct wireless_interface *vif;
struct wireless_vlan *vlan;
+ struct wireless_station *sta;
void *l, *i, *j, *k;
blob_buf_init(, 0);
@@ -171,6 +186,18 @@ prepare_config(struct wireless_device *wdev, struct
blob_buf *buf, bool up)
blobmsg_close_table(, k);
}
blobmsg_close_table(, j);
+
+ j = blobmsg_open_table(, "stas");
+
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Am 25.05.2020 um 11:22 schrieb Sven Eckelmann:
On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote:
[...]
could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the patch
was later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i did
[...]
This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
Just noticed that there was a copy and paste error in my message. The 5GHz was
an QCA9888 [1,2] and not an QCA4019. Otherwise the _pci error wouldn't have made
any sense.
And I can only say at the moment (remember that this was observer 14 months
ago), that it could be reproduced easily on IPQ40xx with an QCA9888 and the
given config running OpenWrt reboot-9440-g0f89c17b57. The diffconfig (seed) of
the installation was:
CONFIG_TARGET_ipq40xx=y
CONFIG_TARGET_ipq40xx_generic=y
CONFIG_TARGET_ipq40xx_generic_DEVICE_openmesh_a62=y
CONFIG_ATH10K_LEDS=y
CONFIG_PACKAGE_ath10k-firmware-qca4019=y
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct is not set
CONFIG_PACKAGE_ath10k-firmware-qca9888=y
# CONFIG_PACKAGE_ath10k-firmware-qca9888-ct is not set
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
# CONFIG_PACKAGE_kmod-hwmon-core is not set
And it still can with this OpenWrt version. But it doesn't seem to happen with
the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000
commits inbetween. So no idea what changed (just a timing thing or an actual
fix - no idea).
Btw. the wireless config was given in the original mail [2,3]
Kind regards,
Sven
maybe openwrt installs a default trigger which doesnt make sense if
nothing is connected to the cards gpio.
we can also modify the patch to exclude the 9888 from led support. you
just need to remove the led_pin defintion from the hw definition.
this patch is mainly for wireless routers like the netgear r7800, r9000
and some tplink archer models. it also works on mikrotik qca988x cards.
but even if the led_pin is set, it should not trigger any action until a
led trigger is set with sysfs. such configurations should be
architecture specific in any way
Sebastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase CMA buffer size from 16 to 32MB
Hi Linus, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Linus Lüssing > Sent: Montag, 25. Mai 2020 09:40 > To: openwrt-devel@lists.openwrt.org > Cc: Linus Lüssing ; Sven Eckelmann > > Subject: [OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase CMA > buffer size from 16 to 32MB > > From: Linus Lüssing > > 16MB are not enough for ath10k to initialize three 4x4 AC Wave 2 PCIe cards > (168c:0046: Qualcomm Atheros QCA9984 802.11ac Wave 2 Wireless Network > Adapter). > This leads to the following error when trying to initialize the third > one: layerscape is already at kernel 5.4, so please patch this config file. Despite, armv7 uses 64 MB ? Best Adrian > > [ 16.742475] ath10k_pci 0002:01:00.0: pci irq msi oper_irq_mode 2 irq_mode > 0 reset_mode 0 > [ 16.874024] ath10k_pci 0002:01:00.0: Direct firmware load for ath10k/pre- > cal-pci-0002:01:00.0.bin failed with error -2 > [ 16.884784] ath10k_pci 0002:01:00.0: Direct firmware load for ath10k/cal- > pci-0002:01:00.0.bin failed with error -2 > [ 16.895224] ath10k_pci 0002:01:00.0: Direct firmware load for > ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2 > [ 16.905956] ath10k_pci 0002:01:00.0: qca9984/qca9994 hw1.0 target > 0x0100 chip_id 0x sub 168c:cafe > [ 16.915881] ath10k_pci 0002:01:00.0: kconfig debug 0 debugfs 1 tracing 0 > dfs > 1 testmode 1 > [ 16.925422] ath10k_pci 0002:01:00.0: firmware ver 10.4-3.9.0.2-00021 api 5 > features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps > crc32 9626782c > [ 18.169022] ath10k_pci 0002:01:00.0: board_file api 2 bmi_id 0:31 crc32 > cf58c3bc > [ 20.692482] cma: cma_alloc: alloc failed, req-size: 200 pages, ret: -12 > [ 25.882670] ath10k_pci 0002:01:00.0: wmi service ready event not received > [ 25.943121] ath10k_pci 0002:01:00.0: could not init core (-110) > [ 25.949048] ath10k_pci 0002:01:00.0: could not probe fw (-110) > > Fixing this issue by doubling the CMA buffer size from 16 to 32MB. > New values in /proc/meminfo, with three such cards connected: > > root@OpenWrt:/# cat /proc/meminfo | grep -i "cma" > CmaTotal: 32768 kB > CmaFree: 19268 kB > > Interestingly, older Qualcomm AC cards > (Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter) > don't seem to use the Contiguous Memory Allocator and therefore don't > suffer from this issue. > > Signed-off-by: Linus Lüssing > --- > target/linux/layerscape/armv8_64b/config-4.14 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/layerscape/armv8_64b/config-4.14 > b/target/linux/layerscape/armv8_64b/config-4.14 > index c1bd718366..ef1bbadd2b 100644 > --- a/target/linux/layerscape/armv8_64b/config-4.14 > +++ b/target/linux/layerscape/armv8_64b/config-4.14 > @@ -140,7 +140,7 @@ CONFIG_CMA_ALIGNMENT=8 > CONFIG_CMA_AREAS=7 > # CONFIG_CMA_DEBUG is not set > # CONFIG_CMA_DEBUGFS is not set > -CONFIG_CMA_SIZE_MBYTES=16 > +CONFIG_CMA_SIZE_MBYTES=32 > # CONFIG_CMA_SIZE_SEL_MAX is not set > CONFIG_CMA_SIZE_SEL_MBYTES=y > # CONFIG_CMA_SIZE_SEL_MIN is not set > -- > 2.27.0.rc0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote:
[...]
> could somone clarify the state here and why it was dropped?
> the original patch i wrote does exclude the soc chipsets, but the patch
> was later reorganized and some part have been rewritten
> so i'm not sure if it covers the scenario mentioned here, which i did
[...]
> > This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
> > add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
> > firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
Just noticed that there was a copy and paste error in my message. The 5GHz was
an QCA9888 [1,2] and not an QCA4019. Otherwise the _pci error wouldn't have
made
any sense.
And I can only say at the moment (remember that this was observer 14 months
ago), that it could be reproduced easily on IPQ40xx with an QCA9888 and the
given config running OpenWrt reboot-9440-g0f89c17b57. The diffconfig (seed) of
the installation was:
CONFIG_TARGET_ipq40xx=y
CONFIG_TARGET_ipq40xx_generic=y
CONFIG_TARGET_ipq40xx_generic_DEVICE_openmesh_a62=y
CONFIG_ATH10K_LEDS=y
CONFIG_PACKAGE_ath10k-firmware-qca4019=y
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct is not set
CONFIG_PACKAGE_ath10k-firmware-qca9888=y
# CONFIG_PACKAGE_ath10k-firmware-qca9888-ct is not set
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
# CONFIG_PACKAGE_kmod-hwmon-core is not set
And it still can with this OpenWrt version. But it doesn't seem to happen with
the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000
commits inbetween. So no idea what changed (just a timing thing or an actual
fix - no idea).
Btw. the wireless config was given in the original mail [2,3]
Kind regards,
Sven
[1] https://openwrt.org/toh/hwdata/open-mesh/open-mesh_a62
[2] https://patchwork.kernel.org/patch/10723033/#22502191
[3] https://patchwork.kernel.org/patch/10327075/#22502179
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC libubox] blobmsg: another attrs iteration fix for blobmsg_check_array_len()
On 2020-05-25 10:31, Rafał Miłecki wrote: > From: Rafał Miłecki > > After more reviews is seems that blobmsg_for_each_attr() should not be > used when dealing with untrusted data as it reads length from blob data > itself. It means it can't be used in the blobmsg_check_array_len(). > > Switch back to using __blobmsg_for_each_attr() BUT pass correct length > to it. Calculate it by subtracting header length from blob length. This should not be necessary, because the length is validated in the blobmsg_check_attr_len call earlier in the same function. I think your previous fix is completely fine as-is. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC libubox] blobmsg: another attrs iteration fix for blobmsg_check_array_len()
From: Rafał Miłecki
After more reviews is seems that blobmsg_for_each_attr() should not be
used when dealing with untrusted data as it reads length from blob data
itself. It means it can't be used in the blobmsg_check_array_len().
Switch back to using __blobmsg_for_each_attr() BUT pass correct length
to it. Calculate it by subtracting header length from blob length.
Signed-off-by: Rafał Miłecki
---
blobmsg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/blobmsg.c b/blobmsg.c
index 59045e1..2295aaa 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -142,7 +142,8 @@ int blobmsg_check_array_len(const struct blob_attr *attr,
int type,
return -1;
}
- blobmsg_for_each_attr(cur, attr, rem) {
+ rem = blob_len - ((uint8_t *)blobmsg_data(attr) - (uint8_t
*)blob_data(attr));
+ __blobmsg_for_each_attr(cur, attr, rem) {
if (type != BLOBMSG_TYPE_UNSPEC && blobmsg_type(cur) != type)
return -1;
--
2.26.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: always use -minterlink-mips16 if USE_MIPS16
On 2020-05-25 02:19, Eneas U de Queiroz wrote: > Individual packages may turn off MIPS16 ISA individually with > PKG_USE_MIPS16. However, they may link to a library compiled with > MIPS16. In such cases, the -minterlink-mips16 is needed to ensure there > are no direct jumps to code compiled with a different ISA. > > Instead of adding -minterlink-mips16 only when PKG_USE_MIPS16 is on, add > it when global USE_MIPS16 is on. > > Signed-off-by: Eneas U de Queiroz > --- > Tested by compiling all packages in base, packages, routing and > telephony feeds for mips_74kc, with MIPS16 enabled. > > This was discovered while working on lxc fixes > (https://github.com/openwrt/packages/pull/12241), where compilation with > mips16 would fail because of '-fstack-check=specific not implemented for > MIPS16', and it would fail with PKG_USE_MIPS16=0 because of jumping to a > different ISA mode: > > lxc-4.0.2/src/lxc/caps.c:24:(.text+0xa4): unsupported jump between ISA > modes; consider recompiling with interlinking enabled > > In theory this could happen in more places, so set interlinking on > whenever MIPS16 is turned on globally. I think there needs be a way to opt-out of this behavior. The -minterlink-mips16 flag affects the performance and code size of generated code, so libraries that disable MIPS16 for performance reasons and don't depend on other MIPS16 enabled libraries should not be compiled with this flag. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase CMA buffer size from 16 to 32MB
From: Linus Lüssing 16MB are not enough for ath10k to initialize three 4x4 AC Wave 2 PCIe cards (168c:0046: Qualcomm Atheros QCA9984 802.11ac Wave 2 Wireless Network Adapter). This leads to the following error when trying to initialize the third one: [ 16.742475] ath10k_pci 0002:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 16.874024] ath10k_pci 0002:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0002:01:00.0.bin failed with error -2 [ 16.884784] ath10k_pci 0002:01:00.0: Direct firmware load for ath10k/cal-pci-0002:01:00.0.bin failed with error -2 [ 16.895224] ath10k_pci 0002:01:00.0: Direct firmware load for ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2 [ 16.905956] ath10k_pci 0002:01:00.0: qca9984/qca9994 hw1.0 target 0x0100 chip_id 0x sub 168c:cafe [ 16.915881] ath10k_pci 0002:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1 [ 16.925422] ath10k_pci 0002:01:00.0: firmware ver 10.4-3.9.0.2-00021 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 9626782c [ 18.169022] ath10k_pci 0002:01:00.0: board_file api 2 bmi_id 0:31 crc32 cf58c3bc [ 20.692482] cma: cma_alloc: alloc failed, req-size: 200 pages, ret: -12 [ 25.882670] ath10k_pci 0002:01:00.0: wmi service ready event not received [ 25.943121] ath10k_pci 0002:01:00.0: could not init core (-110) [ 25.949048] ath10k_pci 0002:01:00.0: could not probe fw (-110) Fixing this issue by doubling the CMA buffer size from 16 to 32MB. New values in /proc/meminfo, with three such cards connected: root@OpenWrt:/# cat /proc/meminfo | grep -i "cma" CmaTotal: 32768 kB CmaFree: 19268 kB Interestingly, older Qualcomm AC cards (Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter) don't seem to use the Contiguous Memory Allocator and therefore don't suffer from this issue. Signed-off-by: Linus Lüssing --- target/linux/layerscape/armv8_64b/config-4.14 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/layerscape/armv8_64b/config-4.14 b/target/linux/layerscape/armv8_64b/config-4.14 index c1bd718366..ef1bbadd2b 100644 --- a/target/linux/layerscape/armv8_64b/config-4.14 +++ b/target/linux/layerscape/armv8_64b/config-4.14 @@ -140,7 +140,7 @@ CONFIG_CMA_ALIGNMENT=8 CONFIG_CMA_AREAS=7 # CONFIG_CMA_DEBUG is not set # CONFIG_CMA_DEBUGFS is not set -CONFIG_CMA_SIZE_MBYTES=16 +CONFIG_CMA_SIZE_MBYTES=32 # CONFIG_CMA_SIZE_SEL_MAX is not set CONFIG_CMA_SIZE_SEL_MBYTES=y # CONFIG_CMA_SIZE_SEL_MIN is not set -- 2.27.0.rc0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: per-interface MTU settings vs per-route MTU settings?
Hey,
>>
>> There's an ongoing discussion in the ModemManager package in github
>> related to how the MTU may be configured in the network interface
>> based on what the MM bearer object reports:
>> https://github.com/openwrt/packages/issues/11383
>>
>> E.g.:
>>
>> $ ip route show
>> default via 25.225.105.222 dev wwan0 proto static src 25.225.105.221 mtu 1430
>>
>> Looks like the protocol handler implementation for netifd may allow
>> setting the MTU to the routes associated with the network interface,
>> instead of assigning the MTU value to the interface itself. Are both
>> methods completely equivalent? Is there any reason to avoid setting
>> the MTU in the interface when using netifd, or just not implemented
>> yet?
>>
>> Cheers!
>>
>> --
>> Aleksander
>> https://aleksander.es
>
>
>
>
> I'm actually not aware of any method to set the interface MTU via netifd that
> isn't a UCI setting.
>
While running as a protocol handler under netifd, we can do this while
setting up the default route:
proto_add_ipv4_route "0.0.0.0" "0" "${gateway}" "${address}"
"${metric}" "${mtu}"
And the given ${mtu} will be set for the route created.
What we're looking for is a way to setup the MTU for the whole network
interface from within the protocol handler automatically.
--
Aleksander
https://aleksander.es
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
