Re: [OpenWrt-Devel] [PATCH ustream-ssl v2 3/3] wolfssl: enable CN validation

[Eneas Queiroz]

I just realized now that my reply went to Hauke only, so I'm sending
it again to the mailing list, as it may be useful for more people.

On Fri, Sep 20, 2019 at 5:43 PM Hauke Mehrtens  wrote:
>
> On 9/19/19 4:18 AM, Eneas U de Queiroz wrote:
> > WolfSSL added a wolfSSL_X509_check_host function to perform CN
> > validation in v3.10.4, depending on the build-time configure options:
> > --enable-nginx enables it for all supported versions;
> > --enable-opensslextra, since v3.14.2.
> >
> > If the function is unavailable, then SSL_get_verify_result will be
> > called, and 'valid_cert' will be true if that call suceeds and we
> > have a peer certificate, just as it happens with openssl. Only
> > 'valid_cn' will not be set.
> >
> > Signed-off-by: Eneas U de Queiroz 
> >
> > diff --git a/CMakeLists.txt b/CMakeLists.txt
> > index 6b3fc8c..86e1b07 100644
> > --- a/CMakeLists.txt
> > +++ b/CMakeLists.txt
> > @@ -21,6 +21,12 @@ ELSEIF(WOLFSSL)
> >IF (NOT HAVE_WOLFSSL_SSLSETIORECV)
> >  ADD_DEFINITIONS(-DNO_WOLFSSL_SSLSETIO_SEND_RECV)
> >ENDIF()
> > +  CHECK_SYMBOL_EXISTS (wolfSSL_X509_check_host
> > +"wolfssl/options.h;wolfssl/ssl.h"
> > +HAVE_WOLFSSL_X509_CHECK_HOST)
> > +  IF (NOT HAVE_WOLFSSL_X509_CHECK_HOST)
> > +ADD_DEFINITIONS(-DNO_X509_CHECK_HOST)
> > +  ENDIF()
> >  ELSE()
> >SET(SSL_SRC ustream-io-openssl.c ustream-openssl.c)
> >SET(SSL_LIB crypto ssl)
> > diff --git a/ustream-openssl.c b/ustream-openssl.c
> > index 21abf61..c830618 100644
> > --- a/ustream-openssl.c
> > +++ b/ustream-openssl.c
> > @@ -203,7 +203,7 @@ static void ustream_ssl_error(struct ustream_ssl *us, 
> > int ret)
> >   uloop_timeout_set(>error_timer, 0);
> >  }
> >
> > -#ifndef WOLFSSL_OPENSSL_H_
> > +#ifndef NO_X509_CHECK_HOST
> >
> >  static bool ustream_ssl_verify_cn(struct ustream_ssl *us, X509 *cert)
> >  {
> > @@ -212,10 +212,15 @@ static bool ustream_ssl_verify_cn(struct ustream_ssl 
> > *us, X509 *cert)
> >   if (!us->peer_cn)
> >   return false;
> >
> > +# ifndef WOLFSSL_OPENSSL_H_
> >   ret = X509_check_host(cert, us->peer_cn, 0, 
> > X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS, NULL);
> > +# else
> > + ret = wolfSSL_X509_check_host(cert, us->peer_cn, 0, 0, NULL);
> > +# endif
> >   return ret == 1;
> >  }
> >
> > +#endif
> >
> >  static void ustream_ssl_verify_cert(struct ustream_ssl *us)
> >  {
> > @@ -235,11 +240,12 @@ static void ustream_ssl_verify_cert(struct 
> > ustream_ssl *us)
> >   return;
> >
> >   us->valid_cert = true;
> > +#ifndef NO_X509_CHECK_HOST
> >   us->valid_cn = ustream_ssl_verify_cn(us, cert);
> > +#endif
> >   X509_free(cert);
> >  }
> >
> > -#endif
> >
> >  __hidden enum ssl_conn_status __ustream_ssl_connect(struct ustream_ssl *us)
> >  {
> > @@ -252,9 +258,7 @@ __hidden enum ssl_conn_status 
> > __ustream_ssl_connect(struct ustream_ssl *us)
> >   r = SSL_connect(ssl);
> >
> >   if (r == 1) {
> > -#ifndef WOLFSSL_OPENSSL_H_
> >   ustream_ssl_verify_cert(us);
> > -#endif
> >   return U_SSL_OK;
> >   }
>
> I am getting this error message with this patch:
>
> [ 12%] Building C object CMakeFiles/ustream-ssl.dir/ustream-ssl.c.o
> In file included from
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-internal.h:27:0,
>  from
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-ssl.c:25:
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-openssl.h:
> In function '__ustream_ssl_set_server_name':
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-openssl.h:48:2:
> error: implicit declaration of function 'SSL_set_tlsext_host_name'; did
> you mean 'SSL_set_tlsext_debug_arg'? [-Werror=implicit-function-declaration]
>   SSL_set_tlsext_host_name(us->ssl, us->server_name);
>   ^~~~
>   SSL_set_tlsext_debug_arg
> cc1: all warnings being treated as errors
> make[6]: *** [CMakeFiles/ustream-ssl.dir/build.make:63:
> CMakeFiles/ustream-ssl.dir/ustream-ssl.c.o] Error 1
>
>
> and this config:
> CONFIG_WOLFSSL_HAS_AES_CCM=y
> CONFIG_WOLFSSL_HAS_ARC4=y
> CONFIG_WOLFSSL_HAS_CHACHA_POLY=y
> CONFIG_WOLFSSL_HAS_DH=y
> CONFIG_WOLFSSL_HAS_NO_HW=y
> CONFIG_WOLFSSL_HAS_OCSP=y
> CONFIG_WOLFSSL_HAS_SESSION_TICKET=y
> CONFIG_WOLFSSL_HAS_TLSV10=y
> CONFIG_WOLFSSL_HAS_TLSV13=y
> CONFIG_WOLFSSL_HAS_WPAS=y
>
>
> Hauke
>
>

I should have mentioned it before, but you need to update the
references from cyassl to wolfssl in openwrt to be able to compile it.
I will send the patch to openwrt once ustream-ssl is updated.
Meanwhile, this should do the trick:

--- a/package/libs/ustream-ssl/Makefile
+++ b/package/libs/ustream-ssl/Makefile
@@ -49,8 +49,8 @@ define 

Re: [OpenWrt-Devel] [PATCH] apm821xx: for Meraki MR24 modify BLOCKSIZE to reduce LEB over-allocation

[Russell Senior]

On Fri, Sep 20, 2019 at 1:35 PM Christian Lamparter 
wrote:

> Hello,
>
> On Tuesday, September 17, 2019 6:59:28 AM CEST Russell Senior wrote:
> > On Meraki MR24, the BLOCKSIZE variable is used to allocate space for the
> > kernel blob. The LEB size on MR24 is 15.5k (15872 bytes). In the
> > particular instance observed, it was found that reducing blocksize to
> > 512 bytes resulted in 3 fewer LEBs being allocated to the kernel ubi
> > volume, with no ill effects.
> >
> > Signed-off-by: Russell Senior 
> > ---
> >  target/linux/apm821xx/image/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/target/linux/apm821xx/image/Makefile
> b/target/linux/apm821xx/image/Makefile
> > index 8203de39c5..1aa4e0dad3 100644
> > --- a/target/linux/apm821xx/image/Makefile
> > +++ b/target/linux/apm821xx/image/Makefile
> > @@ -127,7 +127,7 @@ define Device/meraki_mr24
> >DEVICE_PACKAGES := kmod-spi-gpio -swconfig
> >BOARD_NAME := mr24
> >DEVICE_DTS := meraki-mr24
> > -  BLOCKSIZE := 63k
> > +  BLOCKSIZE := 512
> >IMAGES := sysupgrade.bin
> >DTB_SIZE := 64512
> >IMAGE_SIZE := 8191k
>
> The value looks odd, since UBI volumes are always a multiple of the LEB
> size
> and the documentation we have
> 
> states that "The erasesize is the block size of the flash [...]".
> so in that regard BLOCKSIZE could be 15872 or 16 KiB (if we would stick to
> the real, raw value of the flash).
>

The only thing BLOCKSIZE is used for (afaict, for MR24) is in
bs=$(BLOCKSIZE) while generating the kernel blob (which includes a header
and a device tree binary as well). The DTB_SIZE is to align the device tree
and kernel at particular addresses. The sysupgrade infrastructure
(package/base-files/files/lib/upgrade/nand.sh) on the device deals with ubi
volume creation, and it's going to allocate LEBs to volumes to minimally
accommodate the file that is provided to occupy that volume. We could just
concatenate the kernel with no blocking at all, and it would work fine.
The section you are referring to is talking about the mtd layer, not ubi.


>
> But I don't think a generated image with these parameters would boot
> anymore.
>

Which parameters? I've tested 512 and it boots fine.


> As the problem here is hidden in "MerakiAdd-dtb" step that is used
> generate the
> KERNEL (for sysupgrade) relies on that  BLOCKSIZE value being a integer
> divisible
> of the 63KiB value. Since this magic value (63KiB) is needed to place the
> DTB+kernel at the correct offsets for mkmerakifw.
>

No, the device tree and kernel are placed in the "right spots" (the ones
expected by u-boot) because of the DTB_SIZE variable. There is a header,
the device tree at offset 1k, and the kernel starts at offset 64k.

define Build/MerakiAdd-dtb
$(call Image/BuildDTB,../dts/$(DEVICE_DTS).dts,$@.dtb)
( \
dd if=$@.dtb bs=$(DTB_SIZE) conv=sync; \
dd if=$@ bs=$(BLOCKSIZE) conv=sync; \
) > $@.new
@mv $@.new $@
endef

That second dd could be "cat $@" and I think it would work (but haven't
tested), because the blocking of the kernel is not important.


>
> so, what to do? Because it's possible to get rid of the whole logic as
> well as the
> MR24 portion of the mkmerakifw by refactoring the u-boot boot commands to
> just load
> and boot a multi-file image. The framework is all there since the
> initramfs image is
> already utilizing "MuImage-initramfs". This would save even more since
> this makes it
> possible to also shrink down the DTB as well. As the "raw" information in
> there is
> just around 10k-15k and the rest of this is fluff. (Some of this fluff is
> needed by
> u-boot though. As it needs some space (probably less than 128 bytes) of
> this area to
> "add" in values for frequencies and ranges. So it can't be completely
> removed like
> with newer u-boots).
>

It seems like the current u-boot-env variables won't support that and it's
not clear how to guarantee the u-boot-env is set up before you flash the
new image style. It seems much safer to just stick with the current layout
for now.


>
> So, Would you be willing to do this?
>
> Regards,
> Christian
>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] brcm47xx: fix switch port labels for Asus WL500GP V2

