[PATCH] build: prereq: drop support for Python 3.5

2021-02-15 Thread Andre Heider
The final Python 3.5 release was 3.5.10 in September 2020 [0].
This release series is now End-of-Life (EOL).

The only LTS distribution that still only ships Python 3.5 is Ubuntu 16.04,
which will be EOL in April 2021 [1].

The meson build system bumped their python requirement to 3.6 for the 0.57.0
release. This patch ensures that OpenWrt can update meson while still
relying on the host python.

[0] https://www.python.org/dev/peps/pep-0478/#id4
[1] https://ubuntu.com/about/release-cycle
[2] 
https://mesonbuild.com/Release-notes-for-0-57-0.html#minimum-required-python-version-updated-to-36

Signed-off-by: Andre Heider 
---
 include/prereq-build.mk | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index f88e853b52..88064abf98 100644
--- a/include/prereq-build.mk
+++ b/include/prereq-build.mk
@@ -141,21 +141,19 @@ $(eval $(call SetupHostCommand,perl,Please install Perl 
5.x, \
 
 $(eval $(call CleanupPython2))
 
-$(eval $(call SetupHostCommand,python,Please install Python >= 3.5, \
+$(eval $(call SetupHostCommand,python,Please install Python >= 3.6, \
python3.9 -V 2>&1 | grep 'Python 3', \
python3.8 -V 2>&1 | grep 'Python 3', \
python3.7 -V 2>&1 | grep 'Python 3', \
python3.6 -V 2>&1 | grep 'Python 3', \
-   python3.5 -V 2>&1 | grep 'Python 3', \
-   python3 -V 2>&1 | grep -E 'Python 3\.[5-9]\.?'))
+   python3 -V 2>&1 | grep -E 'Python 3\.[6-9]\.?'))
 
-$(eval $(call SetupHostCommand,python3,Please install Python >= 3.5, \
+$(eval $(call SetupHostCommand,python3,Please install Python >= 3.6, \
python3.9 -V 2>&1 | grep 'Python 3', \
python3.8 -V 2>&1 | grep 'Python 3', \
python3.7 -V 2>&1 | grep 'Python 3', \
python3.6 -V 2>&1 | grep 'Python 3', \
-   python3.5 -V 2>&1 | grep 'Python 3', \
-   python3 -V 2>&1 | grep -E 'Python 3\.[5-9]\.?'))
+   python3 -V 2>&1 | grep -E 'Python 3\.[6-9]\.?'))
 
 $(eval $(call SetupHostCommand,git,Please install Git (git-core) >= 1.7.12.2, \
git --exec-path | xargs -I % -- grep -q -- --recursive %/git-submodule))
-- 
2.30.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: Installation error for libncursesw6

2021-02-15 Thread Brian Norris
On Sun, Feb 14, 2021 at 4:07 PM Ansuel Smith  wrote:
>
> > Collected errors:
> >  * pkg_hash_fetch_best_installation_candidate: Packages for
> > libreadline8 found, but incompatible with the architectures configured
> >  * opkg_install_cmd: Cannot install package libreadline8.
> >  * satisfy_dependencies_for: Cannot satisfy the following dependencies
> > for softethervpn5-libs:
> >  *  libncursesw6
> >  * opkg_install_cmd: Cannot install package softethervpn5-libs.
> > make[2]: *** [package/Makefile:69: package/install] Error 255
> >
> > Multiple packages complain about this... This is from a clean custom build.
> > Think this is caused by the abi changes to buildroot
>
> reverting c92165038217e49075098479704da58a2a3a89bd fix the problem

Thanks for tracking down the regression! This has been bugging me too.

FWIW, I found that the problem seems to be in badly-generated
libncurses ipk files. The 'control' file seems to have lines like
this:

Provides: libncursesw, libncurses, libncursesw

when it should have:

Provides: libncursesw, libncurses, libncursesw6

Brian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


OpenWrt 21.02 branch

2021-02-15 Thread Alexander 'lynxis' Couzens
Hi,

I've created branches for OpenWrt 21.02.
Even there is still a lot of work to be done for the next release
we decided to branch now.
This allow us to stabilize 21.02 and make it ready for release.
Further more patches has been piling up which couldn't merged into
master before the branch for the next release (e.g. linux 5.10).

Best,
lynxis

-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpkyTrPLNH2p.pgp
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] kernel: DSA roaming fix for Marvell Link Street switch series

2021-02-15 Thread Eneas U de Queiroz
On Tue, Feb 2, 2021 at 6:15 AM DENG Qingfang  wrote:
>
> Marvell Link Street switch series cannot perform MAC learning from
> CPU-injected (FROM_CPU) DSA frames, which results in 2 issues.
> - excessive flooding, due to the fact that DSA treats those addresses
> as unknown
> - the risk of stale routes, which can lead to temporary packet loss
>
> Backport those patch series from netdev mailing list, which solve these
> issues by adding and clearing static entries to the switch's FDB.
>
> Add a hack patch to set default VID to 1 in port_fdb_{add,del}. Otherwise
> the static entries will be added to the switch's private FDB if VLAN
> filtering disabled, which will not work.
>
> Link: 
> https://lore.kernel.org/netdev/20210106095136.224739-1-olte...@gmail.com/
> Link: 
> https://lore.kernel.org/netdev/20210116012515.3152-1-tob...@waldekranz.com/
> Link: https://lore.kernel.org/netdev/20210130134334.10243-1-dqf...@gmail.com/
> Ref: https://gitlab.nic.cz/turris/turris-build/-/issues/165
> Signed-off-by: DENG Qingfang 

Tested-by: Eneas U de Queiroz 

I have tested this using WRT3200ACM, and it solves the problem of
clients not able to roam from one AP to the another--my APs are wired,
not using WDS.  Clients would not be able to communicate for 300s
after roaming from one AP to another.  I consider this a critical bug,
so a fix must be included before 2021.02 branches.  I have applied the
patch to 3 APs, and have been using them for days without any real
issue--I'm not considering the 'ATU member violation' messages
reported earlier an issue, as they do appear to be harmless.

Cheers,

Eneas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 2/2] mediatek: add support for Ubiquiti UniFi 6 LR

