Re: [PATCH] kernel: xt_FLOWOFFLOAD: fix use of uninitialized dir variable

[Rosen Penev]

On Tue, Mar 12, 2024 at 8:51 PM Qingfang Deng  wrote:
>
> From: Qingfang Deng 
>
> The dir variable has been used uninitialized since the port to 5.10, and
> somehow this remains undetected by GCC.
This patch looks like it's for iptables. Is it needed anymore?
>
> Fixes: b10d6044599d ("kernel: add linux 5.10 support")
> Signed-off-by: Qingfang Deng 
> ---
>  .../hack-5.15/650-netfilter-add-xt_FLOWOFFLOAD-target.patch   | 4 ++--
>  .../hack-6.1/650-netfilter-add-xt_FLOWOFFLOAD-target.patch| 4 ++--
>  .../hack-6.6/650-netfilter-add-xt_FLOWOFFLOAD-target.patch| 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git 
> a/target/linux/generic/hack-5.15/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
>  
> b/target/linux/generic/hack-5.15/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> index da60334498..ec887539d5 100644
> --- 
> a/target/linux/generic/hack-5.15/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> +++ 
> b/target/linux/generic/hack-5.15/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> @@ -609,6 +609,8 @@ Signed-off-by: Felix Fietkau 
>  +  if (!nf_ct_is_confirmed(ct))
>  +  return XT_CONTINUE;
>  +
> ++  dir = CTINFO2DIR(ctinfo);
> ++
>  +  devs[dir] = xt_out(par);
>  +  devs[!dir] = xt_in(par);
>  +
> @@ -618,8 +620,6 @@ Signed-off-by: Felix Fietkau 
>  +  if (test_and_set_bit(IPS_OFFLOAD_BIT, >status))
>  +  return XT_CONTINUE;
>  +
> -+  dir = CTINFO2DIR(ctinfo);
> -+
>  +  if (xt_flowoffload_route(skb, ct, par, , dir, devs) < 0)
>  +  goto err_flow_route;
>  +
> diff --git 
> a/target/linux/generic/hack-6.1/650-netfilter-add-xt_FLOWOFFLOAD-target.patch 
> b/target/linux/generic/hack-6.1/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> index aee845d984..6fdfc79207 100644
> --- 
> a/target/linux/generic/hack-6.1/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> +++ 
> b/target/linux/generic/hack-6.1/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> @@ -555,6 +555,8 @@ Signed-off-by: Felix Fietkau 
>  +  if (!nf_ct_is_confirmed(ct))
>  +  return XT_CONTINUE;
>  +
> ++  dir = CTINFO2DIR(ctinfo);
> ++
>  +  devs[dir] = xt_out(par);
>  +  devs[!dir] = xt_in(par);
>  +
> @@ -564,8 +566,6 @@ Signed-off-by: Felix Fietkau 
>  +  if (test_and_set_bit(IPS_OFFLOAD_BIT, >status))
>  +  return XT_CONTINUE;
>  +
> -+  dir = CTINFO2DIR(ctinfo);
> -+
>  +  if (xt_flowoffload_route(skb, ct, par, , dir, devs) < 0)
>  +  goto err_flow_route;
>  +
> diff --git 
> a/target/linux/generic/hack-6.6/650-netfilter-add-xt_FLOWOFFLOAD-target.patch 
> b/target/linux/generic/hack-6.6/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> index b9a87a671e..9735983212 100644
> --- 
> a/target/linux/generic/hack-6.6/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> +++ 
> b/target/linux/generic/hack-6.6/650-netfilter-add-xt_FLOWOFFLOAD-target.patch
> @@ -555,6 +555,8 @@ Signed-off-by: Felix Fietkau 
>  +  if (!nf_ct_is_confirmed(ct))
>  +  return XT_CONTINUE;
>  +
> ++  dir = CTINFO2DIR(ctinfo);
> ++
>  +  devs[dir] = xt_out(par);
>  +  devs[!dir] = xt_in(par);
>  +
> @@ -564,8 +566,6 @@ Signed-off-by: Felix Fietkau 
>  +  if (test_and_set_bit(IPS_OFFLOAD_BIT, >status))
>  +  return XT_CONTINUE;
>  +
> -+  dir = CTINFO2DIR(ctinfo);
> -+
>  +  if (xt_flowoffload_route(skb, ct, par, , dir, devs) < 0)
>  +  goto err_flow_route;
>  +
> --
> 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] kernel: of: remove "mac-address-ascii" support hack

[Rosen Penev]

On Fri, Nov 10, 2023 at 1:31 AM Shiji Yang  wrote:
>
> From: Shiji Yang 
>
> ASCII MAC address can be handled by nvmem "fixed-layout" now. And all
> related devices were converted to the new "mac-base" layout format.
> It's time to remove this hack.
>
> Signed-off-by: Shiji Yang 
Reviewed-by: Rosen Penev 
> ---
>
> Git grep ref:
> https://git.openwrt.org/?p=openwrt%2Fopenwrt.git=search=HEAD=grep=mac-address-ascii=1
>
> Regards,
> Shiji Yang
>
>
>  ...of_net-add-mac-address-ascii-support.patch | 116 --
>  ...of_net-add-mac-address-ascii-support.patch | 116 --
>  2 files changed, 232 deletions(-)
>  delete mode 100644 
> target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
>  delete mode 100644 
> target/linux/generic/hack-6.1/601-of_net-add-mac-address-ascii-support.patch
>
> diff --git 
> a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
>  
> b/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
> deleted file mode 100644
> index 55866c3135..00
> --- 
> a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
> +++ /dev/null
> @@ -1,116 +0,0 @@
> -From: Yousong Zhou 
> -Subject: [PATCH] of: net: add nvmem cell mac-address-ascii support
> -
> -This is needed for devices with mac address stored in ascii format,
> -e.g. HiWiFi HC6361 to be ported in the following patch.
> -
> -Submitted-by: Yousong Zhou 
> 
> - net/core/of_net.c | 83 --
> - 1 files changed, 72 insertions(+), 11 deletions(-)
> -
>  a/net/core/of_net.c
> -+++ b/net/core/of_net.c
> -@@ -57,13 +57,70 @@ static int of_get_mac_addr(struct device
> -   return -ENODEV;
> - }
> -
> -+static void *nvmem_cell_get_mac_address(struct nvmem_cell *cell)
> -+{
> -+  size_t len;
> -+  void *mac;
> -+
> -+  mac = nvmem_cell_read(cell, );
> -+  if (IS_ERR(mac))
> -+  return mac;
> -+  if (len != ETH_ALEN) {
> -+  kfree(mac);
> -+  return ERR_PTR(-EINVAL);
> -+  }
> -+  return mac;
> -+}
> -+
> -+static void *nvmem_cell_get_mac_address_ascii(struct nvmem_cell *cell)
> -+{
> -+  size_t len;
> -+  int ret;
> -+  void *mac_ascii;
> -+  u8 *mac;
> -+
> -+  mac_ascii = nvmem_cell_read(cell, );
> -+  if (IS_ERR(mac_ascii))
> -+  return mac_ascii;
> -+  if (len != ETH_ALEN*2+5) {
> -+  kfree(mac_ascii);
> -+  return ERR_PTR(-EINVAL);
> -+  }
> -+  mac = kmalloc(ETH_ALEN, GFP_KERNEL);
> -+  if (!mac) {
> -+  kfree(mac_ascii);
> -+  return ERR_PTR(-ENOMEM);
> -+  }
> -+  ret = sscanf(mac_ascii, "%2hhx:%2hhx:%2hhx:%2hhx:%2hhx:%2hhx",
> -+  [0], [1], [2],
> -+  [3], [4], [5]);
> -+  kfree(mac_ascii);
> -+  if (ret == ETH_ALEN)
> -+  return mac;
> -+  kfree(mac);
> -+  return ERR_PTR(-EINVAL);
> -+}
> -+
> -+static struct nvmem_cell_mac_address_property {
> -+  char *name;
> -+  void *(*read)(struct nvmem_cell *);
> -+} nvmem_cell_mac_address_properties[] = {
> -+  {
> -+  .name = "mac-address",
> -+  .read = nvmem_cell_get_mac_address,
> -+  }, {
> -+  .name = "mac-address-ascii",
> -+  .read = nvmem_cell_get_mac_address_ascii,
> -+  },
> -+};
> -+
> - static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)
> - {
> -   struct platform_device *pdev = of_find_device_by_node(np);
> -+  struct nvmem_cell_mac_address_property *property;
> -   struct nvmem_cell *cell;
> -   const void *mac;
> --  size_t len;
> --  int ret;
> -+  int ret, i;
> -
> -   /* Try lookup by device first, there might be a nvmem_cell_lookup
> -* associated with a given device.
> -@@ -74,17 +131,26 @@ static int of_get_mac_addr_nvmem(struct
> -   return ret;
> -   }
> -
> --  cell = of_nvmem_cell_get(np, "mac-address");
> -+  for (i = 0; i < ARRAY_SIZE(nvmem_cell_mac_address_properties); i++) {
> -+  property = _cell_mac_address_properties[i];
> -+  cell = of_nvmem_cell_get(np, property->name);
> -+  /* For -EPROBE_DEFER don't try other properties.
> -+   * We'll get back to this one.
> -+   */
> -+  if (!IS_ERR(cell) || PTR_ERR(cell) == -EPROBE_DEFER)
> -+  break;
> -+  }
> -+
&g

Re: [PATCH ustream-ssl 1/2] ustream-mbedtls: Add compatibility with Mbed TLS 3.0.0

[Rosen Penev]

On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens  wrote:
>
> This adds support for compiling the code against Mbed TLS 3.0.0.
> It still compiles against Mbed TLS 2.28.
>
> The following changes were needed:
>  * DES and 3DES was removed
>  * mbedtls_pk_context->pk_info is private, use mbedtls_pk_get_type()
>to check if it was initialized
>  * mbedtls_pk_parse_keyfile() now gets a random callback
>  * mbedtls/certs.h contains test data and is not installed any more and
>not needed.
>
> Signed-off-by: Hauke Mehrtens 
> ---
>  ustream-mbedtls.c | 12 +++-
>  ustream-mbedtls.h |  1 -
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
> index 7fc7874..1c70cac 100644
> --- a/ustream-mbedtls.c
> +++ b/ustream-mbedtls.c
> @@ -110,9 +110,15 @@ static const int default_ciphersuites_client[] =
> AES_CBC_CIPHERS(ECDHE_ECDSA),
> AES_CBC_CIPHERS(ECDHE_RSA),
> AES_CBC_CIPHERS(DHE_RSA),
> +/* Removed in Mbed TLS 3.0.0 */
are these for Windows XP compatibility?
> +#ifdef MBEDTLS_TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> MBEDTLS_TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
> +#endif
> AES_CIPHERS(RSA),
> +/* Removed in Mbed TLS 3.0.0 */
> +#ifdef MBEDTLS_TLS_RSA_WITH_3DES_EDE_CBC_SHA
> MBEDTLS_TLS_RSA_WITH_3DES_EDE_CBC_SHA,
> +#endif
> 0
>  };
>
> @@ -171,7 +177,7 @@ static void ustream_ssl_update_own_cert(struct 
> ustream_ssl_ctx *ctx)
> if (!ctx->cert.version)
> return;
>
> -   if (!ctx->key.pk_info)
> +   if (mbedtls_pk_get_type(>key) == MBEDTLS_PK_NONE)
> return;
>
> mbedtls_ssl_conf_own_cert(>conf, >cert, >key);
> @@ -206,7 +212,11 @@ __hidden int __ustream_ssl_set_key_file(struct 
> ustream_ssl_ctx *ctx, const char
>  {
> int ret;
>
> +#if (MBEDTLS_VERSION_NUMBER >= 0x0300)
> +   ret = mbedtls_pk_parse_keyfile(>key, file, NULL, _random, NULL);
> +#else
> ret = mbedtls_pk_parse_keyfile(>key, file, NULL);
> +#endif
> if (ret)
> return -1;
>
> diff --git a/ustream-mbedtls.h b/ustream-mbedtls.h
> index e622e5e..7e7c699 100644
> --- a/ustream-mbedtls.h
> +++ b/ustream-mbedtls.h
> @@ -21,7 +21,6 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.39.2
>
>
> ___
> 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] ath79: use "fixed-layout" for Embedded Wireless devices

[Rosen Penev]

On Fri, Nov 10, 2023 at 2:27 AM Rafał Miłecki  wrote:
>
> From: Rafał Miłecki 
>
> Those devices have Ethernet interfaces using base MAC address increased
> by 0x40 in the 3rd indexed byte (00:00:00:FF:00:00). To describe that we
> were using a custom (downstream) "mac-address-increment-byte" property.
>
> The same result can be achieved by using "mac-base" with a properly
> adjusted offset value (0x40 << 16). It may be not pretty but it should
> work without custom property or downstream kernel patch to support it.
>
> Cc: Ansuel Smith 
> Cc: Catrinel Catrinescu 
> Cc: Felix Fietkau 
> Signed-off-by: Rafał Miłecki 
Reviewed-by: Rosen Penev 
> ---
>  .../dts/ar9331_embeddedwireless_dorin.dts | 26 
>  .../dts/ar9344_embeddedwireless_balin.dts | 30 ++-
>  2 files changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts 
> b/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
> index de6b709b5c..6286f203ef 100644
> --- a/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
> +++ b/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
> @@ -85,6 +85,18 @@
> label = "art";
> reg = <0xff 0x01>;
> read-only;
> +
> +   nvmem-layout {
> +   compatible = "fixed-layout";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   macaddr_art_1002: macaddr@1002 {
> +   compatible = "mac-base";
> +   reg = <0x1002 0x6>;
> +   #nvmem-cell-cells = <1>;
> +   };
> +   };
> };
> };
> };
> @@ -93,10 +105,8 @@
>   {
> status = "okay";
>
> -   nvmem-cells = <_art_1002>;
> +   nvmem-cells = <_art_1002 0x40>;
> nvmem-cell-names = "mac-address";
> -   mac-address-increment-byte = <3>;
> -   mac-address-increment = <0x40>;
>  };
>
>   {
> @@ -108,13 +118,3 @@
>
> mtd-cal-data = < 0x1000>;
>  };
> -
> - {
> -   compatible = "nvmem-cells";
> -   #address-cells = <1>;
> -   #size-cells = <1>;
> -
> -   macaddr_art_1002: macaddr@1002 {
> -   reg = <0x1002 0x6>;
> -   };
> -};
> diff --git a/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts 
> b/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts
> index a84c273f86..de13865818 100644
> --- a/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts
> +++ b/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts
> @@ -83,16 +83,20 @@
> reg = <0xff 0x01>;
> read-only;
>
> -   compatible = "nvmem-cells";
> -   #address-cells = <1>;
> -   #size-cells = <1>;
> -
> -   calibration_art_1000: calibration_data@1000 {
> -   reg = <0x1000 0x440>;
> -   };
> -
> -   macaddr_art_1002: macaddr@1002 {
> -   reg = <0x1002 0x6>;
> +   nvmem-layout {
> +   compatible = "fixed-layout";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   calibration_art_1000: 
> calibration_data@1000 {
> +   reg = <0x1000 0x440>;
> +   };
> +
> +   macaddr_art_1002: macaddr@1002 {
> +   compatible = "mac-base";
> +   reg = <0x1002 0x6>;
> +   #nvmem-cell-cells = <1>;
> +   };
> };
> };
>

Re: [PATCH ustream-ssl 2/2] cmake: Fail if undefined symbols are used

[Rosen Penev]

On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens  wrote:
>
> Make the linking of the shared library fail when undefined symbols are
> used. Linking undefined symbols in a shared library normally works and
> the linking of the binary using the shared library fails. We also
> compile some example applications and they failed already.
>
> Signed-off-by: Hauke Mehrtens 
> ---
>  CMakeLists.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 2de6590..f4dca0d 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -10,6 +10,7 @@ ENDIF()
>  ADD_DEFINITIONS(-Wno-unused-parameter -Wmissing-declarations)
>
>  SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
> +SET(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined")
probably better to convert to meson, which passes this by default.
>
>  IF(MBEDTLS)
>ADD_DEFINITIONS(-DHAVE_MBEDTLS)
> --
> 2.39.2
>
>
> ___
> 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] build: explicitly specify Makefile generator

[Rosen Penev]

On Mon, Oct 9, 2023 at 6:05 AM Eicke Herbertz  wrote:
>
> >
> > Where does that CMAKE_GENERATOR environment variable come from? Would
> > it make sense to undefine it instead?
> >
> > Regards,
> > Jonas
>
> Well, from the environment of my development machine.
> I have it set to Ninja for a long time on this system.
>
> Do you mean undefining it manually or as part of the build process?
>
> I'd dislike having to manually undefine it. It's a documented behaviour
> of CMake since v3.15 and it's tedious to run "make -j1 V=s" to figure
> out the issue first.
I have said before and will say it again: cmake.mk needs to be using
toolchain files instead of these command line shenanigans.
>
> As part of the build process, I find explicitly defining the Makefile
> generator better communicates intent than undefining an environment
> variable and depending on CMake's default (although that probably won't
> change).
>
> Regards,
> Eicke
>
> ___
> 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: mips: Make mips64 n32/o32 userland possible or remove support completely

[Rosen Penev]

On Wed, Jul 19, 2023 at 1:29 AM Jeffery To  wrote:
>
> Hi,
>
> I've been looking into platform triplets for Python and figuring out
> the possible combinations. This has led me to trying to compile images
> of the possible combinations for testing.
>
> As a result, I've been trying to compile malta/be64 with n32/o32
> userland. I haven't been successful so far but before trying to fix
> all the issues, I wanted to take a step back and ask a more general
> question.
>
> I see there is the option to select mips64 ABI in toolchain/Config.in.
> On the other hand, there are commits like 46af22de16b2 ("kernel:
> Remove CONFIG_COMPAT") and 38666e8ae42d ("malta: Deactivate MIPS O32
> and N32 support") (and also the recent discussion with amd64 x32
> support).
>
> Is there a preference to make n32/o32 userland optional/possible, and
> so I should continue trying to get it to work? Or is the preference to
> remove support completely, so I should submit patches to do so?
I think remove support.

Ideally some of these mips platforms should use a more common set of
binaries, but there seems to be no one trying that.
>
> Thanks,
> Jeff
>
> ___
> 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] ath79: increase the rfkill debounce interval for TP-Link Archer C7 v2

[Rosen Penev]

On Fri, Jul 14, 2023 at 8:12 AM Shiji Yang  wrote:
>
> From: Shiji Yang 
>
> Due to circuit issue or silicon defect, sometimes the WiFi switch button
> of the Archer C7 v2 can be accidentally triggered multiple times in one
> second. This will cause WiFi to be unexpectedly shut down and trigger
> 'irq 23: nobody cared'[1] warning. Increasing the key debounce interval
> to 1000 ms can fix this issue. This patch also add the missing rfkill
> key label.
Crazy. I was wondering why 2.4ghz went away. For 5ghz I understand,
ath10k is gartbo, but 2.4ghz I didn't.
>
> [1] Warning Log:
> ```
> [87765.218511] irq 23: nobody cared (try booting with the "irqpoll" option)
> [87765.225331] CPU: 0 PID: 317 Comm: irq/23-keys Not tainted 5.15.118 #0
> ...
> [87765.486246] handlers:
> [87765.488543] [<85257547>] 0x800c29a0 threaded [<5c6328a2>] 0x80ffe0b8 
> [gpio_button_hotplug@4cf73d00+0x1a00]
> [87765.498364] Disabling IRQ #23
> ```
>
> Fixes: https://github.com/openwrt/openwrt/issues/13010
> Fixes: https://github.com/openwrt/openwrt/issues/12167
> Fixes: https://github.com/openwrt/openwrt/issues/11191
> Fixes: https://github.com/openwrt/openwrt/issues/7835
>
> Tested-by: Hans Hasert
> Signed-off-by: Shiji Yang 
> ---
>  target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts 
> b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
> index b7ac902003..1b860dbf2d 100644
> --- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
> +++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
> @@ -13,10 +13,11 @@
>
>   {
> rfkill {
> +   label = "rfkill";
> gpios = < 23 GPIO_ACTIVE_LOW>;
> linux,code = ;
> linux,input-type = ;
> -   debounce-interval = <60>;
> +   debounce-interval = <1000>;
> };
>  };
>
> --
> 2.30.2
>
>
> ___
> 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: OpenWrt Next Generation Ideas

[Rosen Penev]

On Fri, Mar 31, 2023 at 6:50 AM Daniel Golle  wrote:
>
> On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote:
> > On 31.03.2023 14:33, Daniel Golle wrote:
> > > Hi!
> > >
> > > On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
> > > > Hi all,
> > > >
> > > > These are the ideas I've been thinking about for the future of OpenWrt 
> > > > for a
> > > > while. It looks complete enough to share it with all of you.
> > > >
> > > > I'm willing to put a great deal of effort to get as much out-of-tree 
> > > > patches
> > > > on mainline Linux as possible.
> > > >
> > > > You can make a comment on Notion or discuss it here, I'm wondering if 
> > > > the
> > > > ideas are feasible and how well it would benefit the people maintaining
> > > > OpenWrt.
> > > >
> > > > https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb
> > >
> > > I will comment here, I don't have an account on Notion and it seems
> > > to be required to be able to comment there.
> > >
> > > > defconfig for each device instead of config for each (sub)target.
> > >
> > > Given that we support thousands of devices this will not only increase
> > > the time needed to build a release or snapshot by several magnitudes,
> > > but also make debugging **much** harder. As of now, all devices of a
> > > subtarget are using the same kernel, hence e.g. symbol offsets in a
> > > kernel stack dump match for all of them. To reproduce or investigate
> > > a problem it's hence enough to have similar hardware, not necessarily
> > > the exact same board. As we are already lacking testers and maintainers
> > > for the relatively small amount of targets/subtargets, have a build for
> > > each board would make things much worse...
> > >
> > > Per-device builds would also be an invitation to downstream users to
> > > introduce device-specific (kernel-)hacks. If you want that, better go
> > > for OpenEmbedded.
> > >
> > > We can modularize things more or even have more sub-targets if it's
> > > really needed to save space.
> > >
> > > The disadvantages outweight the advantages imho when it comes to having
> > > a complete kernel build for each device.
> >
> > Hmm, what about we enable the bare minimum of kernel options for a target,
> > which is already how it is, then select the rest as kernel modules (like on
> > the makefile of a target for each device) on the defconfig for each device?
> > So, in the end, it wouldn't be any different than selecting a kernel module
> > package from the OpenWrt SDK which, I believe, does not change the symbol
> > offsets in the kernel stack.
> >
> > My reason for pushing for the use defconfigs is that anyone can build the
> > Linux kernel for their device, without needing OpenWrt. So the work for
> > adding support for a device would benefit far more people.
>
> This is pretty much what we are currently doing.
> The exception are network drivers to allow for failsafe mode to work
> and provide SSH access **before** any modules are loaded.
>
> >
> > >
> > > > Some Modest Virtualization Observations
> > >
> > > How is this related? Virtualization (with OpenWrt being the guest)
> > > matters on x86 which is usually not that space-constraint.
> > > And maybe armvirt. If space is a problem for older x86 boards, let's
> > > disable guest support in x86/legacy.
> >
> > It was a broad example without any explanation. What caught my attention
> > there is the configuration of the kernel that causes problems, if I
> > understand correctly.
> >
> > >
> > > > Contribute defconfigs and all the devicetrees on OpenWrt to Linux.
> > >
> > > For devicetrees this would of course be desirable, but also implies a
> > > lot of work and discussions. If you are up to get it started (ie. setup
> > > a tree to collect cleaned-up and ready to submit dts), I think it would
> > > be worth the effort, at least for more recent targets/SoCs.
> >
> > I've been meaning to do this for the mt7621 SoC devices for months. The main
> > roadblock is that some drivers are out-of-tree, like the NAND flash so it
> > makes no sense to have them defined on the devicetree. Getting the
> > out-of-tree patches on mainline Linux is another step so it'll happen
> > eventually.
>
> Hm, I thought that Weijie had sent the mt7621-nand driver also upstream,
> but I haven't been following the process...
Rejected and will never make it upstream. It was requested to modify
the driver in the kernel instead, which would probably break the
driver for MTK's Android hardware.
>
> >
> > I'll get this started with my Linux fork on GitHub.
>
> Very nice, I will join in there.
>
> >
> > >
> > > Regarding defconfigs I don't think we need an individual defconfig for
> > > each board. The problem here is also that OpenWrt currently has a layered
> > > approach (generic->target->subtarget) approach while Linux itself has
> > > a flat approach, and using that would result in a lot of duplication,
> > > which would in turn make keeping all those defconfigs 

Re: [PATCH] tools: meson: bump to 1.0.0

[Rosen Penev]

On Fri, Feb 17, 2023 at 2:13 AM Andre Heider  wrote:
>
> On 17/02/2023 10:18, Koen Vandeputte wrote:
> > Drop upstreamed patch.
> >
> > Tested by compiling the complete gstreamer package which heavily
> > depends on this one.
> >
> > Signed-off-by: Koen Vandeputte 
>
> Not possible unfortunately, see
> https://github.com/openwrt/openwrt/pull/10543
>
> We tried a few times to get meson to not drop support for older python
> versions, but here we are...
Wow this went to my spam. Hilarious.

Ubuntu 18.04 is the earliest distribution supported to compile
OpenWrt. It's interesting that it's not compatible with ccache and
nobody has bothered to fix that. Anyway,

18.04 has python 3.7 and 3.8, making this update possible. IIRC
prereq-build.mk needs to be updated to make either 3.7 or 3.8 the new
minimum.
>
> Cheers,
> Andre
>
>
> ___
> 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 ustream-ssl] ustream-mbedtls: Use getrandom() instead of /dev/urandom

[Rosen Penev]

On Sat, Jan 28, 2023 at 10:45 AM Hauke Mehrtens  wrote:
>
> Instead of keeping a file descriptor open just use the getrandom syscall
> to get random data. This is supported by the musl, glibc and Linux for
> some time now.
>
> This also improves the error handling in case this function returns not
> as many bytes as expected.
>
> Signed-off-by: Hauke Mehrtens 
Acked-by: Rosen Penev 
> ---
>  ustream-mbedtls.c | 23 +--
>  1 file changed, 5 insertions(+), 18 deletions(-)
>
> diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
> index e79e37b..51ba2fa 100644
> --- a/ustream-mbedtls.c
> +++ b/ustream-mbedtls.c
> @@ -17,6 +17,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -25,8 +26,6 @@
>  #include "ustream-ssl.h"
>  #include "ustream-internal.h"
>
> -static int urandom_fd = -1;
> -
>  static int s_ustream_read(void *ctx, unsigned char *buf, size_t len)
>  {
> struct ustream *s = ctx;
> @@ -66,21 +65,12 @@ __hidden void ustream_set_io(struct ustream_ssl_ctx *ctx, 
> void *ssl, struct ustr
> mbedtls_ssl_set_bio(ssl, conn, s_ustream_write, s_ustream_read, NULL);
>  }
>
> -static bool urandom_init(void)
> -{
> -   if (urandom_fd > -1)
> -   return true;
> -
> -   urandom_fd = open("/dev/urandom", O_RDONLY);
> -   if (urandom_fd < 0)
> -   return false;
> -
> -   return true;
> -}
> -
>  static int _urandom(void *ctx, unsigned char *out, size_t len)
>  {
> -   if (read(urandom_fd, out, len) < 0)
> +   ssize_t ret;
> +
> +   ret = getrandom(out, len, 0);
> +   if (ret < 0 || (size_t)ret != len)
> return MBEDTLS_ERR_ENTROPY_SOURCE_FAILED;
>
> return 0;
> @@ -134,9 +124,6 @@ __ustream_ssl_context_new(bool server)
> mbedtls_ssl_config *conf;
> int ep;
>
> -   if (!urandom_init())
> -   return NULL;
> -
> ctx = calloc(1, sizeof(*ctx));
> if (!ctx)
> return NULL;
> --
> 2.39.0
>
>
> ___
> 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: elfutils build failure

[Rosen Penev]

On Wed, Jan 25, 2023 at 1:27 PM Peter Naulls  wrote:
>
>
> This is elfutils-0.188 in master. No doubt I'm using a bad toolchain combo - I
> brought the config over from my 22.03 build:
>
> CONFIG_GCC_VERSION="11.3.0"
> CONFIG_BINUTILS_VERSION_2_38=y
>
>
>
> configure:3994: mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely
> -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float
> -mips16 -minterlink-mips16
> -fmacro-prefix-map=/home/peter/awc/openwrt-master/build_dir/target-mipsel_24kc_musl/elfutils-0.188=elfutils-0.188
> -Wformat -Werror=format-security -DPIC -fpic -fstack-protector-strong
> -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro   -D_GNU_SOURCE -Wno-unused-result
> -Wno-format-nonliteral -Wno-error=use-after-free
> -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/include
> -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include/fortify
> -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include
>
> -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/lib
> -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/lib
> -DPIC -fpic 
> -specs=/home/peter/awc/openwrt-master/include/hardened-ld-pie.specs
> -znow -zrelroconftest.c  >&5
> cc1: error: '-Wno-error=use-after-free': no option '-Wuse-after-free'
Related: https://github.com/openwrt/openwrt/issues/11837#
>
> ___
> 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: mt7621 GPIO mapping mystery

[Rosen Penev]

CC: Sergio

On Fri, Jan 20, 2023 at 11:29 AM Peter Naulls  wrote:
>
>
>
> I posted previously on GPIOs, which caused some debate; this may or may not
> be relevant, but I'd be remiss to not mention it:
>
> http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html
>
> I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt
> 5.10.161 etc kernels.
>
> In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17 and
> 22-24 are LEDs, so their operation should be immediately obvious. The are all
> active high and are all wired as you'd expect.
>
> This all works as expected on a previous 4.14 kernel.  To say that there
> have been significant changes in drivers, GPIO handling and device tree since
> that kernel would be an understatement.
>
> I have tried exporting the GPIOS as LEDs, named GPIOs, direct manipulation in
> /sys/class/gpio and libgpiod, but something is amiss. The actual value of the
> GPIO as seen in software can manipulated in all cases, but the physical value
> does not change.
>
> Suspiciously, MDIO/MDC are at GPIOs 20 and 21, so I don't know if these are
> upsetting the physical mapping.  I've also turned off as much as possible in
> the device tree, and built the kernel without switch and ethernet drivers, 
> etc.
>
> I'm tearing my hair out here, so any clues at all would be appreciated.
>
> Thanks!
>
>
>
> ___
> 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] archs38: mark as source-only

[Rosen Penev]

On Thu, Dec 29, 2022 at 10:52 AM Robert Marko  wrote:
>
> archs38 seems to be pretty much unused, usually only treewide changes or
> kernel bumps in order to branch off new stable are done to it.
>
> Considering that target only support some Synopsis HS38 ARC reference
> boards and no consumer hardware so mark the target as source-only to stop
> using Buildbot resources on building the target and packages for it.
One benefit of building archs38 is that it's glibc, which is somewhat
supported with OpenWrt.
>
> Signed-off-by: Robert Marko 
> ---
>  target/linux/archs38/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/linux/archs38/Makefile b/target/linux/archs38/Makefile
> index e08f779170..756de43561 100644
> --- a/target/linux/archs38/Makefile
> +++ b/target/linux/archs38/Makefile
> @@ -8,6 +8,7 @@ ARCH:=arc
>  CPU_TYPE:=archs
>  BOARD:=archs38
>  BOARDNAME:=Synopsys DesignWare ARC HS38
> +FEATURES:=source-only
>  SUBTARGETS:=generic
>
>  KERNEL_PATCHVER:=5.10
> --
> 2.38.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 RFC] ath79: switch TP-Link Archer C59 v1 to read partitions table