[Michael Heimpold]

The switch port naming in LuCI does not fit the physical numbers
on the front of this device. Since this is confusing, fix it.

Signed-off-by: Michael Heimpold 
---
 target/linux/brcm47xx/base-files/etc/board.d/01_network | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/linux/brcm47xx/base-files/etc/board.d/01_network 
b/target/linux/brcm47xx/base-files/etc/board.d/01_network
index 8428b43dec..6fbd76fc10 100755
--- a/target/linux/brcm47xx/base-files/etc/board.d/01_network
+++ b/target/linux/brcm47xx/base-files/etc/board.d/01_network
@@ -143,8 +143,12 @@ configure_by_model() {
ucidef_set_interfaces_lan_wan "eth0" "eth1"
;;
 
+   "Asus WL500GP V2")
+   ucidef_add_switch "switch0" \
+   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "5@eth0"
+   ;;
+
"Asus RT-N12"* | \
-   "Asus WL500GP V2" | \
"Buffalo WHR-G125" | \
"D-Link DIR-330" | \
"Motorola WR850G" | \
-- 
2.17.1


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

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

[support]

Hi Ben,




When do you think you can port those changes to your firmware?




Thank you for your support.


Klevis.




On Fri, Sep 20, 2019 at 10:01 PM +0200, "Ben Greear"  
wrote:










On 9/20/19 12:55 PM, Vincent Wiemann wrote:
> Hi Klevis,
> 
> have you tried it with a short distance?
> If you did you should better ask Ben Greear directly.

I asked him to post publicly so that others can help answer and that my own 
answers might
help someone else.

I have some patches that should enable coverage class settings for wave-2, but 
I am too busy
with other things right now to port them to my ath10k-ct driver/firmware.

Thanks,
Ben

> 
> By the way ath10k gen 2 chipsets don't work very well with long distance 
> links without a
> special feature which implementation is only available to companies like 
> Ubiquiti and very few
> people who have an own reverse-engineered implementation.
> It works on IPQ401X, QCA9886 and QCA9888 based chips only.
> 
> And it is not possible to set a coverage class for gen 2 devices, yet as far 
> as I know due to missing
> documentation and implementation (correct me if that information is outdated).
> Furthermore a high channel width often results in problems
> due to lower receiver sensibility.
> We have better experiences with lower channel widths and sometimes get more 
> throughput with that.
> 
> Actually I think this does not explain your connection issues as 13 km is not 
> that much.
> 
> Regards,
> 
> Vincent Wiemann
> 
> On 20.09.19 18:30, supp...@maxnet.al wrote:
>> Hello everyone,
>>
>> I am trying to setup a custom made outdoor link with Apu2d2 board devices 
>> and QCA9994 cards from compex. After i installed openwrt and ath10k ct 
>> driver, kmod ath10k and board-2.bin the device can run a 80MHz channel in 
>> WDS AP. The problem is that it won't run as station or station wds. It can 
>> scan
>> the SSIDs but won't connect them.
>>
>> Any suggestion?
>>
>> Thank you!
>> Klevis
>>
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com






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

[OpenWrt-Devel] [PATCH] kernel: fix hw-crypto detection of qce driver

[Eneas U de Queiroz]

This adds the CRYPTO_ALG_KERN_DRIVER_ONLY flag to Qualcomm crypto engine
driver algorithms, so that openssl devcrypto can recognize them as
hardware-accelerated.

Signed-off-by: Eneas U de Queiroz 

--

It was reported to me at the forum:
https://forum.openwrt.org/t/comparing-cpu-soc-performance/36115/20

I have submitted the patch upstream, but haven't got any feedback yet.

This is a basic fix.  Nonetheless, I need someone with access to
Qualcomm Ahteros IPQ40XX/IPQ806X to confirm that it works.  I've
successfully compile-tested it for both targets.

The output of 'openssl engine -pre DUMP_INFO devcrypto' should show the
*-qce drivers as (hw accelerated), instead of (software).

The 4.14 patch should be cherry-picked to openwrt-19.07, and I will send
a patch for it after this is merged unless someone tell me otherwise.

diff --git 
a/target/linux/generic/pending-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
 
b/target/linux/generic/pending-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
new file mode 100644
index 00..71ed00af22
--- /dev/null
+++ 
b/target/linux/generic/pending-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
@@ -0,0 +1,31 @@
+From: Eneas U de Queiroz 
+Subject: [PATCH] crypto: qce - add CRYPTO_ALG_KERN_DRIVER_ONLY flag
+
+Set the CRYPTO_ALG_KERN_DRIVER_ONLY flag to all algorithms exposed by
+the qce driver, since they are all hardware accelerated, accessible
+through a kernel driver only, and not available directly to userspace.
+
+Signed-off-by: Eneas U de Queiroz 
+
+--- a/drivers/crypto/qce/ablkcipher.c
 b/drivers/crypto/qce/ablkcipher.c
