[PATCH] ath79: add Zyxel EMG2926-Q10A

2022-01-20 Thread Alex Henrie
The Zyxel EMG2926-Q10A is 99% the Zyxel NBG6716, but the bootloader
expects a different product name when flashing over TFTP. Also, the
EMG2926-Q10A always has 128 MiB of NAND flash whereas the NBG6716
reportedly can have either 128 MiB or 256 MiB.

Signed-off-by: Alex Henrie 
---
See https://github.com/openwrt/openwrt/pull/4536
---
 .../etc/hotplug.d/ieee80211/00-wifi-migration |  1 +
 .../ath79/dts/qca9558_zyxel_emg2926_q10a.dts  |  8 ++
 target/linux/ath79/image/nand.mk  | 26 +++
 .../nand/base-files/etc/board.d/02_network|  1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  1 +
 .../etc/hotplug.d/ieee80211/10-fix-wifi-mac   |  1 +
 .../base-files/lib/preinit/10_fix_eth_mac.sh  |  1 +
 7 files changed, 39 insertions(+)
 create mode 100644 target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts

diff --git 
a/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration 
b/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration
index d2df0533fe..35e7c4452c 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration
+++ b/target/linux/ath79/base-files/etc/hotplug.d/ieee80211/00-wifi-migration
@@ -16,6 +16,7 @@ migrate_wifi_path() {
case "$board" in
tplink,archer-c7-v1|\
tplink,archer-c7-v2|\
+   zyxel,emg2926-q10a|\
zyxel,nbg6716)
path="pci:00/:00:00.0"
WIFI_PATH_CHANGED=1
diff --git a/target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts 
b/target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts
new file mode 100644
index 00..c00109a5b4
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_zyxel_emg2926_q10a.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "qca9558_zyxel_nbg6716.dts"
+
+/ {
+   compatible = "zyxel,emg2926-q10a", "zyxel,nbg6716", "qca,qca9558";
+   model = "ZyXEL EMG2926-Q10A";
+};
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index d31aba1abc..27a63fdf7e 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -289,6 +289,32 @@ define Device/netgear_wndr4500-v3
 endef
 TARGET_DEVICES += netgear_wndr4500-v3
 
+define Device/zyxel_emg2926_q10a
+  SOC := qca9558
+  DEVICE_VENDOR := ZyXEL
+  DEVICE_MODEL := EMG2926-Q10A
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \
+   ath10k-firmware-qca988x-ct
+  RAS_BOARD := AAVK-EMG2926Q10A
+  RAS_ROOTFS_SIZE := 29696k
+  RAS_VERSION := "OpenWrt Linux-$(LINUX_VERSION)"
+  KERNEL_SIZE := 4096k
+  BLOCKSIZE := 128k
+  PAGESIZE := 2048
+  LOADER_TYPE := bin
+  KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none | \
+   zyxel-buildkerneljffs | check-size 4096k
+  IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
+  IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to (BLOCKSIZE) | \
+   sysupgrade-tar rootfs=@ | append-metadata
+  IMAGE/sysupgrade-4M-Kernel.bin/squashfs := append-kernel | \
+   pad-to (KERNEL_SIZE) | append-ubi | pad-to 263192576 | gzip
+  IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi | 
\
+   zyxel-factory
+  UBINIZE_OPTS := -E 5
+endef
+TARGET_DEVICES += zyxel_emg2926_q10a
+
 define Device/zyxel_nbg6716
   SOC := qca9558
   DEVICE_VENDOR := ZyXEL
diff --git a/target/linux/ath79/nand/base-files/etc/board.d/02_network 
b/target/linux/ath79/nand/base-files/etc/board.d/02_network
index 76cdab18f8..98aa27f5f2 100644
--- a/target/linux/ath79/nand/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/nand/base-files/etc/board.d/02_network
@@ -42,6 +42,7 @@ ath79_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1"
;;
+   zyxel,emg2926-q10a|\
zyxel,nbg6716)
ucidef_add_switch "switch0" \
"0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan" 
"6@eth1"
diff --git 
a/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 03e225ddde..b9a51c6588 100644
--- 
a/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ 
b/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -26,6 +26,7 @@ case "$FIRMWARE" in
netgear,r6100)
caldata_extract "caldata" 0x5000 0x844
;;
+   zyxel,emg2926-q10a|\
zyxel,nbg6716)
caldata_extract "art" 0x5000 0x844
ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii u-boot-env 
ethaddr) 1)
diff --git 
a/target/linux/ath79/nand/base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac 

[iwinfo v2 PATCH 1/2] iwinfo: add support for indoor only chan restriction

2022-01-20 Thread Ansuel Smith
Some countries permit a specific channel to be used only indoors.
Introduce a new restriction_flags entry to declare different restrition
of a specific channel.

Signed-off-by: Ansuel Smith 
---
v2:
- Fix spelling mistake
- Fix wrong define

 include/iwinfo.h |  4 
 iwinfo_nl80211.c | 14 ++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/iwinfo.h b/include/iwinfo.h
index 8469ee7..9832803 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -61,6 +61,9 @@
 #define IWINFO_FREQ_NO_160MHZ  (1 << 5)
 #define IWINFO_FREQ_NO_2160MHZ (1 << 6)
 
+#define IWINFO_FREQ_NO_IR  (1 << 0)
+#define IWINFO_FREQ_NO_OUTDOOR (1 << 1)
+
 extern const char *IWINFO_CIPHER_NAMES[IWINFO_CIPHER_COUNT];
 extern const char *IWINFO_KMGMT_NAMES[IWINFO_KMGMT_COUNT];
 extern const char *IWINFO_AUTH_NAMES[IWINFO_AUTH_COUNT];