2021-02-15 Thread David Bauer
Hardware


MediaTek MT7622
512MB DDR3 RAM
64M SPI-NOR Flash (Winbond W25Q512JV)
MediaTek MT7622 802.11bgn 4T4R WMAC
MediaTek MT7915 802.11ax 4T4R
Marvell AQR1112 100/1000/2500 NBase-T PHY
Holtek HT32F52241 LED controller
Reset Switch

UART


CPU UART0 at the pinout next to the Holtek MCU.

Pinout (first pin next to SoC / MCU)

0 3V3
1 RX
2 TX
3 GND

Settings are 115200 8N1.

Opening the case


Opening the case is not a nice task, as itis glued together. Insert a
flat knife between the front and back casing below the ethernet port.
Open up a gap this way and insert a flat scredriver, remove the knife.

Work your way around the casing by applying force to seperate the front
and back casing. This losens the glue and opens the plastic clips. Be
gentle, as these clips are very cheap and break quickly.

Installation


1. Connect to the booted device at 192.168.1.20 using username/password
   "ubnt".

2. Transfer the OpenWrt sysupgrade image to the device using SCP.

3. Check the mtd partition number for bs / kernel0 / kernel1

   $ cat /proc/mtd

4. Set the bootselect flag to boot from kernel0

   $ dd if=/dev/zero bs=1 count=1 of=/dev/mtdblock6

5. Write the OpenWrt sysupgrade image to both kernel0 as well as kernel1

   $ dd if=openwrt.bin of=/dev/mtdblock8
   $ dd if=openwrt.bin of=/dev/mtdblock9

6. Reboot the device. It should boot into OpenWrt.

Signed-off-by: David Bauer 
---
 .../lib/preinit/05_set_preinit_iface  |  10 +-
 .../dts/mediatek/mt7622-ubnt-unifi-6-lr.dts   | 327 ++
 target/linux/mediatek/image/mt7622.mk |   9 +
 .../mt7622/base-files/etc/board.d/02_network  |   3 +
 target/linux/mediatek/mt7622/config-5.4   |   6 +-
 .../patches-5.4/1020-spi-nor-w25q512jv.patch  |  25 ++
 6 files changed, 378 insertions(+), 2 deletions(-)
 create mode 100644 
target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
 create mode 100644 
target/linux/mediatek/patches-5.4/1020-spi-nor-w25q512jv.patch

diff --git a/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface 
b/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface
index f39e8aee8d..3ac856d1c4 100644
--- a/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface
+++ b/target/linux/mediatek/base-files/lib/preinit/05_set_preinit_iface
@@ -1,6 +1,14 @@
 set_preinit_iface() {
ip link set eth0 up
-   ifname=lan1
+
+   case $(board_name) in
+   ubnt,unifi-6-lr)
+   ifname=eth0
+   ;;
+   *)
+   ifname=lan1
+   ;;
+   esac
 }
 
 boot_hook_add preinit_main set_preinit_iface
diff --git 
a/target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
 