+@@ -373,7 +373,7 @@ static int qce_ablkcipher_register_one(const struct 
qce_ablkcipher_def *def,
+ 
+   alg->cra_priority = 300;
+   alg->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC |
+-   CRYPTO_ALG_NEED_FALLBACK;
++   CRYPTO_ALG_NEED_FALLBACK | CRYPTO_ALG_KERN_DRIVER_ONLY;
+   alg->cra_ctxsize = sizeof(struct qce_cipher_ctx);
+   alg->cra_alignmask = 0;
+   alg->cra_type = _ablkcipher_type;
+--- a/drivers/crypto/qce/sha.c
 b/drivers/crypto/qce/sha.c
+@@ -526,7 +526,7 @@ static int qce_ahash_register_one(const struct 
qce_ahash_def *def,
+   base = >halg.base;
+   base->cra_blocksize = def->blocksize;
+   base->cra_priority = 300;
+-  base->cra_flags = CRYPTO_ALG_ASYNC;
++  base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY;
+   base->cra_ctxsize = sizeof(struct qce_sha_ctx);
+   base->cra_alignmask = 0;
+   base->cra_module = THIS_MODULE;
diff --git 
a/target/linux/generic/pending-4.19/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
 
b/target/linux/generic/pending-4.19/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
new file mode 100644
index 00..b542885d38
--- /dev/null
+++ 
b/target/linux/generic/pending-4.19/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
@@ -0,0 +1,31 @@
+From: Eneas U de Queiroz 
+Subject: [PATCH] crypto: qce - add CRYPTO_ALG_KERN_DRIVER_ONLY flag
+
+Set the CRYPTO_ALG_KERN_DRIVER_ONLY flag to all algorithms exposed by
+the qce driver, since they are all hardware accelerated, accessible
+through a kernel driver only, and not available directly to userspace.
+
+Signed-off-by: Eneas U de Queiroz 
+
+--- a/drivers/crypto/qce/ablkcipher.c
 b/drivers/crypto/qce/ablkcipher.c
+@@ -370,7 +370,7 @@ static int qce_ablkcipher_register_one(const struct 
qce_ablkcipher_def *def,
+ 
+   alg->cra_priority = 300;
+   alg->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC |
+-   CRYPTO_ALG_NEED_FALLBACK;
++   CRYPTO_ALG_NEED_FALLBACK | CRYPTO_ALG_KERN_DRIVER_ONLY;
+   alg->cra_ctxsize = sizeof(struct qce_cipher_ctx);
+   alg->cra_alignmask = 0;
+   alg->cra_type = _ablkcipher_type;
+--- a/drivers/crypto/qce/sha.c
 b/drivers/crypto/qce/sha.c
+@@ -503,7 +503,7 @@ static int qce_ahash_register_one(const struct 
qce_ahash_def *def,
+   base = >halg.base;
+   base->cra_blocksize = def->blocksize;
+   base->cra_priority = 300;
+-  base->cra_flags = CRYPTO_ALG_ASYNC;
++  base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY;
+   base->cra_ctxsize = sizeof(struct qce_sha_ctx);
+   base->cra_alignmask = 0;
+   base->cra_module = THIS_MODULE;

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

Re: [OpenWrt-Devel] [PATCH ustream-ssl v2 3/3] wolfssl: enable CN validation

[Hauke Mehrtens]

On 9/19/19 4:18 AM, Eneas U de Queiroz wrote:
> WolfSSL added a wolfSSL_X509_check_host function to perform CN
> validation in v3.10.4, depending on the build-time configure options:
> --enable-nginx enables it for all supported versions;
> --enable-opensslextra, since v3.14.2.
> 
> If the function is unavailable, then SSL_get_verify_result will be
> called, and 'valid_cert' will be true if that call suceeds and we
> have a peer certificate, just as it happens with openssl. Only
> 'valid_cn' will not be set.
> 
> Signed-off-by: Eneas U de Queiroz 
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 6b3fc8c..86e1b07 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -21,6 +21,12 @@ ELSEIF(WOLFSSL)
>IF (NOT HAVE_WOLFSSL_SSLSETIORECV)
>  ADD_DEFINITIONS(-DNO_WOLFSSL_SSLSETIO_SEND_RECV)
>ENDIF()
> +  CHECK_SYMBOL_EXISTS (wolfSSL_X509_check_host
> +"wolfssl/options.h;wolfssl/ssl.h"
> +HAVE_WOLFSSL_X509_CHECK_HOST)
> +  IF (NOT HAVE_WOLFSSL_X509_CHECK_HOST)
> +ADD_DEFINITIONS(-DNO_X509_CHECK_HOST)
> +  ENDIF()
>  ELSE()
>SET(SSL_SRC ustream-io-openssl.c ustream-openssl.c)
>SET(SSL_LIB crypto ssl)
> diff --git a/ustream-openssl.c b/ustream-openssl.c
> index 21abf61..c830618 100644
> --- a/ustream-openssl.c
> +++ b/ustream-openssl.c
> @@ -203,7 +203,7 @@ static void ustream_ssl_error(struct ustream_ssl *us, int 
> ret)
>   uloop_timeout_set(>error_timer, 0);
>  }
>  
> -#ifndef WOLFSSL_OPENSSL_H_
> +#ifndef NO_X509_CHECK_HOST
>  
>  static bool ustream_ssl_verify_cn(struct ustream_ssl *us, X509 *cert)
>  {
> @@ -212,10 +212,15 @@ static bool ustream_ssl_verify_cn(struct ustream_ssl 
> *us, X509 *cert)
>   if (!us->peer_cn)
>   return false;
>  
> +# ifndef WOLFSSL_OPENSSL_H_
>   ret = X509_check_host(cert, us->peer_cn, 0, 
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS, NULL);
> +# else
> + ret = wolfSSL_X509_check_host(cert, us->peer_cn, 0, 0, NULL);
> +# endif
>   return ret == 1;
>  }
>  
> +#endif
>  
>  static void ustream_ssl_verify_cert(struct ustream_ssl *us)
>  {
> @@ -235,11 +240,12 @@ static void ustream_ssl_verify_cert(struct ustream_ssl 
> *us)
>   return;
>  
>   us->valid_cert = true;
> +#ifndef NO_X509_CHECK_HOST
>   us->valid_cn = ustream_ssl_verify_cn(us, cert);
> +#endif
>   X509_free(cert);
>  }
>  
> -#endif
>  
>  __hidden enum ssl_conn_status __ustream_ssl_connect(struct ustream_ssl *us)
>  {
> @@ -252,9 +258,7 @@ __hidden enum ssl_conn_status 
> __ustream_ssl_connect(struct ustream_ssl *us)
>   r = SSL_connect(ssl);
>  
>   if (r == 1) {
> -#ifndef WOLFSSL_OPENSSL_H_
>   ustream_ssl_verify_cert(us);
> -#endif
>   return U_SSL_OK;
>   }

I am getting this error message with this patch:

[ 12%] Building C object CMakeFiles/ustream-ssl.dir/ustream-ssl.c.o
In file included from
/home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-internal.h:27:0,
 from
/home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-ssl.c:25:
/home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-openssl.h:
In function '__ustream_ssl_set_server_name':
/home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-openssl.h:48:2:
error: implicit declaration of function 'SSL_set_tlsext_host_name'; did
you mean 'SSL_set_tlsext_debug_arg'? [-Werror=implicit-function-declaration]
  SSL_set_tlsext_host_name(us->ssl, us->server_name);
  ^~~~
  SSL_set_tlsext_debug_arg
cc1: all warnings being treated as errors
make[6]: *** [CMakeFiles/ustream-ssl.dir/build.make:63:
CMakeFiles/ustream-ssl.dir/ustream-ssl.c.o] Error 1


and this config:
CONFIG_WOLFSSL_HAS_AES_CCM=y
CONFIG_WOLFSSL_HAS_ARC4=y
CONFIG_WOLFSSL_HAS_CHACHA_POLY=y
CONFIG_WOLFSSL_HAS_DH=y
CONFIG_WOLFSSL_HAS_NO_HW=y
CONFIG_WOLFSSL_HAS_OCSP=y
CONFIG_WOLFSSL_HAS_SESSION_TICKET=y
CONFIG_WOLFSSL_HAS_TLSV10=y
CONFIG_WOLFSSL_HAS_TLSV13=y
CONFIG_WOLFSSL_HAS_WPAS=y


Hauke





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

Re: [OpenWrt-Devel] [PATCH] apm821xx: for Meraki MR24 modify BLOCKSIZE to reduce LEB over-allocation

[Christian Lamparter]

Hello,

On Tuesday, September 17, 2019 6:59:28 AM CEST Russell Senior wrote:
> On Meraki MR24, the BLOCKSIZE variable is used to allocate space for the
> kernel blob. The LEB size on MR24 is 15.5k (15872 bytes). In the
> particular instance observed, it was found that reducing blocksize to
> 512 bytes resulted in 3 fewer LEBs being allocated to the kernel ubi
> volume, with no ill effects.
> 
> Signed-off-by: Russell Senior 
> ---
>  target/linux/apm821xx/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/apm821xx/image/Makefile 
> b/target/linux/apm821xx/image/Makefile
> index 8203de39c5..1aa4e0dad3 100644
> --- a/target/linux/apm821xx/image/Makefile
> +++ b/target/linux/apm821xx/image/Makefile
> @@ -127,7 +127,7 @@ define Device/meraki_mr24
>DEVICE_PACKAGES := kmod-spi-gpio -swconfig
>BOARD_NAME := mr24
>DEVICE_DTS := meraki-mr24
> -  BLOCKSIZE := 63k
> +  BLOCKSIZE := 512
>IMAGES := sysupgrade.bin
>DTB_SIZE := 64512
>IMAGE_SIZE := 8191k

The value looks odd, since UBI volumes are always a multiple of the LEB size
and the documentation we have

states that "The erasesize is the block size of the flash [...]".
so in that regard BLOCKSIZE could be 15872 or 16 KiB (if we would stick to
the real, raw value of the flash).

But I don't think a generated image with these parameters would boot anymore.
As the problem here is hidden in "MerakiAdd-dtb" step that is used generate the
KERNEL (for sysupgrade) relies on that  BLOCKSIZE value being a integer 
divisible
of the 63KiB value. Since this magic value (63KiB) is needed to place the
DTB+kernel at the correct offsets for mkmerakifw.

so, what to do? Because it's possible to get rid of the whole logic as well as 
the
MR24 portion of the mkmerakifw by refactoring the u-boot boot commands to just 
load
and boot a multi-file image. The framework is all there since the initramfs 
image is
already utilizing "MuImage-initramfs". This would save even more since this 
makes it
possible to also shrink down the DTB as well. As the "raw" information in there 
is 
just around 10k-15k and the rest of this is fluff. (Some of this fluff is 
needed by
u-boot though. As it needs some space (probably less than 128 bytes) of this 
area to
"add" in values for frequencies and ranges. So it can't be completely removed 
like
with newer u-boots).

So, Would you be willing to do this? 

Regards,
Christian



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

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

[support]

Hi Vincent,




I have tried short distance with ddwrt and i get 1733/1733 datarates and about 
1Gbps real traffic using iperf. Ubiquiti and MikroTik have 80MHz outdoor radios 
and they work good. I don't want to use 160MHz which is very wide and there are 
lot of 20MHz channels within that will create interferences. Actually i want to 
benefit from VHT-NSS4 so at 80MHz channel i will get 1560Mbps. Ben Greear also 
thinks that is something wrong with ACK timing.From: Vincent Wiemann 

Sent: Friday, 20 September 2019, 21:56
To: supp...@maxnet.al; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

Hi Klevis,

have you tried it with a short distance?
If you did you should better ask Ben Greear directly.

By the way ath10k gen 2 chipsets don't work very well with long distance links 
without a
special feature which implementation is only available to companies like 
Ubiquiti and very few
people who have an own reverse-engineered implementation.
It works on IPQ401X, QCA9886 and QCA9888 based chips only.

And it is not possible to set a coverage class for gen 2 devices, yet as far as 
I know due to missing
documentation and implementation (correct me if that information is outdated).
Furthermore a high channel width often results in problems
due to lower receiver sensibility.
We have better experiences with lower channel widths and sometimes get more 
throughput with that.

Actually I think this does not explain your connection issues as 13 km is not 
that much.

Regards,

Vincent Wiemann

On 20.09.19 18:30, supp...@maxnet.al wrote:
> Hello everyone,
> 
> I am trying to setup a custom made outdoor link with Apu2d2 board devices and 
> QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, 
> kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The 
> problem is that it won't run as station or station wds. It can scan
> the SSIDs but won't connect them. 
> 
> Any suggestion?
> 
> Thank you!
> Klevis
> 

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

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

[Ben Greear]

On 9/20/19 12:55 PM, Vincent Wiemann wrote:

Hi Klevis,

have you tried it with a short distance?
If you did you should better ask Ben Greear directly.


I asked him to post publicly so that others can help answer and that my own 
answers might
help someone else.

I have some patches that should enable coverage class settings for wave-2, but 
I am too busy
with other things right now to port them to my ath10k-ct driver/firmware.

Thanks,
Ben



By the way ath10k gen 2 chipsets don't work very well with long distance links 
without a
special feature which implementation is only available to companies like 
Ubiquiti and very few
people who have an own reverse-engineered implementation.
It works on IPQ401X, QCA9886 and QCA9888 based chips only.

And it is not possible to set a coverage class for gen 2 devices, yet as far as 
I know due to missing
documentation and implementation (correct me if that information is outdated).
Furthermore a high channel width often results in problems
due to lower receiver sensibility.
We have better experiences with lower channel widths and sometimes get more 
throughput with that.

Actually I think this does not explain your connection issues as 13 km is not 
that much.

Regards,

Vincent Wiemann

On 20.09.19 18:30, supp...@maxnet.al wrote:

Hello everyone,

I am trying to setup a custom made outdoor link with Apu2d2 board devices and 
QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, kmod 
ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The 
problem is that it won't run as station or station wds. It can scan
the SSIDs but won't connect them.

Any suggestion?

Thank you!
Klevis



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




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

[Vincent Wiemann]

Hi Klevis,

have you tried it with a short distance?
If you did you should better ask Ben Greear directly.

By the way ath10k gen 2 chipsets don't work very well with long distance links 
without a
special feature which implementation is only available to companies like 
Ubiquiti and very few
people who have an own reverse-engineered implementation.
It works on IPQ401X, QCA9886 and QCA9888 based chips only.

And it is not possible to set a coverage class for gen 2 devices, yet as far as 
I know due to missing
documentation and implementation (correct me if that information is outdated).
Furthermore a high channel width often results in problems
due to lower receiver sensibility.
We have better experiences with lower channel widths and sometimes get more 
throughput with that.

Actually I think this does not explain your connection issues as 13 km is not 
that much.

Regards,

Vincent Wiemann

On 20.09.19 18:30, supp...@maxnet.al wrote:
> Hello everyone,
> 
> I am trying to setup a custom made outdoor link with Apu2d2 board devices and 
> QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, 
> kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The 
> problem is that it won't run as station or station wds. It can scan
> the SSIDs but won't connect them. 
> 
> Any suggestion?
> 
> Thank you!
> Klevis
> 

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

Re: [OpenWrt-Devel] [PATCH] usign: fix some resource leaks

[Hauke Mehrtens]

On 9/2/19 11:27 PM, Rosen Penev wrote:
> On Mon, Sep 2, 2019 at 1:29 PM Hauke Mehrtens  wrote:
>>
>> This fixes some resources leaks mostly in error patches.
>>
>> Coverity: #1330236, #1330237, #1330238
>> Signed-off-by: Hauke Mehrtens 
>> ---
>>  main.c | 12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/main.c b/main.c
>> index 3536443..ef47b28 100644
>> --- a/main.c
>> +++ b/main.c
>> @@ -129,6 +129,7 @@ get_file(const char *filename, char *buf, int buflen)
>>
>> len = fread(buf, 1, buflen - 1, f);
>> buf[len] = 0;
>> +   fclose(f);
> It's more compact to use __attribute__((cleanup)) instead. Although
> last time I tried making changes like those they were shot sown since
> it's a GNU extension.

Nice feature, I was not aware of it.

I still would use the old way because this is a GNU extension.

Hauke



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

[OpenWrt-Devel] [openwrt] Patch notification: 1 patch updated

[Patchwork]

Hello,

The following patch (submitted by you) has been updated in Patchwork:

 * openwrt: [OpenWrt-Devel] build: fix make kernel_menuconfig
 - http://patchwork.ozlabs.org/patch/1163120/
 - for: OpenWrt development
was: Under Review
now: Rejected

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the Patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

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

Re: [OpenWrt-Devel] [PATCH] build: fix make kernel_menuconfig

[Petr Štetiar]

Thomas Albers via openwrt-devel  [2019-09-16 
17:55:42]:

Hi,

[...]

> Use system pkg-config instead of toolchain pkg-config when the kernel 
> config scripts are compiled (see FS#2423)

[...]

> diff --git a/tools/pkg-config/files/pkg-config 
> b/tools/pkg-config/files/pkg-config
> index 82cc74ffcb..00243e663e 100755
> --- a/tools/pkg-config/files/pkg-config
> +++ b/tools/pkg-config/files/pkg-config
> @@ -1,3 +1,7 @@
>  #!/bin/sh
>  
> -pkg-config.real --define-variable=prefix=${STAGING_PREFIX} 
> --define-variable=exec_prefix=${STAGING_PREFIX} 
> --define-variable=bindir=${STAGING_PREFIX}/bin $@
> +if [ -n "${STAGING_PREFIX}" ]; then
> + pkg-config.real --define-variable=prefix=${STAGING_PREFIX} 
> --define-variable=exec_prefix=${STAGING_PREFIX} 
> --define-variable=bindir=${STAGING_PREFIX}/bin $@
> +else
> + ${SYSTEM_PKG_CONFIG} $@
> +fi

I've discussed this patch today on IRC and we came to the conclusion, that
it's too fragile and that it would be preferred to simply focus on fixing just
what is broken, thus just kernel_menuconfig target.

I came up with following fix[1].

1. https://git.openwrt.org/4faf5f30e4479e4f033963c70b312035fa1774ab

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

[Jakub Kicinski]

On Fri, 20 Sep 2019 15:37:08 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Hardware or firmware instability may result in unusable wiphy. In such
> cases usually a hardware reset is needed. To allow a full recovery
> kernel has to indicate problem to the user space.
> 
> This new nl80211 command lets user space known wiphy has crashed and has
> been just recovered. When applicable it should result in supplicant or
> authenticator reconfiguring all interfaces.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> I'd like to use this new cfg80211_crash_report() in brcmfmac after a
> successful recovery from a FullMAC firmware crash.
> 
> Later on I'd like to modify hostapd to reconfigure wiphy using a
> previously used setup.
> 
> I'm OpenWrt developer & user and I got annoyed by my devices not auto
> recovering after various failures. There are things I cannot fix (hw
> failures or closed fw crashes) but I still expect my devices to get
> back to operational state as soon as possible on their own.

Perhaps a slightly larger point, but I think it should be raised - 
is there any chance for reusing debugging, reset and recovery work done
in devlink originally for complex Ethernet devices?

WiFi drivers have been dealing with more complex/FW heavy designs for a
while so maybe you've grow your own interfaces, and maybe they
necessarily need to be 802.11-centric, but I'm a little surprised that:

linux $ git grep devlink -- drivers/net/wireless/
linux $

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

[OpenWrt-Devel] QCA9994 outdoor 13km link

[support]

Hello everyone,
I am trying to setup a custom made outdoor link with Apu2d2 board devices and 
QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, kmod 
ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The 
problem is that it won't run as station or station wds. It can scan the SSIDs 
but won't connect them. 
Any suggestion?
Thank you!Klevis

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

Re: [OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

[Jouni Malinen]

On Fri, Sep 20, 2019 at 03:37:08PM +0200, Rafał Miłecki wrote:
> Hardware or firmware instability may result in unusable wiphy. In such
> cases usually a hardware reset is needed. To allow a full recovery
> kernel has to indicate problem to the user space.

Why? Shouldn't the driver be able to handle this on its own since all
the previous configuration was done through the driver anyway. As far as
I know, there are drivers that do indeed try to do this and handle it
successfully at least for station mode. AP mode may be more complex, but
for that one, I guess it would be fine to drop all associations (and
provide indication of that to user space) and just restart the BSS.

> This new nl80211 command lets user space known wiphy has crashed and has
> been just recovered. When applicable it should result in supplicant or
> authenticator reconfiguring all interfaces.

For me, that is not really "recovered" if some additional
reconfiguration steps are needed.. I'd like to get a more detailed view
on what exactly might need to be reconfigured and how would user space
know what exactly to do. Or would the plan here be that the driver would
not even indicate this crash if it is actually able to internally
recover fully from the firmware restart?

> I'd like to use this new cfg80211_crash_report() in brcmfmac after a
> successful recovery from a FullMAC firmware crash.
> 
> Later on I'd like to modify hostapd to reconfigure wiphy using a
> previously used setup.

So this implies that at least something would need to happen in AP mode.
Do you have a list of items that the driver cannot do on its own and why
it would be better to do them from user space?

> I'm OpenWrt developer & user and I got annoyed by my devices not auto
> recovering after various failures. There are things I cannot fix (hw
> failures or closed fw crashes) but I still expect my devices to get
> back to operational state as soon as possible on their own.

I fully agree with the auto recovery being important thing to cover for
this, but I'm not yet convinced that this needs user space action. Or if
it does, there would need to be more detailed way of indicating what
exactly is needed for user space to do. The proposed change here is just
saying "hey, I crashed and did something to get the hardware/firmware
responding again" which does not really tell much to user space other
than potentially requiring full disable + re-enable for the related
interfaces. And that is something that should not actually be done in
all cases of firmware crashes since there are drivers that handle
recovery in a manner that is in practice completely transparent to user
space.

-- 
Jouni MalinenPGP id EFC895FA

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

[OpenWrt-Devel] [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

[Rafał Miłecki]

From: Rafał Miłecki 

Hardware or firmware instability may result in unusable wiphy. In such
cases usually a hardware reset is needed. To allow a full recovery
kernel has to indicate problem to the user space.

This new nl80211 command lets user space known wiphy has crashed and has
been just recovered. When applicable it should result in supplicant or
authenticator reconfiguring all interfaces.

Signed-off-by: Rafał Miłecki 
---
I'd like to use this new cfg80211_crash_report() in brcmfmac after a
successful recovery from a FullMAC firmware crash.

Later on I'd like to modify hostapd to reconfigure wiphy using a
previously used setup.

I'm OpenWrt developer & user and I got annoyed by my devices not auto
recovering after various failures. There are things I cannot fix (hw
failures or closed fw crashes) but I still expect my devices to get
back to operational state as soon as possible on their own.
---
 include/net/cfg80211.h   |  7 +++
 include/uapi/linux/nl80211.h |  2 ++
 net/wireless/nl80211.c   | 29 +
 3 files changed, 38 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ff45c3e1abff..668fa27c88cc 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -7437,6 +7437,13 @@ void cfg80211_pmsr_complete(struct wireless_dev *wdev,
 bool cfg80211_iftype_allowed(struct wiphy *wiphy, enum nl80211_iftype iftype,
 bool is_4addr, u8 check_swif);
 
+/**
+ * cfg80211_crash_report - report crashed wiphy that requires a setup
+ *
+ * @wiphy: the wiphy
+ * @gfp: allocation flags
+ */
+void cfg80211_crash_report(struct wiphy *wiphy, gfp_t gfp);
 
 /* Logging, debugging and troubleshooting/diagnostic helpers. */
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index beee59c831a7..9e17feb03849 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1325,6 +1325,8 @@ enum nl80211_commands {
 
NL80211_CMD_PROBE_MESH_LINK,
 
+   NL80211_CMD_CRASH_REPORT,
+
/* add new commands above here */
 
/* used to define NL80211_CMD_MAX below */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d21b1581a665..d29785fb0676 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16940,6 +16940,35 @@ void cfg80211_update_owe_info_event(struct net_device 
*netdev,
 }
 EXPORT_SYMBOL(cfg80211_update_owe_info_event);
 
+void cfg80211_crash_report(struct wiphy *wiphy, gfp_t gfp)
+{
+   struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
+   struct sk_buff *msg;
+   void *hdr;
+
+   msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
+   if (!msg)
+   return;
+
+   hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_CRASH_REPORT);
+   if (!hdr)
+   goto nla_put_failure;
+
+   if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx))
+   goto nla_put_failure;
+
+   genlmsg_end(msg, hdr);
+
+   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy), msg, 0,
+   NL80211_MCGRP_CONFIG, gfp);
+
+   return;
+
+nla_put_failure:
+   nlmsg_free(msg);
+}
+EXPORT_SYMBOL(cfg80211_crash_report);
+
 /* initialisation/exit functions */
 
 int __init nl80211_init(void)
-- 
2.21.0


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

Re: [OpenWrt-Devel] [ramips] Linkit Smart 7688

[Ivan Hörler]

I tried to compile the package libmraa as single and have some problems with 
the dependencies:

Followed this: https://openwrt.org/docs/guide-developer/single.package
First i searched for all dependencies:

root@OpenWrt:/# opkg info libmraa
Package: libmraa
Version: 2.0.0-2
Depends: libc, libstdcpp6, libjson-c4
Status: install user installed
Section: libs
Architecture: mipsel_24kc
Size: 64409
Filename: libmraa_2.0.0-2_mipsel_24kc.ipk

root@OpenWrt:/# opkg info libc
Package: libc
Version: 1.1.23-2
Depends: libgcc1
Status: install hold installed
Essential: yes
Architecture: mipsel_24kc
Installed-Time: 1568571183

then i tried to make menuconfig so i can tick the dependencies but i did not 
find the dependencie of libc named libgcc1. 
A try to compile after installing tools and toolchain fails as well:

novski@ubuntu:~/Documents/openwrt$ make package/libgcc1/compile V=s
make[1]: Entering directory '/home/novski/Documents/openwrt'
make[1]: *** No rule to make target 'package/libgcc1/compile'.  Stop.
make[1]: Leaving directory '/home/novski/Documents/openwrt'
/home/novski/Documents/openwrt/include/toplevel.mk:216: recipe for target 
'package/libgcc1/compile' failed
make: *** [package/libgcc1/compile] Error 2

Why do i not find the dependency libgcc1 in 'make menuconfig' search (/)?

Thanks, Ivan 


> Am 19.09.2019 um 20:18 schrieb Ivan Hörler :
> 
> Hi
> I have problems makeing libmraa working on Linkit Smart 7688.
> The installation worked without problems and i tested with a python script. 
> See details below:
> 
> what i did: 
> - Compiled a openWRT 18.6
> - opkg update 
> - opkg install libmraa
> - opkg install python3-light
> - opkg install libmraa-python3
> 
> - copied this skript to /root: 
> 
> import mraa
> import time
> 
> try:
> print (mraa.getVersion())
> except:
> print("no mraa available")
> 
> # Refer to the pin-out digram for the GPIO number to silk print mapping
> # in this example the number 44 maps to Wi-Fi LED.
> pin = mraa.Gpio(2)
> pin.dir(mraa.DIR_OUT)
> while True:
> pin.write(1)
> time.sleep(1)
> pin.write(0)
> time.sleep(1)
> 
> - and executed:
> root@OpenWrt:~# python3 mraa-test-simple.py 
> v2.0.0
> Traceback (most recent call last):
>   File "mraa-test-simple.py", line 11, in 
> pin = mraa.Gpio(2)
>   File "/usr/lib/python3.7/site-packages/mraa.py", line 391, in __init__
> _mraa.Gpio_swiginit(self, _mraa.new_Gpio(pin, owner, raw))
> ValueError: Invalid GPIO pin specified
> 
> 
> - checked with a LED on pin2 like this if GPIO2 works:
> root@OpenWrt:~# cd /sys/class/gpio/
> root@OpenWrt:/sys/class/gpio# ls
> export  gpiochip0   gpiochip32  gpiochip64  unexport
> root@OpenWrt:/sys/class/gpio# echo 2 > export
> root@OpenWrt:/sys/class/gpio# ls
> export  gpio2   gpiochip0   gpiochip32  gpiochip64  unexport
> root@OpenWrt:/sys/class/gpio# cd gpio2
> root@OpenWrt:/sys/devices/platform/1000.palmbus/1600.gpio/gpiochip0/gpio/gpio2#
>  echo "out" > direction
> root@OpenWrt:/sys/devices/platform/1000.palmbus/1600.gpio/gpiochip0/gpio/gpio2#
>  cat value
> 0
> root@OpenWrt:/sys/devices/platform/1000.palmbus/1600.gpio/gpiochip0/gpio/gpio2#
>  echo 1 > value
> 
> - redone previous step with no changes in error output.
> 
> what am i missing?
> 
> Thanks for comments, Ivan Hörler
> ___
> 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] [PATCH v3] ramips: replace backticks by $(...)

[Adrian Schmutzler]

This replaces deprecated backticks by more versatile $(...) syntax.

While at it, remove some useless cat commands and deprecated
egrep commands.

Signed-off-by: Adrian Schmutzler 

---

v3: rebase
---
 target/linux/ramips/base-files/etc/board.d/02_network   | 6 +++---
 .../base-files/lib/preinit/07_set_preinit_iface_ramips  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 7ecc11b37b..63644331e5 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -14,10 +14,10 @@ ramips_setup_rt3x5x_vlans()
local wanports=""
local lanports=""
for port in 5 4 3 2 1 0; do
-   if [ `swconfig dev rt305x port $port get disable` = "1" ]; then
+   if [ "$(swconfig dev rt305x port $port get disable)" = "1" ]; 
then
continue
fi
-   if [ `swconfig dev rt305x port $port get lan` = "0" ]; then
+   if [ "$(swconfig dev rt305x port $port get lan)" = "0" ]; then
wanports="$port:wan $wanports"
else
lanports="$port:lan $lanports"
@@ -503,7 +503,7 @@ ramips_setup_interfaces()
"0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "7t@eth0"
;;
*)
-   RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350)"`
+   RT3X5X=$(grep -E "(RT3.5|RT5350)" /proc/cpuinfo)
if [ -n "${RT3X5X}" ]; then
ramips_setup_rt3x5x_vlans
else
diff --git 
a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips 
b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
index a395956d04..003a4dda7b 100644
--- a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
+++ b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
@@ -4,7 +4,7 @@
 #
 
 ramips_set_preinit_iface() {
-   RT3X5X=`cat /proc/cpuinfo | egrep 
"(RT3.5|RT5350|MT7628|MT7688|MT7620|MT7621)"`
+   RT3X5X=$(grep -E "(RT3.5|RT5350|MT7628|MT7688|MT7620|MT7621)" 
/proc/cpuinfo)
 
if [ -n "${RT3X5X}" ]; then
# The ethernet switch driver enables VLAN by default, but
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH v2 2/2] ramips: fix whitespace issues in DTS files

[Adrian Schmutzler]

This is the result of grepping/searching for several common
whitespace issues like double empty lines, leading spaces, etc.

This patch fixes them for the ramips target.

Signed-off-by: Adrian Schmutzler 

---

v2: rebase, added fixes for EnGenius ESR600, AsiaRF AP7621 DTSI
---
 target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts   | 1 -
 target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts  | 2 --
 target/linux/ramips/dts/mt7620a_edimax_ew-7476rpc.dts| 1 -
 target/linux/ramips/dts/mt7620a_engenius_esr600.dts  | 4 +---
 target/linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts | 2 +-
 target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts  | 1 -
 target/linux/ramips/dts/mt7620n_zbtlink_zbt-cpe102.dts   | 1 -
 target/linux/ramips/dts/mt7621.dtsi  | 2 --
 target/linux/ramips/dts/mt7621_asiarf_ap7621.dtsi| 1 -
 target/linux/ramips/dts/mt7621_elecom_wrc-1900gst.dts| 3 +--
 target/linux/ramips/dts/mt7621_elecom_wrc-2533gst.dts| 3 +--
 target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 1 -
 target/linux/ramips/dts/mt7621_mikrotik_rbm11g.dts   | 2 --
 target/linux/ramips/dts/mt7621_mikrotik_rbm33g.dts   | 2 --
 target/linux/ramips/dts/mt7621_mtc_wr1201.dts| 1 -
 target/linux/ramips/dts/mt7628an_cudy_wr1000.dts | 1 -
 target/linux/ramips/dts/mt7628an_hilink_hlk-7628n.dts| 1 -
 target/linux/ramips/dts/mt7628an_vocore_vocore2.dtsi | 1 -
 target/linux/ramips/dts/mt7628an_wiznet_wizfi630s.dts| 1 -
 target/linux/ramips/dts/rt3050_dlink_dir-615-d.dts   | 2 --
 target/linux/ramips/dts/rt3052_argus_atp-52b.dts | 1 -
 target/linux/ramips/dts/rt3052_asiarf_awapn2403.dts  | 1 -
 target/linux/ramips/dts/rt3052_aximcom_mr-102n.dts   | 1 -
 target/linux/ramips/dts/rt3883_belkin_f9k1109v1.dts  | 1 -
 target/linux/ramips/dts/rt3883_belkin_f9k110x.dtsi   | 1 -
 target/linux/ramips/dts/rt5350_olimex_rt5350f-olinuxino.dtsi | 2 --
 target/linux/ramips/dts/rt5350_zyxel_keenetic-start.dts  | 1 -
 27 files changed, 4 insertions(+), 37 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts 
b/target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts
index cbd8d4cb80..56c0f8f890 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts
@@ -137,4 +137,3 @@
};
};
 };