@@ -168,6 +171,7 @@ struct iwinfo_freqlist_entry {
uint8_t channel;
uint32_t mhz;
uint8_t restricted;
+   uint32_t restricted_flags;
uint32_t flags;
 };
 
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index c4b0ee2..57f820a 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -2911,10 +2911,16 @@ static int nl80211_get_freqlist_cb(struct nl_msg *msg, 
void *arg)
e->mhz = 
nla_get_u32(freqs[NL80211_FREQUENCY_ATTR_FREQ]);
e->channel = 
nl80211_freq2channel(e->mhz);
 
-   e->restricted = (
-   
freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
-   
!freqs[NL80211_FREQUENCY_ATTR_RADAR]
-   ) ? 1 : 0;
+   e->restricted = 
(freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
+
!freqs[NL80211_FREQUENCY_ATTR_RADAR]) ||
+
freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY];
+
+   if (freqs[NL80211_FREQUENCY_ATTR_NO_IR] 
&&
+   
!freqs[NL80211_FREQUENCY_ATTR_RADAR])
+   e->restricted_flags |= 
IWINFO_FREQ_NO_IR;
+
+   if 
(freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY])
+   e->restricted_flags |= 
IWINFO_FREQ_NO_OUTDOOR;
 
if 
(freqs[NL80211_FREQUENCY_ATTR_NO_HT40_MINUS])
e->flags |= 
IWINFO_FREQ_NO_HT40MINUS;
-- 
2.33.1


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


[rpcd v2 PATCH 2/2] rpcd: iwinfo: export no_outdoor restriction

2022-01-20 Thread Ansuel Smith
A channel can declare restriction where it should be used only indoors.
Export this restriction in the channel data.

Signed-off-by: Ansuel Smith 
---
 iwinfo.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/iwinfo.c b/iwinfo.c