b/target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
new file mode 100644
index 00..1f410b1d47
--- /dev/null
+++ 
b/target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7622-ubnt-unifi-6-lr.dts
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+#include 
+#include 
+#include 
+
+#include "mt7622.dtsi"
+#include "mt6380.dtsi"
+
+/ {
+   model = "Ubiquiti UniFi 6 LR";
+   compatible = "ubnt,unifi-6-lr", "mediatek,mt7622";
+
+   aliases {
+   led-boot = _blue;
+   led-failsafe = _blue;
+   led-running = _blue;
+   led-upgrade = _blue;
+   label-mac-device = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   bootargs = "earlycon=uart8250,mmio32,0x11002000 swiotlb=512 
console=ttyS0,115200n8";
+   };
+
+   cpus {
+   cpu@0 {
+   proc-supply = <_vcpu_reg>;
+   sram-supply = <_vm_reg>;
+   };
+
+   cpu@1 {
+   proc-supply = <_vcpu_reg>;
+   sram-supply = <_vm_reg>;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   linux,code = ;
+   gpios = < 62 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   memory {
+   reg = <0 0x4000 0 0x3f00>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator-3p3v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
+ {
+

[PATCH 1/2] mediatek: add Ubiquiti LED driver

2021-02-15 Thread David Bauer
Add a driver for controlling the RGB LED via Ubiquitis own "LEDBAR" LED
controller based on the Holtek HT32F52241 MCU.

This driver is initially used by the Ubiquiti UniFi 6 LR, however
judging from FCC pictures the MCU is also found on the U6-Mesh as well
as the U6-Extender.

Signed-off-by: David Bauer 
---
 .../files-5.4/drivers/leds/leds-ubnt-ledbar.c | 210 ++
 target/linux/mediatek/mt7622/config-5.4   |   1 +
 target/linux/mediatek/mt7623/config-5.4   |   1 +
 target/linux/mediatek/mt7629/config-5.4   |   1 +
 .../patches-5.4/1021-ubnt-ledbar-driver.patch |  29 +++
 5 files changed, 242 insertions(+)
 create mode 100644 
target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c
 create mode 100644 
target/linux/mediatek/patches-5.4/1021-ubnt-ledbar-driver.patch

diff --git a/target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c 
b/target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c
new file mode 100644
index 00..1f50038b8c
--- /dev/null
+++ b/target/linux/mediatek/files-5.4/drivers/leds/leds-ubnt-ledbar.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * Driver for the Ubiquiti RGB LED controller (LEDBAR).
+ * This Controller is based on a Holtek HT32F52241 and connected
+ * via I2C.
+ *
+ *  - The Controller needs an enable signal set to high when
+ *performing a transaction. On the U6-LR, this is located
+ *at Pin 18 (R6902)
+ *
+ *  - The Pin is also printed when calling the "usetled" function
+ *contained in the ubntapp bootloader application.
+ */
+
+#define UBNT_LEDBAR_MAX_BRIGHTNESS 0xff
+
+#define UBNT_LEDBAR_TRANSACTION_LENGTH 8
+#define UBNT_LEDBAR_TRANSACTION_SUCCESS0xaa
+
+#define UBNT_LEDBAR_TRANSACTION_BLUE_IDX   2
+#define UBNT_LEDBAR_TRANSACTION_GREEN_IDX  3
+#define UBNT_LEDBAR_TRANSACTION_RED_IDX4
+
+struct ubnt_ledbar {
+   struct mutex lock;
+   struct i2c_client *client;
+   struct led_classdev led_red;
+   struct led_classdev led_green;
+   struct led_classdev led_blue;
+   struct gpio_desc *enable_gpio;
+};
+
+static int ubnt_ledbar_perform_transaction(struct ubnt_ledbar *ledbar,
+  char *transaction)
+{
+   int ret;
+   int i;
+
+   for (i = 0; i < UBNT_LEDBAR_TRANSACTION_LENGTH; i++)
+   i2c_smbus_write_byte(ledbar->client, transaction[i]);
+
+   return i2c_smbus_read_byte(ledbar->client);
+}
+
+static int ubnt_ledbar_apply_state(struct ubnt_ledbar *ledbar)
+{
+   char setup_msg[UBNT_LEDBAR_TRANSACTION_LENGTH] = {0x40, 0x10, 0x00, 
0x00,
+ 0x00, 0x00, 0x00, 
0x11};
+   char led_msg[UBNT_LEDBAR_TRANSACTION_LENGTH] = {0x40, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x01, 0x00};
+   char i2c_response;
+   int ret = 0;
+
+   mutex_lock(>lock);
+
+   led_msg[UBNT_LEDBAR_TRANSACTION_BLUE_IDX] = ledbar->led_blue.brightness;
+   led_msg[UBNT_LEDBAR_TRANSACTION_GREEN_IDX] = 
ledbar->led_green.brightness;
+   led_msg[UBNT_LEDBAR_TRANSACTION_RED_IDX] = ledbar->led_red.brightness;
+
+   gpiod_set_raw_value(ledbar->enable_gpio, 1);
+
+   msleep(10);
+
+   i2c_response = ubnt_ledbar_perform_transaction(ledbar, setup_msg);
+   if (i2c_response != UBNT_LEDBAR_TRANSACTION_SUCCESS) {
+   dev_err(>client->dev, "Error initializing LED 
transaction: %02x\n", ret);
+   ret = -EINVAL;
+   goto out_gpio;
+   }
+
+   i2c_response = ubnt_ledbar_perform_transaction(ledbar, led_msg);
+   if (i2c_response != UBNT_LEDBAR_TRANSACTION_SUCCESS) {
+   dev_err(>client->dev, "Failed LED transaction: %02x\n", 
ret);
+   ret = -EINVAL;
+   goto out_gpio;
+   }
+
+   msleep(10);
+out_gpio:
+   gpiod_set_raw_value(ledbar->enable_gpio, 0);
+
+   mutex_unlock(>lock);
+
+   return ret;
+}
+
+#define UBNT_LEDBAR_CONTROL_RGBS(name) \
+static int ubnt_ledbar_set_##name##_brightness(struct led_classdev *led_cdev,\
+   enum led_brightness value)  \
+{  \
+   struct ubnt_ledbar *ledbar = \
+   container_of(led_cdev, struct ubnt_ledbar, led_##name); 
\
+   int ret; \
+   led_cdev->brightness = value; \
+   ret = ubnt_ledbar_apply_state(ledbar); \
+   return ret; \
+}
+
+UBNT_LEDBAR_CONTROL_RGBS(red);
+UBNT_LEDBAR_CONTROL_RGBS(green);
+UBNT_LEDBAR_CONTROL_RGBS(blue);
+
+
+static int ubnt_ledbar_init_led(struct device_node *np, struct ubnt_ledbar 
*ledbar,
+   struct led_classdev *led_cdev)
+{
+   struct led_init_data init_data = {};
+   int ret;
+

Re: [PATCH 4/4] mac80211: add AX support

2021-02-15 Thread Philip Prindeville
AX support. Cool.

Is there any UCI defaults stuff that needs to be touched for first boot and 
discovery?

Comments:



> On Feb 15, 2021, at 3:19 AM, John Crispin  wrote:
> 
> Signed-off-by: John Crispin 
> ---
> .../files/lib/netifd/wireless/mac80211.sh | 193 +-
> .../mac80211/files/lib/wifi/mac80211.sh   |  19 +-
> 2 files changed, 195 insertions(+), 17 deletions(-)
> 
> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> index 92c56afd24..b717770d5e 100644
> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> @@ -56,6 +56,13 @@ drv_mac80211_init_device_config() {
>   short_gi_40 \
>   max_amsdu \
>   dsss_cck_40
> + config_add_int \
> + he_su_beamformer \
> + he_su_beamformee \
> + he_mu_beamformer \
> + he_bss_color \
> + he_spr_sr_control \
> + he_spr_non_srg_obss_pd_max_offset
> }
> 
> drv_mac80211_init_iface_config() {
> @@ -69,6 +76,7 @@ drv_mac80211_init_iface_config() {
>   config_add_int max_listen_int
>   config_add_int dtim_period
>   config_add_int start_disabled
> + config_add_int he_twt_required he_spr_sr_control
> 
>   # mesh
>   config_add_string mesh_id
> @@ -96,6 +104,77 @@ mac80211_add_capabilities() {
>   export -n -- "$__var=$__out"
> }
> 
> +mac80211_add_he_capabilities() {
> + local __out= oifs
> +
> + oifs="$IFS"
> + IFS=:

Can't we just do:

local IFS=:

and get rid of oifs, etc.


% cat /tmp/foo
#!/bin/sh

func() {
  local IFS="b"

  echo "IFS=$IFS"
}

IFS="a"

echo "IFS=$IFS"
func

echo "IFS=$IFS"


% /tmp/foo
IFS=a
IFS=b
IFS=a
%




> + for capab in "$@"; do
> + set -- $capab
> + [ "$(($4))" -gt 0 ] || continue
> + [ "$(((0x$2) & $3))" -gt 0 ] || continue
> + append base_cfg "$1=1" "$N"
> + done
> + IFS="$oifs"
> +}
> +
> +mac80211_get_seg0() {
> + local ht_mode="$1"
> + local seg0=0
> +
> + case "$ht_mode" in
> + 40)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$(( ($channel / 4) % 2 ))" in
> + 1) seg0=$(($channel - 2));;
> + 0) seg0=$(($channel + 2));;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$(( ($channel / 4) % 2 ))" in
> + 1) seg0=$(($channel + 2));;
> + 0) seg0=$(($channel - 2));;
> + esac
> + fi
> + ;;
> + 80)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$(( ($channel / 4) % 4 ))" in
> + 0) seg0=$(($channel + 6));;
> + 1) seg0=$(($channel + 2));;
> + 2) seg0=$(($channel - 2));;
> + 3) seg0=$(($channel - 6));;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$(( ($channel / 4) % 4 ))" in
> + 1) seg0=$(($channel + 6));;
> + 2) seg0=$(($channel + 2));;
> + 3) seg0=$(($channel - 2));;
> + 0) seg0=$(($channel - 6));;
> + esac
> + fi
> + ;;
> + 160)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$channel" in
> + 1|5|9|13|17|21|25|29) seg0=15;;
> + 33|37|41|45|49|53|57|61) seg0=47;;
> + 65|69|73|77|81|85|89|93) seg0=79;;
> + 97|101|105|109|113|117|121|125) 
> seg0=111;;
> + 129|133|137|141|145|149|153|157) 
> seg0=143;;
> + 161|165|169|173|177|181|185|189) 
> seg0=175;;
> + 193|197|201|205|209|213|217|221) 
> seg0=207;;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$channel" in
> + 36|40|44|48|52|56|60|64) seg0=50;;
> + 100|104|108|112|116|120|124|128) 
> seg0=114;;
> + esac
> + fi
> + ;;
> + esac
> + printf "$seg0"
> +}
> +
> 