-
diff --git a/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts 
b/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
index a30250e74f..43698d9fd6 100644
--- a/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
+++ b/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
@@ -69,7 +69,6 @@
};
};
 
-
gpio_export {
compatible = "gpio-export";
#size-cells = <0>;
@@ -81,7 +80,6 @@
};
 };
 
-
  {
status = "okay";
 };
diff --git a/target/linux/ramips/dts/mt7620a_edimax_ew-7476rpc.dts 
b/target/linux/ramips/dts/mt7620a_edimax_ew-7476rpc.dts
index eb326ccbd8..782263a068 100644
--- a/target/linux/ramips/dts/mt7620a_edimax_ew-7476rpc.dts
+++ b/target/linux/ramips/dts/mt7620a_edimax_ew-7476rpc.dts
@@ -44,4 +44,3 @@
};
};
 };
-
diff --git a/target/linux/ramips/dts/mt7620a_engenius_esr600.dts 
b/target/linux/ramips/dts/mt7620a_engenius_esr600.dts
index 4636a54736..65d71b99af 100644
--- a/target/linux/ramips/dts/mt7620a_engenius_esr600.dts
+++ b/target/linux/ramips/dts/mt7620a_engenius_esr600.dts
@@ -61,10 +61,8 @@
linux,code = ;
debounce-interval = <60>;
};
-
};
-
- };
+};
 
  {
status = "okay";
diff --git a/target/linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts 
b/target/linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts
index 7bf63b3287..8d58d12f02 100644
--- a/target/linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts
+++ b/target/linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts
@@ -183,5 +183,5 @@
 };
 
  {
-status = "okay";
+   status = "okay";
 };
diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts 
b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
index 2d7f6c03a3..2da35936b1 100644
--- a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
+++ b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
@@ -153,7 +153,6 @@
};
 };
 
-
  {
status = "okay";
 };
diff --git a/target/linux/ramips/dts/mt7620n_zbtlink_zbt-cpe102.dts 
b/target/linux/ramips/dts/mt7620n_zbtlink_zbt-cpe102.dts
index 10d8ca0eb6..3885428345 100644
--- a/target/linux/ramips/dts/mt7620n_zbtlink_zbt-cpe102.dts
+++ b/target/linux/ramips/dts/mt7620n_zbtlink_zbt-cpe102.dts
@@ -13,7 +13,6 @@
bootargs = "console=ttyS0,115200";
};
 
-
aliases {
led-boot = _4g_0;
led-failsafe = _4g_0;

[OpenWrt-Devel] [PATCH v2 1/2] ramips/mt762x: convert devices to interrupt-driven gpio-keys

[Adrian Schmutzler]

This converts all remaining devices to use interrupt-driven
gpio-keys compatible instead of gpio-keys-polled.
The poll-interval is removed.

While at it, add/remove newlines in keys and leds node where
necessary.

Signed-off-by: Adrian Schmutzler 

---

v2: rebase
---
 target/linux/ramips/dts/mt7620a_aigale_ai-br100.dts   |  3 +--
 .../ramips/dts/mt7620a_alfa-network_ac1200rm.dts  |  3 +--
 target/linux/ramips/dts/mt7620a_asus_rp-n53.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts |  3 +--
 target/linux/ramips/dts/mt7620a_bdcom_wap2100-sk.dts  |  3 +--
 target/linux/ramips/dts/mt7620a_buffalo_whr-1166d.dts |  3 +--
 .../linux/ramips/dts/mt7620a_buffalo_whr-300hp2.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_buffalo_whr-600d.dts  |  3 +--
 target/linux/ramips/dts/mt7620a_dlink_dch-m225.dts|  3 +--
 target/linux/ramips/dts/mt7620a_dlink_dir-510l.dts|  4 +---
 target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts|  3 +--
 target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts  |  3 +--
 target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts  |  3 +--
 target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts|  3 +--
 .../linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts  |  6 --
 target/linux/ramips/dts/mt7620a_edimax_ew-7478apc.dts |  3 +--
 target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts  |  4 ++--
 target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts  |  4 ++--
 target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts   |  4 ++--
 .../linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts |  3 +--
 target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi|  3 +--
 target/linux/ramips/dts/mt7620a_hnet_c108.dts |  3 +--
 .../linux/ramips/dts/mt7620a_iodata_wn-ac1167gr.dts   |  3 +--
 .../linux/ramips/dts/mt7620a_iodata_wn-ac733gr3.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_kimax_u25awf-h1.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_lava_lr-25g001.dts|  3 +--
 target/linux/ramips/dts/mt7620a_lenovo_newifi-y1.dtsi |  3 +--
 target/linux/ramips/dts/mt7620a_linksys_e1700.dts |  3 +--
 .../linux/ramips/dts/mt7620a_microduino_microwrt.dts  |  3 +--
 target/linux/ramips/dts/mt7620a_netgear_ex2700.dts|  3 +--
 target/linux/ramips/dts/mt7620a_netgear_ex3700.dts|  3 +--
 .../linux/ramips/dts/mt7620a_netgear_wn3000rp-v3.dts  |  3 +--
 target/linux/ramips/dts/mt7620a_ohyeah_oy-0001.dts|  3 +--
 target/linux/ramips/dts/mt7620a_phicomm_k2g.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_phicomm_psg1208.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_phicomm_psg1218.dtsi  |  3 +--
 target/linux/ramips/dts/mt7620a_phicomm_psg1218a.dts  |  1 +
 target/linux/ramips/dts/mt7620a_phicomm_psg1218b.dts  |  1 +
 target/linux/ramips/dts/mt7620a_planex_cs-qr10.dts|  3 +--
 target/linux/ramips/dts/mt7620a_planex_db-wrt01.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_planex_mzk-750dhp.dts |  3 +--
 .../linux/ramips/dts/mt7620a_planex_mzk-ex300np.dts   |  3 +--
 .../linux/ramips/dts/mt7620a_planex_mzk-ex750np.dts   |  3 +--
 .../linux/ramips/dts/mt7620a_ralink_mt7620a-evb.dts   |  1 -
 .../ramips/dts/mt7620a_ralink_mt7620a-mt7610e-evb.dts |  1 -
 .../ramips/dts/mt7620a_ralink_mt7620a-v22sg-evb.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_sanlinking_d240.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_sercomm_na930.dts |  3 +--
 .../linux/ramips/dts/mt7620a_tplink_archer-c20-v1.dts |  3 +--
 .../linux/ramips/dts/mt7620a_tplink_archer-c20i.dts   |  6 ++
 .../linux/ramips/dts/mt7620a_tplink_archer-c50-v1.dts |  6 +++---
 .../linux/ramips/dts/mt7620a_xiaomi_miwifi-mini.dts   |  3 +--
 target/linux/ramips/dts/mt7620a_youku_yk1.dts |  8 ++--
 target/linux/ramips/dts/mt7620a_yukai_bocco.dts   |  3 +--
 .../linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi   |  5 +++--
 .../linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts |  3 +--
 .../linux/ramips/dts/mt7620a_zbtlink_zbt-we826.dtsi   |  7 +--
 target/linux/ramips/dts/mt7620a_zte_q7.dts|  3 +--
 .../linux/ramips/dts/mt7620a_zyxel_keenetic-viva.dts  |  1 -
 target/linux/ramips/dts/mt7620n_asus_rt-n12p.dts  |  3 +--
 target/linux/ramips/dts/mt7620n_asus_rt-n14u.dts  |  3 +--
 target/linux/ramips/dts/mt7620n_buffalo_wmr-300.dts   |  3 +--
 target/linux/ramips/dts/mt7620n_comfast_cf-wr800n.dts |  3 +--
 target/linux/ramips/dts/mt7620n_dlink_dwr-116-a1.dts  |  3 +--
 target/linux/ramips/dts/mt7620n_dlink_dwr-921-c1.dts  |  3 +--
 target/linux/ramips/dts/mt7620n_dlink_dwr-922-e2.dts  |  3 +--
 target/linux/ramips/dts/mt7620n_elecom_wrh-300cr.dts  |  5 ++---
 target/linux/ramips/dts/mt7620n_kimax_u35wf.dts   |  3 +--
 target/linux/ramips/dts/mt7620n_kingston_mlw221.dts   |  3 +--
 target/linux/ramips/dts/mt7620n_kingston_mlwg2.dts|  3 +--
 target/linux/ramips/dts/mt7620n_nexx_wt3020.dtsi  |  3 +--
 target/linux/ramips/dts/mt7620n_ravpower_wd03.dts |  4 +---
 target/linux/ramips/dts/mt7620n_vonets_var11n-300.dts |  3 +--
 

[OpenWrt-Devel] [openwrt] Patch notification: 1 patch updated

[Patchwork]

Hello,

The following patch (submitted by you) has been updated in Patchwork:

 * openwrt: [OpenWrt-Devel] build: fix make kernel_menuconfig
 - http://patchwork.ozlabs.org/patch/1163120/
 - for: OpenWrt development
was: New
now: Under Review

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the Patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

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

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[Adrian Schmutzler]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of Petr Štetiar
> Sent: Freitag, 20. September 2019 09:56
> To: Kristian Evensen 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files
> 
> Kristian Evensen  [2019-06-23 11:24:47]:
> 
> Hi,
> 
> > This commit makes the following changes to the WE1026 DTS-files:
> 
> could you please rebase to series to the current state of the tree? I would
> like to apply it, thanks!
> 
> BTW don't forget to include the license change ACKs.
> 

Hi Kristian,

if you deal with these devices again anyway, can you check whether WE1026-H has 
the WAN MAC address at , so we do not have to calculate it?

Best

Adrian


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

Re: [OpenWrt-Devel] [PATCH 1/3] ramips/mt762x: convert devices to interrupt-driven gpio-keys

[Adrian Schmutzler]

Hi,

> -Original Message-
> From: Petr Štetiar [mailto:yn...@true.cz]
> Sent: Freitag, 20. September 2019 08:45
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 1/3] ramips/mt762x: convert devices to 
> interrupt-driven gpio-keys
> 
> Adrian Schmutzler  [2019-09-17 14:22:21]:
> 
> Hi,
> 
> > This converts all remaining devices to use interrupt-driven
> > gpio-keys compatible instead of gpio-keys-polled.
> > The poll-interval is removed.
> 
> [...]
> 
> >  161 files changed, 197 insertions(+), 314 deletions(-)
> 
> I'm just wondering what makes you so confident, that this changes wont break
> any of the affected devices. On which devices this has been tested? Some
> Tested-by: would help to get this merged, thanks.