index ba4fc1e..85860e6 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -723,6 +723,9 @@ rpc_iwinfo_freqlist(struct ubus_context *ctx, struct 
ubus_object *obj,
blobmsg_add_u32(, "mhz", f->mhz);
blobmsg_add_u8(, "restricted", f->restricted);
 
+   blobmsg_add_bool(, "no_outdoor", 
f->restricted_flags &
+IWINFO_FREQ_NO_OUTDOOR);
+
if (ch > -1)
blobmsg_add_u8(, "active", f->channel == 
ch);
 
-- 
2.32.0


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


Re: Switch issues and CI to GitHub

2022-01-20 Thread Michael Richardson

Paul Spooren  wrote:
>> "Codeberg e.V. is a registered non-profit association based in Berlin,
>> Germany" So, this makes me feel better.

> I’ll write them an email asking for their long term ideas of
> maintaining Gitea. Just because is a “e.V.” and in Germany doesn’t make
> it super sustainable, trustworthy or anything.

Agreed, but at least it might have a governance model that does not depend
upon three guys doing it only their spare time as a lark.
(And then getting bored or married or having childen.)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Update buildbots (was: Re: Switch issues and CI to GitHub)

2022-01-20 Thread Etienne Champetier
Hi Petr & Jow

Le jeu. 20 janv. 2022 à 09:10, Paul Spooren  a écrit :
>
> Hi Etienne,
>
> >>
> >> Currently we’re facing an issue[1] from our heterogeneous buildbot 
> >> setup[2] that partly uses outdated runners missing packages installed host 
> >> packages, causing them to upload broken SDKs at random.
> >
> > My understanding is that buildbot runner are docker containers now so
> > we are 1 "docker pull" away from fixing this
>
> I agree, however someone needs to do that and also do it in the future.

Any chance you can update the buildbots docker images ?
(I see only you 2 listed as admins here: https://openwrt.org/infrastructure)

Best
Etienne

> We could also automate it[1], but from what I remember people didn’t like the 
> idea.
>
> [1]: https://github.com/containrrr/watchtower
>
> Paul

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


RE: [PATCH v2] kernel/5.10: remove CONFIG_DEVTMPFS{, _MOUNT} from kconfigs

2022-01-20 Thread Adrian Schmutzler
Hi,

just a nitpick: Commit title prefix should be "kernel: 5.10: ...".

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rui Salvaterra
> Sent: Sonntag, 16. Januar 2022 20:46
> To: openwrt-devel@lists.openwrt.org
> Cc: dan...@makrotopia.org; Rui Salvaterra 
> Subject: [PATCH v2] kernel/5.10: remove CONFIG_DEVTMPFS{, _MOUNT}
> from kconfigs
> 
> They are required for container support, but are handled in
Config-kernel.in.
> 
> Signed-off-by: Rui Salvaterra 
> ---
> v2: keep both ksyms (disabled) in the generic kconfig.
> 
>  target/linux/archs38/config-5.10  | 1 -
>  target/linux/layerscape/armv7/config-5.10 | 2 --
>  target/linux/layerscape/armv8_64b/config-5.10 | 2 --
>  target/linux/mediatek/mt7622/config-5.10  | 2 --
>  target/linux/oxnas/config-5.10| 2 --
>  target/linux/rockchip/armv8/config-5.10   | 2 --
>  6 files changed, 11 deletions(-)
> 
> diff --git a/target/linux/archs38/config-5.10
b/target/linux/archs38/config-
> 5.10
> index 5ba3877a64..b082a47331 100644
> --- a/target/linux/archs38/config-5.10
> +++ b/target/linux/archs38/config-5.10
> @@ -84,7 +84,6 @@ CONFIG_CRYPTO_RNG=y
>  CONFIG_CRYPTO_RNG2=y
>  CONFIG_CRYPTO_RNG_DEFAULT=y
>  CONFIG_CRYPTO_SHA256=y
> -CONFIG_DEVTMPFS=y
>  CONFIG_DMADEVICES=y
>  CONFIG_DMA_DIRECT_REMAP=y
>  CONFIG_DMA_ENGINE=y
> diff --git a/target/linux/layerscape/armv7/config-5.10
> b/target/linux/layerscape/armv7/config-5.10
> index 0ec201030f..dd97d67cba 100644
> --- a/target/linux/layerscape/armv7/config-5.10
> +++ b/target/linux/layerscape/armv7/config-5.10
> @@ -170,8 +170,6 @@ CONFIG_DETECT_HUNG_TASK=y  #
> CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set  #
> CONFIG_DEVFREQ_GOV_USERSPACE is not set  #
> CONFIG_DEVFREQ_THERMAL is not set -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y  CONFIG_DMADEVICES=y
> CONFIG_DMA_CMA=y  CONFIG_DMA_ENGINE=y diff --git
> a/target/linux/layerscape/armv8_64b/config-5.10
> b/target/linux/layerscape/armv8_64b/config-5.10
> index aa4be18f05..03c85a5aef 100644
> --- a/target/linux/layerscape/armv8_64b/config-5.10
> +++ b/target/linux/layerscape/armv8_64b/config-5.10
> @@ -204,8 +204,6 @@ CONFIG_DECOMPRESS_LZMA=y
> CONFIG_DECOMPRESS_LZO=y  CONFIG_DECOMPRESS_XZ=y
> CONFIG_DETECT_HUNG_TASK=y -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y  CONFIG_DIMLIB=y
> CONFIG_DMADEVICES=y  CONFIG_DMATEST=y diff --git
> a/target/linux/mediatek/mt7622/config-5.10
> b/target/linux/mediatek/mt7622/config-5.10
> index da1b283f70..946cab7738 100644
> --- a/target/linux/mediatek/mt7622/config-5.10
> +++ b/target/linux/mediatek/mt7622/config-5.10
> @@ -134,8 +134,6 @@ CONFIG_CRYPTO_SHA256=y
> CONFIG_CRYPTO_ZSTD=y  CONFIG_DCACHE_WORD_ACCESS=y
> CONFIG_DEBUG_MISC=y -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y  CONFIG_DIMLIB=y
> CONFIG_DMADEVICES=y  CONFIG_DMATEST=y diff --git
> a/target/linux/oxnas/config-5.10 b/target/linux/oxnas/config-5.10 index
> b0e4789d1e..93fbf5386d 100644
> --- a/target/linux/oxnas/config-5.10
> +++ b/target/linux/oxnas/config-5.10
> @@ -117,8 +117,6 @@ CONFIG_DECOMPRESS_LZ4=y
> CONFIG_DECOMPRESS_LZMA=y  CONFIG_DECOMPRESS_LZO=y
> CONFIG_DECOMPRESS_XZ=y -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y  CONFIG_DMA_CMA=y
> CONFIG_DMA_REMAP=y  CONFIG_DNOTIFY=y diff --git
> a/target/linux/rockchip/armv8/config-5.10
> b/target/linux/rockchip/armv8/config-5.10
> index 9769bab72d..1063489dc6 100644
> --- a/target/linux/rockchip/armv8/config-5.10
> +++ b/target/linux/rockchip/armv8/config-5.10
> @@ -167,8 +167,6 @@ CONFIG_DEVFREQ_GOV_USERSPACE=y  #
> CONFIG_DEVFREQ_THERMAL is not set  CONFIG_DEVMEM=y  #
> CONFIG_DEVPORT is not set -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y  CONFIG_DMADEVICES=y
> CONFIG_DMA_CMA=y  CONFIG_DMA_DIRECT_REMAP=y
> --
> 2.34.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


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


Re: [PATCH 2/2] iproute2: add support for link set

2022-01-20 Thread Rui Salvaterra
Hi again,

On Thu, 20 Jan 2022 at 15:56, Rui Salvaterra  wrote:
>
> Nice, but we'll need to do the same for BusyBox's ip applet. Let's not
> force everyone who needs multi-CPU DSA to install iproute2's ip just
> for this case. ;)

Just to clarify, I'll take care of the BusyBox side of things, don't
worry about it (and it's optional functionality, anyway).

Cheers,
Rui

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


Re: [PATCH 2/2] iproute2: add support for link set

2022-01-20 Thread Rui Salvaterra
Hi, Ansuel,

On Thu, 20 Jan 2022 at 15:11, Ansuel Smith  wrote:
>
> Add support for link set useful to set CPU port for dsa drivers.
>
> Signed-off-by: Ansuel Smith 
> ---
>  ...-iplink_allow_to_change_iplink_value.patch | 94 +++
>  1 file changed, 94 insertions(+)
>  create mode 100644 
> package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
>
> diff --git 
> a/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
>  
> b/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
> new file mode 100644
> index 00..1a8bad9119
> --- /dev/null
> +++ 
> b/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
> @@ -0,0 +1,94 @@
> +From:   Marek Behún 
> +Subject: [PATCH RFC iproute2-next] iplink: allow to change iplink value
> +Date:   Sat, 24 Aug 2019 04:42:51 +0200
> +
> +Allow to change the interface to which a given interface is linked to.
> +This is useful in the case of multi-CPU port DSA, for changing the CPU
> +port of a given user port.
> +
> +Signed-off-by: Marek Behún 
> +Cc: David Ahern 
> +Cc: Stephen Hemminger 
> +Signed-off-by: Ansuel Smith 
> +---
> + ip/iplink.c   | 16 +---
> + man/man8/ip-link.8.in |  7 +++
> + 2 files changed, 12 insertions(+), 11 deletions(-)
> +
> +diff --git a/ip/iplink.c b/ip/iplink.c
> +index 212a0885..d52c0aaf 100644
> +--- a/ip/iplink.c
>  b/ip/iplink.c
> +@@ -579,7 +579,6 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> + {
> +   char *name = NULL;
> +   char *dev = NULL;
> +-  char *link = NULL;
> +   int ret, len;
> +   char abuf[32];
> +   int qlen = -1;
> +@@ -590,6 +589,7 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> +   int numrxqueues = -1;
> +   int link_netnsid = -1;
> +   int index = 0;
> ++  int link = -1;
> +   int group = -1;
> +   int addr_len = 0;
> +
> +@@ -620,7 +620,10 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> +   invarg("Invalid \"index\" value", *argv);
> +   } else if (matches(*argv, "link") == 0) {
> +   NEXT_ARG();
> +-  link = *argv;
> ++  link = ll_name_to_index(*argv);
> ++  if (!link)
> ++  return nodev(*argv);
> ++  addattr32(>n, sizeof(*req), IFLA_LINK, link);
> +   } else if (matches(*argv, "address") == 0) {
> +   NEXT_ARG();
> +   addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
> +@@ -1004,15 +1007,6 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> +   exit(-1);
> +   }
> +
> +-  if (link) {
> +-  int ifindex;
> +-
> +-  ifindex = ll_name_to_index(link);
> +-  if (!ifindex)
> +-  return nodev(link);
> +-  addattr32(>n, sizeof(*req), IFLA_LINK, ifindex);
> +-  }
> +-
> +   req->i.ifi_index = index;
> +   }
> +
> +diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> +index a8ae72d2..800aed05 100644
> +--- a/man/man8/ip-link.8.in
>  b/man/man8/ip-link.8.in
> +@@ -149,6 +149,9 @@ ip-link \- network device configuration
> + .br
> + .RB "[ " nomaster " ]"
> + .br
> ++.RB "[ " link
> ++.IR DEVICE " ]"
> ++.br
> + .RB "[ " vrf
> + .IR NAME " ]"
> + .br
> +@@ -2131,6 +2134,10 @@ set master device of the device (enslave device).
> + .BI nomaster
> + unset master device of the device (release device).
> +
> ++.TP
> ++.BI link " DEVICE"
> ++set device to which this device is linked to.
> ++
> + .TP
> + .BI addrgenmode " eui64|none|stable_secret|random"
> + set the IPv6 address generation mode
> +--
> +2.21.0
> +
> +
> --
> 2.30.2.windows.1
>

Nice, but we'll need to do the same for BusyBox's ip applet. Let's not
force everyone who needs multi-CPU DSA to install iproute2's ip just
for this case. ;)