[Rosen Penev]

On Thu, Nov 10, 2022 at 3:52 AM Rafał Miłecki  wrote:
>
> From: Rafał Miłecki 
>
> So far DTS file for C59 V1 model was assuming flash partitions were
> fixed. It just used a little quirk with a custom "firmware" partition
> covering both: "os-image" and "file-system" to avoid hardcoding their
> offsets and sizes.
>
> That solution works quite reliably in most cases. "firmware" hack is a
> very minor one. Partitions other that "os-image" and "file-system" are
> rather never reorganized (thought they probably could be during firmware
> upgrade).
>
> This change is a minor design and code cleanup. It makes kernel read
> "partition-table" flash partition to register all partitions specified
> there.
This looks very nice.
>
> Benefits:
> 1. Partitions may get changed / reorganized without breaking things
> 2. We don't hardcode & duplicate info about flash partitions in DT
> 3. Linux doesn't have to split "firmware" partition (less magic)
>
> RFC part:
> This change gets rid of "firmware" partition as it isn't defined in the
> "partition-table". That probably breaks OpenWrt's sysupgrade.
So this is untested?
>
> Signed-off-by: Rafał Miłecki 
> ---
>  .../dts/qca9561_tplink_archer-c59-v1.dts  | 33 ---
>  1 file changed, 6 insertions(+), 27 deletions(-)
>
> diff --git a/target/linux/ath79/dts/qca9561_tplink_archer-c59-v1.dts 
> b/target/linux/ath79/dts/qca9561_tplink_archer-c59-v1.dts
> index c385eb1592..6d1d1602fa 100644
> --- a/target/linux/ath79/dts/qca9561_tplink_archer-c59-v1.dts
> +++ b/target/linux/ath79/dts/qca9561_tplink_archer-c59-v1.dts
> @@ -44,38 +44,17 @@
> spi-max-frequency = <2500>;
>
> partitions {
> -   compatible = "fixed-partitions";
> -   #address-cells = <1>;
> -   #size-cells = <1>;
> -
> -   partition@0 {
> -   label = "u-boot";
> -   reg = <0x00 0x01>;
> -   read-only;
> -   };
> -
> -   info: partition@1 {
> -   label = "info";
> -   reg = <0x01 0x01>;
> -   read-only;
> -   };
> +   compatible = "tplink,safeloader-partitions";
> +   partitions-table-offset = <0xe5>;
>
> -   partition@2 {
> -   compatible = "denx,uimage";
> -   label = "firmware";
> -   reg = <0x02 0xe3>;
> +   partition-file-system {
> +   linux,rootfs;
> };
>
> -   partition@e5 {
> -   label = "tplink";
> -   reg = <0xe5 0x1a>;
> -   read-only;
> +   info: partition-default-mac {
> };
>
> -   art: partition@ff {
> -   label = "art";
> -   reg = <0xff 0x01>;
> -   read-only;
> +   art: partition-radio {
> };
> };
> };
> --
> 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] px5g-mbedtls (Was: px5g return value checking)

[Rosen Penev]

On Mon, Nov 7, 2022 at 7:19 AM Peter Naulls  wrote:
>
> On 11/3/22 14:49, Peter Naulls wrote:
> >
> > Another one from our security scan:
> >
> > File: /usr/sbin/px5g
> > Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
> > calling 'mbedtls_rsa_check_pub_priv'
> > Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while
> > calling 'mbedtls_ecp_check_pub_priv'
> >
>
> The problem is in fact with px5g-mbedtls util, not the library:
Upstream marks a bunch of stuff with MBEDTLS_CHECK_RETURN_TYPICAL aka
warn_unused_result. This function is not. Maybe upstream should also
be fixed.

AFAIK, clang-tidy will mark this function as nodiscard if this is a C++ project.
>
>
>
> --- a/px5g-mbedtls.c
> +++ b/px5g-mbedtls.c
> @@ -113,13 +113,13 @@ static void gen_key(mbedtls_pk_context *key, bool rsa, 
> int
> ksize, int exp,
>  mbedtls_pk_init(key);
>  if (rsa) {
>  fprintf(stderr, "Generating RSA private key, %i bit long
> modulus\n", ksize);
> -   mbedtls_pk_setup(key, 
> mbedtls_pk_info_from_type(MBEDTLS_PK_RSA));
> -   if (!mbedtls_rsa_gen_key(mbedtls_pk_rsa(*key), _urandom, NULL,
> ksize, exp))
> +   if (!mbedtls_pk_setup(key,
> mbedtls_pk_info_from_type(MBEDTLS_PK_RSA)) &&
> +   !mbedtls_rsa_gen_key(mbedtls_pk_rsa(*key), _urandom,
> NULL, ksize, exp))
>  return;
>  } else {
>  fprintf(stderr, "Generating EC private key\n");
> -   mbedtls_pk_setup(key, 
> mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY));
> -   if (!mbedtls_ecp_gen_key(curve, mbedtls_pk_ec(*key), _urandom,
> NULL))
> +   if (!mbedtls_pk_setup(key,
> mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY)) &&
> +   !mbedtls_ecp_gen_key(curve, mbedtls_pk_ec(*key),
> _urandom, NULL))
>  return;
>  }
>  fprintf(stderr, "error: key generation failed\n");
>
>
>
>
> ___
> 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: gpio-mt7621 offset fix for 5.10 kernel series

[Rosen Penev]

On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls  wrote:
>
> On 10/18/22 17:10, Lukas Zeller wrote:
> .
> >
> > Just not any more - the mt7621 had this too. I currently patch it back into
> > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3]
> >
> > I can follow the rationale to get rid of legacy GPIOs, but in the context
> > of experimenting platforms, where GPIOs are a thing to work with in
> > user space, there's just no real replacement yet (see details in [1],[2]).
>
> Yes, I see.
>
> I have a mix of C and scripted GPIO access in my setup, and certainly I can
> move to libgpiod for that - or just just access them as files with
> named GPIOs as setup per the DTS.
Let's CC Sergio, who upstreamed this driver.
>
> I do see the GPIO shell examples in the OpenWrt wiki, but the code needs
> more work to deal with multiple banks, and it just makes figuring out
> the GPIO number to use more clunky without any good cause.
>
> Now, the numbered GPIOs really are just for debug in my system, the
> actual code will use the named ones, but still.
>
> Is the long-term intent for shell scripting to instead use the libgpiod
> tools?
>
> https://openwrt.org/docs/techref/hardware/port.gpio
>
> ___
> 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] uqmi: fix compilation with GCC12

[Rosen Penev]

On Thu, Sep 29, 2022 at 7:45 AM Hauke Mehrtens  wrote:
>
> On 9/28/22 04:22, Rosen Penev wrote:
> > On Sun, Aug 21, 2022 at 7:54 AM Hauke Mehrtens  wrote:
> >>
> >> On 6/11/22 16:47, Bjørn Mork wrote:
> >>> e9hack  writes:
> >>>
> >>>> The 'dangling pointer' issue can be fix without using malloc().
> >>>>
> >>>> --- a/dev.c  2022-05-04 02:18:17.0 +0200
> >>>> +++ b/dev.c  2022-06-11 08:48:21.185567953 +0200
> >>>> @@ -206,6 +206,7 @@ void qmi_request_cancel(struct qmi_dev *
> >>>>int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
> >>>>{
> >>>>   bool complete = false;
> >>>> +bool *c;
> >>>>   bool cancelled;
> >>>>   if (!req->pending)
> >>>> @@ -226,8 +227,10 @@ int qmi_request_wait(struct qmi_dev *qmi
> >>>>   uloop_cancelled = cancelled;
> >>>>   }
> >>>>-  if (req->complete == )
> >>>> -req->complete = NULL;
> >>>> +c = req->complete;
> >>>> +req->complete = NULL;
> >>>> +if (c != )
> >>>> +req->complete = c;
> >>>>   return req->ret;
> >>>>}
> >>>
> >>> How about just fixing GCC instead?  Having all sorts of funny and
> >>> pointless code just to avoid bogus compiler warnings is kind of stupid,
> >>> isn't it?
> >>>
> >>> If GCC can't do better that this, then it's much better to disable that
> >>> warning.
> >>
> >> GCC complains about this code because the pointer is only removed
> >> conditionally
> >> ---
> >>  if (req->complete == )
> >>  req->complete = NULL;
> >> ---
> >> https://git.openwrt.org/?p=project/uqmi.git;a=blob;f=dev.c;h=bd1020790f844fd364fd753135acd8f53f34d996;hb=HEAD#l229
> >>
> >> When you make this part unconditionally it does not complain any more.
> >>
> >> Is it possible that something changes the req->complete pointer address
> >> in between?
> > this is still an issue.
> >>
> >> Hauke
> Hi,
>
> Is it possible to deactivate the error and make it only a warning which
> we can ignore?
> I would deactivate this error for the complete application and add a
> comment to it that this is a workaround for GCC 12.
>
> Did someone create a ticket at GCC for this problem? I am aware of the
> one for elfutils only.
What's wrong with working around it? It's not difficult.
>
> Hauke

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

Re: [PATCH] uqmi: fix compilation with GCC12

[Rosen Penev]

On Sun, Aug 21, 2022 at 7:54 AM Hauke Mehrtens  wrote:
>
> On 6/11/22 16:47, Bjørn Mork wrote:
> > e9hack  writes:
> >
> >> The 'dangling pointer' issue can be fix without using malloc().
> >>
> >> --- a/dev.c  2022-05-04 02:18:17.0 +0200
> >> +++ b/dev.c  2022-06-11 08:48:21.185567953 +0200
> >> @@ -206,6 +206,7 @@ void qmi_request_cancel(struct qmi_dev *
> >>   int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
> >>   {
> >>  bool complete = false;
> >> +bool *c;
> >>  bool cancelled;
> >>  if (!req->pending)
> >> @@ -226,8 +227,10 @@ int qmi_request_wait(struct qmi_dev *qmi
> >>  uloop_cancelled = cancelled;
> >>  }
> >>   -  if (req->complete == )
> >> -req->complete = NULL;
> >> +c = req->complete;
> >> +req->complete = NULL;
> >> +if (c != )
> >> +req->complete = c;
> >>  return req->ret;
> >>   }
> >
> > How about just fixing GCC instead?  Having all sorts of funny and
> > pointless code just to avoid bogus compiler warnings is kind of stupid,
> > isn't it?
> >
> > If GCC can't do better that this, then it's much better to disable that
> > warning.
>
> GCC complains about this code because the pointer is only removed
> conditionally
> ---
> if (req->complete == )
> req->complete = NULL;
> ---
> https://git.openwrt.org/?p=project/uqmi.git;a=blob;f=dev.c;h=bd1020790f844fd364fd753135acd8f53f34d996;hb=HEAD#l229
>
> When you make this part unconditionally it does not complain any more.
>
> Is it possible that something changes the req->complete pointer address
> in between?
this is still an issue.
>
> Hauke

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

[PATCHv2 2/2] ubox: fix GCC fanalyzer warnings

[Rosen Penev]

memory leaks and missing NULL checks.

Signed-off-by: Rosen Penev 
---
 v2: remove null check for free
 kmodloader.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/kmodloader.c b/kmodloader.c
index 4b2ffa7..b2e7a8b 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -336,6 +336,11 @@ static int scan_loaded_modules(void)
/* possibly a module outside /lib/modules// */
n = alloc_module(m.name, NULL, 0, m.depends, m.size);
}
+   if (!n) {
+   ULOG_ERR("Failed to allocate memory for module\n");
+   return -1;
+   }
+
n->usage = m.usage;
n->state = LOADED;
}
@@ -583,6 +588,11 @@ static int insert_module(char *path, const char *options)
struct stat s;
int fd, ret = -1;
 
+   if (!path) {
+   ULOG_ERR("Path not specified\n");
+   return ret;
+   }
+
if (stat(path, )) {
ULOG_ERR("missing module %s\n", path);
return ret;
@@ -1164,6 +1174,8 @@ load_options(void)
continue;
}
}
+
+   fclose(f);
 }
 
 int main(int argc, char **argv)
-- 
2.36.1


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

[PATCHv2 1/2] ubox: fix bad realloc usage

[Rosen Penev]

Both cppcheck and gcc's -fanalyzer complain here that realloc is being
used improperly.

Signed-off-by: Rosen Penev 
---
 kmodloader.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kmodloader.c b/kmodloader.c
index 63bae5e..4b2ffa7 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -351,6 +351,7 @@ static struct module* get_module_info(const char *module, 
const char *name)
unsigned int offset, size;
char *map = MAP_FAILED, *strings, *dep = NULL;
const char **aliases = NULL;
+   const char **aliasesr;
int naliases = 0;
struct module *m = NULL;
struct stat s;
@@ -393,12 +394,13 @@ static struct module* get_module_info(const char *module, 
const char *name)
if (!strncmp(strings, "depends=", len + 1))
dep = sep;
else if (!strncmp(strings, "alias=", len + 1)) {
-   aliases = realloc(aliases, sizeof(sep) * (naliases + 
1));
-   if (!aliases) {
+   aliasesr = realloc(aliases, sizeof(sep) * (naliases + 
1));
+   if (!aliasesr) {
ULOG_ERR("out of memory\n");
goto out;
}
 
+   aliases = aliasesr;
aliases[naliases++] = sep;
}
strings = [strlen(sep)];
-- 
2.36.1


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

Re: [PATCH 1/2] ubox: fix GCC fanalyzer warnings

[Rosen Penev]

On Mon, Jul 18, 2022 at 1:45 AM Jo-Philipp Wich  wrote:
>
> Hi,
>
> > [...]
> > - free(aliases);
> > + if (aliases)
> > + free(aliases);
>
> This check is redundant, the free() function is guaranteed to be NULL-safe in
> the standard:
>
>The free() function shall cause the space pointed to by ptr to be
>deallocated; that is, made available for further allocation. If ptr is a
>null pointer, no action shall occur.
It seems the error was fixed in some other way. Removed.
>
> > [...]
>
> ~ Jo
>
> ___
> 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 1/2] ubox: fix GCC fanalyzer warnings

[Rosen Penev]

memory leaks and missing NULL checks.

Signed-off-by: Rosen Penev 
---
 kmodloader.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/kmodloader.c b/kmodloader.c
index 63bae5e..bc5f20c 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -336,6 +336,11 @@ static int scan_loaded_modules(void)
/* possibly a module outside /lib/modules// */
n = alloc_module(m.name, NULL, 0, m.depends, m.size);
}
+   if (!n) {
+   ULOG_ERR("Failed to allocate memory for module\n");
+   return -1;
+   }
+
n->usage = m.usage;
n->state = LOADED;
}
@@ -416,7 +421,8 @@ out:
if (fd >= 0)
close(fd);
 
-   free(aliases);
+   if (aliases)
+   free(aliases);
 
return m;
 }
@@ -581,6 +587,11 @@ static int insert_module(char *path, const char *options)
struct stat s;
int fd, ret = -1;
 
+   if (!path) {
+   ULOG_ERR("Path not specified\n");
+   return ret;
+   }
+
if (stat(path, )) {
ULOG_ERR("missing module %s\n", path);
return ret;
@@ -1162,6 +1173,8 @@ load_options(void)
continue;
}
}
+
+   fclose(f);
 }
 
 int main(int argc, char **argv)
-- 
2.36.1


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

[PATCH 2/2] ubox: fix bad realloc usage

[Rosen Penev]

Both cppcheck and gcc's -fanalyzer complain here that realloc is being
used improperly.

Signed-off-by: Rosen Penev 
---
 kmodloader.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kmodloader.c b/kmodloader.c
index bc5f20c..5f8c9c1 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -356,6 +356,7 @@ static struct module* get_module_info(const char *module, 
const char *name)
unsigned int offset, size;
char *map = MAP_FAILED, *strings, *dep = NULL;
const char **aliases = NULL;
+   const char **aliasesr;
int naliases = 0;
struct module *m = NULL;
struct stat s;
@@ -398,12 +399,13 @@ static struct module* get_module_info(const char *module, 
const char *name)
if (!strncmp(strings, "depends=", len + 1))
dep = sep;
else if (!strncmp(strings, "alias=", len + 1)) {
-   aliases = realloc(aliases, sizeof(sep) * (naliases + 
1));
-   if (!aliases) {
+   aliasesr = realloc(aliases, sizeof(sep) * (naliases + 
1));
+   if (!aliasesr) {
ULOG_ERR("out of memory\n");
goto out;
}
 
+   aliases = aliasesr;
aliases[naliases++] = sep;
}
strings = [strlen(sep)];
-- 
2.36.1


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

Re: Question about ancient TARGET_CFLAGS in rules.mk?

[Rosen Penev]

On Sun, Jul 17, 2022 at 2:29 AM Christian Marangi  wrote:
>
> On Sat, Jul 16, 2022 at 10:17:28PM -0700, Rosen Penev wrote:
> > On Sat, Jul 16, 2022 at 4:52 PM Ansuel Smith  wrote:
> > >
> > > Hi,
> > > some background about this.
> > >
> > > I'm trying to improve our CI system more and more by finally adding
> > > support for real
> > > EXTERNAL_TOOLCHAIN_SUPPORT... I'm running (and abusing) the github CI
> > > to make sure everything works and all compiles correctly...
> > >
> > > While testing it I notice a specific target fails to compile ubox package.
> > > While still to investigate why this is only present on that target, i
> > > found out why
> > > this happen with EXTERNAL_TOOLCHAIN and doesn't fail on a normal build.
> > >
> > > The error is this
> > >
> > > kmodloader.c: In function 'main_loader':
> > > 1339kmodloader.c:1027:41: error: ignoring return value of 'asprintf'
> > > declared with attribute 'warn_unused_result' [-Werror=unused-result]
> > > 1340make[1]: *** [package/Makefile:116: package/system/ubox/compile] 
> > > Error 1
> > > 1341 1027 | asprintf(>opts, "%s %s", prev, opts);
> > > 1342 | ^~~
> > > 1343cc1: all warnings being treated as errors
> > >
> > > The package is compiled with -Wall so it does make sense that the
> > > error is printed...
> > >
> > > Fact is that the error(warning) is actually correct but I couldn't
> > > understand why it was
> > > not flagged on normal build and here the reason...
> > >
> > > In rules.mk we have
> > > TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable
> > > -Wno-error=unused-result
> > > and this is only applied if EXTERNAL_TOOLCHAIN is not selected...
> > >
> > > Now the question... WHY?
> > >
> > > Considering even the linux kernel started to use Wall by default,
> > > should we also start
> > > enforcing correct code and fix every package that present such error?
> > Yes
>
> Ok will prepare a patch.
>
> > > Fixing these kind of error is trivial enough and IMHO we should drop these
> > > warning disable.
> > I've had issues getting stuff merged to core openwrt utilities in the
> > past, especially when it comes to fixing compilation warnings.
>
> Mhhh I notice sometime patch getting rejected as it was trying to fix an
> false-positive error from a faulty version of gcc.
> But I think fixing error caused by disabling warning should be
> accepted... Real problem is that some trivial fix may cause problems...
> Example the error i just fixed for kmodloader... If I wasn't carfule i
> could totally check the error condition for (fail) instead of (fail < 0)
> and that would have caused breakage as asprintf return the bytes written
> so it could totally return a value != 0. (just an example of a simple
> error handling destryong the function of the package)
Not even rejected. example:
>https://patchwork.ozlabs.org/project/openwrt/patch/20220622185800.3156-1-ros...@gmail.com/
> and 
>https://patchwork.ozlabs.org/project/openwrt/patch/20201225011158.35592-1-ros...@gmail.com/

I've had others but retired them after figuring out they were never
going to get merged.
> > >
> > > I will create a PR in the next few days but wonder if anyone wants to
> > > give some feedback
> > > about why these extra flags are set. To me it seems they are just
> > > leftover from older times?
> > Most likely.
>
> Still can't understand why these errors are only in archs38/generic...
> Still a mistery to me...
>
> > >
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> --
> Ansuel

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

Re: Question about ancient TARGET_CFLAGS in rules.mk?

[Rosen Penev]

On Sun, Jul 17, 2022 at 2:29 AM Christian Marangi  wrote:
>
> On Sat, Jul 16, 2022 at 10:17:28PM -0700, Rosen Penev wrote:
> > On Sat, Jul 16, 2022 at 4:52 PM Ansuel Smith  wrote:
> > >
> > > Hi,
> > > some background about this.
> > >
> > > I'm trying to improve our CI system more and more by finally adding
> > > support for real
> > > EXTERNAL_TOOLCHAIN_SUPPORT... I'm running (and abusing) the github CI
> > > to make sure everything works and all compiles correctly...
> > >
> > > While testing it I notice a specific target fails to compile ubox package.
> > > While still to investigate why this is only present on that target, i
> > > found out why
> > > this happen with EXTERNAL_TOOLCHAIN and doesn't fail on a normal build.
> > >
> > > The error is this
> > >
> > > kmodloader.c: In function 'main_loader':
> > > 1339kmodloader.c:1027:41: error: ignoring return value of 'asprintf'
> > > declared with attribute 'warn_unused_result' [-Werror=unused-result]
> > > 1340make[1]: *** [package/Makefile:116: package/system/ubox/compile] 
> > > Error 1
> > > 1341 1027 | asprintf(>opts, "%s %s", prev, opts);
> > > 1342 | ^~~
> > > 1343cc1: all warnings being treated as errors
> > >
> > > The package is compiled with -Wall so it does make sense that the
> > > error is printed...
> > >
> > > Fact is that the error(warning) is actually correct but I couldn't
> > > understand why it was
> > > not flagged on normal build and here the reason...
> > >
> > > In rules.mk we have
> > > TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable
> > > -Wno-error=unused-result
> > > and this is only applied if EXTERNAL_TOOLCHAIN is not selected...
> > >
> > > Now the question... WHY?
> > >
> > > Considering even the linux kernel started to use Wall by default,
> > > should we also start
> > > enforcing correct code and fix every package that present such error?
> > Yes
>
> Ok will prepare a patch.
>
> > > Fixing these kind of error is trivial enough and IMHO we should drop these
> > > warning disable.
> > I've had issues getting stuff merged to core openwrt utilities in the
> > past, especially when it comes to fixing compilation warnings.
>
> Mhhh I notice sometime patch getting rejected as it was trying to fix an
> false-positive error from a faulty version of gcc.
> But I think fixing error caused by disabling warning should be
> accepted... Real problem is that some trivial fix may cause problems...
> Example the error i just fixed for kmodloader... If I wasn't carfule i
> could totally check the error condition for (fail) instead of (fail < 0)
> and that would have caused breakage as asprintf return the bytes written
> so it could totally return a value != 0. (just an example of a simple
> error handling destryong the function of the package)
>
> > >
> > > I will create a PR in the next few days but wonder if anyone wants to
> > > give some feedback
> > > about why these extra flags are set. To me it seems they are just
> > > leftover from older times?
> > Most likely.
>
> Still can't understand why these errors are only in archs38/generic...
> Still a mistery to me...
very clear actually. glibc marks asprintf with
attribute((warn_unused_result)) (nodiscard in C++). musl does not.
>
> > >
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> --
> Ansuel

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

Re: Question about ancient TARGET_CFLAGS in rules.mk?

[Rosen Penev]

On Sat, Jul 16, 2022 at 4:52 PM Ansuel Smith  wrote:
>
> Hi,
> some background about this.
>
> I'm trying to improve our CI system more and more by finally adding
> support for real
> EXTERNAL_TOOLCHAIN_SUPPORT... I'm running (and abusing) the github CI
> to make sure everything works and all compiles correctly...
>
> While testing it I notice a specific target fails to compile ubox package.
> While still to investigate why this is only present on that target, i
> found out why
> this happen with EXTERNAL_TOOLCHAIN and doesn't fail on a normal build.
>
> The error is this
>
> kmodloader.c: In function 'main_loader':
> 1339kmodloader.c:1027:41: error: ignoring return value of 'asprintf'
> declared with attribute 'warn_unused_result' [-Werror=unused-result]
> 1340make[1]: *** [package/Makefile:116: package/system/ubox/compile] Error 1
> 1341 1027 | asprintf(>opts, "%s %s", prev, opts);
> 1342 | ^~~
> 1343cc1: all warnings being treated as errors
>
> The package is compiled with -Wall so it does make sense that the
> error is printed...
>
> Fact is that the error(warning) is actually correct but I couldn't
> understand why it was
> not flagged on normal build and here the reason...
>
> In rules.mk we have
> TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable
> -Wno-error=unused-result
> and this is only applied if EXTERNAL_TOOLCHAIN is not selected...
>
> Now the question... WHY?
>
> Considering even the linux kernel started to use Wall by default,
> should we also start
> enforcing correct code and fix every package that present such error?
Yes
> Fixing these kind of error is trivial enough and IMHO we should drop these
> warning disable.
I've had issues getting stuff merged to core openwrt utilities in the
past, especially when it comes to fixing compilation warnings.
>
> I will create a PR in the next few days but wonder if anyone wants to
> give some feedback
> about why these extra flags are set. To me it seems they are just
> leftover from older times?
Most likely.
>
> ___
> 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] bcm53xx: disable GRO support at kernel level

[Rosen Penev]

On Wed, Jun 22, 2022 at 8:49 PM Rafał Miłecki  wrote:
>
> On 21.06.2022 01:13, Rosen Penev wrote:
> > On Mon, Jun 20, 2022 at 2:33 AM Rafał Miłecki  wrote:
> >>
> >> On 10.06.2022 15:16, Rafał Miłecki wrote:
> >>> This improves NAT masquarade network performance.
> >>>
> >>> An alternative to kernel change would be runtime setup but that requires
> >>> ethtool and identifying relevant network interface and all related
> >>> switch ports interfaces.
> >>
> >> I sent another patch that should supersede this one:
> >> [PATCH] bcm53xx: disable GRO by default at kernel level
> >> https://patchwork.ozlabs.org/project/openwrt/patch/20220620082120.11714-1-zaj...@gmail.com/
> >>
> >> It's probably a better idea to disable GRO *by default* (and allow
> >> re-enabling it).
> > Reminds me of this patch:
> > https://github.com/openwrt/openwrt/commit/13e5e473699b92f171205e0f5c57c9ebe7922492
> > which was subsequently reverted because of slower routing performance
> >
> > Is this patch the same as using napi_gro_receive and passing NETIF_F_GRO ?
>
> Kind of. Reverting above patch removes ar71xx support for GRO totally.
> It's not the best option as some people / cases / devices may want it.
> It's much better to just disable it.
I imagine that would be no routing cases.
>
> GRO can be runtime disabled using ethtool like:
> ethtool -K eth0 gro off
> ethtool -K lan1 gro off
> ethtool -K lan2 gro off
> ethtool -K lan3 gro off
> ethtool -K lan4 gro off
> ethtool -K wan gro off
> (or enabled with "on").
>
> It can also be disabled by default with patch like the one I sent. In
> that case you can still enable it with:
> ethtool -K eth0 gro on
> ethtool -K lan1 gro on
> ethtool -K lan2 gro on
> ethtool -K lan3 gro on
> ethtool -K lan4 gro on
> ethtool -K wan gro on
>
>
> So for ar71xx I'd suggest to:
> 1. Re-implement GRO support
> 2. Disable GRO by default if it worsens performance for most devices
Basically your other patch.

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

[PATCH] libubox: add missing NULL check

[Rosen Penev]

strlen takes non NULL parameters. Found with GCC's -fanalyzer.

Signed-off-by: Rosen Penev 
---
 blobmsg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/blobmsg.c b/blobmsg.c
index d87d607..bb6c469 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -364,6 +364,8 @@ blobmsg_add_string_buffer(struct blob_buf *buf)
int len, attrlen;
 
attr = blob_next(buf->head);
+   if (!attr)
+   return;
len = strlen(blobmsg_data(attr)) + 1;
 
attrlen = blob_raw_len(attr) + len;
-- 
2.36.1


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

Re: [PATCH] bcm53xx: disable GRO support at kernel level

[Rosen Penev]

On Mon, Jun 20, 2022 at 2:33 AM Rafał Miłecki  wrote:
>
> On 10.06.2022 15:16, Rafał Miłecki wrote:
> > This improves NAT masquarade network performance.
> >
> > An alternative to kernel change would be runtime setup but that requires
> > ethtool and identifying relevant network interface and all related
> > switch ports interfaces.
>
> I sent another patch that should supersede this one:
> [PATCH] bcm53xx: disable GRO by default at kernel level
> https://patchwork.ozlabs.org/project/openwrt/patch/20220620082120.11714-1-zaj...@gmail.com/
>
> It's probably a better idea to disable GRO *by default* (and allow
> re-enabling it).
Reminds me of this patch:
https://github.com/openwrt/openwrt/commit/13e5e473699b92f171205e0f5c57c9ebe7922492
which was subsequently reverted because of slower routing performance

Is this patch the same as using napi_gro_receive and passing NETIF_F_GRO ?

>
> ___
> 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] uqmi: fix compilation with GCC12

[Rosen Penev]

GCC12 doesn't seem to see that the completed member gets nulled. Use
malloc to work around this.

Signed-off-by: Rosen Penev 
---
 commands-nas.c | 2 +-
 dev.c  | 9 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/commands-nas.c b/commands-nas.c
index 476cd61..9c0a626 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -710,7 +710,7 @@ static void
 cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request 