Well, for quite some time already every device added to ath79 and ramips has 
been advised to use gpio-keys, and I personally do not remember a single case 
where issues with that have been reported (that were not also present with 
polled keys).

Also note that I only address mt762x devices here, and do not touch the rt 
subtargets.

But I would obviously also be happy about some Tested-by from the list (as with 
ath79, where I received those).

Best

Adrian


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

Re: [OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if missing

[Paul Spooren]

On 17.09.19 00:25, Jonas Gorski wrote:

On Sun, 15 Sep 2019 at 12:49, Paul Spooren  wrote:

What you suggest is about what we have right now. This kind of creates a misleading situation where 
for some targets subtargets are present, while for others paths and image names are 
"fixed" in several places to include a "generic". The reason for Paul's patch 
was to get rid of the fixes at individual places (which was/is applied somewhat inconsistently) by 
just making all targets apply to the same logic (i.e. that there is at least one subtarget).
So, the empty files are introduced to make the process of building and creating 
images afterwards simpler (to follow/understand).

I was suffering from the same problem when I dealt with OpenWrt-derived 
firmware, where I suddenly encountered a target without subtargets and had to 
implement extra code to work around that.

However, I also wondered whether one couldn't code around the necessity of the 
empty file, and just add the SUBTARGET/SUBTARGETS variables here...

Thanks for commenting, that's very much my point!

Maybe the easiest solution is to add `SUBTARGET ?= generic` to
include/image.mk instead of introducing empty files. Will try that tomorrow.

Thanks, this is what I meant, providing some sensible default value(s).

I have to admit, even after reading your changelog and Adrian's email
twice, I still don't quite grasp what issue this change is trying to
fix. An example might be nice in the changelog.


The idea is to have always the same naming pattern for images:



This allows you to be certain to find an image (or related files) at the 
excepted place, instead of guessing if the generic "subtarget" actually 
appears in the filename or not.


To illustrate: I'm trying to create an index with all created images. 
The index maps images and device titels to make it easier finding the 
right firmware. The more variation in the openwrt buildroot, the more I 
have to work around it.


I created an updated PR here[0] which also adds the new subtargets to uboot.

Regards
Paul

[0]: https://github.com/openwrt/openwrt/pull/2431


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

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[Petr Štetiar]

Kristian Evensen  [2019-09-20 10:13:31]:

> I will do it during or right over the weekend. Btw, can I consider
> this your ACK of the licensing change as well?

Acked-by: Petr Štetiar 

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

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[Kristian Evensen]

Hi Petr,

On Fri, Sep 20, 2019 at 9:56 AM Petr Štetiar  wrote:
> could you please rebase to series to the current state of the tree? I would
> like to apply it, thanks!
>
> BTW don't forget to include the license change ACKs.

I will do it during or right over the weekend. Btw, can I consider
this your ACK of the licensing change as well?

Kristian

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

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[Petr Štetiar]

Kristian Evensen  [2019-06-23 11:24:47]:

Hi,

> This commit makes the following changes to the WE1026 DTS-files:

could you please rebase to series to the current state of the tree? I would
like to apply it, thanks!

BTW don't forget to include the license change ACKs.

> Signed-off-by: Kristian Evensen 
> Acked-by: Alex Maclean 
> Acked-by: INAGAKI Hiroshi 

-- ynezz

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

[OpenWrt-Devel] [openwrt] Patch notification: 1 patch updated

[Patchwork]

Hello,

The following patch (submitted by you) has been updated in Patchwork:

 * openwrt: [OpenWrt-Devel] ramips: add support to JS7628 development board
 - http://patchwork.ozlabs.org/patch/1134527/
 - for: OpenWrt development
was: New
now: Superseded

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the Patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

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

Re: [OpenWrt-Devel] [PATCH 3/3] ramips: rearrange LEDs for ZBT-WE826 devices to prevent delete-node

[Petr Štetiar]

Adrian Schmutzler  [2019-09-17 14:22:23]:

Hi,

> So far, for the ZBT-WE826-E the leds pulled from the DTSI are deleted and
> then redefined. The config in the DTSI is then used in two other DTSes for
> the ZBT-WE826 flash variants.
>
> Since the block is effectively only used for two devices, this moves led
> definitions to the device DTSes to prevent the use of delete-node.  This
> seems more logical than created the config and then deleting it again.

maybe, but I would prefer to keep the current state as it avoids copy
of the exactly same leds node to the two places.

>  4 files changed, 42 insertions(+), 23 deletions(-)

You've just added 21 more lines one would need to maintain.

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH 1/3] ramips/mt762x: convert devices to interrupt-driven gpio-keys

[Petr Štetiar]

Adrian Schmutzler  [2019-09-17 14:22:21]:

Hi,

> This converts all remaining devices to use interrupt-driven
> gpio-keys compatible instead of gpio-keys-polled.
> The poll-interval is removed.

[...]

>  161 files changed, 197 insertions(+), 314 deletions(-)

I'm just wondering what makes you so confident, that this changes wont break
any of the affected devices. On which devices this has been tested? Some
Tested-by: would help to get this merged, thanks.

-- ynezz

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