Re: [PATCH v3] fakeroot: fix to work with glibc 2.33

2021-02-15 Thread Ilya Lipnitskiy
Bummer, thanks for the fix - submitted
https://salsa.debian.org/clint/fakeroot/-/merge_requests/11

Ilya

On Mon, Feb 15, 2021 at 11:01 AM Felix Fietkau  wrote:
>
>
> On 2021-02-14 05:41, Ilya Lipnitskiy wrote:
> > The following commit removed _STAT_VER definitions from glibc:
> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
> >
> > That subsequently broke fakeroot:
> > https://bugs.archlinux.org/task/69572
> > https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
> > https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966
> >
> > Make the patch based on Jan Pazdziora's suggestion from here:
> > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/
> >
> > Add wrappers for newly exported symbols in glibc.
> >
> > Apply patch from Debian to fix warnings in fts_read and fts_children:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676428
> > https://sources.debian.org/patches/fakeroot/1.25.3-1.1/eglibc-fts-without-LFS/
> >
> > Fix __xmknod{,at} dev pointer argument. Switch default to assume * and
> > not the absence of *. On glibc 2.33+, there is no definition for these
> > functions in header files, so the compile test doesn't work. But, we
> > can default to using the pointer (as is the case with newer glibc), and
> > use the header file on older platforms to fail the test and use no pointer.
> >
> > Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
> > Also tested by building various .ipks and examining the tar contents, to
> > ensure that the owner uid/gid was 0/0.
> >
> > Signed-off-by: Ilya Lipnitskiy 
> > ---
> >  .../300-glibc-2.33-compatibility.patch| 145 ++
> >  1 file changed, 145 insertions(+)
> >  create mode 100644 
> > tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> >
> > diff --git a/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch 
> > b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> > new file mode 100644
> > index 00..a460cace0c
> > --- /dev/null
> > +++ b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> > @@ -0,0 +1,145 @@
> > +--- a/libfakeroot.c
> >  b/libfakeroot.c
> > +@@ -1358,6 +1368,54 @@ int renameat(int olddir_fd, const char *
> > + #endif /* HAVE_FSTATAT */
> > +
> > +
> > ++#if defined(__GLIBC__) && __GLIBC_PREREQ(2,33)
> Turns out combining those two into a single #if was not such a good
> idea. It breaks on macOS, because __GLIBC_PREREQ is evaluated though
> __GLIBC__ is not defined.
> Splitting it into two #if lines makes things work again.
> The change to the __xmknod dev pointer argument checks also broke.
> I've pushed a fix for both, please check it and submit it upstream.
>
> Thanks,
>
> - Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH v3] fakeroot: fix to work with glibc 2.33

2021-02-15 Thread Felix Fietkau