*req, struct qmi_msg *msg)
 {
struct qmi_nas_get_cell_location_info_response res;
-   void *c, *t, *cell, *freq;
+   void *c = NULL, *t, *cell, *freq;
int i, j;
 
qmi_parse_nas_get_cell_location_info_response(msg, );
diff --git a/dev.c b/dev.c
index bd10207..b1cf2a3 100644
--- a/dev.c
+++ b/dev.c
@@ -205,7 +205,7 @@ void qmi_request_cancel(struct qmi_dev *qmi, struct 
qmi_request *req)
 
 int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
 {
-   bool complete = false;
+   bool *complete = malloc(sizeof(bool));
bool cancelled;
 
if (!req->pending)
@@ -214,8 +214,8 @@ int qmi_request_wait(struct qmi_dev *qmi, struct 
qmi_request *req)
if (req->complete)
*req->complete = true;
 
-   req->complete = 
-   while (!complete) {
+   req->complete = complete;
+   while (!*complete) {
cancelled = uloop_cancelled;
uloop_cancelled = false;
uloop_run();
@@ -226,9 +226,10 @@ int qmi_request_wait(struct qmi_dev *qmi, struct 
qmi_request *req)
uloop_cancelled = cancelled;
}
 
-   if (req->complete == )
+   if (req->complete == complete)
req->complete = NULL;
 
+   free(complete);
return req->ret;
 }
 
-- 
2.36.1


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

Re: [PATCH] nls.mk: clean up INTL flags

[Rosen Penev]

On Sun, Jun 5, 2022 at 11:02 AM Sebastian Kemper  wrote:
>
> gettext (libintl-stub) was removed in commit [1], so the libintl-stub
> lib and include directories aren't existing anymore. This commit cleans
> up the INTL flags for the BUILD_NLS=n case.
>
> [1] e6f569406ffe1d9e35b9b9ea36f38cdd5837728d
>
> Signed-off-by: Sebastian Kemper 
Reviewed-by: Rosen Penev 
> ---
>  include/nls.mk | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/include/nls.mk b/include/nls.mk
> index 163e480932..665ccb565d 100644
> --- a/include/nls.mk
> +++ b/include/nls.mk
> @@ -15,7 +15,7 @@ else
> ICONV_PREFIX:=$(STAGING_DIR)/usr/lib/libiconv-stub
> ICONV_FULL:=
>
> -   INTL_PREFIX:=$(STAGING_DIR)/usr/lib/libintl-stub
> +   INTL_PREFIX:=
> INTL_FULL:=
>  endif
>
> @@ -28,9 +28,15 @@ ICONV_CPPFLAGS:=-I$(ICONV_PREFIX)/include
>  ICONV_LDFLAGS:=-L$(ICONV_PREFIX)/lib -Wl,-rpath-link=$(ICONV_PREFIX)/lib
>
>  INTL_DEPENDS:=+BUILD_NLS:libintl-full
> -INTL_CFLAGS:=-I$(INTL_PREFIX)/include
> -INTL_CPPFLAGS:=-I$(INTL_PREFIX)/include
> -INTL_LDFLAGS:=-L$(INTL_PREFIX)/lib -Wl,-rpath-link=$(INTL_PREFIX)/lib
> +ifeq ($(CONFIG_BUILD_NLS),y)
> +   INTL_CFLAGS:=-I$(INTL_PREFIX)/include
> +   INTL_CPPFLAGS:=-I$(INTL_PREFIX)/include
> +   INTL_LDFLAGS:=-L$(INTL_PREFIX)/lib -Wl,-rpath-link=$(INTL_PREFIX)/lib
> +else
> +   INTL_CFLAGS:=
> +   INTL_CPPFLAGS:=
> +   INTL_LDFLAGS:=
> +endif
>
>  TARGET_CFLAGS += $(ICONV_CFLAGS) $(INTL_CFLAGS)
>  TARGET_CPPFLAGS += $(ICONV_CPPFLAGS) $(INTL_CPPFLAGS)
> --
> 2.30.2
>

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

Re: [PATCH] packages: pagekitec: fix crashing due to musl time64

[Rosen Penev]

On Fri, Jun 3, 2022 at 10:24 AM  wrote:
>
> From: Lukas Zeller 
>
> [Please note: this is my first attempt at submitting a patch,
> please apologize/advise if something is not as it should be. I tried to
> follow the guideline in the wiki]
https://github.com/openwrt/packages <-- PR there
>
> upstream pagekitec/libpagekite is not compatible with musl>=1.2.0 time64
> (time_t being 64 bit rather than 32 bit) due to several format strings using 
> "%d"
> for a time_t parameter.
>
> With time_t becoming 64bit, these (mostly log output) printfs display invalid
> numbers, or even crash when mixed with "%s" format specifiers.
>
> Most prominently visible case is the "Tick!" message which causes any
> real world use of pagekitec/libpagekite crash immediately.
>
> This patch now uses "%lld" with an explicit cast of the arguments to uint64_t.
> The cast ensures that the code is still safe to compile with 32 bit time_t
> (but introduces a slight performance penalty in that case).
>
> Signed-off-by: Lukas Zeller 
> ---
>  net/pagekitec/patches/500-time64-fixes.patch | 70 
>  1 file changed, 70 insertions(+)
>  create mode 100644 net/pagekitec/patches/500-time64-fixes.patch
>
> diff --git a/net/pagekitec/patches/500-time64-fixes.patch 
> b/net/pagekitec/patches/500-time64-fixes.patch
> new file mode 100644
> index 0..a052a16c4
> --- /dev/null
> +++ b/net/pagekitec/patches/500-time64-fixes.patch
> @@ -0,0 +1,70 @@
> +--- a/libpagekite/pklogging.c
>  b/libpagekite/pklogging.c
> +@@ -208,9 +208,9 @@ void pk_dump_conn(char* prefix, struct p
> +   if (conn->sockfd < 0) return;
> +
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/sockfd: %d", prefix, conn->sockfd);
> +-  pk_log(PK_LOG_MANAGER_DEBUG, "%s/activity: %x (%ds ago)", prefix,
> +-   conn->activity,
> +-   pk_time(0) - conn->activity);
> ++  pk_log(PK_LOG_MANAGER_DEBUG, "%s/activity: %llx (%llds ago)", prefix,
ll == long long. PRIu64 == uint64_t.

Same issue throughout this patch.
> ++   (uint64_t)conn->activity,
> ++   (uint64_t)(pk_time(0) - conn->activity));
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/read_bytes: %d", prefix, 
> conn->read_bytes);
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/read_kb: %d", prefix, conn->read_kb);
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/sent_kb: %d", prefix, conn->sent_kb);
> +@@ -281,8 +281,8 @@ void pk_dump_state(struct pk_manager* pk
> +   pk_log(LL, "pk_manager/kite_max: %d", pkm->kite_max);
> +   pk_log(LL, "pk_manager/tunnel_max: %d", pkm->tunnel_max);
> +   pk_log(LL, "pk_manager/be_conn_max: %d", pkm->be_conn_max);
> +-  pk_log(LL, "pk_manager/last_world_update: %x", pkm->last_world_update);
> +-  pk_log(LL, "pk_manager/next_tick: %d", pkm->next_tick);
> ++  pk_log(LL, "pk_manager/last_world_update: %llx", 
> (uint64_t)pkm->last_world_update);
> ++  pk_log(LL, "pk_manager/next_tick: %lld", (uint64_t)pkm->next_tick);
> +   pk_log(LL, "pk_manager/enable_timer: %d", 0 < pkm->enable_timer);
> +   pk_log(LL, "pk_manager/fancy_pagekite_net_rejection_url: %s", 
> pkm->fancy_pagekite_net_rejection_url);
> +   pk_log(LL, "pk_manager/want_spare_frontends: %d", 
> pkm->want_spare_frontends);
> +--- a/libpagekite/pkmanager.c
>  b/libpagekite/pkmanager.c
> +@@ -1070,8 +1070,8 @@ static void pkm_tick_cb(EV_P_ ev_async*
> + pkm->timer.repeat = pkm->next_tick;
> + ev_timer_again(pkm->loop, &(pkm->timer));
> + pk_log(PK_LOG_MANAGER_INFO,
> +-   "Tick!  [repeating=%s, next=%d, status=%d, tunnels=%d, v=%s]",
> +-   pkm->enable_timer ? "yes" : "no", pkm->next_tick,
> ++   "Tick!  [repeating=%s, next=%lld, status=%d, tunnels=%d, v=%s]",
> ++   pkm->enable_timer ? "yes" : "no", (uint64_t)pkm->next_tick,
> +pkm->status, pk_state.live_tunnels, PK_VERSION);
> +
> + /* We slow down exponentially by default... */
> +@@ -1122,8 +1122,8 @@ static void pkm_tick_cb(EV_P_ ev_async*
> +   fe->last_ping = now;
> +   pkc_write(&(fe->conn), ping, pingsize);
> +   pk_log(PK_LOG_TUNNEL_DATA,
> +-  "%d: Sent PING (idle=%ds>%ds)",
> +-  fe->conn.sockfd, now - fe->conn.activity, now - inactive);
> ++  "%d: Sent PING (idle=%llds>%llds)",
> ++  fe->conn.sockfd, (uint64_t)(now - fe->conn.activity), 
> (uint64_t)(now - inactive));
> +   next_tick = 1 + pkm->housekeeping_interval_min;
> + }
> +   }
> +--- a/libpagekite/pkproto.c
>  b/libpagekite/pkproto.c
> +@@ -577,7 +577,7 @@ int pk_make_salt(char* salt) {
> + char* pk_sign(const char* token, const char* secret, time_t ts,
> +   const char* payload, int length, char *buffer)
> + {
> +-  char tbuffer[128], tsbuf[16], scratch[10240];
> ++  char tbuffer[128], tsbuf[32], scratch[10240];
> +
> +   PK_TRACE_FUNCTION;
> +
> +@@ -606,7 +606,7 @@ char* pk_sign(const char* token, const c
> +
> +   /* Optionally embed a timestamp to the 

Re: [PATCH 2/6] tools/dwarves: add host package

[Rosen Penev]

On Mon, Feb 28, 2022 at 8:17 AM Stijn Tintel  wrote:
>
> On 28/02/2022 16:16, Ansuel Smith wrote:
> >> On 27/02/2022 17:20, Ansuel Smith wrote:
> >>>  >
>  From: Tony Ambardar 
> 
>  dwarves is a set of tools that use the debugging information inserted in
>  ELF binaries by compilers such as GCC. Utilities in the dwarves suite
>  include pahole, which can be used to find alignment holes in structs and
>  classes, and also extracts other information such as CPU cacheline
>  alignment, helping pack those structures to achieve more cache hits.
> 
>  These tools are also used to encode and read the BTF type information
>  format used with the bpf syscall, making this a Linux build dependency
>  when using kernel BTF information.
> >>> BTW this fails to build if libdw-dev is not installed with
> >>>
> >>> -- Checking availability of DWARF and ELF development libraries
> >>> -- Could NOT find dwarf include dir
> >>> -- Could NOT find libdw include dir
> >>> -- Could NOT find libdw library
> >>> CMake Error at cmake/modules/FindDWARF.cmake:93 (message):
> >>>   Could NOT find some ELF and DWARF libraries, please install the missing
> >>>   packages
> >>> Call Stack (most recent call first):
> >>>   CMakeLists.txt:60 (find_package)
> >>>
> >>> ERROR: tools/dwarves failed to build.
> >>>
> >>> Should we add it to the build prereq?
> >> Please try this instead:
> >>
> >> diff --git a/tools/dwarves/Makefile b/tools/dwarves/Makefile
> >> index b02a2398a1..e5a55706be 100644
> >> --- a/tools/dwarves/Makefile
> >> +++ b/tools/dwarves/Makefile
> >> @@ -12,14 +12,12 @@PKG_LICENSE:=GPL-2.0-only
> >> PKG_LICENSE_FILES:=COPYING
> >>
> >> HOST_BUILD_PARALLEL:=1
> >> +PKG_BUILD_DEPENDS:=elfutils/host
> >>
> >> include $(INCLUDE_DIR)/host-build.mk
> >> include $(INCLUDE_DIR)/cmake.mk
> >>
> >> CMAKE_HOST_OPTIONS += \
> >> -   -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=BOTH \
> >> -   -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=BOTH \
> >> -   -DCMAKE_BUILD_TYPE=Release \
> >>-D__LIB=lib \
> >>-DCMAKE_INSTALL_RPATH="$(STAGING_DIR_HOST)/lib" \
> >>-DCMAKE_SKIP_RPATH=FALSE
> >>
> >> Thanks,
> >> Stijn
> >>
> > No luck... still
> >
> Apparently we cannot use PKG_BUILD_DEPENDS or HOST_BUILD_DEPENDS in
> tools/, as this is handled in include/package-dumpinfo.mk, which is
> included from include/package.mk, which we don't include in tools/...
> Could use some guidance here, as I am not familiar enough with this part
> of the code.
depends for tools/ are specified in tools/Makefile. Which means it
requires tools/elfutils
>
> Thanks,
> Stijn
>
>
> ___
> 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] firmware-utils: fix compilation with macOS

[Rosen Penev]

On Mon, Feb 28, 2022 at 12:43 AM Paul Spooren  wrote:
>
>
>
> > On 28. Feb 2022, at 08:34, Rosen Penev  wrote:
> >
> > __bswap_32 is a GNU extension.
> >
> > Signed-off-by: Rosen Penev 
> > —
>
> Seems to fix the compile issue on my Mac.
>
> Acked-by: Paul Spooren 
>
> If people change things in tools/, please use GitHub PRs. I added a CI to 
> compile check changes on Ubuntu/macOS since breakage is a recurring issue.
The issue is that it would have to be implemented as a patch file,
which is bad form to be merged.
>
> > src/avm-wasp-checksum.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/avm-wasp-checksum.c b/src/avm-wasp-checksum.c
> > index 8c112f3..41a425e 100644
> > --- a/src/avm-wasp-checksum.c
> > +++ b/src/avm-wasp-checksum.c
> > @@ -156,7 +156,7 @@ int main(int argc, char *argv[])
> >   }
> >   }
> >   if (model == MODEL_X490)
> > - crc = __bswap_32(crc);
> > + crc = bswap_32(crc);
> >   fwrite(, sizeof(uint32_t), 1, out_fp);
> >   if (ferror(out_fp)) {
> >   fprintf(stderr, "Error writing checksum to output file: 
> > %s\n", outfile);
> > --
> > 2.35.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] firmware-utils: fix Wparentheses parnings

[Rosen Penev]

On Sun, Feb 27, 2022 at 11:42 PM Rosen Penev  wrote:
>
> () is normally used for comparison and (()) for assignment and
> comparison. Normalize both situations.
>
> Signed-off-by: Rosen Penev 
> ---
>  src/mkcasfw.c   | 2 +-
>  src/mkcsysimg.c | 2 +-
>  src/mkmylofw.c  | 2 +-
>  src/mkzynfw.c   | 2 +-
>  src/srec2bin.c  | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/mkcasfw.c b/src/mkcasfw.c
> index 09d6ee8..e4ce90c 100644
> --- a/src/mkcasfw.c
> +++ b/src/mkcasfw.c
> @@ -378,7 +378,7 @@ parse_arg(char *arg, char *buf, char *argv[])
>
> memset(argv, 0, MAX_ARG_COUNT * sizeof(void *));
>
> -   if ((arg == NULL)) {
> +   if (arg == NULL) {
> /* no arguments */
> return 0;
> }
> diff --git a/src/mkcsysimg.c b/src/mkcsysimg.c
> index cbe06bb..b78e5fb 100644
> --- a/src/mkcsysimg.c
> +++ b/src/mkcsysimg.c
> @@ -328,7 +328,7 @@ parse_arg(char *arg, char *buf, char *argv[])
>
> memset(argv, 0, MAX_ARG_COUNT * sizeof(void *));
>
> -   if ((arg == NULL)) {
> +   if (arg == NULL) {
> /* no arguments */
> return 0;
> }
> diff --git a/src/mkmylofw.c b/src/mkmylofw.c
> index fd79f1c..74e265d 100644
> --- a/src/mkmylofw.c
> +++ b/src/mkmylofw.c
> @@ -724,7 +724,7 @@ parse_arg(char *arg, char *buf, char *argv[])
> char **ap = 
> int i;
>
> -   if ((arg == NULL)) {
> +   if (arg == NULL) {
> /* invalid argument string */
> return -1;
> }
> diff --git a/src/mkzynfw.c b/src/mkzynfw.c
> index 19909b1..07ec5c6 100644
> --- a/src/mkzynfw.c
> +++ b/src/mkzynfw.c
> @@ -368,7 +368,7 @@ parse_arg(char *arg, char *buf, char *argv[])
>
> memset(argv, 0, MAX_ARG_COUNT * sizeof(void *));
>
> -   if ((arg == NULL)) {
> +   if (arg == NULL) {
> /* no arguments */
> return 0;
> }
> diff --git a/src/srec2bin.c b/src/srec2bin.c
> index ad4222d..0758664 100644
> --- a/src/srec2bin.c
> +++ b/src/srec2bin.c
> @@ -405,7 +405,7 @@ int srecLine(char *pSrecLine)
>  break;
>  case '5': if (count<3) return(SRLerrorout("Invalid Srecord count 
> field",scp));
>itmp=gh(pSrecLine,4); pSrecLine+=4; count-=2;
> -  if (itmp|=s1s2s3_total) return(SRLerrorout("Incorrect 
> number of S3 Record processed",scp));
> +  if ((itmp|=s1s2s3_total)) return(SRLerrorout("Incorrect 
> number of S3 Record processed",scp));
I can't tell if this is a bug in the code or intentional.
>  break;
>  case '6': return(SRLerrorout("Invalid Srecord type",scp));
>  break;
> --
> 2.35.1
>

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

[PATCH] firmware-utils: fix Wparentheses parnings

[Rosen Penev]

() is normally used for comparison and (()) for assignment and
comparison. Normalize both situations.

Signed-off-by: Rosen Penev 
---
 src/mkcasfw.c   | 2 +-
 src/mkcsysimg.c | 2 +-
 src/mkmylofw.c  | 2 +-
 src/mkzynfw.c   | 2 +-
 src/srec2bin.c  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mkcasfw.c b/src/mkcasfw.c
index 09d6ee8..e4ce90c 100644
--- a/src/mkcasfw.c
+++ b/src/mkcasfw.c
@@ -378,7 +378,7 @@ parse_arg(char *arg, char *buf, char *argv[])
 
memset(argv, 0, MAX_ARG_COUNT * sizeof(void *));
 
-   if ((arg == NULL)) {
+   if (arg == NULL) {
/* no arguments */
return 0;
}
diff --git a/src/mkcsysimg.c b/src/mkcsysimg.c
index cbe06bb..b78e5fb 100644
--- a/src/mkcsysimg.c
+++ b/src/mkcsysimg.c
@@ -328,7 +328,7 @@ parse_arg(char *arg, char *buf, char *argv[])
 
memset(argv, 0, MAX_ARG_COUNT * sizeof(void *));
 
-   if ((arg == NULL)) {
+   if (arg == NULL) {
/* no arguments */
return 0;
}
diff --git a/src/mkmylofw.c b/src/mkmylofw.c
index fd79f1c..74e265d 100644
--- a/src/mkmylofw.c
+++ b/src/mkmylofw.c
@@ -724,7 +724,7 @@ parse_arg(char *arg, char *buf, char *argv[])
char **ap = 
int i;
 
-   if ((arg == NULL)) {
+   if (arg == NULL) {
/* invalid argument string */
return -1;
}
diff --git a/src/mkzynfw.c b/src/mkzynfw.c
index 19909b1..07ec5c6 100644
--- a/src/mkzynfw.c
+++ b/src/mkzynfw.c
@@ -368,7 +368,7 @@ parse_arg(char *arg, char *buf, char *argv[])
 
memset(argv, 0, MAX_ARG_COUNT * sizeof(void *));
 
-   if ((arg == NULL)) {
+   if (arg == NULL) {
/* no arguments */
return 0;
}
diff --git a/src/srec2bin.c b/src/srec2bin.c
index ad4222d..0758664 100644
--- a/src/srec2bin.c
+++ b/src/srec2bin.c
@@ -405,7 +405,7 @@ int srecLine(char *pSrecLine)
 break;
 case '5': if (count<3) return(SRLerrorout("Invalid Srecord count 
field",scp));
   itmp=gh(pSrecLine,4); pSrecLine+=4; count-=2;
-  if (itmp|=s1s2s3_total) return(SRLerrorout("Incorrect number 
of S3 Record processed",scp));
+  if ((itmp|=s1s2s3_total)) return(SRLerrorout("Incorrect 
number of S3 Record processed",scp));
 break;
 case '6': return(SRLerrorout("Invalid Srecord type",scp));
 break;
-- 
2.35.1


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

[PATCH] firmware-utils: fix compilation with macOS

[Rosen Penev]

__bswap_32 is a GNU extension.

Signed-off-by: Rosen Penev 
---
 src/avm-wasp-checksum.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/avm-wasp-checksum.c b/src/avm-wasp-checksum.c
index 8c112f3..41a425e 100644
--- a/src/avm-wasp-checksum.c
+++ b/src/avm-wasp-checksum.c
@@ -156,7 +156,7 @@ int main(int argc, char *argv[])
}
}
if (model == MODEL_X490)
-   crc = __bswap_32(crc);
+   crc = bswap_32(crc);
fwrite(, sizeof(uint32_t), 1, out_fp);
if (ferror(out_fp)) {
fprintf(stderr, "Error writing checksum to output file: %s\n", 
outfile);
-- 
2.35.1


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

Re: OpenWrt 21.02 and 19.07 minor release

[Rosen Penev]

On Mon, Feb 14, 2022 at 12:00 PM Hauke Mehrtens  wrote:
>
> On 2/13/22 01:26, Hauke Mehrtens wrote:
> > On 2/10/22 16:12, Seo Suchan wrote:
> >> looks like those dnsmasq exploits aren't real
> >>
> >> bugs never looked by human (no commit related by it), but bots
> >> confirmed that thoses look fixed by commit
> >> 011f8cf1d011ade2f9e7231fca3cabfb1e8eaf06
> >>
> >> https://oss-fuzz.com/revisions?job=afl_asan_dnsmasq=202112300601:202201020605
> >> 
> >>
> >>
> >> when I read that commit it looks like 2.86 had bug that faild to build
> >> on gcc 4.8 and it caused fuzzer to get immediately crash, producing
> >> bunch of 'exploits'
> >
> > Thanks for that information. Do you know about some official statement
> > about this?
> >
> > I fixed some other problems in OpenWrt 21.02:
> > * Linux: update to latests minor version
> > * hostapd: backport the patches
> > * wolfssl: update to recent version
> > * tcpdump: backport a patch
> > * mbedtls: update to new LTS version
> > * glibc: Update to latest minor version
>
> The OpenWrt 21.02 and 19.07 branches are looking fine to me.
> I am still waiting for some LuCI backports from Jo and would like to tag
> and build the next minor releases tomorrow or some days later depending
> on when Jo finishes the backports.
>
> @Rosen: You wanted to update ksmbd in the feeds. Is there already a pull
> request and will you merge it or should I merge it shortly before tagging?
https://github.com/openwrt/packages/pull/17866
>
> I asked on the dnsmasq mailing list about the CVEs we saw. My current
> plan is to ignore them.
>
> Is there anything else missing?
>
> Hauke

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

Re: [PATCH v2 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet

[Rosen Penev]

On Fri, Feb 11, 2022 at 2:27 PM Arınç ÜNAL  wrote:
>
> On 12/02/2022 00:53, Rosen Penev wrote:
> > On Fri, Feb 11, 2022 at 4:46 AM Arınç ÜNAL  wrote:
> >>
> >> Add the missing pinctrl properties on the ethernet node.
> >> GMAC1 will start working with this change.
> >>
> >> Link: 
> >> https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd...@arinc9.com/
> >>
> >> Overwrite pinctrl-0 property without rgmii2_pins on devicetrees which use
> >> the rgmii2 pins as GPIO (22 - 33).
> >>
> >> Add rgmii2 pin group to gpio function on mt7621_tplink_archer-x6-v3.dtsi
> >> which uses GPIO 28.
> >>
> >> Signed-off-by: Arınç ÜNAL 
> >> ---
> >>   target/linux/ramips/dts/mt7621.dtsi | 3 +++
> >>   target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts| 4 
> >>   target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts  | 4 
> >>   target/linux/ramips/dts/mt7621_buffalo_wsr-600dhp.dts   | 4 
> >>   target/linux/ramips/dts/mt7621_d-team_pbr-m1.dts| 4 
> >>   target/linux/ramips/dts/mt7621_firefly_firewrt.dts  | 4 
> >>   target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts| 4 
> >>   target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts| 4 
> >>   target/linux/ramips/dts/mt7621_mediatek_ap-mt7621a-v60.dts  | 4 
> >>   .../linux/ramips/dts/mt7621_mediatek_mt7621-eval-board.dts  | 4 
> >>   .../linux/ramips/dts/mt7621_mikrotik_routerboard-m11g.dts   | 4 
> >>   target/linux/ramips/dts/mt7621_mtc_wr1201.dts   | 4 
> >>   target/linux/ramips/dts/mt7621_netgear_ex6150.dts   | 4 
> >>   target/linux/ramips/dts/mt7621_sercomm_na502.dts| 4 
> >>   target/linux/ramips/dts/mt7621_telco-electronics_x1.dts | 4 
> >>   target/linux/ramips/dts/mt7621_tplink_archer-x6-v3.dtsi | 6 +-
> >>   target/linux/ramips/dts/mt7621_tplink_re350-v1.dts  | 4 
> >>   target/linux/ramips/dts/mt7621_tplink_rexx0-v1.dtsi | 4 
> >>   target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dtsi   | 4 
> >>   target/linux/ramips/dts/mt7621_wavlink_wl-wn531a6.dts   | 4 
> >>   target/linux/ramips/dts/mt7621_wevo_w2914ns-v2.dtsi | 4 
> >>   target/linux/ramips/dts/mt7621_winstars_ws-wn583a6.dts  | 4 
> >>   target/linux/ramips/dts/mt7621_xzwifi_creativebox-v1.dts| 4 
> >>   target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi  | 4 
> >>   target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts   | 4 
> >>   target/linux/ramips/dts/mt7621_zbtlink_zbt-wg3526.dtsi  | 4 
> >>   target/linux/ramips/dts/mt7621_zyxel_nr7101.dts | 4 
> >>   27 files changed, 108 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/target/linux/ramips/dts/mt7621.dtsi 
> >> b/target/linux/ramips/dts/mt7621.dtsi
> >> index bfb66740a2..56799201c0 100644
> >> --- a/target/linux/ramips/dts/mt7621.dtsi
> >> +++ b/target/linux/ramips/dts/mt7621.dtsi
> >> @@ -456,6 +456,9 @@
> >>
> >>  mediatek,ethsys = <>;
> >>
> >> +   pinctrl-names = "default";
> >> +   pinctrl-0 = <_pins _pins _pins>;
> >> +
> >>  gmac0: mac@0 {
> >>  compatible = "mediatek,eth-mac";
> >>  reg = <0>;
> >> diff --git a/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts 
> >> b/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts
> >> index 8c6fdab04f..73c125e496 100644
> >> --- a/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts
> >> +++ b/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts
> >> @@ -147,6 +147,10 @@
> >>  };
> >>   };
> >>
> >> + {
> >> +   pinctrl-0 = <_pins _pins>;
> >> +};
> >> +
> >>{
> >>  nvmem-cells = <_factory_e000>;
> >>  nvmem-cell-names = "mac-address";
> >> diff --git a/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts 
> >> b/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts
> >> index f9211463f8..7b82008ff7 100644
> >> --- a/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts
> >> +++ b/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts
> >> @@ -152,6 +152,

Re: [PATCH v2 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet

[Rosen Penev]

On Fri, Feb 11, 2022 at 4:46 AM Arınç ÜNAL  wrote:
>
> Add the missing pinctrl properties on the ethernet node.
> GMAC1 will start working with this change.
>
> Link: 
> https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd...@arinc9.com/
>
> Overwrite pinctrl-0 property without rgmii2_pins on devicetrees which use
> the rgmii2 pins as GPIO (22 - 33).
>
> Add rgmii2 pin group to gpio function on mt7621_tplink_archer-x6-v3.dtsi
> which uses GPIO 28.
>
> Signed-off-by: Arınç ÜNAL 
> ---
>  target/linux/ramips/dts/mt7621.dtsi | 3 +++
>  target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts| 4 
>  target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts  | 4 
>  target/linux/ramips/dts/mt7621_buffalo_wsr-600dhp.dts   | 4 
>  target/linux/ramips/dts/mt7621_d-team_pbr-m1.dts| 4 
>  target/linux/ramips/dts/mt7621_firefly_firewrt.dts  | 4 
>  target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts| 4 
>  target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts| 4 
>  target/linux/ramips/dts/mt7621_mediatek_ap-mt7621a-v60.dts  | 4 
>  .../linux/ramips/dts/mt7621_mediatek_mt7621-eval-board.dts  | 4 
>  .../linux/ramips/dts/mt7621_mikrotik_routerboard-m11g.dts   | 4 
>  target/linux/ramips/dts/mt7621_mtc_wr1201.dts   | 4 
>  target/linux/ramips/dts/mt7621_netgear_ex6150.dts   | 4 
>  target/linux/ramips/dts/mt7621_sercomm_na502.dts| 4 
>  target/linux/ramips/dts/mt7621_telco-electronics_x1.dts | 4 
>  target/linux/ramips/dts/mt7621_tplink_archer-x6-v3.dtsi | 6 +-
>  target/linux/ramips/dts/mt7621_tplink_re350-v1.dts  | 4 
>  target/linux/ramips/dts/mt7621_tplink_rexx0-v1.dtsi | 4 
>  target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dtsi   | 4 
>  target/linux/ramips/dts/mt7621_wavlink_wl-wn531a6.dts   | 4 
>  target/linux/ramips/dts/mt7621_wevo_w2914ns-v2.dtsi | 4 
>  target/linux/ramips/dts/mt7621_winstars_ws-wn583a6.dts  | 4 
>  target/linux/ramips/dts/mt7621_xzwifi_creativebox-v1.dts| 4 
>  target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi  | 4 
>  target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts   | 4 
>  target/linux/ramips/dts/mt7621_zbtlink_zbt-wg3526.dtsi  | 4 
>  target/linux/ramips/dts/mt7621_zyxel_nr7101.dts | 4 
>  27 files changed, 108 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/ramips/dts/mt7621.dtsi 
> b/target/linux/ramips/dts/mt7621.dtsi
> index bfb66740a2..56799201c0 100644
> --- a/target/linux/ramips/dts/mt7621.dtsi
> +++ b/target/linux/ramips/dts/mt7621.dtsi
> @@ -456,6 +456,9 @@
>
> mediatek,ethsys = <>;
>
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins _pins _pins>;
> +
> gmac0: mac@0 {
> compatible = "mediatek,eth-mac";
> reg = <0>;
> diff --git a/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts 
> b/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts
> index 8c6fdab04f..73c125e496 100644
> --- a/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts
> +++ b/target/linux/ramips/dts/mt7621_alfa-network_quad-e4g.dts
> @@ -147,6 +147,10 @@
> };
>  };
>
> + {
> +   pinctrl-0 = <_pins _pins>;
> +};
> +
>   {
> nvmem-cells = <_factory_e000>;
> nvmem-cell-names = "mac-address";
> diff --git a/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts 
> b/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts
> index f9211463f8..7b82008ff7 100644
> --- a/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts
> +++ b/target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts
> @@ -152,6 +152,10 @@
> };
>  };
>
> + {
> +   pinctrl-0 = <_pins _pins>;
> +};
> +
>   {
> ports {
> port@0 {
> diff --git a/target/linux/ramips/dts/mt7621_buffalo_wsr-600dhp.dts 
> b/target/linux/ramips/dts/mt7621_buffalo_wsr-600dhp.dts
> index 5d20b6e28a..5e295791a3 100644
> --- a/target/linux/ramips/dts/mt7621_buffalo_wsr-600dhp.dts
> +++ b/target/linux/ramips/dts/mt7621_buffalo_wsr-600dhp.dts
> @@ -172,6 +172,10 @@
> };
>  };
>
> + {
> +   pinctrl-0 = <_pins _pins>;
> +};
> +
>   {
> nvmem-cells = <_factory_4>;
> nvmem-cell-names = "mac-address";
> diff --git a/target/linux/ramips/dts/mt7621_d-team_pbr-m1.dts 
> b/target/linux/ramips/dts/mt7621_d-team_pbr-m1.dts
> index d30e4d1953..dc537cf504 100644
> --- a/target/linux/ramips/dts/mt7621_d-team_pbr-m1.dts
> +++ b/target/linux/ramips/dts/mt7621_d-team_pbr-m1.dts
> @@ -174,6 +174,10 @@
> };
>  };
>
> + {
> +   pinctrl-0 = <_pins _pins>;
> +};
> +
>   {
> nvmem-cells = <_factory_e000>;
> nvmem-cell-names = "mac-address";
> diff --git a/target/linux/ramips/dts/mt7621_firefly_firewrt.dts 
> 

Re: [PATCH 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet

[Rosen Penev]

On Tue, Feb 8, 2022 at 1:02 PM Arınç ÜNAL  wrote:
>
>
>
> On 08/02/2022 18:02, Arınç ÜNAL wrote:
> > Hey Chuanhong,
> >
> > On 08/02/2022 17:20, Chuanhong Guo wrote:
> >> Hi!
> >>
> >> On Tue, Feb 8, 2022 at 3:38 AM Arınç ÜNAL  wrote:
> >>> diff --git a/target/linux/ramips/dts/mt7621.dtsi
> >>> b/target/linux/ramips/dts/mt7621.dtsi
> >>> index 9256e118e4..95113d4e11 100644
> >>> --- a/target/linux/ramips/dts/mt7621.dtsi
> >>> +++ b/target/linux/ramips/dts/mt7621.dtsi
> >>> @@ -456,6 +456,9 @@
> >>>
> >>>  mediatek,ethsys = <>;
> >>>
> >>> +   pinctrl-names = "default";
> >>> +   pinctrl-0 = <_pins _pins _pins>;
> >>> +
> >>
> >> There are devices using rgmii2 pins as GPIO. (e.g. PBR-M1)
> >> rgmii2_pins should be excluded from pinctrl-0 in dts of these routers
> >> if you enable it by default here.
> >
> > Thanks for pointing this out. These are the devicetrees which use any of
> > the GPIOs for rgmii2 (GPIO 22 - 33).
> >
> > mt7621_xzwifi_creativebox-v1.dts
> > mt7621_tplink_rexx0-v1.dtsi
> > mt7621_firefly_firewrt.dts
> > mt7621_alfa-network_quad-e4g.dts
> > mt7621_winstars_ws-wn583a6.dts
> > mt7621_mikrotik_routerboard-m11g.dts
> > mt7621_sercomm_na502.dts
> > mt7621_mtc_wr1201.dts
> > mt7621_tplink_re350-v1.dts
> > mt7621_d-team_pbr-m1.dts
> > mt7621_telco-electronics_x1.dts
> > mt7621_wavlink_wl-wn531a6.dts
> > mt7621_zbtlink_zbt-wg3526.dtsi
> > mt7621_zbtlink_zbt-wg2626.dts
> > mt7621_gnubee_gb-pc2.dts
> > mt7621_gnubee_gb-pc1.dts
> > mt7621_wevo_w2914ns-v2.dtsi
> > mt7621_tplink_archer-x6-v3.dtsi
> > mt7621_netgear_ex6150.dts
> >
> > I will send v2 where the pinctrl-0 property for ethernet is overwritten
> > with only the rgmii1_pins and mdio_pins values for these devices.
>
> On a second note, I see that the devicetrees of these devices set rgmii2
> pins to function as gpio. Even with this, do we still need to prevent
> calling rgmii2_pins on the ethernet node for these devices?
Note that the GnuBee PC2 has an ethernet interface connected to
RGMII2. dts probably needs updating.
>
> ___
> 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 0/6] backport fixes and improvements for MT7530

[Rosen Penev]

On Sat, Feb 5, 2022 at 10:23 AM Hauke Mehrtens  wrote:
>
> On 2/5/22 19:21, Rosen Penev wrote:
> > On Sat, Feb 5, 2022 at 10:12 AM Hauke Mehrtens  wrote:
> >>
> >> On 2/3/22 13:06, DENG Qingfang wrote:
> >>> Hi,
> >>>
> >>> This series backports some patches from upstream to address the current
> >>> MT7530 DSA driver's problems.
> >>>
> >>> Thanks.
> >>>
> >>> DENG Qingfang (6):
> >>> kernel: backport MediaTek jumbo frame support
> >>> kernel: backport MT7530 ageing time support
> >>> kernel: backport MT7530 VLAN fix
> >>> kernel: backport MT7530 MDB operations
> >>> kernel: backport MediaTek Ethernet PHY driver
> >>> kernel: backport MT7530 IRQ support
> >>>
> >> Hi,
> >>
> >> The last two patches are breaking the Linksys e8450 (mt7622) for me.
> >>
> >> I am getting these errors:
> > Note the commentary in
> > https://github.com/openwrt/openwrt/commit/3f4301e123f29348b4ad87578d62b7d1f5f210c6
> >
> > The message in dmesg is harmless. It just says the functionality in
> > this patch needs dts bindings, which were only provided for ramips.
>
> The following error messages are a bigger problem:
> 
> [1.312943] mt7530 mdio-bus:00 lan1 (uninitialized): failed to
> connect to PHY: -EINVAL
> [1.320890] mt7530 mdio-bus:00 lan1 (uninitialized): error -22
> setting up PHY for tree 0, switch 0, port 0
> -
>
> The LAN ports are not registered and then LAN is not working at all.
I think the PHY driver was written for mt7530. The e8450 uses mt7531 AFAIK.

>
> Hauke

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

Re: [PATCH 0/6] backport fixes and improvements for MT7530

[Rosen Penev]

On Sat, Feb 5, 2022 at 10:12 AM Hauke Mehrtens  wrote:
>
> On 2/3/22 13:06, DENG Qingfang wrote:
> > Hi,
> >
> > This series backports some patches from upstream to address the current
> > MT7530 DSA driver's problems.
> >
> > Thanks.
> >
> > DENG Qingfang (6):
> >kernel: backport MediaTek jumbo frame support
> >kernel: backport MT7530 ageing time support
> >kernel: backport MT7530 VLAN fix
> >kernel: backport MT7530 MDB operations
> >kernel: backport MediaTek Ethernet PHY driver
> >kernel: backport MT7530 IRQ support
> >
> Hi,
>
> The last two patches are breaking the Linksys e8450 (mt7622) for me.
>
> I am getting these errors:
Note the commentary in
https://github.com/openwrt/openwrt/commit/3f4301e123f29348b4ad87578d62b7d1f5f210c6

The message in dmesg is harmless. It just says the functionality in
this patch needs dts bindings, which were only provided for ramips.
> -
> [1.243304] pci_bus 0001:00: bus scan returning with max=00
> [1.249219] mtk_hsdma 1b007000.dma-controller: Using 3 as missing
> dma-requests property
> [1.257493] mtk_hsdma 1b007000.dma-controller: MediaTek HSDMA driver
> registered
> [1.300554] mt7530 mdio-bus:00: no interrupt support
> [1.312943] mt7530 mdio-bus:00 lan1 (uninitialized): failed to
> connect to PHY: -EINVAL
> [1.320890] mt7530 mdio-bus:00 lan1 (uninitialized): error -22
> setting up PHY for tree 0, switch 0, port 0
> [1.331163] mt7530 mdio-bus:00 lan2 (uninitialized): failed to
> connect to PHY: -EINVAL
> [1.339085] mt7530 mdio-bus:00 lan2 (uninitialized): error -22
> setting up PHY for tree 0, switch 0, port 1
> [1.349321] mt7530 mdio-bus:00 lan3 (uninitialized): failed to
> connect to PHY: -EINVAL
> [1.357241] mt7530 mdio-bus:00 lan3 (uninitialized): error -22
> setting up PHY for tree 0, switch 0, port 2
> [1.367452] mt7530 mdio-bus:00 lan4 (uninitialized): failed to
> connect to PHY: -EINVAL
> [1.375367] mt7530 mdio-bus:00 lan4 (uninitialized): error -22
> setting up PHY for tree 0, switch 0, port 3
> [1.385750] mt7530 mdio-bus:00 wan (uninitialized): failed to connect
> to PHY: -EINVAL
> [1.393575] mt7530 mdio-bus:00 wan (uninitialized): error -22 setting
> up PHY for tree 0, switch 0, port 4
> [1.404399] mt7530 mdio-bus:00: configuring for fixed/2500base-x link
> mode
> [1.411452] DSA: tree 0 setup
> [1.411640] mt7530 mdio-bus:00: Link is Up - 2.5Gbps/Full - flow
> control rx/tx
> -
>
> I will revert both patches in master now.
>
> Hauke
>
> ___
> 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 1/5] ath79: mikrotik: change to qca8k DSA driver

[Rosen Penev]

On Tue, Jan 25, 2022 at 10:44 PM Oskari Lemmela  wrote:
>
> Current mikrotik ath79 devices do not use switch drivers.
> Enable the QCA8K driver and disable the old AR8126 phy.
>
> Signed-off-by: Oskari Lemmela 
> ---
>  target/linux/ath79/mikrotik/config-default | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/target/linux/ath79/mikrotik/config-default 
> b/target/linux/ath79/mikrotik/config-default
> index 2ff8a14f1d..175c4fac1f 100644
> --- a/target/linux/ath79/mikrotik/config-default
> +++ b/target/linux/ath79/mikrotik/config-default
> @@ -1,3 +1,5 @@
> +CONFIG_AR8216_PHY=n
> +CONFIG_AR8216_PHY_LEDS=n
should be # ... is not set
>  CONFIG_CRC16=y
>  CONFIG_CRYPTO_DEFLATE=y
>  CONFIG_GPIO_LATCH=y
> @@ -27,6 +29,8 @@ CONFIG_MTD_UBI_BLOCK=y
>  CONFIG_MTD_UBI_WL_THRESHOLD=4096
>  CONFIG_MTD_UBI_BEB_LIMIT=20
>  CONFIG_NET_DSA=y
> +CONFIG_NET_DSA_QCA8K=y
> +CONFIG_NET_DSA_TAG_QCA=y
>  CONFIG_NET_SWITCHDEV=y
>  CONFIG_PCI_AR71XX=y
>  CONFIG_PHY_AR7100_USB=y
> --
> 2.25.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] toolchain/gcc: set dialects for each version

[Rosen Penev]

On Tue, Jan 25, 2022 at 9:06 AM Stijn Tintel  wrote:
>
> GCC has an option "-std=" to set the language standard for C and C++.
> Newer GCC versions sometimes switch to newer standards by default. This
> has the potential to break the OpenWrt toolchain build whenever a distro
> introduces a new GCC version that uses a newer dialect by default.
>
> Let's set the default dialects used for each of the GCC versions we
> support, to avoid these toolchain build failures in the future.
>
> Signed-off-by: Stijn Tintel 
> ---
>  toolchain/gcc/common.mk | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
> index bef4fa37f8..3e31a139cd 100644
> --- a/toolchain/gcc/common.mk
> +++ b/toolchain/gcc/common.mk
> @@ -29,14 +29,20 @@ PKG_SOURCE_URL:=@GNU/gcc/gcc-$(PKG_VERSION)
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
>
>  ifeq ($(PKG_VERSION),8.4.0)
> +  C_DIALECT=-std=gnu17
> +  CXX_DIALECT=-std=gnu++14
>PKG_HASH:=e30a6e52d10e1f27ed55104ad233c30bd1e99cfb5ff98ab022dc941edd1b2dd4
>  endif
>
>  ifeq ($(PKG_VERSION),10.3.0)
> +  C_DIALECT=-std=gnu17
> +  CXX_DIALECT=-std=gnu++14
>PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344
>  endif
>
>  ifeq ($(PKG_VERSION),11.2.0)
> +  C_DIALECT=-std=gnu17
> +  CXX_DIALECT=-std=gnu++17
I mentioned this on IRC. GCC8 is the first version to support
std=c++17. prereq-build says GCC6 which supports c++1z.
>PKG_HASH:=d08edc536b54c372a1010ff6619dd274c0f1603aa49212ba20f7aa2cda36fa8b
>  endif
>
> @@ -86,6 +92,8 @@ GCC_CONFIGURE:= \
> CFLAGS="-O2 -fbracket-depth=512 -pipe" \
> CXXFLAGS="-O2 -fbracket-depth=512 -pipe" \
> ) \
> +   CFLAGS="$(CFLAGS) $(C_DIALECT)" \
> +   CXXFLAGS="$(CXXFLAGS) $(CXX_DIALECT)" \
> $(HOST_SOURCE_DIR)/configure \
> --with-bugurl=$(BUGURL) \
> --with-pkgversion="$(PKGVERSION)" \
> --
> 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: Switch issues and CI to GitHub

[Rosen Penev]

On Fri, Jan 7, 2022 at 1:38 AM Paul Spooren  wrote:
>
> Hi all,
>
> Back at the Hamburg meeting in 2019 and a succeeding vote we decided to 
> migrate over to a self-hosted GitLab instance. Some years passed and nothing 
> really happened so I’d like to give this another go.
>
> None of the OpenWrt project members is willing to setup and maintain a GitLab 
> instance and there were multiple vetos again gitlab.com.
>
> Our current bug tracker at bugs.openwrt.org is used by a minority of users 
> (and devs), all community repositories (LuCI, packages, …) use GitHub for 
> issue tracking. Instead of maintaining flyspray and the server, I’d like to 
> export all flyspray issues, migrate them to GitHub and open GitHub issues for 
> openwrt/openwrt to the public. A static or read-only version of flyspray 
> could be hosted for the near future.
>
> Secondly I’d like to give the CI of the main repository another go. Our CI to 
> build Docker images is currently on gitlab.com, I’d migrate that over to 
> GitHub. Also I’d suggest to add similar CI checks as added to the packages 
> (and routing and video and LuCI) repository. We could compile targets and 
> tooling, check checksums etc, even build snapshots to lower the resource 
> usage of our Buildbot infrastructure.
>
> During a recent _poll_ in #openwrt-adm multiple members liked the idea, 
> however before doing or voting on anything, I’d like to ask for more comments.
+1 for github.

https://www.gnu.org/software/repo-criteria-evaluation.html seems to be
complete garbage. Seems the higher the criteria, the less users.
>
> Thanks for all feedback,
> 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: [PATCH] ramips: add support for Zbtlink ZBT-WG1602

[Rosen Penev]

On Tue, Nov 16, 2021 at 2:14 AM Sergey Ryazanov  wrote:
>
> Zbtlink ZBT-WG1602 is a Wi-Fi router intendent to use with WWAN
> (UMTS/LTE/3G/4G) modems. The router board offsers a couple of miniPCIe
> slots with USB and SIM only and another one pure miniPCIe slot as well
> as five Gigabit Ethernet ports (4xLAN + WAN).
>
> Specification:
>
> * SoC: MT7621A
> * RAM: 256/512 MiB
> * Flash: 16/32 MiB (SPI NOR)
> * external watchdog (looks like Torexsemi XC6131B)
> * Eth: 10/100/100 Mbps Ethernet x5 ports (4xLAN + WAN)
> * WLAN 2GHz: MT7603EN (.11n, MIMO 2x2)
> * WLAN 5GHz: MT7612EN (.11ac, MIMO 2x2)
> * WLAN Ants: detachable x2, shared by 2GHz & 5GHz radios
> * miniPCIe: 2x slots with USB + 1x slot with regular PCIe bus
> * WWAN Ants: detachable x4
> * External storage: microSD (SDXC) slot
> * USB: 2.0 Type-A port
> * LED: 11 (5 per Eth phy, 3 SoC controlled, 2 WLAN 2/5 controlled, 1
>power indicator)
switch LEDs can be controlled now. See
https://github.com/openwrt/openwrt/commit/360c181dd747f033cb61f83915ce277c6497720f
> * Button: 1 (reset)
> * UART: console (115200 baud)
> * Power: DC jack (12 V / 2.5 A)
>
> Additional HW information:
>
> * SoC USB port #1 is shared by internal miniPCIe slot and external
>   Type-A USB port, USB D+/D- lines are toggled between ports using a
>   GPIO controlled DPDT switch.
> * Power of the USB enabled miniPCIe slots can be individually controlled
>   using dedicated GPIO lines.
> * Vendor firmware feeds the external watchdog with 1s pulses. GPIO
>   watchdog driver is able to either generate a 1us pulses or toggle the
>   output line. 1us is not enough for the external watchod timer, so
>   the line toggling driver mode is utilized.
>
> Installation:
>
> Vendor's firmware is OpenWrt (LEDE) based, so the sysupgrade image can
> be directly used to install OpenWrt. Firmware must be upgraded using the
> 'force' and 'do not save configuration' command line options (or
> correspondig web interface checkboxes) since the vendor firmware is from
> the pre-DSA era.
>
> Signed-off-by: Sergey Ryazanov 
> ---
>  .../dts/mt7621_zbtlink_zbt-wg1602-16m.dts |  10 +
>  .../ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi | 206 ++
>  target/linux/ramips/image/mt7621.mk   |  12 +
>  3 files changed, 228 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
>  create mode 100644 target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
>
> diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts 
> b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
> new file mode 100644
> index 00..216c7b3cf0
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
> @@ -0,0 +1,10 @@
> +#include "mt7621_zbtlink_zbt-wg1602.dtsi"
> +
> +/ {
> +   compatible = "zbtlink,zbt-wg1602-16m", "zbtlink,zbt-wg1602", 
> "mediatek,mt7621-soc";
> +   model = "Zbtlink ZBT-WG1602 (16M)";
> +};
> +
> + {
> +   reg = <0x5 0xfb>;
> +};
> diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi 
> b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
> new file mode 100644
> index 00..e377a13444
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
> @@ -0,0 +1,206 @@
> +#include "mt7621.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> +   compatible = "zbtlink,zbt-wg1602", "mediatek,mt7621-soc";
> +
> +   aliases {
> +   led-boot = _sm;
> +   led-failsafe = _sm;
> +   led-running = _sm;
> +   led-upgrade = _sm;
> +   label-mac-device = 
> +   };
> +
> +   chosen {
> +   bootargs = "console=ttyS0,115200";
> +   };
> +
> +   keys {
> +   compatible = "gpio-keys";
> +
> +   reset {
> +   label = "reset";
> +   gpios = < 18 GPIO_ACTIVE_LOW>;
> +   linux,code = ;
> +   };
> +   };
> +
> +   leds {
> +   compatible = "gpio-leds";
> +
> +   led_sm: sm {
> +   label = "green:sm";
> +   gpios = < 4 GPIO_ACTIVE_LOW>;
> +   };
> +
> +   4g1 {
> +   label = "green:4g1";
> +   gpios = < 10 GPIO_ACTIVE_LOW>;
> +   };
> +
> +   4g2 {
> +   label = "green:4g2";
> +   gpios = < 12 GPIO_ACTIVE_LOW>;
> +   };
> +   };
> +
> +   watchdog {
> +   compatible = "linux,wdt-gpio";
> +   gpios = < 3 GPIO_ACTIVE_HIGH>;
> +   hw_algo = "toggle";
> +   /* hw_margin_ms is actually ~120s but driver limits it to 60s 
> */
> +   hw_margin_ms = <6>;
> +   always-running;
> +   };
> +
> +   gpio-export {
> +   compatible = "gpio-export";
> +   #size-cells = <0>;
> +
> + 

Re: warning about which deprecated

[Rosen Penev]

On Sun, Nov 7, 2021 at 10:14 PM Rosen Penev  wrote:
>
> On Sun, Nov 7, 2021 at 12:32 PM Ansuel Smith  wrote:
> >
> > Il giorno dom 7 nov 2021 alle ore 19:18 Bjørn Mork  ha 
> > scritto:
> > >
> > > Ansuel Smith  writes:
> > >
> > > > Updating to latest ubuntu devel this now comes up
> > > > /home/ansuel/openwrt/staging_dir/host/bin/which: this version of
> > > > `which' is deprecated; use `command -v' in scripts instead.
> > > >
> > > > I think we have to update something?
> > >
> > > See https://lwn.net/SubscriberLink/874049/b563dc08d4eb5829/ for the full
> > > story.
> > >
> > >
> > > Bjørn
> >
> > Should we consider building it as a toolchain tool or should we migrate to
> > command -v ?
> https://github.com/openwrt/openwrt/commit/1f5e7224868109a170a9248d18f8d2b6124e9c5a
Wonder if switching command -v to type -a -p makes sense.
> >
> > ___
> > 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: warning about which deprecated

[Rosen Penev]

On Sun, Nov 7, 2021 at 12:32 PM Ansuel Smith  wrote:
>
> Il giorno dom 7 nov 2021 alle ore 19:18 Bjørn Mork  ha scritto:
> >
> > Ansuel Smith  writes:
> >
> > > Updating to latest ubuntu devel this now comes up
> > > /home/ansuel/openwrt/staging_dir/host/bin/which: this version of
> > > `which' is deprecated; use `command -v' in scripts instead.
> > >
> > > I think we have to update something?
> >
> > See https://lwn.net/SubscriberLink/874049/b563dc08d4eb5829/ for the full
> > story.
> >
> >
> > Bjørn
>
> Should we consider building it as a toolchain tool or should we migrate to
> command -v ?
https://github.com/openwrt/openwrt/commit/1f5e7224868109a170a9248d18f8d2b6124e9c5a
>
> ___
> 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] config: Activate SECCOMP also on MIPS 64

[Rosen Penev]

On Mon, Nov 1, 2021 at 10:05 AM Hauke Mehrtens  wrote:
>
> This activates SECCOMP also on mips64 and mips64el.
>
> This was working fine in a basic test in qemu.
>
> Signed-off-by: Hauke Mehrtens 
> ---
>
> I only did very basic testing, why was this not activated in the beginning?
>
>
>  config/Config-build.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/config/Config-build.in b/config/Config-build.in
> index a028ebfbc37a..9bef36e53ea1 100644
> --- a/config/Config-build.in
> +++ b/config/Config-build.in
> @@ -376,7 +376,7 @@ menu "Global build settings"
> bool "Enable SECCOMP"
> select KERNEL_SECCOMP
> select PACKAGE_procd-seccomp
> -   depends on (aarch64 || arm || armeb || mips || mipsel || i386 
> || powerpc || x86_64)
> +   depends on (aarch64 || arm || armeb || mips || mipsel || 
> mips64 || mips64el || i386 || powerpc || x86_64)
this should be changed to !arc. It's the only platform with no support.
> depends on !TARGET_uml
> default y
> help
> --
> 2.30.2
>
>
> ___
> 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: Marvell EBU 32-bit performance benchmarks (VFPv3-D16 vs NEON builds, Turris Omnia).

[Rosen Penev]

On Thu, Oct 21, 2021 at 12:19 PM Kabuli Chana  wrote:
>
> For me the argument was not about whether there should 2, but whether
> the change to vfpv3-d16 was the right choice as the 1. openssl is of
> course preordained to run NEON SIMD code so no change would be expected,
> but a benefit is seen on WG. I would suggest that is the result of 16
> vs. 32 FP registers being available, and nothing to do with NEON; i.e.
> vfpv3-d16 vs. vfpv3. The result being smaller and faster due to more
> concise FP code generation due to less FP register rejigging.
I call BS.

WireGuard does not use floating point.Just fixed point arithmetic,
like most crypto. WireGuard being faster probably has to do with its
usage of NEON assembly.
>
> On 2021-10-21 09:38, Rui Salvaterra wrote:
> > Hi, guys,
> >
> > So, last meeting I proposed splitting the 32-bit mvebu target in
> > vfpv3-d16 and neon subtargets. It seems this subject comes up every
> > couple of years, or so. This time I hope to show solid evidence on why
> > it would be an exercise in futility, closing the matter once and for
> > all. In order to do so, I tested the performance of openssl speed (10
> > seconds time limit), cryptsetup benchmark and iperf3 over WireGuard.
> > Here are the results for each build:
> >
> > VFPv3-D16:
> > https://paste.debian.net/1216262/
> >
> > NEON:
> > https://paste.debian.net/1216261/
> >
> > These are master builds from my stmvebu branch, running Linux 5.10.75.
> > The configuration is custom, but each build differs only in the
> > CPU_SUBTYPE (vfpv3-d16 vs neon).
> >
> > Cheers,
> > Rui
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [PATCH] libubox: remove support for jsoncpp

[Rosen Penev]

ping

On Thu, Dec 24, 2020 at 5:12 PM Rosen Penev  wrote:
>
> jsoncpp requires a C++ compiler instead of a C one. Fixes the following
> build error:
>
> fatal error: cstddef: No such file or directory
>  '#include 
>
> Issue was discovered on the buildbots where an SDK contained a broken
> pkgconf. Make json-c required in order to not even attempt compilation
> when json-c is missing.
>
> Signed-off-by: Rosen Penev 
> ---
>  CMakeLists.txt | 7 ++-
>  blobmsg_json.c | 6 +-
>  jshn.c | 6 +-
>  3 files changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 1a1b7d5..34a98bd 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -15,11 +15,8 @@ OPTION(BUILD_LUA "build Lua plugin" ON)
>  OPTION(BUILD_EXAMPLES "build examples" ON)
>
>  INCLUDE(FindPkgConfig)
> -PKG_SEARCH_MODULE(JSONC json-c)
> -IF(JSONC_FOUND)
> -  ADD_DEFINITIONS(-DJSONC)
> -  INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
> -ENDIF()
> +PKG_SEARCH_MODULE(JSONC json-c REQUIRED)
> +INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
>
>  SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
> ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c 
> base64.c)
>
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index dce81e9..35bdc21 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -17,11 +17,7 @@
>  #include "blobmsg.h"
>  #include "blobmsg_json.h"
>
> -#ifdef JSONC
> -   #include 
> -#else
> -   #include 
> -#endif
> +#include 
>
>  bool blobmsg_add_object(struct blob_buf *b, json_object *obj)
>  {
> diff --git a/jshn.c b/jshn.c
> index 1b685e5..061fc7f 100644
> --- a/jshn.c
> +++ b/jshn.c
> @@ -13,11 +13,7 @@
>   * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>   */
> -#ifdef JSONC
> -#include 
> -#else
> -#include 
> -#endif
> +#include 
>
>  #include 
>  #include 
> --
> 2.29.2
>

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

Re: Release goals for 22.XX

[Rosen Penev]

On Wed, Oct 6, 2021 at 10:46 AM Rui Salvaterra  wrote:
>
> Hi, Rich,
>
> On Wed, 6 Oct 2021 at 17:54, Rich Brown  wrote:
> >
> > Paul, Rafał,
> >
> > I think our emails passed in the ether... 
> > (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html)
> >
> > As I said in that message, I am very aware of the time constraints of the 
> > volunteers for OpenWrt. And I don't mean to suck the conversation into 
> > "grand strategies" without any endpoint.
> >
> > Let's focus on our next step. In my earlier note, I asked:
> >
> > 1) What would prevent us from accomplishing the 22.XX Release Goals in 
> > March 2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx)
> >
> > - How do we see the time between now and March playing out?
> > - Are there things we should leave out? Or should the release date be 
> > shifted?
>
> I think the target date is fine, as long as we don't try to bite more
> than we can chew. :)
> I'm a bit wary of the firewall4 migration, to be honest. Do we have
> performance numbers comparing nftables vs iptables, for complex rule
> sets? I'm asking because nftables can be slower than iptables [1], in
> at least in some scenarios.
>
> I also believe the priority should be to get all targets at 5.10 by
> default and to drop those which are stuck at 5.4 for some reason
> (small flash/RAM, unmaintained, etc.). And a dropped target doesn't
> mean it's gone forever, it can always be revived in the future, with
> enough interest, talent and Git. :) With this out of the way, bumping
> mac80211 to 5.15 is probably the hardest task at hand and, after it's
> done, I think we're release-worthy. Anything else (say, DSA for ath79
> targets with qca8k switches) would be a nice bonus, but never a
> release blocker.
As a sidenote, more testers are needed for it. There's also the issue
of LED configuration. Colors are not easy to figure out. Some configs
are totally bogus as well.
>
> Just my 0.02 €. Thoughts?
>
> Thanks,
> Rui
>
> [1] https://www.phoronix.com/scan.php?page=news_item=BPFILTER-2021
>
> ___
> 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: RFC: toolchain for building eBPF modules within the OpenWrt build system

[Rosen Penev]

On Sun, Oct 3, 2021 at 5:47 AM Felix Fietkau  wrote:
>
>
> Hi,
>
> I recently spent some time digging into what's needed for proper eBPF
> build support in OpenWrt. Here's what I found so far:
>
> Most out-of-tree eBPF based projects fork some of the BPF related kernel
> headers from various different kernel versions and manually maintain
> those forks. These header files are usually very incomplete and tailored
> specifically for the project that uses them. To make things even worse,
> they typically explicitly rely on including headers from the local x86
> host toolchain header files when building for the BPF target.
>
> The in-kernel build of BPF modules is weird in a different way. It
> explicitly includes all the header files from the arch that the kernel
> is being built for. And because a lot of assembly stuff in there is
> completely incompatible with building for the BPF target, the build
> system actually targets clang to the same arch that the kernel is being
> built for and only emits un-optimized LLVM bitcode without running any
> of the LLVM passes. It then passes that bitcode to the optimizer and
> target code generator with bpf specified as target arch.
> It's a weird hack, but it seems to work properly even when
> cross-compiling to non-x86 targets.
>
> When writing ebpf modules myself, I definitely don't want to rely on the
> crappy header fork mess that most out-of-tree projects use. In my tests
> it was simply too fragile, and I couldn't get it to work on my macOS
> build host either. Even if we could make it work for more use cases, it
> would still be a maintenance hell when comes to supporting more features
> and newer kernel versions.
>
> I think staying close to the way that in-tree BPF module builds work is
> the way to go. Unfortunately, this means that we will not be able to use
> GCC for BPF (which Daniel has been working on), because targeting the
> frontend and the rest of the compiler to different architectures is only
> supported by clang/LLVM.
>
> I just did a test build of LLVM with reduced features and targetting
> only BPF, and it takes around 42 minutes to build on my 2018 macbook.
> That's more than the time needed to build a typical basic OpenWrt build
> from scratch.
>
> The way I see it, these are our options for eBPF support:
>
> 1. Add a host dependency on a recent enough LLVM version for eBPF.
> 1a) disable it by default
> 1b) hide eBPF packages unless host support is available
> 2. Add llvm to tools/ to ensure that it is only built once, even when
> switching between targets
> 3. Add llvm as a host package and use build-dependencies in eBPF
> 4. Ship precompiled big and little endian eBPF binaries + scripts to
> recompile in packages, and rely on CO-RE (compile once, run everywhere)
>
> What do you think?
I've been thinking of adding a toolchain/llvm section before. I don't
know how realistic it would be or if it solves the eBPF issue.
>
> - Felix
>
> ___
> 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: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out

[Rosen Penev]

On Sun, Oct 3, 2021 at 5:18 AM Adrian Schmutzler
 wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of daxiong
> > Sent: Sonntag, 3. Oktober 2021 13:35
> > To: openwrt-devel@lists.openwrt.org
> > Subject: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit
> > queue 0 timed out
> >
> > Use flow control or BQL maybe lead to bug.
> > Iperf3 was usedfor 24 hours, Transmit Queue 0 timed out may occur.
> >  example:
> >Server: iperf3 -s
> >Client: iperf3 -c 172.16.10.20
> >
> > Signed-off-by: daxiong 
>
> Is this your (full) real name?
daxiong = big bear. So probably not.
>
> Best
>
> Adrian
>
> > ---
> >  ...iatek-ethernet-transmit-queue-timeout-bug.patch | 109
> > +
> >  1 file changed, 109 insertions(+)
> >  create mode 100644 target/linux/ramips/patches-5.4/500-mediatek-
> > ethernet-transmit-queue-timeout-bug.patch
> >
> > diff --git a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-
> > transmit-queue-timeout-bug.patch b/target/linux/ramips/patches-5.4/500-
> > mediatek-ethernet-transmit-queue-timeout-bug.patch
> > new file mode 100644
> > index 000..d5da9e4
> > --- /dev/null
> > +++ b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-
> > que
> > +++ ue-timeout-bug.patch
> > @@ -0,0 +1,109 @@
> > +--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> > 18:46:25.065801660 +0800
> >  b/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> > 19:13:24.931017393 +0800
> > +@@ -26,6 +26,11 @@
> > +
> > + #include "mtk_eth_soc.h"
> > +
> > ++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0
> > ++timed out //Bug fixed: BQL and FC maybe QUEUE to be stopped forever
> > ++#define DISABLE_MTK_BQL //disable Byte Queue Limit #define
> > ++DISABLE_MTK_FC  //disable Flow Control
> > ++
> > + static int mtk_msg_level = -1;
> > + module_param_named(msg_level, mtk_msg_level, int, 0);
> > +MODULE_PARM_DESC(msg_level, "Message level
> > +(-1=defaults,0=none,...,16=all)");
> > +@@ -380,6 +385,10 @@ static void mtk_mac_config(struct phylin
> > + mcr_new |= MAC_MCR_FORCE_RX_FC;
> > + }
> > +
> > ++#ifdef DISABLE_MTK_FC
> > ++mcr_new &= ~(MAC_MCR_FORCE_RX_FC |
> > MAC_MCR_FORCE_TX_FC);
> > ++#endif
> > ++
> > + /* Only update control register when needed! */
> > + if (mcr_new != mcr_cur)
> > + mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
> > @@ -535,8 +544,10
> > +@@ static void mtk_validate(struct phylink_
> > + }
> > + }
> > +
> > ++#ifndef DISABLE_MTK_FC
> > + phylink_set(mask, Pause);
> > + phylink_set(mask, Asym_Pause);
> > ++#endif
> > +
> > + linkmode_and(supported, supported, mask);
> > + linkmode_and(state->advertising, state->advertising, mask); @@
> > +-1071,8 +1082,10 @@ static int mtk_tx_map(struct sk_buff *sk
> > + txd_pdma->txd2 |= TX_DMA_LS1;
> > + }
> > +
> > ++#ifndef DISABLE_MTK_BQL
> > + netdev_sent_queue(dev, skb->len);
> > + skb_tx_timestamp(skb);
> > ++#endif
> > +
> > + ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
> > + atomic_sub(n_desc, >free_count); @@ -1496,7 +1509,9 @@
> > static
> > +int mtk_poll_tx(struct mtk_eth *e
> > + for (i = 0; i < MTK_MAC_COUNT; i++) {
> > + if (!eth->netdev[i] || !done[i])
> > + continue;
> > ++#ifndef DISABLE_MTK_BQL
> > + netdev_completed_queue(eth->netdev[i], done[i],
> > bytes[i]);
> > ++#endif
> > + total += done[i];
> > + eth->tx_packets += done[i];
> > + eth->tx_bytes += bytes[i];
> > +--- a/drivers/net/dsa/mt7530.c   2021-10-03 18:47:00.077800119 +0800
> >  b/drivers/net/dsa/mt7530.c   2021-10-03 19:13:37.807016826 +0800
> > +@@ -22,6 +22,8 @@
> > +
> > + #include "mt7530.h"
> > +
> > ++#define DISABLE_MTK_FC  //disable Flow Control
> > ++
> > + /* String, offset, and register size in bytes if different from 4
> > +bytes */  static const struct mt7530_mib_desc mt7530_mib[] = {
> > + MIB_DESC(1, 0x00, "TxDrop"),
> > +@@ -1281,6 +1283,18 @@ mt7530_setup(struct dsa_switch *ds)
> > + val |= MHWTRAP_MANUAL;
> > + mt7530_write(priv, MT7530_MHWTRAP, val);
> > +
> > ++#ifdef DISABLE_MTK_FC
> > ++usleep_range(10, 20);
> > ++
> > ++val = mt7530_read(priv, 0x1FE0);
> > ++val &= ~BIT(31);
> > ++mt7530_write(priv, 0x1FE0, val);
> > ++
> > ++mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
> > ++mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
> > ++usleep_range(10, 20);
> > ++#endif
> > ++
> > + priv->p6_interface = PHY_INTERFACE_MODE_NA;
> > +
> > + /* Enable and reset MIB counters */
> > +@@ -1427,6 +1441,10 @@ static void mt7530_phylink_mac_config(st
> > + mcr_new |= PMCR_RX_FC_EN;
> > + }
> > +
> > ++#ifdef DISABLE_MTK_FC
> > ++mcr_new &= 

[PATCH] tools/firmware-utils: remove all std= settings

[Rosen Penev]

The minimum GCC today is GCC6, which defaults to gnu11. Compatibility
with older compilers is not needed.

Also removed fgnu89-inline. I have no idea why this was kept. Easier to
just fix the issue.

Added byteswap header to avoid warning about missing bswap_32 on some
platforms.

Signed-off-by: Rosen Penev 
---
 tools/firmware-utils/Makefile | 16 
 tools/firmware-utils/src/mktplinkfw-lib.h |  8 
 tools/firmware-utils/src/mktplinkfw.c |  1 +
 3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index d5b0816816..a9e500cee2 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -7,7 +7,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME := firmware-utils
-PKG_RELEASE := 11
+PKG_RELEASE := 12
 
 include $(INCLUDE_DIR)/host-build.mk
 include $(INCLUDE_DIR)/kernel.mk
@@ -54,7 +54,7 @@ define Host/Compile
$(call cc,mkdapimg,-Wall)
$(call cc,mkdapimg2,-Wall)
$(call cc,mkdhpimg buffalo-lib,-Wall)
-   $(call cc,mkdlinkfw mkdlinkfw-lib,-lz -Wall --std=c99)
+   $(call cc,mkdlinkfw mkdlinkfw-lib,-lz -Wall)
$(call cc,mkdniimg,-Wall)
$(call cc,mkedimaximg,-Wall)
$(call cc,mkfwimage,-lz -Wall -Werror -Wextra -D_FILE_OFFSET_BITS=64)
@@ -66,13 +66,13 @@ define Host/Compile
$(call cc,mkmylofw,-Wall)
$(call cc,mkplanexfw sha1,-Wall)
$(call cc,mkporayfw,-Wall)
-   $(call cc,mkrasimage,--std=gnu99 -Wall)
+   $(call cc,mkrasimage,-Wall)
$(call cc,mkrtn56uimg,-lz -Wall)
-   $(call cc,mksenaofw md5,-Wall --std=gnu99)
+   $(call cc,mksenaofw md5,-Wall)
$(call cc,mksercommfw,-Wall)
$(call cc,mktitanimg,-Wall)
-   $(call cc,mktplinkfw mktplinkfw-lib md5,-Wall -fgnu89-inline)
-   $(call cc,mktplinkfw2 mktplinkfw-lib md5,-Wall -fgnu89-inline)
+   $(call cc,mktplinkfw mktplinkfw-lib md5,-Wall)
+   $(call cc,mktplinkfw2 mktplinkfw-lib md5,-Wall)
$(call cc,mkwrggimg md5,-Wall)
$(call cc,mkwrgimg md5,-Wall)
$(call cc,mkzcfw cyg_crc32,-Wall)
@@ -80,7 +80,7 @@ define Host/Compile
$(call cc,mkzyxelzldfw md5,-Wall)
$(call cc,motorola-bin,-Wall)
$(call cc,nand_ecc,-Wall)
-   $(call cc,nec-enc,-Wall --std=gnu99)
+   $(call cc,nec-enc,-Wall)
$(call cc,osbridge-crc,-Wall)
$(call cc,oseama md5,-Wall)
$(call cc,otrx,-Wall)
@@ -90,7 +90,7 @@ define Host/Compile
$(call cc,sign_dlink_ru md5,-Wall)
$(call cc,spw303v,-Wall)
$(call cc,srec2bin)
-   $(call cc,tplink-safeloader md5,-Wall --std=gnu99)
+   $(call cc,tplink-safeloader md5,-Wall)
$(call cc,trx,-Wall)
$(call cc,trx2edips,-Wall)
$(call cc,trx2usr,-Wall)
diff --git a/tools/firmware-utils/src/mktplinkfw-lib.h 
b/tools/firmware-utils/src/mktplinkfw-lib.h
index 2003908cf9..a46a16f8f3 100644
--- a/tools/firmware-utils/src/mktplinkfw-lib.h
+++ b/tools/firmware-utils/src/mktplinkfw-lib.h
@@ -55,10 +55,10 @@ void get_md5(const char *data, int size, uint8_t *md5);
 int get_file_stat(struct file_info *fdata);
 int read_to_buf(const struct file_info *fdata, char *buf);
 int write_fw(const char *ofname, const char *data, int len);
-inline void inspect_fw_pstr(const char *label, const char *str);
-inline void inspect_fw_phex(const char *label, uint32_t val);
-inline void inspect_fw_phexdec(const char *label, uint32_t val);
-inline void inspect_fw_pmd5sum(const char *label, const uint8_t *val, const 
char *text);
+void inspect_fw_pstr(const char *label, const char *str);
+void inspect_fw_phex(const char *label, uint32_t val);
+void inspect_fw_phexdec(const char *label, uint32_t val);
+void inspect_fw_pmd5sum(const char *label, const uint8_t *val, const char 
*text);
 int build_fw(size_t header_size);
 
 #endif /* mktplinkfw_lib_h */
diff --git a/tools/firmware-utils/src/mktplinkfw.c 
b/tools/firmware-utils/src/mktplinkfw.c
index e6d76a1942..16eff49d1f 100644
--- a/tools/firmware-utils/src/mktplinkfw.c
+++ b/tools/firmware-utils/src/mktplinkfw.c
@@ -7,6 +7,7 @@
  *   Copyright (C) 2008,2009 Wang Jian 
  */
 
+#include 
 #include 
 #include 
 #include 
-- 
2.31.1


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

Re: Release goals for 22.XX

[Rosen Penev]

On Fri, Oct 1, 2021 at 3:05 PM Hauke Mehrtens  wrote:
>
> On 9/30/21 10:40 PM, Paul Spooren wrote:
> >
> > On 9/30/21 10:01, Nick wrote:
> >>
> >> On 9/30/21 21:43, Daniel Golle wrote:
> >>> On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:
>  On 30/09/2021 01:19, Nick wrote:
> > On 9/29/21 22:28, Hauke Mehrtens wrote:
> >
> >> kernel 5.10:
> >> We should get all targets to kernel 5.10. All targets which are not
> >> on kernel 5.10 when we branch off should get removed.
> > Kernel 5.15 could be also a LTS Kernel that should be released in the
> > end of October? Why not aiming for it if we plan to release in 2022?
>  This would undoubtedly delay the next release, as we've seen in the
>  past. We don't even have all targets on 5.10, which was released
>  roughly
>  9 months ago. You do the math. If we target 5.15, I doubt we'll even
>  see
>  a release in 2022.
> >>> I also believe we should do the next release based on Linux 5.10 and
> >>> try branching still this year (which I believe is realistic to make all
> >>> targets build with 5.10 till then), so we can target April 2022 as time
> >>> of release.
>
> I agree with you Daniel and think this timeline is reasonable.
>
> >> Sounds good, so we can go on with 5.15 when it is released?
> >
> > Some targets already moved to 5.10 as default, feel free to add 5.15 as
> > the new TESTING kernel there.
>
> I am against adding support for kernel 5.15 now, we should better wait
> till after we branched the relase off.
>
> >
> >> I think the most problematic thing is if we want to have DSA support
> >> for all targets as requirement. Not sure if this is possible.
> >
> > It seems fine found a okay'ish middle ground between DSA and non-DSA, so
> > I'd not make DSA blocking for the next release but continue to integrate
> > it where ever possible (and stable).
>
> I think we will never convert all swconfig drivers to DSA. I do not
> think anyone will invest the time to write a DSA driver for the ADM6996L
> chip for example. It could be that we just remove support for the last
> boards which still use swconfig in some years.
Not that many look like they can get DSA treatment. With realtek
switches, only RTL8366RB seems supported upstream. ar8216 can be
replaced by qca8k currently but lots of testing is needed. I have no
idea about mediatek and why it has an swconfig driver when there's a
DSA one upstream.
>
> Hauke
> ___
> 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: Release goals for 22.XX

[Rosen Penev]

On Thu, Sep 30, 2021 at 1:05 PM Nick  wrote:
>
>
> On 9/30/21 21:43, Daniel Golle wrote:
> > On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:
> >> On 30/09/2021 01:19, Nick wrote:
> >>> On 9/29/21 22:28, Hauke Mehrtens wrote:
> >>>
>  kernel 5.10:
>  We should get all targets to kernel 5.10. All targets which are not
>  on kernel 5.10 when we branch off should get removed.
> >>> Kernel 5.15 could be also a LTS Kernel that should be released in the
> >>> end of October? Why not aiming for it if we plan to release in 2022?
> >> This would undoubtedly delay the next release, as we've seen in the
> >> past. We don't even have all targets on 5.10, which was released roughly
> >> 9 months ago. You do the math. If we target 5.15, I doubt we'll even see
> >> a release in 2022.
> > I also believe we should do the next release based on Linux 5.10 and
> > try branching still this year (which I believe is realistic to make all
> > targets build with 5.10 till then), so we can target April 2022 as time
> > of release.
> Sounds good, so we can go on with 5.15 when it is released?
> I think the most problematic thing is if we want to have DSA support for
> all targets as requirement. Not sure if this is possible.
Don't think so. I think some platforms will get DSA.
>
> Bests
> Nick
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [PATCH] ath79/ag71xx: rearrange ag71xx structs to remove holes

[Rosen Penev]

On Sun, Sep 26, 2021 at 11:31 AM Rui Salvaterra  wrote:
>
> Hi, David,
>
> On Sun, 26 Sept 2021 at 12:37, David Bauer  wrote:
> >
> > Does this mean parts of this patch are already applied upstream?
>
> Yes, the ag71xx_ring section.
>
> > Also are there already performance numbers available?
>
> Rosen has performance numbers comparing ar71xx to ath79 DSA including
> this patch (with huge improvements [1]), but not for this specific
> patch in isolation, I think. Rosen?

Those benchmarks had this patch. I only changed the switch driver between them.
>
> [1] https://gist.github.com/neheb/5f3636eb8008431239f73613cbf543b6
>
> Thanks,
> Rui

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

[PATCH] linux: backport GPIO LED patch for MT7350

[Rosen Penev]

This allows to specify and control switch LEDs on devices using mt7530
(typically mediatek and ramips targets).

Normally these LED GPIOs are 0, 3, 6, 9, and 12. wan/lan assignment is
per device. GPIO 9 is normally inverted. so GPIO_ACTIVE_HIGH instead of
GPIO_ACTIVE_LOW.

Tested on Linksys E7350.

Renumbered some patches to keep the date of backports.

Refreshed all patches.

Signed-off-by: Rosen Penev 
---
 ...-mt7530-MT7530-optional-GPIO-support.patch | 181 ++
 ...mt7530-Add-support-for-EEE-features.patch} |   6 +-
 ...he-dst-buffer-to-of_get_mac_address.patch} |   0
 ...addr_nvmem-for-non-platform-devices.patch} |   0
 4 files changed, 184 insertions(+), 3 deletions(-)
 create mode 100644 
target/linux/generic/backport-5.10/781-v5.12-net-dsa-mt7530-MT7530-optional-GPIO-support.patch
 rename 
target/linux/generic/backport-5.10/{781-v5.13-net-dsa-mt7530-Add-support-for-EEE-features.patch
 => 782-v5.13-net-dsa-mt7530-Add-support-for-EEE-features.patch} (95%)
 rename 
target/linux/generic/backport-5.10/{782-net-next-1-of-net-pass-the-dst-buffer-to-of_get_mac_address.patch
 => 783-net-next-1-of-net-pass-the-dst-buffer-to-of_get_mac_address.patch} 
(100%)
 rename 
target/linux/generic/backport-5.10/{782-net-next-2-of-net-fix-of_get_mac_addr_nvmem-for-non-platform-devices.patch
 => 
783-net-next-2-of-net-fix-of_get_mac_addr_nvmem-for-non-platform-devices.patch} 
(100%)

diff --git 
a/target/linux/generic/backport-5.10/781-v5.12-net-dsa-mt7530-MT7530-optional-GPIO-support.patch
 
b/target/linux/generic/backport-5.10/781-v5.12-net-dsa-mt7530-MT7530-optional-GPIO-support.patch
new file mode 100644
index 00..6931500c44
--- /dev/null
+++ 
b/target/linux/generic/backport-5.10/781-v5.12-net-dsa-mt7530-MT7530-optional-GPIO-support.patch
@@ -0,0 +1,181 @@
+From 429a0edeefd88cbfca5c417dfb8561047bb50769 Mon Sep 17 00:00:00 2001
+From: DENG Qingfang 
+Date: Mon, 25 Jan 2021 12:43:22 +0800
+Subject: [PATCH] net: dsa: mt7530: MT7530 optional GPIO support
+
+MT7530's LED controller can drive up to 15 LED/GPIOs.
+
+Add support for GPIO control and allow users to use its GPIOs by
+setting gpio-controller property in device tree.
+
+Signed-off-by: DENG Qingfang 
+Reviewed-by: Linus Walleij 
+Reviewed-by: Andrew Lunn 
+Signed-off-by: Jakub Kicinski 
+---
+ drivers/net/dsa/mt7530.c | 110 +++
+ drivers/net/dsa/mt7530.h |  20 +++
+ 2 files changed, 130 insertions(+)
+
+--- a/drivers/net/dsa/mt7530.c
 b/drivers/net/dsa/mt7530.c
+@@ -18,6 +18,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include "mt7530.h"
+@@ -1540,6 +1541,109 @@ mtk_get_tag_protocol(struct dsa_switch *
+   }
+ }
+ 
++static inline u32
++mt7530_gpio_to_bit(unsigned int offset)
++{
++  /* Map GPIO offset to register bit
++   * [ 2: 0]  port 0 LED 0..2 as GPIO 0..2
++   * [ 6: 4]  port 1 LED 0..2 as GPIO 3..5
++   * [10: 8]  port 2 LED 0..2 as GPIO 6..8
++   * [14:12]  port 3 LED 0..2 as GPIO 9..11
++   * [18:16]  port 4 LED 0..2 as GPIO 12..14
++   */
++  return BIT(offset + offset / 3);
++}
++
++static int
++mt7530_gpio_get(struct gpio_chip *gc, unsigned int offset)
++{
++  struct mt7530_priv *priv = gpiochip_get_data(gc);
++  u32 bit = mt7530_gpio_to_bit(offset);
++
++  return !!(mt7530_read(priv, MT7530_LED_GPIO_DATA) & bit);
++}
++
++static void
++mt7530_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
++{
++  struct mt7530_priv *priv = gpiochip_get_data(gc);
++  u32 bit = mt7530_gpio_to_bit(offset);
++
++  if (value)
++  mt7530_set(priv, MT7530_LED_GPIO_DATA, bit);
++  else
++  mt7530_clear(priv, MT7530_LED_GPIO_DATA, bit);
++}
++
++static int
++mt7530_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
++{
++  struct mt7530_priv *priv = gpiochip_get_data(gc);
++  u32 bit = mt7530_gpio_to_bit(offset);
++
++  return (mt7530_read(priv, MT7530_LED_GPIO_DIR) & bit) ?
++  GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN;
++}
++
++static int
++mt7530_gpio_direction_input(struct gpio_chip *gc, unsigned int offset)
++{
++  struct mt7530_priv *priv = gpiochip_get_data(gc);
++  u32 bit = mt7530_gpio_to_bit(offset);
++
++  mt7530_clear(priv, MT7530_LED_GPIO_OE, bit);
++  mt7530_clear(priv, MT7530_LED_GPIO_DIR, bit);
++
++  return 0;
++}
++
++static int
++mt7530_gpio_direction_output(struct gpio_chip *gc, unsigned int offset, int 
value)
++{
++  struct mt7530_priv *priv = gpiochip_get_data(gc);
++  u32 bit = mt7530_gpio_to_bit(offset);
++
++  mt7530_set(priv, MT7530_LED_GPIO_DIR, bit);
++
++  if (value)
++  mt7530_set(priv, MT7530_LED_GPIO_DATA, bit);
++  else
++  mt7530_clear(priv, MT7530_LED_GPIO_DATA, bit);
++
++  mt7530_set(priv, MT7530_LED_GPIO_OE, bit);
++
++  return 0;
++}
++
++static int
++mt7530_setup_gpio(struct mt7530_priv *priv)
++{

[PATCH] tools/libressl: update to 3.4.0

[Rosen Penev]

Signed-off-by: Rosen Penev 
---
 tools/libressl/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libressl/Makefile b/tools/libressl/Makefile
index 29fae1dfb6..7d5f87d041 100644
--- a/tools/libressl/Makefile
+++ b/tools/libressl/Makefile
@@ -8,8 +8,8 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=libressl
-PKG_VERSION:=3.3.4
-PKG_HASH:=bcce767a3fed252bfd1210f8a7e3505a2b54d3008f66e43d9b95e3f30c072931
+PKG_VERSION:=3.4.0
+PKG_HASH:=e52eae758d40206a71d763a1a87b71037223bf1986ac239a6be1a6d2ac3916d2
 PKG_RELEASE:=1
 
 PKG_CPE_ID:=cpe:/a:openbsd:libressl
-- 
2.31.1


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

Re: [PATCH] base-files: fix zoneinfo support

[Rosen Penev]

On Wed, Jun 23, 2021 at 3:40 PM Paul Spooren  wrote:
>
> Hi,
>
> if I'm not mistaken this patch doesn't quite do the trick: You removed
> the removal of /tmp/TZ which seem to be preferred by `hwclock`, meaning
> even if $zonename (aka $zname) is found, /tmp/TZ is still there. As a
> result both /tmp/TZ and /tmp/localtime exists both, allowing the user no
> longer to change the timezone at all, even when typing the "correct"
> entry (i.e. Pacific/Port_Moresby).
Ummm. This script is the one that creates /tmp/TZ in the first place.
/tmp/TZ is an openwrt hack that is used when there are no zoneinfo
files. After this patch, it gets created only if they are missing.
>
> Please send a v2 removing the /tmp/TZ file again iff $zonename exists.
There's no point in removing that which is not present.
>
> On 4/9/21 2:22 PM, Rosen Penev wrote:
> > The system init script currently sets /tmp/localinfo when zoneinfo is
> > populated. However, zoneinfo has spaces in it whereas the actual files
> > have _ instead of spaces. This made the if condition never return true.
> >
> > Example failure when removing the if condition:
> >
> > /tmp/localtime -> /usr/share/zoneinfo/America/Los Angeles
> >
> > This file does not exist. America/Los_Angeles does.
> >
> > Signed-off-by: Rosen Penev 
> > ---
> >   this should be backported to 21.02 and 19.07 as the issue is also
> >   present there. This was tested on 19.07.
> >   package/base-files/files/etc/init.d/system | 10 +++---
> >   1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/package/base-files/files/etc/init.d/system 
> > b/package/base-files/files/etc/init.d/system
> > index 08cf86b97f..b1fc154cec 100755
> > --- a/package/base-files/files/etc/init.d/system
> > +++ b/package/base-files/files/etc/init.d/system
> > @@ -22,9 +22,13 @@ system_config() {
> >
> >   echo "$hostname" > /proc/sys/kernel/hostname
> >   [ -z "$conloglevel" -a -z "$buffersize" ] || dmesg ${conloglevel:+-n 
> > $conloglevel} ${buffersize:+-s $buffersize}
> > - echo "$timezone" > /tmp/TZ
> > - [ -n "$zonename" ] && [ -f "/usr/share/zoneinfo/$zonename" ] && \
> > - ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm 
> > -f /tmp/TZ
> > + if [ -n "$zonename" ]; then
> > + local zname=$(echo "$zonename" | tr ' ' _)
> > + [ -f "/usr/share/zoneinfo/$zname" ] && \
> > + ln -sf "/usr/share/zoneinfo/$zname" /tmp/localtime
> > + else
> > + echo "$timezone" > /tmp/TZ
> > + fi
> >
> >   # apply timezone to kernel
> >   hwclock -u --systz

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

Re: [PATCH] Revert "dbus: update to 1.13.18"

[Rosen Penev]

On Apr 21, 2021, at 10:46, Ansuel Smith  wrote:

>> 
>> This reverts commit 0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92.
>> 
>> root@finn:/# /etc/init.d/dbus start
>> dbus[2537]: Failed to start message bus: Failed to open 
>> "/dbus-1/system.conf": No such file or directory
>> 
> 
> The avahi package is also affected by this breakage and crash loop in
> the current master.

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

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

[Rosen Penev]

On Sat, Apr 17, 2021 at 2:49 PM Sven Roederer  wrote:
>
> Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer:
> > On my Ubuntu 16.04 based build-system I also have build-failures for meson
> > using Python3.5.
>
> Correction: it's a 18.04 LTS ...
GCC6 is now minimum, breaking CentOS 7. That and the make version update.

I tried installing homebrew on CentOS7 but the build system prefers to
use the OS tools...

Speaking of homebrew, you could try that on Ubuntu.
>
> Sven
>
>
>
> ___
> 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] kernel: Disable CONFIG_COMPAT_32BIT_TIME by default

[Rosen Penev]

On Wed, Apr 14, 2021 at 4:47 PM Linus Walleij  wrote:
>
> On Thu, Apr 15, 2021 at 12:49 AM Rosen Penev  wrote:
>
> > time_t is still 32-bit for 32-bit targets. OpenWrt has not migrated to
> > musl 1.2.x.
> >
> > https://github.com/openwrt/openwrt/pull/3004 is a pull request to do
> > so but it seems nobody has looked into merging it.
>
> Oh that's a bummer. I was certain it was migrated...
The only 32-bit arch with a 64-bit time_t is ARC because of glibc. But
ARC equipment is practically nonexistent for the purposes of OpenWrt.
>
> Let's hold this off then.
>
> Yours,
> Linus Walleij

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

Re: [PATCH] kernel: Disable CONFIG_COMPAT_32BIT_TIME by default

[Rosen Penev]

On Wed, Apr 14, 2021 at 6:27 AM Linus Walleij  wrote:
>
> OpenWRT rebuilds the whole userspace from scratch and uses
> recent versions of tools and libraries, thus it should not
> be necessary in general to support CONFIG_COMPAT_32BIT_TIME,
> not even for purely 32bit systems: their updated userspace
> components should be fine with only 64bit time_t.
Funny.

time_t is still 32-bit for 32-bit targets. OpenWrt has not migrated to
musl 1.2.x.

https://github.com/openwrt/openwrt/pull/3004 is a pull request to do
so but it seems nobody has looked into merging it.
>
> As OpenWRT is used as a base for embedded products for the
> future market it is the right default to set.
I agree
>
> Several targets enable this selectively, probably some of
> them should consider disabling it and see what happens.
That's an upstream issue, no?
>
> Cc: Arnd Bergmann 
> Signed-off-by: Linus Walleij 
> ---
>  target/linux/generic/config-5.10 | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/linux/generic/config-5.10 
> b/target/linux/generic/config-5.10
> index 120d1d8c3f4a..024d65ba7c8d 100644
> --- a/target/linux/generic/config-5.10
> +++ b/target/linux/generic/config-5.10
> @@ -939,6 +939,7 @@ CONFIG_CMDLINE=""
>  CONFIG_COMPACTION=y
>  # CONFIG_COMPAL_LAPTOP is not set
>  # CONFIG_COMPAT is not set
> +# CONFIG_COMPAT_32BIT_TIME is not set
>  # CONFIG_COMPAT_BRK is not set
>  # CONFIG_COMPILE_TEST is not set
>  # CONFIG_CONFIGFS_FS is not set
> --
> 2.29.2
>
>
> ___
> 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] RFC: kernel: Remove CFQ activate BFQ

[Rosen Penev]

On Wed, Apr 14, 2021 at 4:46 AM Linus Walleij  wrote:
>
> The CFQ IO scheduler is deleted from the Linux kernel
> since commit f382fb0bcef4c37dc049e9f6963e3baf204d815c
> "block: remove legacy IO schedulers".
>
> The new multiqueue block layer has an IO scheduler named
> BFQ (Budget Fair Queue) that is suitable for slow
> single-queue block devices such as (S)ATA harddrives,
> flash memories, MMC/SD cards and USB dongles, so activate
> that instead.
This should be tested first.

Most OpenWrt routers use squashfs with a jffs2 overlay. Last I tested,
there was no difference in speed. There would be when using USB or
SATA connected drives.
>
> To actually use BFQ by default distributions such as
> Fedora uses this (/lib/udev/rules.d/60-block-scheduler.rules):
>
> ACTION=="add", SUBSYSTEM=="block", \
>   KERNEL=="mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|sd*[!0-9]|sr*", \
>   ATTR{queue/scheduler}="bfq"
>
> We are not using udev so we need a similar rule in a
> similar patch for procd, or we can patch the kernel to
> use BFQ by default if we do not expect people to use
> OpenWRT with enterprise storage arrays.
>
> Signed-off-by: Linus Walleij 
> ---
> This patch is more of an RFC, I am in contact with the
> author of BFQ if we need to discuss its applicability for
> OpenWRT targets. I can make a kernel patch to make BFQ
> the default IO scheduler as well.
Last time I posted a patch messing with IOSCHED it got rejected.
Specifically because it removed all io schedulers except noop, which
seems to perform equal to CFQ last I tested.
> ---
>  target/linux/generic/config-5.10 | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/target/linux/generic/config-5.10 
> b/target/linux/generic/config-5.10
> index 120d1d8c3f4a..fda3ef301dde 100644
> --- a/target/linux/generic/config-5.10
> +++ b/target/linux/generic/config-5.10
> @@ -2601,8 +2601,7 @@ CONFIG_INPUT_MISC=y
>  # CONFIG_INV_MPU6050_SPI is not set
>  # CONFIG_IOMMU_SUPPORT is not set
>  # CONFIG_IONIC is not set
> -# CONFIG_IOSCHED_BFQ is not set
> -# CONFIG_IOSCHED_CFQ is not set
> +CONFIG_IOSCHED_BFQ=y
>  CONFIG_IOSCHED_DEADLINE=y
>  CONFIG_IOSCHED_NOOP=y
>  CONFIG_IO_STRICT_DEVMEM=y
> --
> 2.29.2
>
>
> ___
> 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] libsemanage: fix pkgconfig paths

[Rosen Penev]

The pkgconfig file currently post to host paths.

Signed-off-by: Rosen Penev 
---
 package/libs/libsemanage/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/libs/libsemanage/Makefile 
b/package/libs/libsemanage/Makefile
index ff1519f14e..2fde14c06c 100644
--- a/package/libs/libsemanage/Makefile
+++ b/package/libs/libsemanage/Makefile
@@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=libsemanage
 PKG_VERSION:=3.2
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://github.com/SELinuxProject/selinux/releases/download/3.2
@@ -58,6 +58,8 @@ define Build/InstallDev
$(CP) $(PKG_INSTALL_DIR)/usr/include/* $(1)/usr/include/
$(INSTALL_DIR) $(1)/usr/lib/pkgconfig
$(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/libsemanage.pc 
$(1)/usr/lib/pkgconfig/
+   $(SED) 's,/usr/include,{prefix}/include,g' 
$(1)/usr/lib/pkgconfig/libsemanage.pc
+   $(SED) 's,/usr/lib,{exec_prefix}/lib,g' 
$(1)/usr/lib/pkgconfig/libsemanage.pc
$(INSTALL_DIR) $(1)/usr/lib
$(CP) $(PKG_INSTALL_DIR)/usr/lib/* $(1)/usr/lib/
 endef
-- 
2.30.2


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

Re: [PATCH] fortify-headers: fix compilation with GCC 10.3

[Rosen Penev]

On Tue, Apr 13, 2021 at 3:53 PM Hauke Mehrtens  wrote:
>
> On 4/13/21 6:03 AM, Rosen Penev wrote:
> > For some reason, fortified mempcpy does not work with GCC 10.3. It
> > worked with GCC 10.2.
> >
> > Some output with tvheadend:
> >
> > error: 'mempcpy' undeclared here (not in a function);
> > did you mean 'memccpy'?
> > 144 | _FORTIFY_FN(mempcpy) void *mempcpy(void *__d,
> > const void *__s, size_t __n)
> >  | ^~~
> > note: in definition of macro '_FORTIFY_ORIG'
> > 20 | #define _FORTIFY_ORIG(p,fn)
> > __typeof__(fn) __orig_##fn __asm__(_FORTIFY_STR(p) #fn)
> > note: in expansion of macro
> > '_FORTIFY_FN'
> > 144 | _FORTIFY_FN(mempcpy) void
> > *mempcpy(void *__d, const void *__s, size_t __n)
> > In function 'mempcpy':
> > error: called object '__orig_mempcpy' is not a
> > function or function pointer
> > 151 |  return _orig_mempcpy(__d, __s, __n);
> >
> > Signed-off-by: Rosen Penev 
> > ---
> >   toolchain/fortify-headers/Makefile  |  2 +-
> >   toolchain/fortify-headers/patches/010-mempcpy.patch | 11 +++
> >   2 files changed, 12 insertions(+), 1 deletion(-)
> >   create mode 100644 toolchain/fortify-headers/patches/010-mempcpy.patch
> >
>
> Could you please share your OpenWrt configuration.
It's basically malta - little endian (64-bit) with GCC10 and CONFIG_ALL.

I can post if you really want.
>
> With this configuration it is compiling for me:
> -
> hauke@hauke-t480:~/openwrt/openwrt$ ./scripts/diffconfig.sh
> CONFIG_TARGET_x86=y
> CONFIG_TARGET_x86_64=y
> CONFIG_TARGET_x86_64_DEVICE_generic=y
> CONFIG_DEVEL=y
> CONFIG_TOOLCHAINOPTS=y
> CONFIG_GCC_USE_VERSION_10=y
> # CONFIG_GCC_USE_VERSION_8 is not set
> CONFIG_GCC_VERSION="10.3.0"
> CONFIG_GCC_VERSION_10=y
> CONFIG_OPENSSL_ENGINE=y
> CONFIG_OPENSSL_OPTIMIZE_SPEED=y
> CONFIG_OPENSSL_WITH_ASM=y
> CONFIG_OPENSSL_WITH_CHACHA_POLY1305=y
> CONFIG_OPENSSL_WITH_CMS=y
> CONFIG_OPENSSL_WITH_DEPRECATED=y
> CONFIG_OPENSSL_WITH_ERROR_MESSAGES=y
> CONFIG_OPENSSL_WITH_PSK=y
> CONFIG_OPENSSL_WITH_SRP=y
> CONFIG_OPENSSL_WITH_TLS13=y
> CONFIG_PACKAGE_libopenssl=y
> CONFIG_PACKAGE_tvheadend=y
> CONFIG_PACKAGE_zlib=y
> CONFIG_TVHEADEND_CWC_SUPPORT=y
> CONFIG_TVHEADEND_DVBSCAN_SUPPORT=y
> CONFIG_TVHEADEND_LINUXDVB_SUPPORT=y
> 
>
> This could be similar to the umdns problem which only shows up on 32 bit
> platforms.
>
> Hauke

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

[PATCH] fortify-headers: fix compilation with GCC 10.3

[Rosen Penev]

For some reason, fortified mempcpy does not work with GCC 10.3. It
worked with GCC 10.2.

Some output with tvheadend:

error: 'mempcpy' undeclared here (not in a function);
did you mean 'memccpy'?
144 | _FORTIFY_FN(mempcpy) void *mempcpy(void *__d,
const void *__s, size_t __n)
| ^~~
note: in definition of macro '_FORTIFY_ORIG'
20 | #define _FORTIFY_ORIG(p,fn)
__typeof__(fn) __orig_##fn __asm__(_FORTIFY_STR(p) #fn)
note: in expansion of macro
'_FORTIFY_FN'
144 | _FORTIFY_FN(mempcpy) void
*mempcpy(void *__d, const void *__s, size_t __n)
In function 'mempcpy':
error: called object '__orig_mempcpy' is not a
function or function pointer
151 |  return _orig_mempcpy(__d, __s, __n);

Signed-off-by: Rosen Penev 
---
 toolchain/fortify-headers/Makefile  |  2 +-
 toolchain/fortify-headers/patches/010-mempcpy.patch | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 toolchain/fortify-headers/patches/010-mempcpy.patch

diff --git a/toolchain/fortify-headers/Makefile 
b/toolchain/fortify-headers/Makefile
index a6151bb2f1..bb67c33c30 100644
--- a/toolchain/fortify-headers/Makefile
+++ b/toolchain/fortify-headers/Makefile
@@ -9,7 +9,7 @@ include $(INCLUDE_DIR)/target.mk
 
 PKG_NAME:=fortify-headers
 PKG_VERSION:=1.1
-PKG_RELEASE=1
+PKG_RELEASE=2
 
 PKG_SOURCE_URL:=http://dl.2f30.org/releases
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
diff --git a/toolchain/fortify-headers/patches/010-mempcpy.patch 
b/toolchain/fortify-headers/patches/010-mempcpy.patch
new file mode 100644
index 00..8423395da5
--- /dev/null
+++ b/toolchain/fortify-headers/patches/010-mempcpy.patch
@@ -0,0 +1,11 @@
+--- a/include/string.h
 b/include/string.h
+@@ -139,7 +139,7 @@ _FORTIFY_FN(strncpy) char *strncpy(char
+   return __orig_strncpy(__d, __s, __n);
+ }
+ 
+-#ifdef _GNU_SOURCE
++#if 0
+ #undef mempcpy
+ _FORTIFY_FN(mempcpy) void *mempcpy(void *__d, const void *__s, size_t __n)
+ {
-- 
2.30.2


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

Re: [PATCH] toolchain: gcc: Update to version 10.3.0

[Rosen Penev]

On Sat, Apr 10, 2021 at 3:17 PM Hauke Mehrtens  wrote:
>
> Signed-off-by: Hauke Mehrtens 
Breaks fortify-headers interestingly enough.
> ---
>  toolchain/gcc/Config.version| 2 +-
>  toolchain/gcc/common.mk | 4 ++--
>  .../patches/{10.2.0 => 10.3.0}/002-case_insensitive.patch   | 0
>  .../gcc/patches/{10.2.0 => 10.3.0}/010-documentation.patch  | 0
>  .../patches/{10.2.0 => 10.3.0}/110-Fix-MIPS-PR-84790.patch  | 0
>  .../gcc/patches/{10.2.0 => 10.3.0}/230-musl_libssp.patch| 0
>  .../{10.2.0 => 10.3.0}/300-mips_Os_cpu_rtx_cost_model.patch | 0
>  .../{10.2.0 => 10.3.0}/810-arm-softfloat-libgcc.patch   | 0
>  .../gcc/patches/{10.2.0 => 10.3.0}/820-libgcc_pic.patch | 0
>  .../{10.2.0 => 10.3.0}/840-armv4_pass_fix-v4bx_to_ld.patch  | 0
>  .../patches/{10.2.0 => 10.3.0}/850-use_shared_libgcc.patch  | 0
>  .../patches/{10.2.0 => 10.3.0}/851-libgcc_no_compat.patch   | 0
>  .../patches/{10.2.0 => 10.3.0}/870-ppc_no_crtsavres.patch   | 0
>  .../gcc/patches/{10.2.0 => 10.3.0}/881-no_tm_section.patch  | 0
>  .../gcc/patches/{10.2.0 => 10.3.0}/900-bad-mips16-crt.patch | 0
>  .../gcc/patches/{10.2.0 => 10.3.0}/910-mbsd_multi.patch | 6 +++---
>  .../{10.2.0 => 10.3.0}/920-specs_nonfatal_getenv.patch  | 0
>  .../{10.2.0 => 10.3.0}/930-fix-mips-noexecstack.patch   | 0
>  .../931-libffi-fix-MIPS-softfloat-build-issue.patch | 0
>  ...gotools-fix-compilation-when-making-cross-compiler.patch | 0
>  20 files changed, 6 insertions(+), 6 deletions(-)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/002-case_insensitive.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/010-documentation.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/110-Fix-MIPS-PR-84790.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/230-musl_libssp.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 
> 10.3.0}/300-mips_Os_cpu_rtx_cost_model.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 
> 10.3.0}/810-arm-softfloat-libgcc.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/820-libgcc_pic.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 
> 10.3.0}/840-armv4_pass_fix-v4bx_to_ld.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/850-use_shared_libgcc.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/851-libgcc_no_compat.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/870-ppc_no_crtsavres.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/881-no_tm_section.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/900-bad-mips16-crt.patch 
> (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/910-mbsd_multi.patch (96%)
>  rename toolchain/gcc/patches/{10.2.0 => 
> 10.3.0}/920-specs_nonfatal_getenv.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 
> 10.3.0}/930-fix-mips-noexecstack.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 
> 10.3.0}/931-libffi-fix-MIPS-softfloat-build-issue.patch (100%)
>  rename toolchain/gcc/patches/{10.2.0 => 
> 10.3.0}/960-gotools-fix-compilation-when-making-cross-compiler.patch (100%)
>
> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> index 967ce9e4892b..4e141477a516 100644
> --- a/toolchain/gcc/Config.version
> +++ b/toolchain/gcc/Config.version
> @@ -14,7 +14,7 @@ config GCC_VERSION
> string
> default "7.5.0" if GCC_VERSION_7
> default "9.3.0" if GCC_VERSION_9
> -   default "10.2.0"if GCC_VERSION_10
> +   default "10.3.0"if GCC_VERSION_10
> default "8.4.0"
>
>  config GCC_USE_IREMAP
> diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
> index 55fad1fcc48d..ef8fd9de47fd 100644
> --- a/toolchain/gcc/common.mk
> +++ b/toolchain/gcc/common.mk
> @@ -40,8 +40,8 @@ ifeq ($(PKG_VERSION),9.3.0)
>PKG_HASH:=71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1
>  endif
>
> -ifeq ($(PKG_VERSION),10.2.0)
> -  PKG_HASH:=b8dd4368bb9c7f0b98188317ee0254dd8cc99d1e3a18d0ff146c855fe16c1d8c
> +ifeq ($(PKG_VERSION),10.3.0)
> +  PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344
>  endif
>
>  PATCH_DIR=../patches/$(GCC_VERSION)
> diff --git a/toolchain/gcc/patches/10.2.0/002-case_insensitive.patch 
> b/toolchain/gcc/patches/10.3.0/002-case_insensitive.patch
> similarity index 100%
> rename from toolchain/gcc/patches/10.2.0/002-case_insensitive.patch
> rename to toolchain/gcc/patches/10.3.0/002-case_insensitive.patch
> diff --git a/toolchain/gcc/patches/10.2.0/010-documentation.patch 
> b/toolchain/gcc/patches/10.3.0/010-documentation.patch
> similarity index 100%
> rename from toolchain/gcc/patches/10.2.0/010-documentation.patch
> rename to toolchain/gcc/patches/10.3.0/010-documentation.patch
> diff --git a/toolchain/gcc/patches/10.2.0/110-Fix-MIPS-PR-84790.patch 
> b/toolchain/gcc/patches/10.3.0/110-Fix-MIPS-PR-84790.patch
> 

Re: [PATCH] base-files: fix zoneinfo support

[Rosen Penev]

On Fri, Apr 9, 2021 at 5:22 PM Rosen Penev  wrote:
>
> The system init script currently sets /tmp/localinfo when zoneinfo is
> populated. However, zoneinfo has spaces in it whereas the actual files
> have _ instead of spaces. This made the if condition never return true.
>
> Example failure when removing the if condition:
>
> /tmp/localtime -> /usr/share/zoneinfo/America/Los Angeles
>
> This file does not exist. America/Los_Angeles does.
>
> Signed-off-by: Rosen Penev 
I'll add that this problem was there since the beginning:
https://github.com/openwrt/openwrt/commit/bfbbe5893f92cd572c48c4d37fbd975f148093d6
> ---
>  this should be backported to 21.02 and 19.07 as the issue is also
>  present there. This was tested on 19.07.
>  package/base-files/files/etc/init.d/system | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/package/base-files/files/etc/init.d/system 
> b/package/base-files/files/etc/init.d/system
> index 08cf86b97f..b1fc154cec 100755
> --- a/package/base-files/files/etc/init.d/system
> +++ b/package/base-files/files/etc/init.d/system
> @@ -22,9 +22,13 @@ system_config() {
>
> echo "$hostname" > /proc/sys/kernel/hostname
> [ -z "$conloglevel" -a -z "$buffersize" ] || dmesg ${conloglevel:+-n 
> $conloglevel} ${buffersize:+-s $buffersize}
> -   echo "$timezone" > /tmp/TZ
> -   [ -n "$zonename" ] && [ -f "/usr/share/zoneinfo/$zonename" ] && \
> -   ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm 
> -f /tmp/TZ
> +   if [ -n "$zonename" ]; then
> +   local zname=$(echo "$zonename" | tr ' ' _)
> +   [ -f "/usr/share/zoneinfo/$zname" ] && \
> +   ln -sf "/usr/share/zoneinfo/$zname" /tmp/localtime
> +   else
> +   echo "$timezone" > /tmp/TZ
> +   fi
>
> # apply timezone to kernel
> hwclock -u --systz
> --
> 2.30.2
>

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

[PATCH] base-files: fix zoneinfo support

[Rosen Penev]

The system init script currently sets /tmp/localinfo when zoneinfo is
populated. However, zoneinfo has spaces in it whereas the actual files
have _ instead of spaces. This made the if condition never return true.

Example failure when removing the if condition:

/tmp/localtime -> /usr/share/zoneinfo/America/Los Angeles

This file does not exist. America/Los_Angeles does.

Signed-off-by: Rosen Penev 
---
 this should be backported to 21.02 and 19.07 as the issue is also
 present there. This was tested on 19.07.
 package/base-files/files/etc/init.d/system | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/package/base-files/files/etc/init.d/system 
b/package/base-files/files/etc/init.d/system
index 08cf86b97f..b1fc154cec 100755
--- a/package/base-files/files/etc/init.d/system
+++ b/package/base-files/files/etc/init.d/system
@@ -22,9 +22,13 @@ system_config() {
 
echo "$hostname" > /proc/sys/kernel/hostname
[ -z "$conloglevel" -a -z "$buffersize" ] || dmesg ${conloglevel:+-n 
$conloglevel} ${buffersize:+-s $buffersize}
-   echo "$timezone" > /tmp/TZ
-   [ -n "$zonename" ] && [ -f "/usr/share/zoneinfo/$zonename" ] && \
-   ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm -f 
/tmp/TZ
+   if [ -n "$zonename" ]; then
+   local zname=$(echo "$zonename" | tr ' ' _)
+   [ -f "/usr/share/zoneinfo/$zname" ] && \
+   ln -sf "/usr/share/zoneinfo/$zname" /tmp/localtime
+   else
+   echo "$timezone" > /tmp/TZ
+   fi
 
# apply timezone to kernel
hwclock -u --systz
-- 
2.30.2


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

[PATCH]-19.07 busybox: backport hwclock fixes

[Rosen Penev]

Currently on devices with an RTC, sysfixtime uses busybox' hwclock to
set the RTC time. Unfortunately, g/settimeofday on musl completely
ignore the second parameter which forces users to use the syscall
directly.

Backport two patches to fix hwclock's support for timezones.

Signed-off-by: Rosen Penev 
---
 Note: this is already fixed in master and 21.02.
 package/utils/busybox/Makefile|   2 +-
 ...ock-Fix-settimeofday-for-glibc-v2.31.patch |  53 +
 ...fix-musl-breakage-of-settimeofday-tz.patch | 195 ++
 3 files changed, 249 insertions(+), 1 deletion(-)
 create mode 100644 
package/utils/busybox/patches/010-hwclock-Fix-settimeofday-for-glibc-v2.31.patch
 create mode 100644 
package/utils/busybox/patches/020-hwclock-fix-musl-breakage-of-settimeofday-tz.patch

diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile
index 23dd5498a1..a12401ff30 100644
--- a/package/utils/busybox/Makefile
+++ b/package/utils/busybox/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=busybox
 PKG_VERSION:=1.30.1
-PKG_RELEASE:=6
+PKG_RELEASE:=7
 PKG_FLAGS:=essential
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
diff --git 
a/package/utils/busybox/patches/010-hwclock-Fix-settimeofday-for-glibc-v2.31.patch
 
b/package/utils/busybox/patches/010-hwclock-Fix-settimeofday-for-glibc-v2.31.patch
new file mode 100644
index 00..c6dd897b78
--- /dev/null
+++ 
b/package/utils/busybox/patches/010-hwclock-Fix-settimeofday-for-glibc-v2.31.patch
@@ -0,0 +1,53 @@
+From 38b8f0a91a786f42531b1e27746060377fbdcaba Mon Sep 17 00:00:00 2001
+From: Eddie James 
+Date: Mon, 10 Aug 2020 09:59:02 -0500
+Subject: [PATCH 1/2] hwclock: Fix settimeofday for glibc v2.31+
+
+The glibc implementation changed for settimeofday, resulting in "invalid
+argument" error when attempting to set both timezone and time with a single
+call. Fix this by calling settimeofday twice
+
+Signed-off-by: Eddie James 
+Signed-off-by: Denys Vlasenko 
+---
+ util-linux/hwclock.c | 14 +++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+--- a/util-linux/hwclock.c
 b/util-linux/hwclock.c
+@@ -122,16 +122,20 @@ static void to_sys_clock(const char **pp
+   struct timeval tv;
+   struct timezone tz;
+ 
+-  tz.tz_minuteswest = timezone/60;
++  tz.tz_minuteswest = timezone / 60;
+   /* ^^^ used to also subtract 60*daylight, but it's wrong:
+* daylight!=0 means "this timezone has some DST
+* during the year", not "DST is in effect now".
+*/
+   tz.tz_dsttime = 0;
+ 
++  /* glibc v2.31+ returns an error if both args are non-NULL */
++  if (settimeofday(NULL, ))
++  bb_simple_perror_msg_and_die("settimeofday");
++
+   tv.tv_sec = read_rtc(pp_rtcname, NULL, utc);
+   tv.tv_usec = 0;
+-  if (settimeofday(, ))
++  if (settimeofday(, NULL))
+   bb_perror_msg_and_die("settimeofday");
+ }
+ 
+@@ -283,7 +287,11 @@ static void set_system_clock_timezone(in
+   gettimeofday(, NULL);
+   if (!utc)
+   tv.tv_sec += tz.tz_minuteswest * 60;
+-  if (settimeofday(, ))
++
++  /* glibc v2.31+ returns an error if both args are non-NULL */
++  if (settimeofday(NULL, ))
++  bb_perror_msg_and_die("settimeofday");
++  if (settimeofday(, NULL))
+   bb_perror_msg_and_die("settimeofday");
+ }
+ 
diff --git 
a/package/utils/busybox/patches/020-hwclock-fix-musl-breakage-of-settimeofday-tz.patch
 
b/package/utils/busybox/patches/020-hwclock-fix-musl-breakage-of-settimeofday-tz.patch
new file mode 100644
index 00..88ab9f7b18
--- /dev/null
+++ 
b/package/utils/busybox/patches/020-hwclock-fix-musl-breakage-of-settimeofday-tz.patch
@@ -0,0 +1,195 @@
+From 54644059ef984727168c124858448ec66f4ecb5f Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Wed, 16 Dec 2020 13:49:10 +0100
+Subject: [PATCH 2/2] hwclock: fix musl breakage of settimeofday(tz)
+
+function old new   delta
+set_kernel_timezone_and_clock  - 119+119
+set_kernel_tz  -  28 +28
+hwclock_main 480 301-179
+--
+(add/remove: 2/0 grow/shrink: 0/1 up/down: 147/-179)  Total: -32 bytes
+
+Signed-off-by: Denys Vlasenko 
+---
+ util-linux/hwclock.c | 128 +--
+ 1 file changed, 75 insertions(+), 53 deletions(-)
+
+--- a/util-linux/hwclock.c
 b/util-linux/hwclock.c
+@@ -37,6 +37,19 @@
+ #include 
+ #include "rtc_.h"
+ 
++
++//musl has no __MUSL__ or similar define to check for,
++//but its  has these lines:
++// #define __NEED_fsblkcnt_t
++// #define __NEED_fsfilcnt_t
++#if defined(__linux__) && defined(__NEED_fsblkcnt_t) 

Re: [PATCH] kernel: Activate FORTIFY_SOURCE for MIPS kernel 5.4

[Rosen Penev]

On Wed, Apr 7, 2021 at 3:26 PM Hauke Mehrtens  wrote:
>
> CONFIG_FORTIFY_SOURCE=y is already set in the generic kernel
> configuration, but it is not working for MIPS on kernel 5.4, support for
> MIPS was only added with kernel 5.5, other architectures like aarch64
> support FORTIFY_SOURCE already since some time.
>
> This patch adds support for FORTIFY_SOURCE to MIPS with kernel 5.4,
> kernel 5.10 already supports this and needs no changes.
>
> This backports one patch from kernel 5.5 and one fix from 5.8 to make
> fortify source also work on our kernel 5.4.
>
> The changes are not compatible with the
> 306-mips_mem_functions_performance.patch patch which was also removed
> with kernel 5.10, probably because of the same problems. I think it is
> not needed anyway as the compiler should automatically optimize the
> calls to memset(), memcpy() and memmove() even when not explicitly
> telling the compiler to use the build in variant.
>
> Signed-off-by: Hauke Mehrtens 
Acked-by: Rosen Penev 
> ---
>
> I would like to backport this to 21.02 too.
Seems good.
>
>  ...-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch |  32 ++
>  ...11-MIPS-Fix-exception-handler-memcpy.patch | 107 ++
>  .../301-mips_image_cmdline_hack.patch |   2 +-
>  ...CPU_MIPS64-for-remaining-MIPS64-CPUs.patch |   2 +-
>  .../300-mips_expose_boot_raw.patch|   4 +-
>  .../306-mips_mem_functions_performance.patch  | 106 -
>  6 files changed, 143 insertions(+), 110 deletions(-)
>  create mode 100644 
> target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
>  create mode 100644 
> target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
>  delete mode 100644 
> target/linux/generic/pending-5.4/306-mips_mem_functions_performance.patch
>
> diff --git 
> a/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
>  
> b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
> new file mode 100644
> index ..e02f10354376
> --- /dev/null
> +++ 
> b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
> @@ -0,0 +1,32 @@
> +From a8d2bb0559b5fefa5173ff4e7496cc6250db2c8a Mon Sep 17 00:00:00 2001
> +From: Dmitry Korotin 
> +Date: Thu, 12 Sep 2019 22:53:45 +
> +Subject: [PATCH] mips: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE
> +
> +FORTIFY_SOURCE detects various overflows at compile and run time.
> +(6974f0c4555e ("include/linux/string.h:
> +add the option of fortified string.h functions)
> +
> +ARCH_HAS_FORTIFY_SOURCE means that the architecture can be built and
> +run with CONFIG_FORTIFY_SOURCE.
> +
> +Since mips can be built and run with that flag,
> +select ARCH_HAS_FORTIFY_SOURCE as default.
> +
> +Signed-off-by: Dmitry Korotin 
> +Signed-off-by: Paul Burton 
> +Cc: linux-m...@vger.kernel.org
> +---
> + arch/mips/Kconfig | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +--- a/arch/mips/Kconfig
>  b/arch/mips/Kconfig
> +@@ -7,6 +7,7 @@ config MIPS
> +   select ARCH_CLOCKSOURCE_DATA
> +   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> +   select ARCH_HAS_UBSAN_SANITIZE_ALL
> ++  select ARCH_HAS_FORTIFY_SOURCE
> +   select ARCH_SUPPORTS_UPROBES
> +   select ARCH_USE_BUILTIN_BSWAP
> +   select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
> diff --git 
> a/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
>  
> b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
> new file mode 100644
> index ..5a6725c7a072
> --- /dev/null
> +++ 
> b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
> @@ -0,0 +1,107 @@
> +From e01c91a360793298c9e1656a61faceff01487a43 Mon Sep 17 00:00:00 2001
> +From: Ben Hutchings 
> +Date: Sat, 23 May 2020 23:50:34 +0800
> +Subject: [PATCH] MIPS: Fix exception handler memcpy()
> +
> +The exception handler subroutines are declared as a single char, but
> +when copied to the required addresses the copy length is 0x80.
> +
> +When range checks are enabled for memcpy() this results in a build
> +failure, with error messages such as:
> +
> +In file included from arch/mips/mti-malta/malta-init.c:15:
> +In function 'memcpy',
> +inlined from 'mips_nmi_setup' at arch/mips/mti-malta/malta-init.c:98:2:
> +include/linux/string.h:376:4: error: call to '__read_overflow2' declared 
> with attribute error: detected read beyond size of object passed as 2nd 
> parameter
> +  376 |__read_overflow2();
> +  |^~
> +
> +Change the declarations to use type char[].
> 

[PATCH] toolchain/gdb: fix compilation with ccache

[Rosen Penev]

For some reason, one of the configure checks results in some infinite
loop and ends up spawning endless gcc processes, causing OOM. Just pass
a configure var to avoid it.

Same fix as 6e23813c1ed7494a9da3b5e59cfcafd71097c420

Signed-off-by: Rosen Penev 
---
 toolchain/gdb/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile
index 3bcc9d1238..05e3c7de3c 100644
--- a/toolchain/gdb/Makefile
+++ b/toolchain/gdb/Makefile
@@ -22,6 +22,7 @@ HOST_BUILD_PARALLEL:=1
 include $(INCLUDE_DIR)/toolchain-build.mk
 
 HOST_CONFIGURE_VARS += \
+   acx_cv_cc_gcc_supports_ada=false \
gdb_cv_func_sigsetjmp=yes
 
 HOST_CONFIGURE_ARGS = \
-- 
2.30.2


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

Re: Data loss issue (and solution) for MTK uSD driver

[Rosen Penev]

On Fri, Apr 2, 2021 at 4:22 PM Enrico Mioso  wrote:
>
> Hello all!!
>
> I experienced an issue that could cause data loss on a uSD card when used in 
> some ramips MT7621 devices, like the Zbtlink ZBT-WG3526 (32M).
> I fixed it by following the nice solution pointed our here:
> https://forum.openwrt.org/t/a-lot-of-errors-with-sd-card-reader-mikrotik-rbm33g/36760
>
> I would like to say thanks to the author.
>
> Is there something we can do to fix this in a general way?
The MMC driver used in OpenWrt is not the upstream one. I've been
pushing to switch to the latter but some devices have pinctrl issues
it seems.
> The issue is important enough, given the fact that just mounting, creating a 
> folder and umounting the device is enough to get e2fsck screaming at you! :)
> The same card seems to work fine on a GB-PC1. I am experiencing this issue 
> with OpenWRt snapshot (commit ec6293febc244d187e71a6e54f44920be679cde4), 
> running 5.4 kernel.
>
> I seen the FS get corrupted several times. BTW, has this the potential to 
> damage the card itself?
No.
>
> Thanks!!
>
> Enrico
>
>
> ___
> 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: Data loss issue (and solution) for MTK uSD driver

[Rosen Penev]

On Fri, Apr 2, 2021 at 5:12 PM Rosen Penev  wrote:
>
> On Fri, Apr 2, 2021 at 4:22 PM Enrico Mioso  wrote:
> >
> > Hello all!!
> >
> > I experienced an issue that could cause data loss on a uSD card when used 
> > in some ramips MT7621 devices, like the Zbtlink ZBT-WG3526 (32M).
> > I fixed it by following the nice solution pointed our here:
> > https://forum.openwrt.org/t/a-lot-of-errors-with-sd-card-reader-mikrotik-rbm33g/36760

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-dts?h=next-20210401=cf8e49ae200baa05b8536e99fbee37faf9c2cebb
shows it at 48 not 50.

> >
> > I would like to say thanks to the author.
> >
> > Is there something we can do to fix this in a general way?
> The MMC driver used in OpenWrt is not the upstream one. I've been
> pushing to switch to the latter but some devices have pinctrl issues
> it seems.
> > The issue is important enough, given the fact that just mounting, creating 
> > a folder and umounting the device is enough to get e2fsck screaming at you! 
> > :)
> > The same card seems to work fine on a GB-PC1. I am experiencing this issue 
> > with OpenWRt snapshot (commit ec6293febc244d187e71a6e54f44920be679cde4), 
> > running 5.4 kernel.
> >
> > I seen the FS get corrupted several times. BTW, has this the potential to 
> > damage the card itself?
> No.
> >
> > Thanks!!
> >
> > Enrico
> >
> >
> > ___
> > 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] openssl: don't rename a file with quilt

[Rosen Penev]

On Fri, Mar 26, 2021 at 2:57 PM Felix Fietkau  wrote:
>
>
> On 2021-03-26 22:39, Eneas U de Queiroz wrote:
> > On Fri, Mar 26, 2021 at 4:28 PM Rosen Penev  wrote:
> >>
> >> On Fri, Mar 26, 2021 at 5:55 AM Eneas U de Queiroz
> >>  wrote:
> >> >
> >> > On Fri, Mar 26, 2021 at 6:26 AM Rosen Penev  wrote:
> >> > > +ifeq ($(QUILT),)
> >> > > +   mv $(PKG_BUILD_DIR)/crypto/engine/eng_devcrypto.c 
> >> > > $(PKG_BUILD_DIR)/engines/e_devcrypto.c
> >> > > +endif
> >> >
> >> > This will break compilation with QUILT, as the rename will never
> >> > happen then.  You're using this strategy with other packages, so I
> >> > won't mention them individually, but this applies to all.
> >> > I would handle it at the patch level by removing the old file and
> >> > creating the new one.
> >> It doesn't break quilt as the rename happens separately. Note that the
> >> patches were modified to refer to the old name.
> > It breaks 'make package/openssl/compile QUILT=1', because the 'mv'
> > command will never run when QUILT is not empty.  You can't run the
> > 'mv' line with quilt because the patches are not applied in
> > Build/Prepare.  However, you must ensure it is run later, or the
> > package will not compile with QUILT=1.  I can point you to
> > openwrt/packages#14894 to see why you can't just skip running stuff
> > when QUILT is defined.
> I fully agree with Eneas here (though I don't like his patch for this
> issue either). Here's a way to fix this:
>
> include/package-defaults.mk has this:
>
>   define Build/Prepare/Default
> $(PKG_UNPACK)
> [ ! -d ./src/ ] || $(CP) ./src/. $(PKG_BUILD_DIR)
> $(Build/Patch)
>   endef
>
> You can adjust it to define this in the package Makefile:
>
> define Build/Prepare
> $(PKG_UNPACK)
> [ ! -d ./src/ ] || $(CP) ./src/. $(PKG_BUILD_DIR)
> mv $(PKG_BUILD_DIR)/crypto/engine/eng_devcrypto.c 
> $(PKG_BUILD_DIR)/engines/e_devcrypto.c
> $(Build/Patch)
> endef
https://github.com/openwrt/openwrt/pull/4030 is the full patchset.
Makefile hackery was NAKed so I manually "fixed" the patches.
>
> - Felix

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

Re: [RFC PATCH] openssl: make the patches QUILT-friendly

[Rosen Penev]

On Fri, Mar 26, 2021 at 11:56 AM Eneas U de Queiroz
 wrote:
>
> The patches in this package are all made by git format-patches.  If one
> were to run 'make package/openssl/{refresh,update}', then things will
> not work as expected, because quilt QUILT does not deal well with
> patches that rename files.  For openssl, the problematic patch is
> 430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch.
>
> So, I've generated a new patch with 'git format-patch --no-renames', and
> then 'make package/openssl/{refresh,update}'.
NAK. This just bloats the patches for no good reason. It also makes it
harder to deal with upstream changes.

I know that you're fairly competent when dealing with this, but think
about it from a drive by contributor. Getting a setup to properly
refresh patches like these is difficult.
>
> Signed-off-by: Eneas U de Queiroz 
> ---
>
> While I really prefer to leave the git-formatted patches as they are, I
> know quilt is the preferred way of handling patches in OpenWRT, so I'm
> presenting this as RFC, so the core developers can decide.
>
> ldir has made a similar commit e27ef2da0d, and then reverted it right away
> in bbb9c1c2be, and I don't know why.
>
> neheb proposed a patch [1] that does the file renaming in Build/Prepare, so
> that it is easier to use quilt while refreshing patches after a package
> bump.  It has an undesirable side-effect of not running the renaming
> portion at all when using QUILT, resulting in a build failure.
>
> Some packages in the packages feed are skipping build steps when running
> with QUILT, to speed up automatic refresh of patches, and I've been
> fixing them as I stumble upon some of the failures.
>
> At least to me, being able to quickly build with QUILT=1, without having
> to start from scratch and go through dependencies is an immensively
> useful feature that I would not trade for having tidier patches.
>
> For this package, one could rename the files in Build/Configure when
> compiling with QUILT without a problem.  So, if desired, it could be
> done neheb's way instead.
>
> In my opinion, QUILT is not particularly useful for rebasing large
> changes, such as the engine patches here.  So even if neheb's proposal
> has a nice intention, it is not appropriate for this package.
>
> If the motivation is just to run make package/openssl/{refresh,update},
> perhaps automatically to keep patches tidy, then this patch will
> suffice.
>
> Cheers,
>
> Eneas
>
> [1] 
> https://patchwork.ozlabs.org/project/openwrt/patch/20210326092548.14019-1-ros...@gmail.com/
>
> diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
> index 7ab4c6ccd0..458b064f13 100644
> --- a/package/libs/openssl/Makefile
> +++ b/package/libs/openssl/Makefile
> @@ -11,7 +11,7 @@ PKG_NAME:=openssl
>  PKG_BASE:=1.1.1
>  PKG_BUGFIX:=k
>  PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>  PKG_USE_MIPS16:=0
>  ENGINES_DIR=engines-1.1
>
> diff --git a/package/libs/openssl/patches/100-Configure-afalg-support.patch 
> b/package/libs/openssl/patches/100-Configure-afalg-support.patch
> index 98944103b5..2ae5938bdc 100644
> --- a/package/libs/openssl/patches/100-Configure-afalg-support.patch
> +++ b/package/libs/openssl/patches/100-Configure-afalg-support.patch
> @@ -1,4 +1,4 @@
> -From 559fbff13af9ce2fbc0b9bc5727a7323e1db6217 Mon Sep 17 00:00:00 2001
> +From  Mon Sep 17 00:00:00 2001
>  From: Eneas U de Queiroz 
>  Date: Thu, 27 Sep 2018 08:29:21 -0300
>  Subject: Do not use host kernel version to disable AFALG
> @@ -8,11 +8,9 @@ version to disable building the AFALG engine on openwrt 
> targets.
>
>  Signed-off-by: Eneas U de Queiroz 
>
> -diff --git a/Configure b/Configure
> -index 5a699836f3..74d057c219 100755
>  --- a/Configure
>  +++ b/Configure
> -@@ -1545,7 +1545,9 @@ unless ($disabled{"crypto-mdebug-backtrace"})
> +@@ -1545,7 +1545,9 @@ unless ($disabled{"crypto-mdebug-backtra
>
>   unless ($disabled{afalgeng}) {
>   $config{afalgeng}="";
> diff --git a/package/libs/openssl/patches/110-openwrt_targets.patch 
> b/package/libs/openssl/patches/110-openwrt_targets.patch
> index d0530b4661..50a9ebe2d6 100644
> --- a/package/libs/openssl/patches/110-openwrt_targets.patch
> +++ b/package/libs/openssl/patches/110-openwrt_targets.patch
> @@ -1,4 +1,4 @@
> -From 3d43acc6068f00dbfc0c9a06355e2c8f7d302d0f Mon Sep 17 00:00:00 2001
> +From  Mon Sep 17 00:00:00 2001
>  From: Eneas U de Queiroz 
>  Date: Thu, 27 Sep 2018 08:30:24 -0300
>  Subject: Add openwrt targets
> @@ -7,9 +7,6 @@ Targets are named: linux-$(CONFIG_ARCH)-openwrt
>
>  Signed-off-by: Eneas U de Queiroz 
>
> -diff --git a/Configurations/25-openwrt.conf b/Configurations/25-openwrt.conf
> -new file mode 100644
> -index 00..86a86d31e4
>  --- /dev/null
>  +++ b/Configurations/25-openwrt.conf
>  @@ -0,0 +1,48 @@
> diff --git a/package/libs/openssl/patches/120-strip-cflags-from-binary.patch 
> 

Re: [PATCH] openssl: don't rename a file with quilt

[Rosen Penev]

On Fri, Mar 26, 2021 at 5:55 AM Eneas U de Queiroz
 wrote:
>
> Hi Rosen
>
> This patch does not apply as is, but don't write a v2 yet.
> I'm testing the bump to 1.1.1k, and I'll handle it from there, by
> using --no-renames with git format-patch.  I'm maintaining the patches
> at https://github.com/cotequeiroz/openssl, and refreshing backports
> with git is much easier than with quilt.  See comments below, as your
> patchset breaks compilation with QUILT.
>
> On Fri, Mar 26, 2021 at 6:26 AM Rosen Penev  wrote:
> >
> > quilt cannot handle file renames and ends up duplicating the file.
> > Instead of doing that, handle the renaming in the Makefile so that
> > the upstream file can change.
> >
> > Signed-off-by: Rosen Penev 
> > ---
> >  package/libs/openssl/Makefile |7 +
> >  ...o-make-the-dev-crypto-engine-dynamic.patch | 2633 +
> >  ...default-to-not-use-digests-in-engine.patch |4 +-
> >  ...to-ignore-error-when-closing-session.patch |4 +-
> >  4 files changed, 151 insertions(+), 2497 deletions(-)
> >
> > diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
> > index 436abfd94c..f3113cab6e 100644
> > --- a/package/libs/openssl/Makefile
> > +++ b/package/libs/openssl/Makefile
> > @@ -324,6 +324,13 @@ OPENSSL_TARGET:=linux-$(call 
> > qstrip,$(CONFIG_ARCH))-openwrt
> >
> >  STAMP_CONFIGURED := $(STAMP_CONFIGURED)_$(shell echo $(OPENSSL_OPTIONS) | 
> > mkhash md5)
> >
> > +define Build/Prepare
> > +   $(call Build/Prepare/Default)
>
>
> > +ifeq ($(QUILT),)
> > +   mv $(PKG_BUILD_DIR)/crypto/engine/eng_devcrypto.c 
> > $(PKG_BUILD_DIR)/engines/e_devcrypto.c
> > +endif
>
> This will break compilation with QUILT, as the rename will never
> happen then.  You're using this strategy with other packages, so I
> won't mention them individually, but this applies to all.
> I would handle it at the patch level by removing the old file and
> creating the new one.
It doesn't break quilt as the rename happens separately. Note that the
patches were modified to refer to the old name.
>
> Alternatively, you can keep your strategy, adding the rename with
> QUILT in Build/Configure, with the caveat that it will run every time
> compile is called, so you'll need to ignore an eventual error, and
> make sure that the original file was not recreated somewhere in the
> build process by a previous compile run, which would clobber the
> patched file.
I haven't seen any issues. Locally I run make package/x/{clean,refresh}
>
> Cheers

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

[PATCH 2/2] lua5.3: refresh patches

[Rosen Penev]

Renamed doc files in Build/Prepare instead of patches as quilt cannot
handle renames in patches.

Signed-off-by: Rosen Penev 
---
 package/utils/lua5.3/Makefile |  8 +++
 .../patches/001-include-version-number.patch  |  8 ---
 .../lua5.3/patches/020-shared_liblua.patch| 60 +--
 3 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/package/utils/lua5.3/Makefile b/package/utils/lua5.3/Makefile
index c9e9bebb1a..6ab9301d9e 100644
--- a/package/utils/lua5.3/Makefile
+++ b/package/utils/lua5.3/Makefile
@@ -78,6 +78,14 @@ endef
 
 TARGET_CFLAGS += -DLUA_USE_LINUX $(FPIC) -std=gnu99
 
+define Build/Prepare
+   $(call Build/Prepare/Default)
+ifeq ($(QUILT),)
+   mv $(PKG_BUILD_DIR)/doc/lua.1 $(PKG_BUILD_DIR)/lua5.3.1
+   mv $(PKG_BUILD_DIR)/doc/luac.1 $(PKG_BUILD_DIR)/luac5.3.1
+endif
+endef
+
 define Build/Compile
$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
CC="$(TARGET_CROSS)gcc" \
diff --git a/package/utils/lua5.3/patches/001-include-version-number.patch 
b/package/utils/lua5.3/patches/001-include-version-number.patch
index 78f0054960..2312e281bc 100644
--- a/package/utils/lua5.3/patches/001-include-version-number.patch
+++ b/package/utils/lua5.3/patches/001-include-version-number.patch
@@ -8,7 +8,6 @@ Including it allows multiple lua versions to coexist.
 Signed-off-by: Rafał Miłecki 
 ---
 
-diff --git a/Makefile b/Makefile
 --- a/Makefile
 +++ b/Makefile
 @@ -12,7 +12,7 @@ PLAT= none
@@ -43,13 +42,6 @@ diff --git a/Makefile b/Makefile
  
  test: dummy
src/lua -v
-diff --git a/doc/lua.1 b/doc/lua5.3.1
-rename from doc/lua.1
-rename to doc/lua5.3.1
-diff --git a/doc/luac.1 b/doc/luac5.3.1
-rename from doc/luac.1
-rename to doc/luac5.3.1
-diff --git a/src/Makefile b/src/Makefile
 --- a/src/Makefile
 +++ b/src/Makefile
 @@ -28,7 +28,7 @@ MYOBJS=
diff --git a/package/utils/lua5.3/patches/020-shared_liblua.patch 
b/package/utils/lua5.3/patches/020-shared_liblua.patch
index 7fa9652290..a462fa4f1e 100644
--- a/package/utils/lua5.3/patches/020-shared_liblua.patch
+++ b/package/utils/lua5.3/patches/020-shared_liblua.patch
@@ -1,5 +1,5 @@
 a/Makefile 2019-07-02 09:24:57.554332875 -0600
-+++ b/Makefile 2019-07-02 09:25:42.626694604 -0600
+--- a/Makefile
 b/Makefile
 @@ -41,7 +41,7 @@ PLATS= aix bsd c89 freebsd generic linux
  # What to install.
  TO_BIN= lua$V luac$V
@@ -19,8 +19,8 @@
cd doc && $(INSTALL_DATA) $(TO_MAN) $(INSTALL_MAN)
  
  uninstall:
 a/src/ldo.h2017-04-19 11:20:42.0 -0600
-+++ b/src/ldo.h2019-07-02 09:25:42.626694604 -0600
+--- a/src/ldo.h
 b/src/ldo.h
 @@ -47,8 +47,8 @@ LUAI_FUNC int luaD_pcall (lua_State *L,
  LUAI_FUNC int luaD_poscall (lua_State *L, CallInfo *ci, StkId firstResult,
int nres);
@@ -32,8 +32,8 @@
  LUAI_FUNC void luaD_inctop (lua_State *L);
  
  LUAI_FUNC l_noret luaD_throw (lua_State *L, int errcode);
 a/src/lfunc.h  2017-04-19 11:39:34.0 -0600
-+++ b/src/lfunc.h  2019-07-02 09:25:42.630694635 -0600
+--- a/src/lfunc.h
 b/src/lfunc.h
 @@ -47,14 +47,14 @@ struct UpVal {
  #define upisopen(up)  ((up)->v != &(up)->u.value)
  
@@ -55,8 +55,8 @@
   int pc);
  
  
 a/src/lgc.h2017-04-19 11:39:34.0 -0600
-+++ b/src/lgc.h2019-07-02 09:25:42.634694666 -0600
+--- a/src/lgc.h
 b/src/lgc.h
 @@ -133,11 +133,11 @@
  
  LUAI_FUNC void luaC_fix (lua_State *L, GCObject *o);
@@ -71,8 +71,8 @@
  LUAI_FUNC void luaC_barrierback_ (lua_State *L, Table *o);
  LUAI_FUNC void luaC_upvalbarrier_ (lua_State *L, UpVal *uv);
  LUAI_FUNC void luaC_checkfinalizer (lua_State *L, GCObject *o, Table *mt);
 a/src/llex.h   2017-04-19 11:20:42.0 -0600
-+++ b/src/llex.h   2019-07-02 09:25:42.630694635 -0600
+--- a/src/llex.h
 b/src/llex.h
 @@ -73,13 +73,13 @@ typedef struct LexState {
  
  
@@ -92,8 +92,8 @@
  
  
  #endif
 a/src/lmem.h   2017-04-19 11:20:42.0 -0600
-+++ b/src/lmem.h   2019-07-02 09:25:42.630694635 -0600
+--- a/src/lmem.h
 b/src/lmem.h
 @@ -56,12 +56,12 @@
  #define luaM_reallocvector(L, v,oldn,n,t) \
 ((v)=cast(t *, luaM_reallocv(L, v, oldn, n, sizeof(t
@@ -110,8 +110,8 @@
 size_t size_elem, int limit,
 const char *what);
  
 a/src/lobject.h2017-04-19 11:39:34.0 -0600
-+++ b/src/lobject.h2019-07-02 09:25:42.630694635 -0600
+--- a/src/lobject.h
 b/src/lobject.h
 @@ -525,7 +525,7 @@ typedef struct Table {
  #define luaO_nilobject(_nilobject_)
  
@@ -141,8 +141,8 @@
  
  
  #endif
 a/src/lopcodes.h   2017-04-19 11:20:42.0 -0600
-+++ b/src/lopcodes.h   2019-07-02 09:25:42.630694635 -0600
+--- a/src/lopcodes.h
 b/src/lopcodes.h
 @@ -278,7 +278,7 @@ enum OpArgMask {
OpArgK   /* argument is a constant or register/const

[PATCH 1/2] lua: refresh patches

[Rosen Penev]

Renamed doc files in Build/Prepare instead of patches as quilt cannot
handle renames in patches.

Signed-off-by: Rosen Penev 
---
 package/utils/lua/Makefile|  8 
 .../lua/patches/001-include-version-number.patch  | 10 +-
 .../lua/patches/013-lnum-strtoul-parsing-fixes.patch  | 11 ++-
 3 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/package/utils/lua/Makefile b/package/utils/lua/Makefile
index a54ef7d25a..ca8d4b43f7 100644
--- a/package/utils/lua/Makefile
+++ b/package/utils/lua/Makefile
@@ -92,6 +92,14 @@ endef
 
 TARGET_CFLAGS += -DLUA_USE_LINUX $(FPIC) -std=gnu99
 
+define Build/Prepare
+   $(call Build/Prepare/Default)
+ifeq ($(QUILT),)
+   mv $(PKG_BUILD_DIR)/doc/lua.1 $(PKG_BUILD_DIR)/lua5.1.1
+   mv $(PKG_BUILD_DIR)/doc/luac.1 $(PKG_BUILD_DIR)/luac5.1.1
+endif
+endef
+
 define Build/Compile
$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
CC="$(TARGET_CROSS)gcc" \
diff --git a/package/utils/lua/patches/001-include-version-number.patch 
b/package/utils/lua/patches/001-include-version-number.patch
index f769e60736..17a2778da9 100644
--- a/package/utils/lua/patches/001-include-version-number.patch
+++ b/package/utils/lua/patches/001-include-version-number.patch
@@ -8,7 +8,6 @@ Including it allows multiple lua versions to coexist.
 Signed-off-by: Rafał Miłecki 
 ---
 
-diff --git a/Makefile b/Makefile
 --- a/Makefile
 +++ b/Makefile
 @@ -41,10 +41,10 @@ RANLIB= ranlib
@@ -33,16 +32,9 @@ diff --git a/Makefile b/Makefile
  
  test: dummy
src/lua test/hello.lua
-diff --git a/doc/lua.1 b/doc/lua5.1.1
-rename from doc/lua.1
-rename to doc/lua5.1.1
-diff --git a/doc/luac.1 b/doc/luac5.1.1
-rename from doc/luac.1
-rename to doc/luac5.1.1
-diff --git a/src/Makefile b/src/Makefile
 --- a/src/Makefile
 +++ b/src/Makefile
-@@ -29,10 +29,10 @@ CORE_O=lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o 
lgc.o llex.o lmem.o \
+@@ -29,10 +29,10 @@ CORE_O=lapi.o lcode.o ldebug.o ldo.o ld
  LIB_O=lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o 
ltablib.o \
lstrlib.o loadlib.o linit.o
  
diff --git a/package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch 
b/package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch
index 7f00c8c3a2..8887229589 100644
--- a/package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch
+++ b/package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch
@@ -1,8 +1,6 @@
-diff --git a/src/lnum.c b/src/lnum.c
-index 1456b6a2ed23..b0632b04c2b7 100644
 --- a/src/lnum.c
 +++ b/src/lnum.c
-@@ -127,6 +127,8 @@ static int luaO_str2i (const char *s, lua_Integer *res, 
char **endptr_ref) {
+@@ -127,6 +127,8 @@ static int luaO_str2i (const char *s, lu
  #else
return 0;  /* Reject the number */
  #endif
@@ -11,7 +9,7 @@ index 1456b6a2ed23..b0632b04c2b7 100644
  }
} else if ((v > LUA_INTEGER_MAX) || (*endptr && (!isspace(*endptr {
  return TK_NUMBER; /* not in signed range, or has '.', 'e' etc. trailing */
-@@ -310,3 +312,13 @@ int try_unmint( lua_Integer *r, lua_Integer ib ) {
+@@ -310,3 +312,13 @@ int try_unmint( lua_Integer *r, lua_Inte
return 0;
  }
  
@@ -25,8 +23,6 @@ index 1456b6a2ed23..b0632b04c2b7 100644
 +  return (unsigned LUA_INTEGER)v;
 +}
 +#endif
-diff --git a/src/lnum_config.h b/src/lnum_config.h
-index 19d7a4231a49..1092eead6629 100644
 --- a/src/lnum_config.h
 +++ b/src/lnum_config.h
 @@ -141,7 +141,12 @@
@@ -43,6 +39,3 @@ index 19d7a4231a49..1092eead6629 100644
  #endif
  #ifndef LUA_INTEGER_MIN
  # define LUA_INTEGER_MIN (-LUA_INTEGER_MAX -1)  /* -2^16|32 */
--- 
-1.9.1
-
-- 
2.25.1


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

Re: [PATCH] build: remove GCC7 support

[Rosen Penev]

On Fri, Mar 26, 2021 at 1:49 AM Paul Spooren  wrote:
>
> Since we recently branched a new release which already ships with GCC7,
> version 6 could be considered obsolete.
version 6?

Could also mention GCC7 does not support std::filesystem , which is
needed by some programs such as gerbera in the packages feed. That's
actually why I don't backport gerbera to 19.07.
>
> Signed-off-by: Paul Spooren 
Acked-by: Rosen Penev 
> ---
>  toolchain/gcc/Config.in   |   4 -
>  toolchain/gcc/Config.version  |  10 -
>  toolchain/gcc/common.mk   |   4 -
>  .../001-revert_register_mode_search.patch |  77 
>  .../patches/7.5.0/002-case_insensitive.patch  |  24 ---
>  .../gcc/patches/7.5.0/010-documentation.patch |  35 
>  .../patches/7.5.0/110-Fix-MIPS-PR-84790.patch |  20 --
>  .../gcc/patches/7.5.0/230-musl_libssp.patch   |  28 ---
>  .../300-mips_Os_cpu_rtx_cost_model.patch  |  21 --
>  .../7.5.0/800-arm_v5te_no_ldrd_strd.patch |  32 
>  .../7.5.0/810-arm-softfloat-libgcc.patch  |  33 
>  .../gcc/patches/7.5.0/820-libgcc_pic.patch|  44 -
>  .../7.5.0/840-armv4_pass_fix-v4bx_to_ld.patch |  28 ---
>  .../patches/7.5.0/850-use_shared_libgcc.patch |  54 --
>  .../patches/7.5.0/851-libgcc_no_compat.patch  |  22 ---
>  .../patches/7.5.0/870-ppc_no_crtsavres.patch  |  18 --
>  .../gcc/patches/7.5.0/881-no_tm_section.patch |  22 ---
>  .../patches/7.5.0/900-bad-mips16-crt.patch|  30 ---
>  .../gcc/patches/7.5.0/910-mbsd_multi.patch| 146 --
>  .../7.5.0/920-specs_nonfatal_getenv.patch |  22 ---
>  .../7.5.0/930-fix-mips-noexecstack.patch  | 111 ---
>  ...ibffi-fix-MIPS-softfloat-build-issue.patch | 175 -
>  .../7.5.0/940-no-clobber-stamp-bits.patch |  33 
>  .../7.5.0/950-cpp_file_path_translation.patch | 181 --
>  ...mpilation-when-making-cross-compiler.patch |  73 ---
>  25 files changed, 1247 deletions(-)
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/001-revert_register_mode_search.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/002-case_insensitive.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/010-documentation.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/110-Fix-MIPS-PR-84790.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/230-musl_libssp.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/300-mips_Os_cpu_rtx_cost_model.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/800-arm_v5te_no_ldrd_strd.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/810-arm-softfloat-libgcc.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/820-libgcc_pic.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/840-armv4_pass_fix-v4bx_to_ld.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/850-use_shared_libgcc.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/851-libgcc_no_compat.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/870-ppc_no_crtsavres.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/881-no_tm_section.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/900-bad-mips16-crt.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/910-mbsd_multi.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/920-specs_nonfatal_getenv.patch
>  delete mode 100644 toolchain/gcc/patches/7.5.0/930-fix-mips-noexecstack.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/931-libffi-fix-MIPS-softfloat-build-issue.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/940-no-clobber-stamp-bits.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/950-cpp_file_path_translation.patch
>  delete mode 100644 
> toolchain/gcc/patches/7.5.0/960-gotools-fix-compilation-when-making-cross-compiler.patch
>
> diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in
> index f0fc31d567..1f22b35bc6 100644
> --- a/toolchain/gcc/Config.in
> +++ b/toolchain/gcc/Config.in
> @@ -6,10 +6,6 @@ choice
> help
>   Select the version of gcc you wish to use.
>
> -   config GCC_USE_VERSION_7
> -   bool "gcc 7.x"
> -   depends on !arc
> -
> config GCC_USE_VERSION_8
> bool "gcc 8.x"
>
> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> index 967ce9e489..3db4b90e21 100644
> --- a/toolchain/gcc/Config.version
> +++ b/toolchain/gcc/Config.version
> @@ -1,7 +1,3 @@
> -config GCC_VERSION_7
> -   default y if GCC_USE_VERSION_7
> -   bool
> -
>  config GCC_VERSION_9
> default y if GCC_USE_VERSION_9
> bool
> @@ -12,12 +8,6 @@ config GCC_VERSION_10
>
>  config GCC_VERSION

[PATCH] openssl: don't rename a file with quilt

[Rosen Penev]

quilt cannot handle file renames and ends up duplicating the file.
Instead of doing that, handle the renaming in the Makefile so that
the upstream file can change.

Signed-off-by: Rosen Penev 
---
 package/libs/openssl/Makefile |7 +
 ...o-make-the-dev-crypto-engine-dynamic.patch | 2633 +
 ...default-to-not-use-digests-in-engine.patch |4 +-
 ...to-ignore-error-when-closing-session.patch |4 +-
 4 files changed, 151 insertions(+), 2497 deletions(-)

diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 436abfd94c..f3113cab6e 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -324,6 +324,13 @@ OPENSSL_TARGET:=linux-$(call qstrip,$(CONFIG_ARCH))-openwrt
 
 STAMP_CONFIGURED := $(STAMP_CONFIGURED)_$(shell echo $(OPENSSL_OPTIONS) | 
mkhash md5)
 
+define Build/Prepare
+   $(call Build/Prepare/Default)
+ifeq ($(QUILT),)
+   mv $(PKG_BUILD_DIR)/crypto/engine/eng_devcrypto.c 
$(PKG_BUILD_DIR)/engines/e_devcrypto.c
+endif
+endef
+
 define Build/Configure
(cd $(PKG_BUILD_DIR); \
./Configure $(OPENSSL_TARGET) \
diff --git 
a/package/libs/openssl/patches/430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch
 
b/package/libs/openssl/patches/430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch
index 4218fbe76c..56d2309b72 100644
--- 
a/package/libs/openssl/patches/430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch
+++ 
b/package/libs/openssl/patches/430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch
@@ -107,2461 +107,111 @@ Signed-off-by: Eneas U de Queiroz 

  ENGINES_NO_INST=ossltest dasync
  SOURCE[dasync]=e_dasync.c
 --- a/crypto/engine/eng_devcrypto.c
-+++ /dev/null
-@@ -1,1264 +0,0 @@
--/*
-- * Copyright 2017-2019 The OpenSSL Project Authors. All Rights Reserved.
-- *
-- * Licensed under the OpenSSL license (the "License").  You may not use
-- * this file except in compliance with the License.  You can obtain a copy
-- * in the file LICENSE in the source distribution or at
-- * https://www.openssl.org/source/license.html
-- */
--
--#include "e_os.h"
--#include 
--#include 
--#include 
--#include 
--#include 
--#include 
--#include 
--
--#include 
--#include 
--#include 
--#include 
--#include 
--#include 
--
--#include "crypto/engine.h"
--
--/* #define ENGINE_DEVCRYPTO_DEBUG */
--
--#if CRYPTO_ALGORITHM_MIN < CRYPTO_ALGORITHM_MAX
--# define CHECK_BSD_STYLE_MACROS
--#endif
--
--/*
-- * ONE global file descriptor for all sessions.  This allows operations
-- * such as digest session data copying (see digest_copy()), but is also
-- * saner...  why re-open /dev/crypto for every session?
-- */
--static int cfd;
--#define DEVCRYPTO_REQUIRE_ACCELERATED 0 /* require confirmation of 
acceleration */
--#define DEVCRYPTO_USE_SOFTWARE1 /* allow software drivers */
--#define DEVCRYPTO_REJECT_SOFTWARE 2 /* only disallow confirmed software 
drivers */
--
--#define DEVCRYPTO_DEFAULT_USE_SOFDTRIVERS DEVCRYPTO_REJECT_SOFTWARE
--static int use_softdrivers = DEVCRYPTO_DEFAULT_USE_SOFDTRIVERS;
--
--/*
-- * cipher/digest status & acceleration definitions
-- * Make sure the defaults are set to 0
-- */
--struct driver_info_st {
--enum devcrypto_status_t {
--DEVCRYPTO_STATUS_FAILURE = -3, /* unusable for other reason */
--DEVCRYPTO_STATUS_NO_CIOCCPHASH   = -2, /* hash state copy not 
supported */
--DEVCRYPTO_STATUS_NO_CIOCGSESSION = -1, /* session open failed */
--DEVCRYPTO_STATUS_UNKNOWN =  0, /* not tested yet */
--DEVCRYPTO_STATUS_USABLE  =  1  /* algo can be used */
--} status;
--
--enum devcrypto_accelerated_t {
--DEVCRYPTO_NOT_ACCELERATED= -1, /* software implemented */
--DEVCRYPTO_ACCELERATION_UNKNOWN   =  0, /* acceleration support unkown 
*/
--DEVCRYPTO_ACCELERATED=  1  /* hardware accelerated */
--} accelerated;
--
--char *driver_name;
--};
--
--static int clean_devcrypto_session(struct session_op *sess) {
--if (ioctl(cfd, CIOCFSESSION, >ses) < 0) {
--SYSerr(SYS_F_IOCTL, errno);
--return 0;
--}
--memset(sess, 0, sizeof(struct session_op));
--return 1;
--}
--
--/**
-- *
-- * Ciphers
-- *
-- * Because they all do the same basic operation, we have only one set of
-- * method functions for them all to share, and a mapping table between
-- * NIDs and cryptodev IDs, with all the necessary size data.
-- *
-- */
--
--struct cipher_ctx {
--struct session_op sess;
--int op;  /* COP_ENCRYPT or COP_DECRYPT */
--unsigned long mode;  /* EVP_CIPH_*_MODE */
--
--/* to handle ctr mode being a stream cipher */
--unsigned char partial[EVP_MAX_BLOCK_LENGTH];
--unsigned int blocksize, num;
--};
--
--static const struct cipher_data_st {
--int

[PATCHv2 2/2] kernel: add exfat again

[Rosen Penev]

With kernel 5.10, exfat is out of staging and in tree.

Added small hack to make it work with kernel 5.4 as well.

Added removed config options for 5.4 to generic config.

Signed-off-by: Rosen Penev 
---
 v2: Add missing config options
 package/kernel/linux/modules/fs.mk | 20 
 target/linux/generic/config-5.4|  6 ++
 2 files changed, 26 insertions(+)

diff --git a/package/kernel/linux/modules/fs.mk 
b/package/kernel/linux/modules/fs.mk
index 91ef535821..7de1a0673c 100644
--- a/package/kernel/linux/modules/fs.mk
+++ b/package/kernel/linux/modules/fs.mk
@@ -164,6 +164,26 @@ endef
 $(eval $(call KernelPackage,fs-efivarfs))
 
 
+define KernelPackage/fs-exfat
+  SUBMENU:=$(FS_MENU)
+  TITLE:=exFAT filesystem support
+  KCONFIG:= \
+   CONFIG_EXFAT_FS \
+   CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
+  FILES:= \
+   $(LINUX_DIR)/drivers/staging/exfat/exfat.ko@lt5.7 \
+   $(LINUX_DIR)/fs/exfat/exfat.ko@ge5.7
+  AUTOLOAD:=$(call AutoLoad,30,exfat,1)
+  DEPENDS:=+kmod-nls-base
+endef
+
+define KernelPackage/fs-exfat/description
+ Kernel module for exFAT filesystem support
+endef
+
+$(eval $(call KernelPackage,fs-exfat))
+
+
 define KernelPackage/fs-exportfs
   SUBMENU:=$(FS_MENU)
   TITLE:=exportfs kernel server support
diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 68fe001609..4f7ccf1efc 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -1498,7 +1498,13 @@ CONFIG_ETHERNET=y
 # CONFIG_ETHOC is not set
 CONFIG_EVENTFD=y
 # CONFIG_EVM is not set
+# CONFIG_EXFAT_DEBUG_MSG is not set
+# CONFIG_EXFAT_DEFAULT_CODEPAGE is not set
+# CONFIG_EXFAT_DELAYED_SYNC is not set
+# CONFIG_EXFAT_DISCARD is not set
+# CONFIG_EXFAT_DONT_MOUNT_VFAT is not set
 # CONFIG_EXFAT_FS is not set
+# CONFIG_EXFAT_KERNEL_DEBUG is not set
 CONFIG_EXPERT=y
 CONFIG_EXPORTFS=y
 # CONFIG_EXPORTFS_BLOCK_OPS is not set
-- 
2.25.1


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

[PATCHv2 1/2] package/exfat: remove

[Rosen Penev]

Now that kernel 5.10 is in tree, this can be removed.

Signed-off-by: Rosen Penev 
---
 package/kernel/exfat/Makefile | 46 ---
 1 file changed, 46 deletions(-)
 delete mode 100644 package/kernel/exfat/Makefile

diff --git a/package/kernel/exfat/Makefile b/package/kernel/exfat/Makefile
deleted file mode 100644
index 3f873a71ee..00
--- a/package/kernel/exfat/Makefile
+++ /dev/null
@@ -1,46 +0,0 @@
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-include $(TOPDIR)/rules.mk
-include $(INCLUDE_DIR)/kernel.mk
-
-PKG_NAME:=exfat
-PKG_VERSION:=5.10.1
-PKG_RELEASE:=1
-
-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=https://codeload.github.com/namjaejeon/linux-exfat-oot/tar.gz/$(PKG_VERSION)?
-PKG_HASH:=0ff77dd7d39eb231d00c3c4909b9fad31ebeeb618bd6fa18fce142becc9c1f98
-PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/linux-exfat-oot-$(PKG_VERSION)
-
-PKG_MAINTAINER:=
-PKG_LICENSE:=GPL-2.0-only
-
-include $(INCLUDE_DIR)/package.mk
-
-define KernelPackage/fs-exfat
-  SECTION:=kernel
-  CATEGORY:=Kernel modules
-  SUBMENU:=Filesystems
-  TITLE:=exFAT kernel module
-  URL:=https://github.com/namjaejeon/linux-exfat-oot
-  FILES:=$(PKG_BUILD_DIR)/exfat.ko
-  AUTOLOAD:=$(call AutoProbe,exfat)
-  DEPENDS:= +kmod-nls-base
-endef
-
-define KernelPackage/exfat/description
-  This package provides the kernel module for exfat.
-endef
-
-define Build/Compile
-   $(KERNEL_MAKE) M="$(PKG_BUILD_DIR)" \
-   EXTRA_CFLAGS="$(EXTRA_CFLAGS)" \
-   $(PKG_EXTRA_KCONFIG) \
-   CONFIG_EXFAT_FS=m \
-   modules
-endef
-
-$(eval $(call KernelPackage,fs-exfat))
-- 
2.25.1


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

[PATCH] pcre: bring back C++ bindings

[Rosen Penev]

It seems some people use them privately.

Reported-by: Jan Kardell 
Signed-off-by: Rosen Penev 
---
 package/libs/pcre/Makefile | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/package/libs/pcre/Makefile b/package/libs/pcre/Makefile
index 8644746b4b..60f30cd787 100644
--- a/package/libs/pcre/Makefile
+++ b/package/libs/pcre/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=pcre
 PKG_VERSION:=8.44
-PKG_RELEASE:=4
+PKG_RELEASE:=5
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=@SF/$(PKG_NAME)
@@ -24,6 +24,7 @@ PKG_INSTALL:=1
 PKG_BUILD_PARALLEL:=1
 
 PKG_CONFIG_DEPENDS:=\
+   CONFIG_PACKAGE_libpcrecpp \
CONFIG_PCRE_JIT_ENABLED
 
 include $(INCLUDE_DIR)/package.mk
@@ -54,12 +55,19 @@ define Package/libpcre32
   TITLE:=A Perl Compatible Regular Expression library (32bit support)
 endef
 
+define Package/libpcrecpp
+  $(call Package/libpcre/default)
+  TITLE:=C++ wrapper for Perl Compatible Regular Expression library
+  DEPENDS:=+libpcre +libstdcpp
+endef
+
+
 HOST_CONFIGURE_ARGS += \
--enable-utf8 \
--enable-unicode-properties \
--enable-pcre16 \
--with-match-limit-recursion=16000 \
-   --disable-cpp
+   --enable-cpp
 
 TARGET_CFLAGS += $(FPIC)
 
@@ -70,7 +78,7 @@ CONFIGURE_ARGS += \
--enable-pcre32 \
$(if $(CONFIG_PCRE_JIT_ENABLED),--enable-jit,--disable-jit) \
--with-match-limit-recursion=16000 \
-   -disable-cpp
+   --$(if $(CONFIG_PACKAGE_libpcrecpp),en,dis)able-cpp
 
 MAKE_FLAGS += \
CFLAGS="$(TARGET_CFLAGS)"
@@ -109,7 +117,13 @@ define Package/libpcre32/install
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libpcre32.so* $(1)/usr/lib/
 endef
 
+define Package/libpcrecpp/install
+   $(INSTALL_DIR) $(1)/usr/lib
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libpcrecpp.so.* $(1)/usr/lib/
+endef
+
 $(eval $(call BuildPackage,libpcre))
 $(eval $(call BuildPackage,libpcre16))
 $(eval $(call BuildPackage,libpcre32))
+$(eval $(call BuildPackage,libpcrecpp))
 $(eval $(call HostBuild))
-- 
2.25.1


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

Re: [PATCH] pcre: disable C++ bindings

[Rosen Penev]

On Sun, Mar 14, 2021 at 2:40 PM Karl Palsson  wrote:
>
>
> Rosen Penev  wrote:
> > On Sun, Mar 14, 2021 at 7:40 AM Jan Kardell
> >  wrote:
> > >
> > > Rosen Penev skrev:
> > > > Nothing uses them. Allows to simplify the Makefile.
> > > Actually I use it for stuff that is not in openwrt repos. That means I
> > > must keep pcrecpp out-of-tree. Maybe others do too, but have not yet
> > > discovered this change. Is really a few saved lines in a makefile worth
> > > to make life more difficult for people who uses openwrt as a base for
> > > there own projects? Or is openwrt not meant to be used that way?
> > >
> > > So I kindly request that this change is reverted.
> > News to me. From the small research I did on Arch and Debian,
> > all packages use the C API.
>
> I would presume they were refering to their own packages not in
> the openwrt repos, not "random package frrom arch/debian"
>
> Given how much support _is_ given to downstream openwrt builds,
> it doesn't seem unreasonable that for a general package like this
> we should offer all of it?
GMail put this in spam for some reason.

I have no problem with reverting the commit. The uClibc++ stuff should
be removed though.
>
> Sincerely,
> Karl Palsson

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

Re: [PATCH] pcre: disable C++ bindings

[Rosen Penev]

On Sun, Mar 14, 2021 at 7:40 AM Jan Kardell  wrote:
>
> Rosen Penev skrev:
> > Nothing uses them. Allows to simplify the Makefile.
> Actually I use it for stuff that is not in openwrt repos. That means I
> must keep pcrecpp out-of-tree. Maybe others do too, but have not yet
> discovered this change. Is really a few saved lines in a makefile worth
> to make life more difficult for people who uses openwrt as a base for
> there own projects? Or is openwrt not meant to be used that way?
>
> So I kindly request that this change is reverted.
News to me. From the small research I did on Arch and Debian, all
packages use the C API.
>
> //Jan
>
> >
> > Signed-off-by: Rosen Penev 
> > ---
> >   package/libs/pcre/Makefile | 21 +++--
> >   1 file changed, 3 insertions(+), 18 deletions(-)
> >
> > diff --git a/package/libs/pcre/Makefile b/package/libs/pcre/Makefile
> > index 37d939da7f..8644746b4b 100644
> > --- a/package/libs/pcre/Makefile
> > +++ b/package/libs/pcre/Makefile
> > @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> >
> >   PKG_NAME:=pcre
> >   PKG_VERSION:=8.44
> > -PKG_RELEASE:=3
> > +PKG_RELEASE:=4
> >
> >   PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
> >   PKG_SOURCE_URL:=@SF/$(PKG_NAME)
> > @@ -24,10 +24,8 @@ PKG_INSTALL:=1
> >   PKG_BUILD_PARALLEL:=1
> >
> >   PKG_CONFIG_DEPENDS:=\
> > - CONFIG_PACKAGE_libpcrecpp \
> >   CONFIG_PCRE_JIT_ENABLED
> >
> > -include $(INCLUDE_DIR)/uclibc++.mk
> >   include $(INCLUDE_DIR)/package.mk
> >   include $(INCLUDE_DIR)/host-build.mk
> >
> > @@ -56,19 +54,12 @@ define Package/libpcre32
> > TITLE:=A Perl Compatible Regular Expression library (32bit support)
> >   endef
> >
> > -define Package/libpcrecpp
> > -  $(call Package/libpcre/default)
> > -  TITLE:=C++ wrapper for Perl Compatible Regular Expression library
> > -  DEPENDS:=+libpcre $(CXX_DEPENDS)
> > -endef
> > -
> > -
> >   HOST_CONFIGURE_ARGS += \
> >   --enable-utf8 \
> >   --enable-unicode-properties \
> >   --enable-pcre16 \
> >   --with-match-limit-recursion=16000 \
> > - --enable-cpp
> > + --disable-cpp
> >
> >   TARGET_CFLAGS += $(FPIC)
> >
> > @@ -79,7 +70,7 @@ CONFIGURE_ARGS += \
> >   --enable-pcre32 \
> >   $(if $(CONFIG_PCRE_JIT_ENABLED),--enable-jit,--disable-jit) \
> >   --with-match-limit-recursion=16000 \
> > - $(if $(CONFIG_PACKAGE_libpcrecpp),--enable,--disable)-cpp
> > + -disable-cpp
> >
> >   MAKE_FLAGS += \
> >   CFLAGS="$(TARGET_CFLAGS)"
> > @@ -118,13 +109,7 @@ define Package/libpcre32/install
> >   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libpcre32.so* $(1)/usr/lib/
> >   endef
> >
> > -define Package/libpcrecpp/install
> > - $(INSTALL_DIR) $(1)/usr/lib
> > - $(CP) $(PKG_INSTALL_DIR)/usr/lib/libpcrecpp.so.* $(1)/usr/lib/
> > -endef
> > -
> >   $(eval $(call BuildPackage,libpcre))
> >   $(eval $(call BuildPackage,libpcre16))
> >   $(eval $(call BuildPackage,libpcre32))
> > -$(eval $(call BuildPackage,libpcrecpp))
> >   $(eval $(call HostBuild))
>

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

[PATCH 1/2] package/exfat: remove

[Rosen Penev]

Now that kernel 5.10 is in tree, this can be removed.

Signed-off-by: Rosen Penev 
---
 package/kernel/exfat/Makefile | 46 ---
 1 file changed, 46 deletions(-)
 delete mode 100644 package/kernel/exfat/Makefile

diff --git a/package/kernel/exfat/Makefile b/package/kernel/exfat/Makefile
deleted file mode 100644
index 3f873a71ee..00
--- a/package/kernel/exfat/Makefile
+++ /dev/null
@@ -1,46 +0,0 @@
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-include $(TOPDIR)/rules.mk
-include $(INCLUDE_DIR)/kernel.mk
-
-PKG_NAME:=exfat
-PKG_VERSION:=5.10.1
-PKG_RELEASE:=1
-
-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=https://codeload.github.com/namjaejeon/linux-exfat-oot/tar.gz/$(PKG_VERSION)?
-PKG_HASH:=0ff77dd7d39eb231d00c3c4909b9fad31ebeeb618bd6fa18fce142becc9c1f98
-PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/linux-exfat-oot-$(PKG_VERSION)
-
-PKG_MAINTAINER:=
-PKG_LICENSE:=GPL-2.0-only
-
-include $(INCLUDE_DIR)/package.mk
-
-define KernelPackage/fs-exfat
-  SECTION:=kernel
-  CATEGORY:=Kernel modules
-  SUBMENU:=Filesystems
-  TITLE:=exFAT kernel module
-  URL:=https://github.com/namjaejeon/linux-exfat-oot
-  FILES:=$(PKG_BUILD_DIR)/exfat.ko
-  AUTOLOAD:=$(call AutoProbe,exfat)
-  DEPENDS:= +kmod-nls-base
-endef
-
-define KernelPackage/exfat/description
-  This package provides the kernel module for exfat.
-endef
-
-define Build/Compile
-   $(KERNEL_MAKE) M="$(PKG_BUILD_DIR)" \
-   EXTRA_CFLAGS="$(EXTRA_CFLAGS)" \
-   $(PKG_EXTRA_KCONFIG) \
-   CONFIG_EXFAT_FS=m \
-   modules
-endef
-
-$(eval $(call KernelPackage,fs-exfat))
-- 
2.25.1


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

[PATCH 2/2] kernel: add exfat again

[Rosen Penev]

With kernel 5.10, exfat is out of staging and in tree.

Added small hack to make it work with kernel 5.4 as well.

Signed-off-by: Rosen Penev 
---
 package/kernel/linux/modules/fs.mk | 20 
 1 file changed, 20 insertions(+)

diff --git a/package/kernel/linux/modules/fs.mk 
b/package/kernel/linux/modules/fs.mk
index 91ef535821..7de1a0673c 100644
--- a/package/kernel/linux/modules/fs.mk
+++ b/package/kernel/linux/modules/fs.mk
@@ -164,6 +164,26 @@ endef
 $(eval $(call KernelPackage,fs-efivarfs))
 
 
+define KernelPackage/fs-exfat
+  SUBMENU:=$(FS_MENU)
+  TITLE:=exFAT filesystem support
+  KCONFIG:= \
+   CONFIG_EXFAT_FS \
+   CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
+  FILES:= \
+   $(LINUX_DIR)/drivers/staging/exfat/exfat.ko@lt5.7 \
+   $(LINUX_DIR)/fs/exfat/exfat.ko@ge5.7
+  AUTOLOAD:=$(call AutoLoad,30,exfat,1)
+  DEPENDS:=+kmod-nls-base
+endef
+
+define KernelPackage/fs-exfat/description
+ Kernel module for exFAT filesystem support
+endef
+
+$(eval $(call KernelPackage,fs-exfat))
+
+
 define KernelPackage/fs-exportfs
   SUBMENU:=$(FS_MENU)
   TITLE:=exportfs kernel server support
-- 
2.25.1


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

Re: [PATCH] ramips: add support for TOTOLINK X5000R

[Rosen Penev]

On Fri, Mar 12, 2021 at 6:27 PM Chuanhong Guo  wrote:
>
> Hi!
>
> On Sat, Mar 13, 2021 at 7:27 AM Bas Mevissen  wrote:
> >
> > Hi,
> >
> > Thanks for creating this patch. Got my X5000R today. Before flashing it
> > to OpenWRT, can you please tell me whether you (or anyone else) did
> > performance measurements with the original and the OpenWRT firmware?
>
> The wifi chip used in this router wasn't supported by mt76 when I created
> this patch, so my X5000R has no wifi now and I don't have any
> wireless performance numbers.
> My X5000R has been sitting on the shelf since I posted this patch, and
> I don't even know whether the mt7915d used in this router is supported
> now or not. You should probably ask TOTOLINK for a copy of the original
> firmware image before trying OpenWrt, so that you can go back to the
> original firmware if needed. (A forced sysupgrade from OpenWrt using
> their firmware image should work.)
I see 
https://github.com/openwrt/mt76/commit/b436da4d9d925f6ff80310841d1fbeb25c93b667
and a bunch of other commits referencing it.
>
> --
> Regards,
> Chuanhong Guo
>
> ___
> 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] uclibc++: remove

[Rosen Penev]

On Sat, Feb 27, 2021 at 7:41 AM Hauke Mehrtens  wrote:
>
> On 2/27/21 5:17 AM, Rosen Penev wrote:
> > No package here depends on it. Furthermore, uClibc++ is a fairly buggy
> > C++ library and seems to be relatively inactive upstream.
> >
> > It also lacks proper support for modern C++11 features.
> >
> > The main benefit of it is size: 66.6 KB   vs 287.3 KB on mips24kc. 
> > Static
> > linking and LTO can help bring the size down of packages that need it.
> >
> > Added warning message to uclibc++.mk
> >
> > Signed-off-by: Rosen Penev 
> > ---
> >   config/Config-build.in|  14 --
> >   include/uclibc++.mk   |  18 +--
> >   package/libs/uclibc++/Makefile| 105 -
> >   package/libs/uclibc++/files/config.default|  58 ---
> >   .../libs/uclibc++/patches/001-no-ansi.patch   |  10 --
> >   .../patches/002-undef-functions.patch |  35 -
> >   .../libs/uclibc++/patches/003-no-fPIC.patch   |  10 --
> >   ...ibc-Make-long-long-available-to-C-11.patch | 143 --
> >   .../005-istream_helpers-Fix-sscanf-typo.patch |  37 -
> >   9 files changed, 2 insertions(+), 428 deletions(-)
> >   delete mode 100644 package/libs/uclibc++/Makefile
> >   delete mode 100644 package/libs/uclibc++/files/config.default
> >   delete mode 100644 package/libs/uclibc++/patches/001-no-ansi.patch
> >   delete mode 100644 package/libs/uclibc++/patches/002-undef-functions.patch
> >   delete mode 100644 package/libs/uclibc++/patches/003-no-fPIC.patch
> >   delete mode 100644 
> > package/libs/uclibc++/patches/004-uClibc-Make-long-long-available-to-C-11.patch
> >   delete mode 100644 
> > package/libs/uclibc++/patches/005-istream_helpers-Fix-sscanf-typo.patch
> >
>
> Acked-by: Hauke Mehrtens 
All packages in the normal feeds have been changed to not use
uclibc++.mk. Should I remove and resend this patch?

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

Re: [PATCH 0/4] import libcap from packages feed

[Rosen Penev]

On Fri, Mar 12, 2021 at 2:10 AM Stijn Tintel  wrote:
>
> On 12/03/2021 10:50, Petr Štetiar wrote:
> > Stijn Tintel  [2021-03-12 01:25:24]:
> >
> > Hi,
> >
> >> Having libcap in OpenWrt base allows us to enable libcap support in
> >> other packages in base.
> > there is same functionality available through procd already so essentialy
> > you're throwing away that effort, increasing flash space usage etc.
>
> Is that documented somewhere? Did you test that lldpd even starts when
> limiting it like that? I have had issues when I tried to limit the
> capabilities of infnoised [1] in the systemd unit file; it simply
> wouldn't start.
>
> The flash space usage is a moot point, we no longer care about 4MB
> devices, and libcap is only 12kb.  We can offset that by building lldpd
> with LTO.
>
> >
> >> In lldpd, this would allow the monitor process to drop its privileges
> >> instead of running as root, improving security. It will also allow us to
> >> drop our patch to disable libcap.
> > I assume, that you can do it even better with procd's seccomp/jails and
> > likely confine the master process as well.
>
> The non-monitor process already runs as the lldp user without libcap.
>
> Processes with libcap disabled:
>
>   1642 root  4360 S/usr/sbin/lldpd -d -c -f -s -e -M 4 -x -X
> /var/run/agentx.sock
>   1693 lldp  4804 S/usr/sbin/lldpd -d -c -f -s -e -M 4 -x -X
> /var/run/agentx.sock
>
> With libcap enabled:
>
>   1804 lldp  1216 S/usr/sbin/lldpd -d -c -f -s -e -M 4
>   1886 lldp  1232 S/usr/sbin/lldpd -d -c -f -s -e -M 4
>
> >
> >> I suspect some people might counter this by saying lldpd belongs in the
> >> packages feed;
> > IMO it belongs to packages feed, because currently it's optional package.  
> > In
> > other words, it's not included in any of the images by default.
>
> See Bjorn's reply. It's required to properly support 802.3af/at/bt (PoE).
>
> Also, I don't agree that any optional package should be moved to the
> packages feed. The packages feed is a mess, often PR's are accepted
> without maintainer approval, sometimes even after explicit NACK by the
> maintainer or others. For this reason, I'm seriously considering
> removing myself as maintainer from any packages I maintain there.
No idea about explicit NACK. I merge mostly complete PRs to avoid the
situation in base where hundreds of good PRs pile up only because
there is no one to review.
>
> >
> >> I strongly disagree as imo LLDP is an essential service for any network
> >> device, and especially switches. Even the cheapest managed switches support
> >> LLDP for more than 5 years already.
> > If it's that essential, why it's not enabled and shipped by default? I 
> > assume
> > it's because some folks would complain, that LLDP is use case specific, not
> > everybody would like to have another network exposed service running by
> > default, not everybody needs LLDP by default in RX/TX mode as TX mode might 
> > be
> > enough etc.
> We're considering enabling it on realtek by default.
> >
> > Cheers,
> >
> > Petr
>
> Stijn
>
> [1] https://github.com/13-37-org/infnoise
>
> ___
> 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: Dsa multi-cpu port problem

[Rosen Penev]

On Wed, Mar 10, 2021 at 4:56 PM Ansuel Smith  wrote:
>
> >
> > On Wed, Mar 10, 2021 at 4:19 PM Ansuel Smith  wrote:
> > >
> > > I'm working on the conversion of ipq806x to dsa.
> > > It's been 2 years and still dsa doesn't support multi-cpu port.
> > > Online there are many patches that add support for this but they were
> > > never accepted upstream since there isn't a solution that would work
> > > for all the switches. Fact is that openwrt is different and have some
> > > flexibility about this kind problem.
> > > There is actually a patchset (rejected) that adds multi-cpu support
> > > defined in the dts that can be used and doesn't look that bad.
> > >
> > > So here is the question:
> > > Considering the fact that at least 3 target have disabled port (mtk,
> > > mvebu and upcoming ipq806x) why not use the proposed patch
> > > while upstream a final solution is found for this problem?
> > > Turris already use a variant of that patch and also mediatek use
> > > it.
> > I closed https://github.com/openwrt/openwrt/pull/3655 since 21.02 was
> > branched. I would use that patchset as the Turris people are working
> > on upstreaming a bunch of stuff.
>
> Didn't know there was already a port of the variant. So in your
> opinion the round-robin should be the right solution.
> Turris and mediatek from what i found online used the original
> implementation with the cpu port hardcoded in the dts.
> I can only find rfc of the round-robin patch online, do you have more
> discussion about that? Curious to know if upstream they finally take a
> decision instead of keep staying in the limbo.
This patchset was taken from
https://gitlab.nic.cz/turris/turris-build/-/blob/hbd/patches/openwrt/wip/0005-mvebu-initial-support-for-Omnia-on-5.4-kernel.patch

Limbo so far. The developer needs to resend it. I believe upstream had
no issue with this patchset.
>
> > >
> > > The idea would be to place the patch as a hack in the generic
> > > target dir and targets can add patches to modify the dsa driver
> > > accordingly (if needed).
> > >
> > > (the multi-cpu variant i'm talking about it the one that statically
> > > link a port to a dedicated cpu port in the dts)
> > >
> > > ___
> > > 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: Dsa multi-cpu port problem

[Rosen Penev]

On Wed, Mar 10, 2021 at 4:19 PM Ansuel Smith  wrote:
>
> I'm working on the conversion of ipq806x to dsa.
> It's been 2 years and still dsa doesn't support multi-cpu port.
> Online there are many patches that add support for this but they were
> never accepted upstream since there isn't a solution that would work
> for all the switches. Fact is that openwrt is different and have some
> flexibility about this kind problem.
> There is actually a patchset (rejected) that adds multi-cpu support
> defined in the dts that can be used and doesn't look that bad.
>
> So here is the question:
> Considering the fact that at least 3 target have disabled port (mtk,
> mvebu and upcoming ipq806x) why not use the proposed patch
> while upstream a final solution is found for this problem?
> Turris already use a variant of that patch and also mediatek use
> it.
I closed https://github.com/openwrt/openwrt/pull/3655 since 21.02 was
branched. I would use that patchset as the Turris people are working
on upstreaming a bunch of stuff.
>
> The idea would be to place the patch as a hack in the generic
> target dir and targets can add patches to modify the dsa driver
> accordingly (if needed).
>
> (the multi-cpu variant i'm talking about it the one that statically
> link a port to a dedicated cpu port in the dts)
>
> ___
> 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: Build openwrt with clang

[Rosen Penev]

On Sat, Mar 6, 2021 at 12:19 AM Michael Fuckner  wrote:
>
> Hi,
>
> I'm not exactly sure if this is trivial or totally insane- I have the idea to 
> compile the whole openwrt with clang instead of gcc. I could not get a point 
> to start at. Can you help me?
I don't think LLVM supports all the targets OpenWrt does.

Replacing gcc/g++ with clang(++) for host packages is possible but the
cabal here does not support that. Patches that fix such problems are
quickly rejected.
>
> Any hints?
>
> Regards,
>  Michael!
>
> ___
> 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] binutils: fix compilation with ccache

[Rosen Penev]

For some reason, one of the configure checks results in some infinite
loop and ends up spawning endless gcc processes, causing OOM. Just pass
a configure var to avoid it.

Signed-off-by: Rosen Penev 
---
 toolchain/binutils/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/toolchain/binutils/Makefile b/toolchain/binutils/Makefile
index 60b0a41715..fba064a1a5 100644
--- a/toolchain/binutils/Makefile
+++ b/toolchain/binutils/Makefile
@@ -64,6 +64,9 @@ ifneq ($(CONFIG_EXTRA_TARGET_ARCH),)
--enable-targets=$(call 
qstrip,$(CONFIG_EXTRA_TARGET_ARCH_NAME))-linux-$(TARGET_SUFFIX)
 endif
 
+HOST_CONFIGURE_VARS += \
+   acx_cv_cc_gcc_supports_ada=false
+
 define Host/Prepare
$(call Host/Prepare/Default)
ln -snf $(notdir $(HOST_BUILD_DIR)) $(BUILD_DIR_TOOLCHAIN)/$(PKG_NAME)
-- 
2.29.2


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