Cheers,
Rui

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


[PATCH 2/2] iproute2: add support for link set

2022-01-20 Thread Ansuel Smith
Add support for link set useful to set CPU port for dsa drivers.

Signed-off-by: Ansuel Smith 
---
 ...-iplink_allow_to_change_iplink_value.patch | 94 +++
 1 file changed, 94 insertions(+)
 create mode 100644 
package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch

diff --git 
a/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
 
b/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
new file mode 100644
index 00..1a8bad9119
--- /dev/null
+++ 
b/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
@@ -0,0 +1,94 @@
+From:   Marek Behún 
+Subject: [PATCH RFC iproute2-next] iplink: allow to change iplink value
+Date:   Sat, 24 Aug 2019 04:42:51 +0200
+
+Allow to change the interface to which a given interface is linked to.
+This is useful in the case of multi-CPU port DSA, for changing the CPU
+port of a given user port.
+
+Signed-off-by: Marek Behún 
+Cc: David Ahern 
+Cc: Stephen Hemminger 
+Signed-off-by: Ansuel Smith 
+---
+ ip/iplink.c   | 16 +---
+ man/man8/ip-link.8.in |  7 +++
+ 2 files changed, 12 insertions(+), 11 deletions(-)
+
+diff --git a/ip/iplink.c b/ip/iplink.c
+index 212a0885..d52c0aaf 100644
+--- a/ip/iplink.c
 b/ip/iplink.c
+@@ -579,7 +579,6 @@ int iplink_parse(int argc, char **argv, struct iplink_req 
*req, char **type)
+ {
+   char *name = NULL;
+   char *dev = NULL;
+-  char *link = NULL;
+   int ret, len;
+   char abuf[32];
+   int qlen = -1;
+@@ -590,6 +589,7 @@ int iplink_parse(int argc, char **argv, struct iplink_req 
*req, char **type)
+   int numrxqueues = -1;
+   int link_netnsid = -1;
+   int index = 0;
++  int link = -1;
+   int group = -1;
+   int addr_len = 0;
+ 
+@@ -620,7 +620,10 @@ int iplink_parse(int argc, char **argv, struct iplink_req 
*req, char **type)
+   invarg("Invalid \"index\" value", *argv);
+   } else if (matches(*argv, "link") == 0) {
+   NEXT_ARG();
+-  link = *argv;
++  link = ll_name_to_index(*argv);
++  if (!link)
++  return nodev(*argv);
++  addattr32(>n, sizeof(*req), IFLA_LINK, link);
+   } else if (matches(*argv, "address") == 0) {
+   NEXT_ARG();
+   addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
+@@ -1004,15 +1007,6 @@ int iplink_parse(int argc, char **argv, struct 
iplink_req *req, char **type)
+   exit(-1);
+   }
+ 
+-  if (link) {
+-  int ifindex;
+-
+-  ifindex = ll_name_to_index(link);
+-  if (!ifindex)
+-  return nodev(link);
+-  addattr32(>n, sizeof(*req), IFLA_LINK, ifindex);
+-  }
+-
+   req->i.ifi_index = index;
+   }
+ 
+diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
+index a8ae72d2..800aed05 100644
+--- a/man/man8/ip-link.8.in
 b/man/man8/ip-link.8.in