On 2021-02-14 05:41, Ilya Lipnitskiy wrote:
> The following commit removed _STAT_VER definitions from glibc:
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
> 
> That subsequently broke fakeroot:
> https://bugs.archlinux.org/task/69572
> https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
> https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966
> 
> Make the patch based on Jan Pazdziora's suggestion from here:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/
> 
> Add wrappers for newly exported symbols in glibc.
> 
> Apply patch from Debian to fix warnings in fts_read and fts_children:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676428
> https://sources.debian.org/patches/fakeroot/1.25.3-1.1/eglibc-fts-without-LFS/
> 
> Fix __xmknod{,at} dev pointer argument. Switch default to assume * and
> not the absence of *. On glibc 2.33+, there is no definition for these
> functions in header files, so the compile test doesn't work. But, we
> can default to using the pointer (as is the case with newer glibc), and
> use the header file on older platforms to fail the test and use no pointer.
> 
> Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
> Also tested by building various .ipks and examining the tar contents, to
> ensure that the owner uid/gid was 0/0.
> 
> Signed-off-by: Ilya Lipnitskiy 
> ---
>  .../300-glibc-2.33-compatibility.patch| 145 ++
>  1 file changed, 145 insertions(+)
>  create mode 100644 tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> 
> diff --git a/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch 
> b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> new file mode 100644
> index 00..a460cace0c
> --- /dev/null
> +++ b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> @@ -0,0 +1,145 @@
> +--- a/libfakeroot.c
>  b/libfakeroot.c
> +@@ -1358,6 +1368,54 @@ int renameat(int olddir_fd, const char *
> + #endif /* HAVE_FSTATAT */
> + 
> + 
> ++#if defined(__GLIBC__) && __GLIBC_PREREQ(2,33)
Turns out combining those two into a single #if was not such a good
idea. It breaks on macOS, because __GLIBC_PREREQ is evaluated though
__GLIBC__ is not defined.
Splitting it into two #if lines makes things work again.
The change to the __xmknod dev pointer argument checks also broke.
I've pushed a fix for both, please check it and submit it upstream.

Thanks,

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 4/4] mac80211: add AX support

2021-02-15 Thread Felix Fietkau


On 2021-02-15 11:19, John Crispin wrote:
> Signed-off-by: John Crispin 
> ---
>  .../files/lib/netifd/wireless/mac80211.sh | 193 +-
>  .../mac80211/files/lib/wifi/mac80211.sh   |  19 +-
>  2 files changed, 195 insertions(+), 17 deletions(-)
> 
> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> index 92c56afd24..b717770d5e 100644
> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> @@ -56,6 +56,13 @@ drv_mac80211_init_device_config() {
[...]
> +mac80211_get_seg0() {
> + local ht_mode="$1"
> + local seg0=0
> +
> + case "$ht_mode" in
> + 40)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$(( ($channel / 4) % 2 ))" in
> + 1) seg0=$(($channel - 2));;
> + 0) seg0=$(($channel + 2));;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$(( ($channel / 4) % 2 ))" in
> + 1) seg0=$(($channel + 2));;
> + 0) seg0=$(($channel - 2));;
> + esac
> + fi
> + ;;
> + 80)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$(( ($channel / 4) % 4 ))" in
> + 0) seg0=$(($channel + 6));;
> + 1) seg0=$(($channel + 2));;
> + 2) seg0=$(($channel - 2));;
> + 3) seg0=$(($channel - 6));;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$(( ($channel / 4) % 4 ))" in
> + 1) seg0=$(($channel + 6));;
> + 2) seg0=$(($channel + 2));;
> + 3) seg0=$(($channel - 2));;
> + 0) seg0=$(($channel - 6));;
> + esac
> + fi
> + ;;
> + 160)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$channel" in
> + 1|5|9|13|17|21|25|29) seg0=15;;
> + 33|37|41|45|49|53|57|61) seg0=47;;
> + 65|69|73|77|81|85|89|93) seg0=79;;
> + 97|101|105|109|113|117|121|125) 
> seg0=111;;
> + 129|133|137|141|145|149|153|157) 
> seg0=143;;
> + 161|165|169|173|177|181|185|189) 
> seg0=175;;
> + 193|197|201|205|209|213|217|221) 
> seg0=207;;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$channel" in
> + 36|40|44|48|52|56|60|64) seg0=50;;
> + 100|104|108|112|116|120|124|128) 
> seg0=114;;
> + esac
> + fi
> + ;;
> + esac
> + printf "$seg0"
> +}
This function duplicates the seg0 that's already done for VHT+HE and
simply adds some extra conditions for 6 GHz. Those extra conditions
should be folded into the existing code.