+@@ -149,6 +149,9 @@ ip-link \- network device configuration
+ .br
+ .RB "[ " nomaster " ]"
+ .br
++.RB "[ " link
++.IR DEVICE " ]"
++.br
+ .RB "[ " vrf
+ .IR NAME " ]"
+ .br
+@@ -2131,6 +2134,10 @@ set master device of the device (enslave device).
+ .BI nomaster
+ unset master device of the device (release device).
+ 
++.TP
++.BI link " DEVICE"
++set device to which this device is linked to.
++
+ .TP
+ .BI addrgenmode " eui64|none|stable_secret|random"
+ set the IPv6 address generation mode
+-- 
+2.21.0
+
+
-- 
2.30.2.windows.1


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


[PATCH 1/2] linux: introduce multi-cpu dsa patch

2022-01-20 Thread Ansuel Smith
Add support for multi-cpu dsa. This is a reworked version of the RFC patch
proposed some time ago. By default the cpus are selected in a round-robin
way and the command 'ip link set PORT link CPU_PORT' can be used to change
the used cpu port at runtime.
A specific function port_change_cpu_port to correctly setup the port on
cpu change request.

Signed-off-by: Ansuel Smith 
---
 ...net-dsa-allow_for_multiple_CPU_ports.patch | 159 ++
 ..._ndo_for_setting_the_iflink_property.patch |  88 ++
 ..._netlink_for_changing_ports_CPU_port.patch |  89 ++
 ...clude-net-add-dsa_cpu_ports-function.patch |  34 
 4 files changed, 370 insertions(+)
 create mode 100644 
target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
 create mode 100644 
target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_iflink_property.patch
 create mode 100644 
target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_netlink_for_changing_ports_CPU_port.patch
 create mode 100644 
target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch

diff --git 
a/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
 
b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
new file mode 100644
index 00..9c3a9e77e2
--- /dev/null
+++ 
b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
@@ -0,0 +1,159 @@
+From:   Marek Behún 
+Subject: [PATCH RFC net-next 1/3] net: dsa: allow for multiple CPU ports
+Date:   Sat, 24 Aug 2019 04:42:48 +0200
+
+Allow for multiple CPU ports in a DSA switch tree. By default assign the
+CPU ports to user ports in a round robin way, ie. if there are two CPU
+ports connected to eth0 and eth1, and five user ports (lan1..lan5),
+assign them as:
+  lan1 <-> eth0
+  lan2 <-> eth1
+  lan3 <-> eth0
+  lan4 <-> eth1
+  lan5 <-> eth0
+
+Signed-off-by: Marek Behún 
+Signed-off-by: Ansuel Smith 
+---
+ include/net/dsa.h |  5 +--
+ net/dsa/dsa2.c| 84 +++
+ 2 files changed, 58 insertions(+), 31 deletions(-)
+
+--- a/net/dsa/dsa2.c
 b/net/dsa/dsa2.c
+@@ -211,36 +211,46 @@ static bool dsa_tree_setup_routing_table
+   return complete;
+ }
+ 
+-static struct dsa_port *dsa_tree_find_first_cpu(struct dsa_switch_tree *dst)
++static int dsa_tree_setup_default_cpus(struct dsa_switch_tree *dst)
+ {
+-  struct dsa_port *dp;
+-
++  struct dsa_port *cpu_dp, *dp, *first_cpu_dp = NULL, *last_cpu_dp = NULL;
++  
++  /* Find first and last CPU port */
+   list_for_each_entry(dp, >ports, list)
+-  if (dsa_port_is_cpu(dp))
+-  return dp;
+-
+-  return NULL;
+-}
++  if (dsa_port_is_cpu(dp)) {
++  if (first_cpu_dp == NULL)
++  first_cpu_dp = dp;
+ 
+-static int dsa_tree_setup_default_cpu(struct dsa_switch_tree *dst)
+-{
+-  struct dsa_port *cpu_dp, *dp;
++  last_cpu_dp = dp;
++  }
+ 
+-  cpu_dp = dsa_tree_find_first_cpu(dst);
+-  if (!cpu_dp) {
++  if (first_cpu_dp == NULL) {
+   pr_err("DSA: tree %d has no CPU port\n", dst->index);
+   return -EINVAL;
+   }
+ 
+-  /* Assign the default CPU port to all ports of the fabric */
++  cpu_dp = first_cpu_dp;
++
++  /* Assign the CPU ports in round-robbin way to all ports of the fabric 
*/
+   list_for_each_entry(dp, >ports, list)
+-  if (dsa_port_is_user(dp) || dsa_port_is_dsa(dp))
++  if (dsa_port_is_user(dp) || dsa_port_is_dsa(dp)) {
+   dp->cpu_dp = cpu_dp;
+ 
++  if (cpu_dp == last_cpu_dp)
++  cpu_dp = first_cpu_dp;
++  else
++  while((cpu_dp = list_next_entry(cpu_dp, list)) 
!= 0)
++  if (dsa_port_is_cpu(cpu_dp))
++  break;
++
++  if (dp->ds->ops->port_change_cpu_port)
++  dp->ds->ops->port_change_cpu_port(dp->ds, 
dp->index, dp->cpu_dp);
++  }
++
+   return 0;
+ }
+ 
+-static void dsa_tree_teardown_default_cpu(struct dsa_switch_tree *dst)
++static void dsa_tree_teardown_default_cpus(struct dsa_switch_tree *dst)
+ {
+   struct dsa_port *dp;
+ 
+@@ -572,7 +582,7 @@ static void dsa_tree_teardown_switches(s
+   dsa_switch_teardown(dp->ds);
+ }
+ 
+-static int dsa_tree_setup_master(struct dsa_switch_tree *dst)
++static int dsa_tree_setup_masters(struct dsa_switch_tree *dst)
+ {
+   struct dsa_port *dp;
+   int err;
+@@ -581,14 +591,20 @@ static int dsa_tree_setup_master(struct
+   if (dsa_port_is_cpu(dp)) {
+   err = dsa_master_setup(dp->master, dp);
+   if (err)
+-  return err;
++ 

Re: Switch issues and CI to GitHub

2022-01-20 Thread Paul Spooren
Hi Etienne,

>> 
>> Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2] 
>> that partly uses outdated runners missing packages installed host packages, 
>> causing them to upload broken SDKs at random.
> 
> My understanding is that buildbot runner are docker containers now so
> we are 1 "docker pull" away from fixing this

I agree, however someone needs to do that and also do it in the future.

We could also automate it[1], but from what I remember people didn’t like the 
idea.

[1]: https://github.com/containrrr/watchtower

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


[RFC] ath79: MikroTik RB912UAG-2HPnD: add initial value to SSR

2022-01-20 Thread Denis Kalashnikov
From: Denis Kalashnikov 

ar71xx mach-rb91x.c and others set SSR init value through
platform data (this ability is added to upstream
drivers/gpio/gpio-74x164.c by
451-gpio-74x164-improve-platform-device-support.patch).
When we ported RB912UAG-2HPnD to ath79, we used DTS gpio-exports
instead. But this broke some mPCIe cards. To fix this we
turn back to gpio-74x164 the ability to get an init value
from DTS.

Why is using DTS gpio-hog option not good in this case? Since
then gpio-export of the hogged line is not working. But we need
it, since with pcie_power and usb_power we can reset USB devices,
e.g cell modems.

Also move SSR beeper pin value from gpio-exports to SSR init value,
since user should never change its value.

Why did some mPCIe cards not work?
RouterBoot leaves USB port power and mPCIe port power lines on the
Serial Shift Register =1. In ar71xx firmware doesn't touch them -
ssr has the same intial values in march init code. In ath79 we
have a DTS instead, where gpio-export is used. When SSR has no
explicit default value, it uses 0 and there is a short period
when mPCIe and USP power lines are =0 (till gpio-export reasserts
them). And MikroTik mPCIe Wi-Fi 5Hz card R11e-5HacT doesn't work:
PCI driver when starts logs warning: "PCIe link is down", lspci
shows no device, rescan (echo 1 > /sys/bus/pci/rescan) doesn't work.

PCI controller (arch/mips/pci-ar724x) starts... and says: "PCIe link
is down", remembers this in the internal link_up field and never
re-check AR724x_PCI_RESET_LINK_UP register bit. When link_up is false,
pci read/write handlers always return error. When I patched it to
actually check link status before reading, I had kernel panic with
Device bus error when trying to read Vendor ID from config register
(see "MIPS: pci-ar724x: avoid data bus error due to a missing PCIe
module" Gabor Juhos patch). It seems that we need to somehow reinit
the PCI host controller. Or init it after gpio-exports. Or simply
don't touch mPCIe power. We prefer the last option.

Acknowledgments: Koen Vandeputte 
Reported-by: Thomas Hühn 
Signed-off: Denis Kalashnikov 
---
 ...9342_mikrotik_routerboard-912uag-2hpnd.dts | 14 ++---
 .../451-gpio-74x164-init-val-support.patch| 20 +++
 2 files changed, 27 insertions(+), 7 deletions(-)
 create mode 100644 
target/linux/ath79/patches-5.10/451-gpio-74x164-init-val-support.patch

diff --git 
a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts 
b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
index 77a0d29113..b8dbe8b784 100644
--- a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
+++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
@@ -107,12 +107,6 @@
gpio-export {
compatible = "gpio-export";
 
-   beeper {
-   gpio-export,name = "beeper";
-   gpio-export,output = <1>;   /* Must be 1 to avoid 
EMI induced clicking noise */
-   gpios = < 5 GPIO_ACTIVE_HIGH>;
-   };
-
usb_power {
gpio-export,name = "power-usb";
gpio-export,output = <1>;
@@ -121,7 +115,7 @@
 
pcie_power {
gpio-export,name = "power-pcie";
-   gpio-export,output = <0>;
+   gpio-export,output = <1>;
gpios = < 7 GPIO_ACTIVE_HIGH>;
};
};
@@ -175,6 +169,12 @@
registers-number = <1>;
reg = <1>;
spi-max-frequency = <5000>;
+
+   /*
+   bit 7 -- pcie_power, bit 6 -- usb_power, bit 5 -- beeper
+   power (must be 1 to avoid EMI induced clicking noise)
+   */
+   init-data = /bits/ 8 <0xe0>;
};
 };
 
diff --git 
a/target/linux/ath79/patches-5.10/451-gpio-74x164-init-val-support.patch 
b/target/linux/ath79/patches-5.10/451-gpio-74x164-init-val-support.patch
new file mode 100644
index 00..9dabb181b5
--- /dev/null
+++ b/target/linux/ath79/patches-5.10/451-gpio-74x164-init-val-support.patch
@@ -0,0 +1,20 @@
+--- a/drivers/gpio/gpio-74x164.c
 b/drivers/gpio/gpio-74x164.c
+@@ -145,6 +145,17 @@ static int gen_74x164_probe(struct spi_d
+   chip->gpio_chip.parent = >dev;
+   chip->gpio_chip.owner = THIS_MODULE;
+ 
++  /*
++   * Read optional inital value of registers. First byte -- last register.
++   * E.g. init-data = /bits/ 8 <0x01 0x1f 0x02>;
++   */
++  ret = of_property_read_u8_array(spi->dev.of_node, "init-data",
++  (u8 *)chip->buffer, (size_t)nregs);
++  if (ret && ret != -EINVAL /* Not found */) {
++  dev_err(>dev, "Invalid 'init-data' property.\n");
++  return -EINVAL;
++  }
++
+   mutex_init(>lock);
+ 
+   ret = __gen_74x164_write_config(chip);
-- 
2.31.1



Re: Switch issues and CI to GitHub

2022-01-20 Thread Etienne Champetier
Hi Paul,

Le jeu. 20 janv. 2022 à 05:04, Paul Spooren  a écrit :
>
> Hi Florian,
>
> > I have now been persuaded to share my thoughts on the subject as well.
>
> Thank you.
>
> > Why not gitlab?
> > Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them.
>
> Some people don’t like the particularly “bloated” interface of GitLab but I 
> agree, they offer the stuff we’re looking for (and much much much more we 
> don’t).
>
> > And if necessary, we can also host everything ourselves.
>
> That’s not an entirely new idea. However in the last three years nobody 
> stepped up to host (and maintain) it. Setting up a GitLab instance is easy 
> enough, hosting it for the next 15 years or something is a bit more of a 
> task. None of the OpenWrt project members were particularly excited about 
> hosting it.
>
> >
> > What I like is the CI handling with the gitlabrunners.
> > We can take the ones from Gitlab or we can configure gitlabrunners running 
> > on our own hardware.
>
> When you say GitLab here I’m assuming GitLab.com. During the vote multiple 
> people were against GitLab.com due to their past in buying and shutting down 
> another Git service. It’s surely possible to host GitLab and a bunch of 
> workers ourselves, the question is, do we want that?
>
> Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2] 
> that partly uses outdated runners missing packages installed host packages, 
> causing them to upload broken SDKs at random.

My understanding is that buildbot runner are docker containers now so
we are 1 "docker pull" away from fixing this

Best
Etienne

> > Somewhere in the thread @arprcar I read that gitlab is not an option.
> > Unfortunately, it didn't say why.
> > Did you mean hosting it yourself?
>
> Neither GitLab.com nor a self hosted GitLab instance seem great at this point.
>
> [1]: https://github.com/openwrt/packages/pull/17645#issuecomment-1016548435
> [2]: https://buildbot.openwrt.org/master/images/#/workers
>
> Best,
> Paul
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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


Re: Switch issues and CI to GitHub

2022-01-20 Thread Paul Spooren
Hi Florian,

> I have now been persuaded to share my thoughts on the subject as well.

Thank you.

> Why not gitlab?
> Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them.

Some people don’t like the particularly “bloated” interface of GitLab but I 
agree, they offer the stuff we’re looking for (and much much much more we 
don’t).

> And if necessary, we can also host everything ourselves.

That’s not an entirely new idea. However in the last three years nobody stepped 
up to host (and maintain) it. Setting up a GitLab instance is easy enough, 
hosting it for the next 15 years or something is a bit more of a task. None of 
the OpenWrt project members were particularly excited about hosting it.
 
> 
> What I like is the CI handling with the gitlabrunners.
> We can take the ones from Gitlab or we can configure gitlabrunners running on 
> our own hardware.

When you say GitLab here I’m assuming GitLab.com. During the vote multiple 
people were against GitLab.com due to their past in buying and shutting down 
another Git service. It’s surely possible to host GitLab and a bunch of workers 
ourselves, the question is, do we want that?

Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2] 
that partly uses outdated runners missing packages installed host packages, 
causing them to upload broken SDKs at random.

> Somewhere in the thread @arprcar I read that gitlab is not an option.
> Unfortunately, it didn't say why.
> Did you mean hosting it yourself?

Neither GitLab.com nor a self hosted GitLab instance seem great at this point.

[1]: https://github.com/openwrt/packages/pull/17645#issuecomment-1016548435
[2]: https://buildbot.openwrt.org/master/images/#/workers

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


Re: Switch issues and CI to GitHub

2022-01-20 Thread Paul Spooren
Hi Michael,

> "Codeberg e.V. is a registered non-profit association based in Berlin, 
> Germany"
> So, this makes me feel better.

I’ll write them an email asking for their long term ideas of maintaining Gitea. 
Just because is a “e.V.” and in Germany doesn’t make it super sustainable, 
trustworthy or anything.

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


Re: Switch issues and CI to GitHub

2022-01-20 Thread Paul Spooren
Hi Sam,
> 
> A big thank you for doing this.

Half the fun.

> 
> Must confess: I was unaware of the ~16k issue body character limit when
> I proposed SourceHut.  Did you find a public bug report or feature
> request about that?  (I looked just now.  Could not find one myself, but
> perhaps my search-fu is off today.)

I discussed this with Drew (sourcehut developer) and the limit is due to email 
compatibility.

> 
>> A quick bug tracker conclusion, I'd be happy to use codeberg.org for
>> issue tracking. Both sr.ht and codeberg.org are FOSS, GitHub not so
>> much. [..]
> 
> GitHub not at all, last time I checked.

Some of their frameworks, actions etc are open source, however their core 
isn’t, right.

> 
>> As an immediate action, we might as well close down bugs.openwrt.org
>> and open issues on GitHub.com without any migration of existing
>> issues. Both users and developers already know the workflows over
>> there and issues have a higher visibility. A migration away from
>> GitHub over to coderberg or sr.ht is possible with much less effort
>> than migrating away from flyspray.
> 
> I wish to caution against this.
> 
> Here are some reasons not to use GitHub for hosting issue/bug-reports.
> 
> 
> # BROKEN HANDLING OF USER ACCOUNT DELETIONS
> 
> Best practice for handling user account deletions is to either:
> 
> 1.  If the user is happy for a record of their contributions to remain
>attributed to them:
> 
>Leave the username shown unchanged in the remaining webpages where
>it was used, so that at-mentions ("@username") within discussions
>still work (aren't broken), and quotations remain correctly
>attributed ("username commented MMM DD, ").
> 
>Or...
> 
> 2.  If the user is *not* happy for that:
> 
>Replace all instances of the username (at-mentions, quotation
>attributions, etc) with a non-personally-identifying pseudonym, e.g.
>"user12345".
> 
>This, too, retains comprehensibility and avoids link-breakage.
> 
> 
> GitHub does neither.
> 
> Instead, GitHub replaces *some but not all* instances of a deleted
> user's username with "Ghost".  That can make it difficult to follow a
> discussion (bug report, pull request, etc) featuring a now-deleted user.
> 
> See e.g. https://github.com/GothenburgBitFactory/taskwarrior/issues/2088
> .  If you didn't know that the comments therein that are now attributed
> to "Ghost" were in fact made by me, it would be a confusing discussion
> to follow.
> 
> (I later closed my GitHub account due to the increasing accessibility
> problems I encountered on GitHub.)
> 
> That would be bad enough.  But because *every* deleted user account is
> processed this way by GitHub, it effectively conflates *all* deleted
> users into one confusing account.  For instance, the "Ghost" account
> here is *not* me: https://github.com/matrix-org/synapse/issues/5778  .
> But a third party would be unable to know that.
> 
> 
> 
> This is especially problematic if more than one now-deleted user
> contributed to a single discussion.  Both user's posts would now be
> attributed - by GitHub's incompetence - to the same user, making it look
> as though one, rather than several, people made those comments.  (I
> don't have an example at hand, but I'd be amazed if this hasn't happened
> several times now, given GitHub's size.)

I think they are in a bit of a pickle there. If you delete everything a lot of 
issues miss comments and stop making sense. If you rename the the user account 
“aparcar” to a random string like “mystery-blob-64”, other users can still 
“recreate” the deleted user behavior by specifically looking for that _new_ 
name. Their solution seems to combine “anonymity" with usability (aka not 
ruining issue discussions entirely).

> 
> 
> Worse still, because GitHub is proprietary and doesn't have a good way
> for users to report GitHub bugs or submit patches to fix them, bugs like
> this tend to go undiscussed and unfixed for years, leading to
> progressive corruption in GitHub discussions.
> 

They have a forum[0] and a “Discussion” thing[1]

[0]: https://github.community
[1]: https://github.com/github/feedback/discussions

> 
> # BROKEN SEARCH
> 
> There is no way within GitHub to avoid irrelevant search results.  For
> instance, if I search in the TaskWarrior repo for
> 
>is:issue in:title "TW-10"
> 
> I get results like "[TW-1733] taskwarrior 2.5.0 can not compile FreeBSD
> 10.1", because they have a "TW" and a "10" in the title.  In other
> words, GitHub fails to perform exact string matching.
> 
> Try it yourself:
> https://github.com/GothenburgBitFactory/taskwarrior/issues?utf8=%E2%9C%93=is%3Aissue+in%3Atitle+%22TW-10%22
> 
> This makes GitHub's search feature a real pain to use.
> 
> Again, because GitHub is proprietary and lacks good ways to track or fix
> GitHub bugs, ones like this go unfixed for years.

This critique came up multiple times, are you aware of a better search 
implementation? I’d be keen to find something 

Re: Switch issues and CI to GitHub

2022-01-20 Thread Florian Eckert

I have now been persuaded to share my thoughts on the subject as well.
Since this is a major change.
In itself, I think it is good that thought is being given to 
unification.


Github was the first web-based source code management tool.
So I think it's just that most of user are also on github.

However, since Microsoft has joined the game, I am in worry about the 
transparency.

Yes, Mircosoft has improved in that aspect.
But it always depends on the company philosophy if they love or hate 
FOSS :-)


Why not gitlab?
Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them.
And if necessary, we can also host everything ourselves.

What I like is the CI handling with the gitlabrunners.
We can take the ones from Gitlab or we can configure gitlabrunners 
running on our own hardware.


Somewhere in the thread @arprcar I read that gitlab is not an option.
Unfortunately, it didn't say why.
Did you mean hosting it yourself?

Best Regards

Florian

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