> +
>  mac80211_hostapd_setup_base() {
>   local phy="$1"
>  
> @@ -333,20 +412,105 @@ mac80211_hostapd_setup_base() {
>   # 802.11ax
>   enable_ax=0
>   case "$htmode" in
> - HE*) enable_ax=1 ;;
> + HE20)   enable_ax=1
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + append base_cfg "op_class=131" "$N"
> + fi
> + ;;
> + HE40)
> + enable_ax=1
> + idx="$(mac80211_get_seg0 "40")"
> + if [ $freq -ge 5180 ] && [ $freq != 5935 ]; then
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; 
> then
> + append base_cfg "op_class=132" "$N"
> + fi
> + append base_cfg "he_oper_chwidth=0" "$N"
> + append base_cfg 
> "he_oper_centr_freq_seg0_idx=$idx" "$N"
> + fi
> + ;;
> + HE80)
> + enable_ax=1
> + idx="$(mac80211_get_seg0 "80")"
> + if [ $freq != 5935 ]; then
> + if [ $freq -gt 

RE: Commit e95b1b23f1b6951318d6c6caf3803fb933f71a6c kernel: bump 5.4 to 5.4.97 kills mt7621/dir860l

2021-02-15 Thread Adrian Schmutzler
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Russell Senior
> Sent: Montag, 15. Februar 2021 02:08
> To: Stijn Segers 
> Cc: John Audia ; openwrt-devel  de...@lists.openwrt.org>; Adrian Schmutzler 
> Subject: Re: Commit e95b1b23f1b6951318d6c6caf3803fb933f71a6c kernel:
> bump 5.4 to 5.4.97 kills mt7621/dir860l
> 
> I rev'd up to 15785-g0fde111702 today (without my revert) and the freeze
is
> gone, the dir860l-b1 boots normally again.
> 
> I don't know why, but not knowing is made more tolerable by it working.

Maybe something in 5.4.98, which is included in the newer test?

Couldn't identify anything  on a quick look, though.

> 
> --
> Russell Senior
> russ...@personaltelco.net
> 
> On Sun, Feb 14, 2021 at 4:51 AM Russell Senior 
> wrote:
> >
> > Looks like this linux-stable commit might be the guilty party:
> >
> >   e57d70c59bb7f6835ee47eb633e44efce4ab51b9
> >
> > Reverting it in openwrt seems to fix the freezes.
> >
> > On Sun, Feb 14, 2021 at 4:07 AM Russell Senior
> >  wrote:
> > >
> > > I am stepping though the kernel patches (intially 10 at a whack)
> > > between 5.4.96 and 5.4.97 to see if I can find what broke it.
> > >
> > > On Sat, Feb 13, 2021 at 2:51 PM Stijn Segers

> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Op zaterdag 13 februari 2021 om 18u05 schreef Adrian Schmutzler
> > > > :
> > > > >>  [1.176208] mt7621-pci 1e14.pcie: Parsing DT failed
> > > > >
> > > > > Is this introduced with the commit or has it been there before
> > > > > on this device?
> > > >
> > > >
> > > > This has been around for quite a while on MT7621. See also this
> > > > comment on the ramips 5.10 PR of the MT7621 PCI driver author as
> > > > to why this can be safely ignored:
> > > >
> > > > https://github.com/openwrt/openwrt/pull/3693#issuecomment-
> 75043648
> > > > 3
> > > >
> > > > I am seeing this message on all three MT7621 devices I have in
> > > > production with master builds, every single time. I thought it was
> > > > an issue as well until Sergio pointed out it really isn't.
> > > >
> > > > Cheers
> > > >
> > > > Stijn
> > > >
> > > > >
> > > > > Best
> > > > >
> > > > > Adrian
> > > > > ___
> > > > > 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


[PATCH 4/4] mac80211: add AX support

2021-02-15 Thread John Crispin
Signed-off-by: John Crispin 
---
 .../files/lib/netifd/wireless/mac80211.sh | 193 +-
 .../mac80211/files/lib/wifi/mac80211.sh   |  19 +-
 2 files changed, 195 insertions(+), 17 deletions(-)

diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 92c56afd24..b717770d5e 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -56,6 +56,13 @@ drv_mac80211_init_device_config() {
short_gi_40 \
max_amsdu \
dsss_cck_40
+   config_add_int \
+   he_su_beamformer \
+   he_su_beamformee \
+   he_mu_beamformer \
+   he_bss_color \
+   he_spr_sr_control \
+   he_spr_non_srg_obss_pd_max_offset
 }
 
 drv_mac80211_init_iface_config() {
@@ -69,6 +76,7 @@ drv_mac80211_init_iface_config() {
config_add_int max_listen_int
config_add_int dtim_period
config_add_int start_disabled
+   config_add_int he_twt_required he_spr_sr_control
 
# mesh
config_add_string mesh_id
@@ -96,6 +104,77 @@ mac80211_add_capabilities() {
export -n -- "$__var=$__out"
 }
 
+mac80211_add_he_capabilities() {
+   local __out= oifs
+
+   oifs="$IFS"
+   IFS=:
+   for capab in "$@"; do
+   set -- $capab
+   [ "$(($4))" -gt 0 ] || continue
+   [ "$(((0x$2) & $3))" -gt 0 ] || continue
+   append base_cfg "$1=1" "$N"
+   done
+   IFS="$oifs"
+}
+
+mac80211_get_seg0() {
+   local ht_mode="$1"
+   local seg0=0
+
+   case "$ht_mode" in
+   40)
+   if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
+   case "$(( ($channel / 4) % 2 ))" in
+   1) seg0=$(($channel - 2));;
+   0) seg0=$(($channel + 2));;
+   esac
+   elif [ $freq != 5935 ]; then
+   case "$(( ($channel / 4) % 2 ))" in
+   1) seg0=$(($channel + 2));;
+   0) seg0=$(($channel - 2));;
+   esac
+   fi
+   ;;
+   80)
+   if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
+   case "$(( ($channel / 4) % 4 ))" in
+   0) seg0=$(($channel + 6));;
+   1) seg0=$(($channel + 2));;
+   2) seg0=$(($channel - 2));;
+   3) seg0=$(($channel - 6));;
+   esac
+   elif [ $freq != 5935 ]; then
+   case "$(( ($channel / 4) % 4 ))" in
+   1) seg0=$(($channel + 6));;
+   2) seg0=$(($channel + 2));;
+   3) seg0=$(($channel - 2));;
+   0) seg0=$(($channel - 6));;
+   esac
+   fi
+   ;;
+   160)
+   if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
+   case "$channel" in
+   1|5|9|13|17|21|25|29) seg0=15;;
+   33|37|41|45|49|53|57|61) seg0=47;;
+   65|69|73|77|81|85|89|93) seg0=79;;
+   97|101|105|109|113|117|121|125) 
seg0=111;;
+   129|133|137|141|145|149|153|157) 
seg0=143;;
+   161|165|169|173|177|181|185|189) 
seg0=175;;
+   193|197|201|205|209|213|217|221) 
seg0=207;;
+   esac
+   elif [ $freq != 5935 ]; then
+   case "$channel" in
+   36|40|44|48|52|56|60|64) seg0=50;;
+   100|104|108|112|116|120|124|128) 
seg0=114;;
+   esac
+   fi
+   ;;
+   esac
+   printf "$seg0"
+}
+
 mac80211_hostapd_setup_base() {
local phy="$1"
 
@@ -333,20 +412,105 @@ mac80211_hostapd_setup_base() {
# 802.11ax
enable_ax=0
case "$htmode" in
-   HE*) enable_ax=1 ;;
+   HE20)   enable_ax=1
+   if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
+   append base_cfg "op_class=131" "$N"
+   fi
+   ;;
+   

[PATCH 2/4] hostapd: add additional radius options

2021-02-15 Thread John Crispin
- add functionality to configure RADIUS NAS-Id and Operator-Name
- sdd functionality to configure RADIUS accounting interval
- enable RADIUS "Chargeable User Identity"

Signed-off-by: John Crispin 
---
 .../network/services/hostapd/files/hostapd.sh  | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index fb9629170c..1ded08a6f6 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -335,6 +335,9 @@ hostapd_common_add_bss_config() {
config_add_array hostapd_bss_options
 
config_add_int rts_threshold
+   config_add_boolean request_cui
+   config_add_array radius_auth_req_attr
+   config_add_array radius_acct_req_attr
 }
 
 hostapd_set_vlan_file() {
@@ -462,6 +465,14 @@ append_airtime_sta_weight() {
[ -n "$1" ] && append bss_conf "airtime_sta_weight=$1" "$N"
 }
 
+append_radius_acct_req_attr() {
+   [ -n "$1" ] && append bss_conf "radius_acct_req_attr=$1" "$N"
+}
+
+append_radius_auth_req_attr() {
+   [ -n "$1" ] && append bss_conf "radius_auth_req_attr=$1" "$N"
+}
+
 hostapd_set_bss_options() {
local var="$1"
local phy="$2"
@@ -551,6 +562,7 @@ hostapd_set_bss_options() {
append bss_conf 
"acct_server_shared_secret=$acct_secret" "$N"
[ -n "$acct_interval" ] && \
append bss_conf 
"radius_acct_interim_interval=$acct_interval" "$N"
+   json_for_each_item append_radius_acct_req_attr 
radius_acct_req_attr
}
 
case "$auth_type" in
@@ -605,7 +617,7 @@ hostapd_set_bss_options() {
auth_server auth_secret auth_port \
dae_client dae_secret dae_port \
ownip radius_client_addr \
-   eap_reauth_period
+   eap_reauth_period request_cui
 
# radius can provide VLAN ID for clients
vlan_possible=1
@@ -617,7 +629,7 @@ hostapd_set_bss_options() {
 
set_default auth_port 1812
set_default dae_port 3799
-
+   set_default request_cui 0
 
append bss_conf "auth_server_addr=$auth_server" "$N"
append bss_conf "auth_server_port=$auth_port" "$N"
@@ -636,6 +648,8 @@ hostapd_set_bss_options() {
append bss_conf "ieee8021x=1" "$N"
 
[ "$eapol_version" -ge "1" -a "$eapol_version" -le "2" 
] && append bss_conf "eapol_version=$eapol_version" "$N"
+   [ "$request_cui" -gt 0 ] && append bss_conf 
"radius_request_cui=$request_cui" "$N"
+   json_for_each_item append_radius_auth_req_attr 
radius_auth_req_attr
;;
wep)
local wep_keyidx=0
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 1/4] hostapd: add rts_threshold support

2021-02-15 Thread John Crispin
Signed-off-by: John Crispin 
---
 package/network/services/hostapd/files/hostapd.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 45a49b8faa..fb9629170c 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -333,6 +333,8 @@ hostapd_common_add_bss_config() {
config_add_boolean multicast_to_unicast per_sta_vif
 
config_add_array hostapd_bss_options
+
+   config_add_int rts_threshold
 }
 
 hostapd_set_vlan_file() {
@@ -482,7 +484,7 @@ hostapd_set_bss_options() {
bss_load_update_period chan_util_avg_period sae_require_mfp \
multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key 
skip_inactivity_poll \
airtime_bss_weight airtime_bss_limit airtime_sta_weight \
-   multicast_to_unicast per_sta_vif
+   multicast_to_unicast per_sta_vif rts_threshold
 
set_default isolate 0
set_default maxassoc 0
@@ -503,6 +505,7 @@ hostapd_set_bss_options() {
set_default multi_ap 0
set_default airtime_bss_weight 0
set_default airtime_bss_limit 0
+   set_default rts_threshold -1
 
append bss_conf "ctrl_interface=/var/run/hostapd"
if [ "$isolate" -gt 0 ]; then
@@ -529,6 +532,7 @@ hostapd_set_bss_options() {
append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
append bss_conf "utf8_ssid=$utf8_ssid" "$N"
append bss_conf "multi_ap=$multi_ap" "$N"
+   append bss_conf "rts_threshold=$rts_threshold" "$N"
 
[ "$tdls_prohibit" -gt 0 ] && append bss_conf 
"tdls_prohibit=$tdls_prohibit" "$N"
 
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH 3/4] hostapd: add HE support

2021-02-15 Thread John Crispin
Signed-off-by: John Crispin 
---
 .../network/services/hostapd/files/hostapd.sh | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 1ded08a6f6..3842aa2b34 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -105,6 +105,8 @@ hostapd_common_add_device_config() {
 
config_add_int airtime_mode
 
+   config_add_boolean multiple_bssid rnr_beacon he_co_locate ema
+
hostapd_add_log_config
 }
 
@@ -115,7 +117,8 @@ hostapd_prepare_device_config() {
local base_cfg=
 
json_get_vars country country_ie beacon_int:100 dtim_period:2 doth 
require_mode legacy_rates \
-   acs_chan_bias local_pwr_constraint spectrum_mgmt_required 
airtime_mode cell_density
+   acs_chan_bias local_pwr_constraint spectrum_mgmt_required 
airtime_mode cell_density \
+   multiple_bssid he_co_locate rnr_beacon ema
 
hostapd_set_log_options base_cfg
 
@@ -125,6 +128,10 @@ hostapd_prepare_device_config() {
set_default legacy_rates 0
set_default airtime_mode 0
set_default cell_density 0
+   set_default multiple_bssid 0
+   set_default rnr_beacon 0
+   set_default he_co_locate 0
+   set_default ema 0
 
[ -n "$country" ] && {
append base_cfg "country_code=$country" "$N"
@@ -211,6 +218,10 @@ hostapd_prepare_device_config() {
append base_cfg "beacon_int=$beacon_int" "$N"
append base_cfg "dtim_period=$dtim_period" "$N"
[ "$airtime_mode" -gt 0 ] && append base_cfg 
"airtime_mode=$airtime_mode" "$N"
+   [ "$multiple_bssid" -gt 0 ] && append base_cfg 
"multiple_bssid=$multiple_bssid" "$N"
+   [ "$rnr_beacon" -gt 0 ] && append base_cfg "rnr_beacon=$rnr_beacon" "$N"
+   [ "$ema" -gt 0 ] && append base_cfg "ema=$ema" "$N"
+   [ "$he_co_locate" -gt 0 ] && append base_cfg 
"he_co_locate=$he_co_locate" "$N"
 
json_get_values opts hostapd_options
for val in $opts; do
@@ -1097,9 +1108,9 @@ wpa_supplicant_set_fixed_freq() {
VHT*) append network_data "vht=1" "$N$T";;
esac
case "$htmode" in
-   VHT80) append network_data "max_oper_chwidth=1" "$N$T";;
-   VHT160) append network_data "max_oper_chwidth=2" "$N$T";;
-   VHT20|VHT40) append network_data "max_oper_chwidth=0" "$N$T";;
+   VHT80|HE80) append network_data "max_oper_chwidth=1" "$N$T";;
+   VHT160|HE160) append network_data "max_oper_chwidth=2" "$N$T";;
+   VHT20|HE20|VHT40|HE40) append network_data "max_oper_chwidth=0" 
"$N$T";;
*) append network_data "disable_vht=1" "$N$T";;
esac
 }
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: New layerscape/aarch64 board

2021-02-15 Thread Michael Walle

Hi Mathew,

Am 2021-02-15 01:28, schrieb Mathew McBride:

On Sat, Feb 13, 2021, at 2:13 AM, Michael Walle wrote:


Hi,

I am looking into how to bring openwrt support for my board
(Kontron sl28) upstream. The board has upstream support in
both vanilla linux (since 5.8) and vanilla u-boot. Someone
in IRC told me there will be a new release based on 5.10 after
the 21.02 branch is created. So that would be a nice fit.
I'd have thought the board will fit it linux/layerscape but that
is the vanilla kernel with all the NXP lsdk patches on top of it,
which my board doesn't need and frankly speaking I don't want. The
same is true for the uboot-layerscape package. Thats the LSDK
version.



I/we (Traverse) also have layerscape boards that run OpenWrt.


I've seen that.


When the layerscape target was first introduced (~2017), most of the
drivers for these SoCs were not in mainline linux yet.

Since then, the situation has changed, the newer SoCs (e.g
DPAA2/LS1088/LS2088) are very much complete (and in some ways, better)
in >=5.10 and the others are not far behind.

I understand there are some edge cases, such as the DPAA1
(LS1043/LS1046) Ethernet drivers in mainline were a 'clean' rewrite of
NXP/Freescale's long standing 'Netcomm' driver  and have different
performance and features to mainline.

I would put forward the following options:

1. For future OpenWrt releases with kernel >=5.10, stop using LSDK
patches, or only pick the required patchset for SoCs not in upstream
(e.g any new Layerscape SoCs that are introduced)

I suspect the size of the NXP LSDK patchset will decrease signifcantly
when rebased onto >=5.10 so this problem may solve itself.


From what I can tell they just exported the patches of their LSDK
kernel regardless if they are needed or not. For example, there are
patches for the LS1028A and its integrated switch, although it is not
supported according to the README in openwrt. So really, I presume NXP
took the simple way and just export all their patches regardless if
they are really needed or not.

One might argue, that is actually a good thing, because that way it
is also easy to support other SoCs. But yeah..

Anyway, for my board I really don't like to use the LSDK kernel.


2. Introduce a generic 'armv8' target for systems that have 'block
storage' (SATA/MMC/NVMe), targetting U-Boot distroboot and ARM
EBBR(EFI), which would look a lot like the existing x86 target.


That sounds exactly what I had in mind. Both distroboot and EFI
boot is supported on my board.


I did have a go myself at introducing an 'armserver' target for EFI
boot a while ago, this was before x86-64 EFI support was introduced.

There were suggestions that it should go into 'armvirt', though the
existing armvirt/32 target may not share the same goals.


I'd presume that armvirt has a rather limited set of actual
hardware drivers, in contrast to a generic armv8 board which would
need all kind of hardware drivers for its supported boards.

Since I'm new to openwrt, is there a rule which drivers are compiled
into the kernel and which are not? Could we make the generic arm64
board use modules as much as possible?


Boards that boot from flash (ubifs) or have special requirements (such
as bundling the RCW/ATF) could continue using the individual targets.


Right, I don't see a need to actually cover the board startup for the
layerscape SoC and assume there will be a functional bootloader and
block storage device. I mean, I don't think there will be memory and
flash constrained boards which actually use these SoCs. And I guess
this is also true for EFI (or distroboot) capable arm64 boards.

-michael

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel