Re: [OpenWrt-Devel] cns3xxx + gcc8 = compile error
> /home/kvdp/firmware/builds/generic_cns3xxx/tmp/ccuGhaLZ.s: Assembler > messages: > /home/kvdp/firmware/builds/generic_cns3xxx/tmp/ccuGhaLZ.s:401: Error: > selected processor does not support `sev' in ARM mode Similar to https://github.com/openwrt/openwrt/pull/1203 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: modules: fix kmod-regmap
On 30/07/18 22:33, Christian Lamparter wrote: This patch fixes the a compile issue that was triggered by apm821xx/sata when kmod-regmap was selected. The CONFIG_REGMAP is declared in drivers/base/regmap/Kconfig as type "bool" and not "tristate". Hence the symbol should never be set to module, as this confuses the #if CONFIG_REGMAP guards in include/linux/regmap.h: |.../drivers/regulator/core.c:4041: undefined reference to `dev_get_regmap' |.../drivers/regulator/core.c:4042: undefined reference to `dev_get_regmap' |.../drivers/regulator/core.c:4044: undefined reference to `dev_get_regmap' |.../drivers/regulator/helpers.o: In function `regulator_is_enabled_regmap': |.../drivers/regulator/helpers.c:36: undefined reference to `regmap_read' |... i started a test build 2 minutes ago to figure this one out :-) thanks ! Signed-off-by: Christian Lamparter --- package/kernel/linux/modules/other.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index 7e18a21db3..dd037cf86c 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -718,7 +718,7 @@ define KernelPackage/regmap SUBMENU:=$(OTHER_MENU) TITLE:=Generic register map support DEPENDS:=+kmod-lib-lzo +kmod-i2c-core - KCONFIG:=CONFIG_REGMAP \ + KCONFIG:=CONFIG_REGMAP=y \ CONFIG_REGMAP_MMIO \ CONFIG_REGMAP_SPI \ CONFIG_REGMAP_I2C \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: modules: fix kmod-regmap
This patch fixes the a compile issue that was triggered by apm821xx/sata when kmod-regmap was selected. The CONFIG_REGMAP is declared in drivers/base/regmap/Kconfig as type "bool" and not "tristate". Hence the symbol should never be set to module, as this confuses the #if CONFIG_REGMAP guards in include/linux/regmap.h: |.../drivers/regulator/core.c:4041: undefined reference to `dev_get_regmap' |.../drivers/regulator/core.c:4042: undefined reference to `dev_get_regmap' |.../drivers/regulator/core.c:4044: undefined reference to `dev_get_regmap' |.../drivers/regulator/helpers.o: In function `regulator_is_enabled_regmap': |.../drivers/regulator/helpers.c:36: undefined reference to `regmap_read' |... Signed-off-by: Christian Lamparter --- package/kernel/linux/modules/other.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index 7e18a21db3..dd037cf86c 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -718,7 +718,7 @@ define KernelPackage/regmap SUBMENU:=$(OTHER_MENU) TITLE:=Generic register map support DEPENDS:=+kmod-lib-lzo +kmod-i2c-core - KCONFIG:=CONFIG_REGMAP \ + KCONFIG:=CONFIG_REGMAP=y \ CONFIG_REGMAP_MMIO \ CONFIG_REGMAP_SPI \ CONFIG_REGMAP_I2C \ -- 2.18.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] kernel: bump 4.9 to 4.9.116 for 18.06
* Refreshed patches. * Removed patches: - target/linux/ar71xx/patches-4.9/103-MIPS-ath79-fix-register-address-in-ath79_ddr_wb_flus.patch superseded by upstream - target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch superseded by upstream - target/linux/brcm63xx/patches-4.9/001-4.11-01-mtd-m25p80-consider-max-message-size-in-m25p80_read.patch accepted upstream - target/linux/brcm63xx/patches-4.9/001-4.15-08-bcm63xx_enet-correct-clock-usage.patch accepted upstream - target/linux/brcm63xx/patches-4.9/001-4.15-09-bcm63xx_enet-do-not-write-to-random-DMA-channel-on-B.patch accepted upstream Compile-tested on: ar71xx Run-tested on: ar71xx Signed-off-by: Stijn Segers --- include/kernel-version.mk | 4 +- ...fix-register-address-in-ath79_ddr_wb_flus.patch | 23 -- .../403-mtd_fix_cfi_cmdset_0002_status_check.patch | 69 - ...low-to-pass-probe-types-via-platform-data.patch | 4 +- .../411-mtd-cfi_cmdset_0002-force-word-write.patch | 8 +- .../patches-4.9/910-unaligned_access_hacks.patch | 10 +- ...gnore-dtco-targets-when-filtering-symbols.patch | 2 +- .../patches-4.9/950-0031-Add-dwc_otg-driver.patch | 2 +- ...-consider-max-message-size-in-m25p80_read.patch | 30 -- ...-4.15-08-bcm63xx_enet-correct-clock-usage.patch | 101 -- ...t-do-not-write-to-random-DMA-channel-on-B.patch | 29 -- .../024-1-tcp-tsq-add-tsq_flags-tsq_enum.patch | 6 +- ...-remove-one-locked-operation-in-tcp_wfree.patch | 4 +- ...-tcp-tsq-add-shortcut-in-tcp_tasklet_func.patch | 6 +- ...4-4-tcp-tsq-avoid-one-atomic-in-tcp_wfree.patch | 4 +- ...q-add-a-shortcut-in-tcp_small_queue_check.patch | 2 +- ...tcp-tcp_mtu_probe-is-likely-to-exit-early.patch | 2 +- ...tsq-move-tsq_flags-close-to-sk_wmem_alloc.patch | 14 +- ...add-a-missing-barrier-in-tcp_tasklet_func.patch | 2 +- .../025-tcp-allow-drivers-to-tweak-TSQ-logic.patch | 4 +- ...ort-for-releasing-multiple-instances-of-a.patch | 2 +- ..._alloc_page_frag-to-page_frag_alloc-and-_.patch | 4 +- ..._page_frag-functions-to-__page_frag_cache.patch | 6 +- .../090-net-generalize-napi_complete_done.patch| 8 +- .../generic/hack-4.9/207-disable-modorder.patch| 4 +- .../hack-4.9/211-host_tools_portability.patch | 2 +- .../linux/generic/hack-4.9/220-gc_sections.patch | 4 +- ...c_node_mem_map-with-ARCH_PFN_OFFSET-calcu.patch | 2 +- .../pending-4.9/201-extra_optimization.patch | 2 +- ...610-netfilter_match_bypass_default_checks.patch | 6 +- .../pending-4.9/630-packet_socket_type.patch | 6 +- .../generic/pending-4.9/834-ledtrig-libata.patch | 10 +- .../900-gen_stats-fix-netlink-stats-padding.patch | 49 --- .../patches-4.9/600-skb_avoid_dmabounce.patch | 2 +- ...MTD-m25p80-allow-loading-mtd-name-from-OF.patch | 4 +- .../202-core-linux-support-layerscape.patch| 6 +- .../patches-4.9/703-phy-support-layerscape.patch | 2 +- .../patches-4.9/817-usb-support-layerscape.patch | 10 +- .../sunxi/patches-4.9/0052-stmmac-form-4-12.patch | 344 ++--- 39 files changed, 238 insertions(+), 561 deletions(-) delete mode 100644 target/linux/ar71xx/patches-4.9/103-MIPS-ath79-fix-register-address-in-ath79_ddr_wb_flus.patch delete mode 100644 target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch delete mode 100644 target/linux/brcm63xx/patches-4.9/001-4.11-01-mtd-m25p80-consider-max-message-size-in-m25p80_read.patch delete mode 100644 target/linux/brcm63xx/patches-4.9/001-4.15-08-bcm63xx_enet-correct-clock-usage.patch delete mode 100644 target/linux/brcm63xx/patches-4.9/001-4.15-09-bcm63xx_enet-do-not-write-to-random-DMA-channel-on-B.patch delete mode 100644 target/linux/generic/pending-4.9/900-gen_stats-fix-netlink-stats-padding.patch diff --git a/include/kernel-version.mk b/include/kernel-version.mk index f0d8160e34..2e77f812df 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -4,12 +4,12 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .71 LINUX_VERSION-4.4 = .121 -LINUX_VERSION-4.9 = .111 +LINUX_VERSION-4.9 = .116 LINUX_VERSION-4.14 = .54 LINUX_KERNEL_HASH-3.18.71 = 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 LINUX_KERNEL_HASH-4.4.121 = 44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729 -LINUX_KERNEL_HASH-4.9.111 = 5966558959dc580f163766f3fdefd7e57c01b2b45d51202d00b3807c253759dd +LINUX_KERNEL_HASH-4.9.116 = 999e8291bec0bcef2e0b91b6d58d8be5eb5e7c70881df59439364b22b693ff1d LINUX_KERNEL_HASH-4.14.54 = 451642ac28c539a91072f1fb83b1c061d6d44df870ddf5562400ade5e1c4b6c6 remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1 diff --git a/target/linux/ar71xx/patches-4.9/103-MIPS-ath79-fix-register-address-in-ath79_ddr_wb_flus.patch b/target/linux/ar71xx/patches-4.9/103-MIPS-ath79-fix-register-address-in-ath79_ddr_wb_flus.patch deleted file mode 100644 index
[OpenWrt-Devel] [PATCH 2/2] kernel: bump 4.14 to 4.14.59 for 18.06
* Refreshed patches. * Patches made redundant by changes upstream: - target/linux/ramips/patches-4.14/0036-mtd-fix-cfi-cmdset-0002-erase-status-check.patch * Patches accepted upstream: - target/linux/apm821xx/patches-4.14/020-0001-crypto-crypto4xx-remove-bad-list_del.patch - target/linux/apm821xx/patches-4.14/020-0011-crypto-crypto4xx-fix-crypto4xx_build_pdr-crypto4xx_b.patch - target/linux/brcm63xx/patches-4.14/001-4.15-08-bcm63xx_enet-correct-clock-usage.patch - target/linux/brcm63xx/patches-4.14/001-4.15-09-bcm63xx_enet-do-not-write-to-random-DMA-channel-on-B.patch - target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch - target/linux/generic/pending-4.14/900-gen_stats-fix-netlink-stats-padding.patch Compile-tested on: ramips/mt7621, x86/64 Run-tested on: ramips/mt7621, x86/64 Signed-off-by: Stijn Segers --- include/kernel-version.mk | 4 +- ...0001-crypto-crypto4xx-remove-bad-list_del.patch | 32 ...to4xx-remove-unused-definitions-and-write.patch | 2 +- ...to4xx-set-CRYPTO_ALG_KERN_DRIVER_ONLY-fla.patch | 2 +- ...to4xx-remove-double-assignment-of-pd_uinf.patch | 2 +- ...to4xx-enable-AES-RFC3686-ECB-CFB-and-OFB-.patch | 2 +- ...pto4xx-refactor-crypto4xx_copy_pkt_to_dst.patch | 2 +- ...to4xx-replace-crypto4xx_dev-s-scatter_buf.patch | 8 +- ...to4xx-fix-crypto4xx_build_pdr-crypto4xx_b.patch | 84 -- .../802-usb-xhci-force-msi-renesas-xhci.patch | 2 +- ...-add-support-for-performing-fake-doorbell.patch | 2 +- .../patches-4.14/830-huawei_e970_support.patch | 4 +- ...-4.15-08-bcm63xx_enet-correct-clock-usage.patch | 101 ...t-do-not-write-to-random-DMA-channel-on-B.patch | 29 .../025-tcp-allow-drivers-to-tweak-TSQ-logic.patch | 4 +- ...-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch | 172 - ...15-netfilter-exit_net-cleanup-check-added.patch | 2 +- .../generic/hack-4.14/207-disable-modorder.patch | 4 +- .../hack-4.14/211-host_tools_portability.patch | 2 +- .../linux/generic/hack-4.14/220-gc_sections.patch | 2 +- .../linux/generic/hack-4.14/902-debloat_proc.patch | 2 +- ...rocess-negative-stack-offsets-on-stack-tr.patch | 2 +- .../pending-4.14/201-extra_optimization.patch | 2 +- ...610-netfilter_match_bypass_default_checks.patch | 6 +- .../pending-4.14/630-packet_socket_type.patch | 6 +- .../generic/pending-4.14/834-ledtrig-libata.patch | 10 +- .../900-gen_stats-fix-netlink-stats-padding.patch | 49 -- .../patches-4.14/0052-net-phy-add-FC.patch | 2 +- ...ci-allow-imod-interval-to-be-configurable.patch | 2 +- .../oxnas/patches-4.14/999-libata-hacks.patch | 8 +- .../0032-USB-dwc2-add-device_reset.patch | 2 +- ...td-fix-cfi-cmdset-0002-erase-status-check.patch | 29 ...0037-mtd-cfi-cmdset-0002-force-word-write.patch | 2 +- 33 files changed, 44 insertions(+), 540 deletions(-) delete mode 100644 target/linux/apm821xx/patches-4.14/020-0001-crypto-crypto4xx-remove-bad-list_del.patch delete mode 100644 target/linux/apm821xx/patches-4.14/020-0011-crypto-crypto4xx-fix-crypto4xx_build_pdr-crypto4xx_b.patch delete mode 100644 target/linux/brcm63xx/patches-4.14/001-4.15-08-bcm63xx_enet-correct-clock-usage.patch delete mode 100644 target/linux/brcm63xx/patches-4.14/001-4.15-09-bcm63xx_enet-do-not-write-to-random-DMA-channel-on-B.patch delete mode 100644 target/linux/generic/backport-4.14/080-net-convert-sock.sk_wmem_alloc-from-atomic_t-to-refc.patch delete mode 100644 target/linux/generic/pending-4.14/900-gen_stats-fix-netlink-stats-padding.patch delete mode 100644 target/linux/ramips/patches-4.14/0036-mtd-fix-cfi-cmdset-0002-erase-status-check.patch diff --git a/include/kernel-version.mk b/include/kernel-version.mk index 2e77f812df..631b9785e9 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -5,12 +5,12 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .71 LINUX_VERSION-4.4 = .121 LINUX_VERSION-4.9 = .116 -LINUX_VERSION-4.14 = .54 +LINUX_VERSION-4.14 = .59 LINUX_KERNEL_HASH-3.18.71 = 5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240 LINUX_KERNEL_HASH-4.4.121 = 44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729 LINUX_KERNEL_HASH-4.9.116 = 999e8291bec0bcef2e0b91b6d58d8be5eb5e7c70881df59439364b22b693ff1d -LINUX_KERNEL_HASH-4.14.54 = 451642ac28c539a91072f1fb83b1c061d6d44df870ddf5562400ade5e1c4b6c6 +LINUX_KERNEL_HASH-4.14.59 = 7ec633c661bba941239e340bb35391d356eda541fb4c323d07034d09d05b319b remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1 sanitize_uri=$(call qstrip,$(subst @,_,$(subst :,_,$(subst .,_,$(subst -,_,$(subst /,_,$(1))) diff --git a/target/linux/apm821xx/patches-4.14/020-0001-crypto-crypto4xx-remove-bad-list_del.patch b/target/linux/apm821xx/patches-4.14/020-0001-crypto-crypto4xx-remove-bad-list_del.patch deleted file mode
Re: [OpenWrt-Devel] [PATCH] kernel/generic: (try) fixing MAP-E patch misbehaving in 4.0
Hi Axel,
Can you make a pull-request towards gh.com/openwrt/openwrt (master)?
We can then backport this to 18.06, so it's a bit urgent.
Cheers
Daniel
On Thu, May 24, 2018 at 08:17:23PM +0200, Axel Neumann wrote:
> I meanwhile created another patch in a openwrt fork at github here
> https://github.com/axn/openwrt/commit/8ea3fc4f808fe5e9aef50d082bd19095a3113750
> that should be more clean (
> there is a branch for for-master and for openwrt-18.06 branch).
> But we want to do a few more tests before opening a pull request. Comments
> are welcome anyway. /axel
>
> Am 23. Mai 2018 20:18:46 MESZ schrieb Daniel Golle :
> >Hi Axel,
> >Hi Steven,
> >
> >revisiting your patch, I try to understand what we need to fix here
> >or if the issue has already been resolved in the meantime.
> >See below:
> >
> >On Fri, Feb 09, 2018 at 01:20:53PM +0100, Axel Neumann wrote:
> >> Hello,
> >>
> >> the 666 kernel patches [1,2,3] break the possibility for using an
> >ip4ip6
> >> tunnel interface as a fall back interface accepting ip4-in-ip6
> >tunneled
> >> packets from any remote address. This works out of the box with any
> >> normal (non-666-patched) 4.4 (and earlier) kernel and can be
> >configured
> >> by setting up an 'ip -6 tunnel' with type 'any' or 'ip4ip6' and a
> >remote
> >> address of '::'.
> >>
> >> The misbehavior comes with line 290 of [3] which discards all packets
> >> that do not show the expected saddr, even if no single fmr rule was
> >> defined and despite the validity of the saddr was already approved
> >earlier.
> >>
> >> Attached diff would re-enable this fall back capability without
> >> affecting the behavior in case of any configured FMR rules.
> >>
> >> It would be nice if the proposed or a similar fix could be applied
> >asap
> >> because currently I see no way of recovering the standard kernel
> >> behavior which breaks certain desired bmx6 and bmx7 tunneling
> >features.
> >>
> >> Best regards
> >> /axel
> >>
> >>
> >> [1]
> >>
> >https://github.com/openwrt-mirror/openwrt/blob/master/target/linux/generic/patches-3.18/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch
> >> [2]
> >>
> >https://github.com/openwrt-mirror/openwrt/blob/master/target/linux/generic/patches-4.1/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch
> >> [3]
> >>
> >https://github.com/openwrt-mirror/openwrt/blob/master/target/linux/generic/patches-4.4/666-Add-support-for-MAP-E-FMRs-mesh-mode.patch#L290
> >>
> >
> >The patch below is supposedly applied to net/ipv6/ip6_tunnel.c after
> >666-Add-support-for-MAP-E-FMRs-mesh-mode.patch has been applied, right?
> >
> >> 1032c1032
> >> < if (fmr) {
> >> ---
> >> > if (fmr)
> >> 1036,1039c1036,1038
> >> < if (!ipv6_addr_equal(>saddr,
> >> )) {
> >> < rcu_read_unlock();
> >> < goto discard;
> >> < }
> >> ---
> >> > if (!ipv6_addr_equal(>saddr, ))
> >> > {
> >> > rcu_read_unlock();
> >> > goto discard;
> >
> >The original hunk in 666-Add-support-for-MAP-E-FMRs-mesh-mode.patch
> >looks like this
> >
> >---
> >@@ -832,6 +950,27 @@ static int __ip6_tnl_rcv(struct ip6_tnl
> > skb_reset_network_header(skb);
> > memset(skb->cb, 0, sizeof(struct inet6_skb_parm));
> >
> >+if (tpi->proto == htons(ETH_P_IP) &&
> >+!ipv6_addr_equal(>saddr, >parms.raddr)) {
> >+/* Packet didn't come from BR, so lookup FMR */
> >+struct __ip6_tnl_fmr *fmr;
> >+struct in6_addr expected = tunnel->parms.raddr;
> >+for (fmr = tunnel->parms.fmrs; fmr; fmr = fmr->next)
> >+if (ipv6_prefix_equal(>saddr,
> >+>ip6_prefix, fmr->ip6_prefix_len))
> >+break;
> >+
> >+/* Check that IPv6 matches IPv4 source to prevent
> >spoofing */
> >+if (fmr)
> >+ip4ip6_fmr_calc(, ip_hdr(skb),
> >+skb_tail_pointer(skb), fmr,
> >false);
> >+
> >+if (!ipv6_addr_equal(>saddr, )) {
> >+rcu_read_unlock();
> >+goto drop;
> >+}
> >+}
> >+
> > __skb_tunnel_rx(skb, tunnel->dev, tunnel->net);
> >
> > err = dscp_ecn_decapsulate(tunnel, ipv6h, skb);
> >---
> >
> >Reading this it is obvious that yout patch can be reverse-applied to
> >ip6_tunnel.c after 666-Add-support-for-MAP-E-FMRs-mesh-mode.patch has
> >been applied. As the MAP-E patch apparently hasn't been touched for
> >quite a while I assume that it must have looked the same at the time
> >when you sent the patch and you just used diff in a slightly
> >counter-intuitive way...
> >
[OpenWrt-Devel] [PATCH] ustream-ssl: mbedtls: use chacha-poly ciphersuites
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
These ciphersuites were added in mbedtls v2.12.0, our current version.
Signed-off-by: Eneas U de Queiroz
diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
index 347c600..b7d7629 100644
--- a/ustream-mbedtls.c
+++ b/ustream-mbedtls.c
@@ -94,7 +94,9 @@ static int _urandom(void *ctx, unsigned char *out, size_t len)
static const int default_ciphersuites_server[] =
{
+ MBEDTLS_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
AES_CIPHERS(ECDHE_ECDSA),
+ MBEDTLS_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
AES_CIPHERS(ECDHE_RSA),
AES_CIPHERS(RSA),
0
@@ -102,8 +104,11 @@ static const int default_ciphersuites_server[] =
static const int default_ciphersuites_client[] =
{
+ MBEDTLS_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
AES_CIPHERS(ECDHE_ECDSA),
+ MBEDTLS_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
AES_CIPHERS(ECDHE_RSA),
+ MBEDTLS_TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
AES_CIPHERS(DHE_RSA),
MBEDTLS_TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
AES_CIPHERS(RSA),
--
2.16.4
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/4] ramips: fix RBM33G partitioning
On 2018-07-30 04:09 AM, Thibaut wrote: > > >> Le 30 juil. 2018 à 08:40, John Crispin a écrit : >> >> >> >> On 29/07/18 11:07, Thibaut VARÈNE wrote: >>> This patch improves 5684d087418d176cfdef4e045e1950ca7ba3b09f by correcting >>> the partition scheme for the "RouterBoot" section of the flash. >>> >>> This section is subdivided in several segments, as they are on ar71xx >>> RB devices, albeit with different offsets and sizes. The naming convention >>> from ar71xx has been preserved. The preferred 'fixed-partitions' DTS >>> node syntax is used, with nesting support as introduced in 2a598bbaa3. >>> >>> The OEM source code also define a "RouterBootFake" partition at the >>> beginning of the secondary flash chip: to avoid trouble if OEM ever makes >>> use of that space, it is also defined here. >> >> as discussed on IRC we concluded, that this should be done with a mtd >> splitter. >> John > > I’m sorry, we didn’t conclude anything, I believe you demanded it be done so. > > Unfortunately, after a more careful investigation, I am now convinced this is > not the right course of action. Here’s why, in my very humble opinion and > limited understanding: > > - this splitter will be quite intrusive in generic code (currently « mtdsplit > » only works with « firmware » and « rootfs » named partitions) > - the bootloaders (routerboot and routerboot2) cannot be programmatically > splitted: they are raw machine code without a signature > - all ramips routerboard machines share the exact same partition scheme which > is different from all the ar71xx routerboard machines (which also all share > the same scheme) > - if I read the OEM source code correctly, it’s likely their ARM-based boards > have yet another partition scheme > > Consequently, a purported splitter will be invasive and full of hardcoded > numbers, making its upstream acceptance very unlikely (I anticipate the > argument « this should all be done in DTS, especially now that DTS supports > nested partitions »). > > Now, I would like to hope that a correct partition scheme that uses all the > OpenWRT-accepted features and follows guidelines would be more likely to be > accepted in the source than the currently broken, incorrect and incomplete > existing one. > I'm not sure but I think https://github.com/openwrt/openwrt/commit/2a598bbaa3f75b7051c2453a6ccf706191cf2153 (kernel: backport mtd support for subpartitions in DT) might be of use here... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [18.06] ar71xx: define switch for rb-952ui-5ac2nd
On 30/07/18 17:37, Thibaut VARÈNE wrote: QCA9533 built-in switch can be configured is this a backport ? if so, please reference the master commit hash. John Tested-by: Thibaut VARÈNE Signed-off-by: Thibaut VARÈNE --- target/linux/ar71xx/base-files/etc/board.d/02_network | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network b/target/linux/ar71xx/base-files/etc/board.d/02_network index b0076366bc..f650b4cd04 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/02_network +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network @@ -169,7 +169,6 @@ ar71xx_setup_interfaces() pb42|\ pb44|\ rb-951ui-2hnd|\ - rb-952ui-5ac2nd|\ routerstation|\ tl-wr710n|\ tl-wr720n-v3|\ @@ -182,7 +181,8 @@ ar71xx_setup_interfaces() rb-750-r2|\ rb-750p-pbr2|\ rb-750up-r2|\ - rb-951ui-2nd) + rb-951ui-2nd|\ + rb-952ui-5ac2nd) ucidef_set_interfaces_lan_wan "eth1.1" "eth0" ucidef_add_switch "switch0" \ "0@eth1" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [18.06] ar71xx: define switch for rb-952ui-5ac2nd
QCA9533 built-in switch can be configured Tested-by: Thibaut VARÈNE Signed-off-by: Thibaut VARÈNE --- target/linux/ar71xx/base-files/etc/board.d/02_network | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network b/target/linux/ar71xx/base-files/etc/board.d/02_network index b0076366bc..f650b4cd04 100755 --- a/target/linux/ar71xx/base-files/etc/board.d/02_network +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network @@ -169,7 +169,6 @@ ar71xx_setup_interfaces() pb42|\ pb44|\ rb-951ui-2hnd|\ - rb-952ui-5ac2nd|\ routerstation|\ tl-wr710n|\ tl-wr720n-v3|\ @@ -182,7 +181,8 @@ ar71xx_setup_interfaces() rb-750-r2|\ rb-750p-pbr2|\ rb-750up-r2|\ - rb-951ui-2nd) + rb-951ui-2nd|\ + rb-952ui-5ac2nd) ucidef_set_interfaces_lan_wan "eth1.1" "eth0" ucidef_add_switch "switch0" \ "0@eth1" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" -- 2.13.6 (Apple Git-96) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multi build failures using today's master
On 2018-07-30 15:05, Jo-Philipp Wich wrote:
Hi Koen,
In function 'ath10k_dfs_radar_report':
/mnt/ramdisk/koen/firmware/builds/generic_glmifi/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/ath10k-ct-2018-05-30-127f9818/ath10k-4.13/wmi.c:3993:7:
error: too few arguments to function 'ar->dfs_detector->add_pulse'
if (!ar->dfs_detector->add_pulse(ar->dfs_detector, )) {
^~
3083962dd4 ("ath10k-ct: fix build with current mac80211 package")
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3083962dd409360059199753bb465427c667daf5
I can confirm it's fixed.
Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multi build failures using today's master
On 2018-07-30 14:55, Rafał Miłecki wrote:
On Mon, 30 Jul 2018 at 11:46, Koen Vandeputte
wrote:
I started building today's master this morning for 7 different targets,
and most of them failed. (some 4.9 and some 4.14 kernels)
On ar71xx (Rocket M5) :(Added Rafał in CC as I noticed he worked on
this)
a3d2448fae54 ("kernel: add missing include to redboot.c")
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a3d2448fae5499356a31d71585a812ac65e7a39a
I can confirm it's fixed.
Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] wolfssl: remove myself as maintainer
I no longer have the time, nor the desire to maintain this package. Remove myself as maintainer. Signed-off-by: Alexandru Ardelean --- package/libs/wolfssl/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index e08b6f3929..87ce9328e7 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -40,7 +40,6 @@ define Package/libwolfssl CATEGORY:=Libraries TITLE:=wolfSSL library URL:=http://www.wolfssl.com/ - MAINTAINER:=Alexandru Ardelean MENU:=1 PROVIDES:=libcyassl endef -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: add kmod-iio-htu21
This adds support for the htu21 humidity and temperature sensor. To get it to work you have to do something like this: echo "htu21 0x40" >/sys/class/i2c-dev/i2c-1/device/new_device for example by adding it to rc.local Compile tested on brcm2708 and I have used an earlier version of this patch for more than a year. Signed-off-by: Torbjörn Jansson --- package/kernel/linux/modules/iio.mk | 22 ++ 1 file changed, 22 insertions(+) diff --git a/package/kernel/linux/modules/iio.mk b/package/kernel/linux/modules/iio.mk index c35ccca1bb..a1410170db 100644 --- a/package/kernel/linux/modules/iio.mk +++ b/package/kernel/linux/modules/iio.mk @@ -133,3 +133,25 @@ define KernelPackage/iio-bmp280-spi/description endef $(eval $(call KernelPackage,iio-bmp280-spi)) + +define KernelPackage/iio-htu21 + SUBMENU:=$(IIO_MENU) + DEPENDS:=+kmod-i2c-core +kmod-iio-core + TITLE:=HTU21 humidity & temperature sensor + KCONFIG:= \ + CONFIG_HTU21 \ + CONFIG_IIO_MS_SENSORS_I2C + FILES:= \ + $(LINUX_DIR)/drivers/iio/humidity/htu21.ko \ + $(LINUX_DIR)/drivers/iio/common/ms_sensors/ms_sensors_i2c.ko + AUTOLOAD:=$(call AutoLoad,56,htu21) +endef + +define KernelPackage/iio-htu21/description + support for the Measurement Specialties HTU21 humidity and + temperature sensor. + This driver is also used for MS8607 temperature, pressure & humidity + sensor +endef + +$(eval $(call KernelPackage,iio-htu21)) -- 2.14.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multi build failures using today's master
Hi Koen,
> In function 'ath10k_dfs_radar_report':
> /mnt/ramdisk/koen/firmware/builds/generic_glmifi/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/ath10k-ct-2018-05-30-127f9818/ath10k-4.13/wmi.c:3993:7:
> error: too few arguments to function 'ar->dfs_detector->add_pulse'
> if (!ar->dfs_detector->add_pulse(ar->dfs_detector, )) {
> ^~
3083962dd4 ("ath10k-ct: fix build with current mac80211 package")
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3083962dd409360059199753bb465427c667daf5
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multi build failures using today's master
On Mon, 30 Jul 2018 at 11:46, Koen Vandeputte
wrote:
> I started building today's master this morning for 7 different targets,
> and most of them failed. (some 4.9 and some 4.14 kernels)
>
>
> On ar71xx (Rocket M5) :(Added Rafał in CC as I noticed he worked on
> this)
a3d2448fae54 ("kernel: add missing include to redboot.c")
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a3d2448fae5499356a31d71585a812ac65e7a39a
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] libevent2: Don't build tests and samples
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- This reduces build time significantly. Signed-off-by: Eneas U de Queiroz diff --git a/package/libs/libevent2/patches/0002-Makefile.am-omit-building-sample-and-test.patch b/package/libs/libevent2/patches/0002-Makefile.am-omit-building-sample-and-test.patch new file mode 100644 index 00..506137d555 --- /dev/null +++ b/package/libs/libevent2/patches/0002-Makefile.am-omit-building-sample-and-test.patch @@ -0,0 +1,13 @@ +--- a/Makefile.am b/Makefile.am +@@ -143,8 +143,8 @@ CLEANFILES= + DISTCLEANFILES= + BUILT_SOURCES = + include include/include.am +-include sample/include.am +-include test/include.am ++#include sample/include.am ++#include test/include.am + + if BUILD_WIN32 + -- 2.16.4 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/1] libevent2: Don't build tests and samples
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- This reduces build time significantly (times are for brcm47xx): time: package/libs/libevent2/compile#38.00#2.68#47.53 time: package/libs/libevent2/compile#21.46#1.76#28.24 I left PKG_REVISION unchanged since this does not alter any package files. Eneas U de Queiroz (1): libevent2: Don't build tests and samples .../0002-Makefile.am-omit-building-sample-and-test.patch| 13 + 1 file changed, 13 insertions(+) create mode 100644 package/libs/libevent2/patches/0002-Makefile.am-omit-building-sample-and-test.patch -- 2.16.4 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Second RGMII ethernet on MT7621?
Torbjorn Jansson writes: > On 2018-05-01 12:17, Bjørn Mork wrote: >> John Crispin writes: >> >>> making gmac2 work s not trivial with the current driver. >> >> Thanks for confirming. Then I guess I can just wrap up what I have and >> make it public. Just want to figure out how the LEDs are connected >> first. Bootloader initiated blinking patterns are persistent, so I'm >> guessing some I2C(?) connected controller. Or something.. >> >>> however making the upstream mtk_eth_soc driver work on mt7621 is >>> pretty easy i think and will give you dual gmac support. upstream only >>> supports mt7623 arm atm. its been on my todo list for a while but i >>> simply have not been able to find the 2-3 days required to make it >>> work. >> >> I wish I could help. But I have enough self-insight to realize that it >> is way beyond my capabilities, after a quick look at the driver. >> >> >> Bjørn > > sorry for reviving old mail thread but just out of curiosity, will > this help the ubiquiti edgerouter x sfp with getting the sfp port > working too? > it is also an mt7621. I would guess yes. But I might be wrong. I am not sure I understand the high level block diagrams I've seen correctly. My understanding is that the MT7621 has 2 CPU GMACs, a 7 port switch, 5 PHYs and 1 set of RGMII pads. The first GMAC is always connected to the switch. The second GMAC can be connected either to the switch or to the RGMII pads. If this is correct then I would assume that a design with an SFP cage would use some external PHY with SERDES, connected to the second GMAC using the RGMII pads. But it would be good to have someone with a clue confirm or refute this... The WiFi extender I am having trouble with (ZyXEL WAP6805 - similar to the WAP6806) has an RGMII connected Quantenna 5Ghz module. My assumption is that this module is connected to the RGMII pads on the MT7621 and that I need support for the second GMAC to get it running. The Quantenna module loads its firmware using TFTP in the OEM firmware. I note that forum user Thirsty has had some success using the mainline MT7623 driver to enable both GMACs: https://forum.lede-project.org/t/er-x-sfp-sfp-eth5-port-has-link-state-led-lit-but-swconfig-says-link-port-5-link-down/4608/70 but this currently implies DSA, so it's not exactly plug-and-play with OpenWrt. I haven't tried it myself yet. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Disclaimer for user documentation?
There are few documentation specific licenses with disclaimers, you might consider those: 1. CC license Documentation/books/images are often published under some variant of Creative Commons license. For example Wikipedia uses CreativeCommons Attribution - ShareAlike variant https://creativecommons.org/licenses/by/4.0/legalcode The disclaimer there reads (probably needs to be adjusted for a OpenWRT wiki to clarify terms used): Section 5 – Disclaimer of Warranties and Limitation of Liability. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 2. FreeBSD documentation license The FreeBSD documentation license - simpler to digest, do not about quality from lawyer point of view: https://www.freebsd.org/copyright/freebsd-doc-license.html THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Maksym ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Disclaimer for user documentation?
Hi, maybe it would make sense to copy one of the standard boilerplate liability remarks from one of the OSS licenses and put that as generic statement into the wiki footer. Example from Apache 2.0: "Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied." or MIT (sorry for the all-caps, I lazily copy-pasted): "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE." or GPL 3: "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES." My personal approach would be picking one of these, swapping "software" with "documentation" and put that in fine print into the wiki footer, somewhere next to the license remark. Having this is yellow warning banner on top of every documentation article seems like overkill to me and would like detract users from the actual content of the documentation. My 2cents, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multi build failures using today's master
On 2018-07-30 11:46, Koen Vandeputte wrote:
Hi All,
I started building today's master this morning for 7 different
targets, and most of them failed. (some 4.9 and some 4.14 kernels)
On ar71xx (Rocket M5) : (Added Rafał in CC as I noticed he worked
on this)
touch
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111/.configured
rm -f
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/root-ar71xx/init
make -C
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111
HOSTCFLAGS="-O2
-I/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/host/include
-Wall -Wmissing-prototypes -Wstrict-prototypes"
CROSS_COMPILE="mips-openwrt-linux-musl-" ARCH="mips"
KBUILD_HAVE_NLS=no KBUILD_BUILD_USER="" KBUILD_BUILD_HOST=""
KBUILD_BUILD_TIMESTAMP="Mon Jul 30 06:39:52 2018"
KBUILD_BUILD_VERSION="0"
HOST_LOADLIBES="-L/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/host/lib"
CONFIG_SHELL="bash" V='' cmd_syscalls= KERNELRELEASE=4.9.111
CC="ccache_cc" all modules
make[5]: Entering directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111'
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
LD drivers/mtd/mtd.o
CC drivers/mtd/redboot.o
drivers/mtd/redboot.c:306:34: error: array type has incomplete element
type 'struct of_device_id'
static const struct of_device_id redboot_parser_of_match_table[] = {
^
drivers/mtd/redboot.c:307:4: error: field name not in record or union
initializer
{ .compatible = "redhat,redboot-partitions" },
^
drivers/mtd/redboot.c:307:4: note: (near initialization for
'redboot_parser_of_match_table')
drivers/mtd/redboot.c:306:34: warning: 'redboot_parser_of_match_table'
defined but not used [-Wunused-variable]
static const struct of_device_id redboot_parser_of_match_table[] = {
^
scripts/Makefile.build:296: recipe for target 'drivers/mtd/redboot.o'
failed
make[7]: *** [drivers/mtd/redboot.o] Error 1
scripts/Makefile.build:547: recipe for target 'drivers/mtd' failed
make[6]: *** [drivers/mtd] Error 2
Makefile:1006: recipe for target 'drivers' failed
make[5]: *** [drivers] Error 2
make[5]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111'
Makefile:24: recipe for target
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111/.image'
failed
make[4]: ***
[/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111/.image]
Error 2
make[4]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/target/linux/ar71xx'
Makefile:13: recipe for target 'install' failed
make[3]: *** [install] Error 2
make[3]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/target/linux'
Command exited with non-zero status 2
time: target/linux/install#2.88#1.22#8.03
target/Makefile:23: recipe for target 'target/linux/install' failed
make[2]: *** [target/linux/install] Error 2
make[2]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm'
target/Makefile:19: recipe for target
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/target-mips_24kc_musl/stamp/.target_install'
failed
make[1]: ***
[/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/target-mips_24kc_musl/stamp/.target_install]
Error 2
make[1]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm'
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/include/toplevel.mk:216:
recipe for target 'world' failed
make: *** [world] Error 2
On ar71xx (gl-mifi) and imx6 when using ath10k-ct:
make CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m CONFIG_ATH10K_AHB=m -C
"/mnt/ramdisk/koen/firmware/builds/generic_glmifi/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111"
HOSTCFLAGS="-O2
-I/mnt/ramdisk/koen/firmware/builds/generic_glmifi/staging_dir/host/include
-I/mnt/ramdisk/koen/firmware/builds/generic_glmifi/staging_dir/hostpkg/include
-I/mnt/ramdisk/koen/firmware/builds/generic_glmifi/staging_dir/target-mips_24kc_musl/host/include
-Wall -Wmissing-prototypes -Wstrict-prototypes"
CROSS_COMPILE="mips-openwrt-linux-musl-" ARCH="mips"
KBUILD_HAVE_NLS=no KBUILD_BUILD_USER="" KBUILD_BUILD_HOST=""
KBUILD_BUILD_TIMESTAMP="Mon Jul 30 06:39:52 2018"
KBUILD_BUILD_VERSION="0"
[OpenWrt-Devel] Multi build failures using today's master
Hi All,
I started building today's master this morning for 7 different targets,
and most of them failed. (some 4.9 and some 4.14 kernels)
On ar71xx (Rocket M5) : (Added Rafał in CC as I noticed he worked on
this)
touch
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111/.configured
rm -f
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/root-ar71xx/init
make -C
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111
HOSTCFLAGS="-O2
-I/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/host/include
-Wall -Wmissing-prototypes -Wstrict-prototypes"
CROSS_COMPILE="mips-openwrt-linux-musl-" ARCH="mips" KBUILD_HAVE_NLS=no
KBUILD_BUILD_USER="" KBUILD_BUILD_HOST="" KBUILD_BUILD_TIMESTAMP="Mon
Jul 30 06:39:52 2018" KBUILD_BUILD_VERSION="0"
HOST_LOADLIBES="-L/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/host/lib"
CONFIG_SHELL="bash" V='' cmd_syscalls= KERNELRELEASE=4.9.111
CC="ccache_cc" all modules
make[5]: Entering directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111'
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
LD drivers/mtd/mtd.o
CC drivers/mtd/redboot.o
drivers/mtd/redboot.c:306:34: error: array type has incomplete element
type 'struct of_device_id'
static const struct of_device_id redboot_parser_of_match_table[] = {
^
drivers/mtd/redboot.c:307:4: error: field name not in record or union
initializer
{ .compatible = "redhat,redboot-partitions" },
^
drivers/mtd/redboot.c:307:4: note: (near initialization for
'redboot_parser_of_match_table')
drivers/mtd/redboot.c:306:34: warning: 'redboot_parser_of_match_table'
defined but not used [-Wunused-variable]
static const struct of_device_id redboot_parser_of_match_table[] = {
^
scripts/Makefile.build:296: recipe for target 'drivers/mtd/redboot.o' failed
make[7]: *** [drivers/mtd/redboot.o] Error 1
scripts/Makefile.build:547: recipe for target 'drivers/mtd' failed
make[6]: *** [drivers/mtd] Error 2
Makefile:1006: recipe for target 'drivers' failed
make[5]: *** [drivers] Error 2
make[5]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111'
Makefile:24: recipe for target
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111/.image'
failed
make[4]: ***
[/mnt/ramdisk/koen/firmware/builds/generic_rocketm/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111/.image]
Error 2
make[4]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/target/linux/ar71xx'
Makefile:13: recipe for target 'install' failed
make[3]: *** [install] Error 2
make[3]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/target/linux'
Command exited with non-zero status 2
time: target/linux/install#2.88#1.22#8.03
target/Makefile:23: recipe for target 'target/linux/install' failed
make[2]: *** [target/linux/install] Error 2
make[2]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm'
target/Makefile:19: recipe for target
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/target-mips_24kc_musl/stamp/.target_install'
failed
make[1]: ***
[/mnt/ramdisk/koen/firmware/builds/generic_rocketm/staging_dir/target-mips_24kc_musl/stamp/.target_install]
Error 2
make[1]: Leaving directory
'/mnt/ramdisk/koen/firmware/builds/generic_rocketm'
/mnt/ramdisk/koen/firmware/builds/generic_rocketm/include/toplevel.mk:216:
recipe for target 'world' failed
make: *** [world] Error 2
On ar71xx (gl-mifi) and imx6 when using ath10k-ct:
make CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m CONFIG_ATH10K_AHB=m -C
"/mnt/ramdisk/koen/firmware/builds/generic_glmifi/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/linux-4.9.111"
HOSTCFLAGS="-O2
-I/mnt/ramdisk/koen/firmware/builds/generic_glmifi/staging_dir/host/include
-I/mnt/ramdisk/koen/firmware/builds/generic_glmifi/staging_dir/hostpkg/include
-I/mnt/ramdisk/koen/firmware/builds/generic_glmifi/staging_dir/target-mips_24kc_musl/host/include
-Wall -Wmissing-prototypes -Wstrict-prototypes"
CROSS_COMPILE="mips-openwrt-linux-musl-" ARCH="mips" KBUILD_HAVE_NLS=no
KBUILD_BUILD_USER="" KBUILD_BUILD_HOST="" KBUILD_BUILD_TIMESTAMP="Mon
Jul 30 06:39:52 2018" KBUILD_BUILD_VERSION="0"
Re: [OpenWrt-Devel] how to add/package kernel module?
On 2018-07-30 08:24, John Crispin wrote: On 27/07/18 17:26, Torbjorn Jansson wrote: Hello. Probably over a year ago i built a rasperry pi and made a custom build of openwrt and added a small patch for myself to make module for htu21 temp and humidity sensor available. the patch i made i'm not sure if it is correct or not and even if it still works with all the changes that has been done but it would be nice to have the kernel module (kmod-iio-htu21) built and available as an option preferably in some future release. i use the htu21 kernel module with a small shell script to push the data out to an mqtt server for further handling. there is probably more iio modules that could be useful to others but for now i'm happy if i can make a new version of openwrt with the kernel module added and preferably also get it included so i don't need a custom build. below is my old patch. Patch looks ok at first glance, but there are a few formal errors, the Signed-off-by is missing and the patch headline needs to be prefixed and a proper description needs to be written -> https://openwrt.org/submitting-patches John thanks, i'll take a look there. and i will try and figure out how to get git sendmail to work, i know i had problems last time i used it. i will refresh my patch and also move the module from Other to IIO sub menu since that's where it belongs. one more question, in the case of htu21 it depends on another module, ms_sensors_i2c and as i wrote the patch they both get included in the same package. right now i don't think any other kernel module package uses ms_sensors_i2c. is it ok to put both modules in same package or should i make ms_sensors_i2c go in its own package with a dependency between them? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/4] ramips: fix RBM33G partitioning
> Le 30 juil. 2018 à 08:40, John Crispin a écrit : > > > > On 29/07/18 11:07, Thibaut VARÈNE wrote: >> This patch improves 5684d087418d176cfdef4e045e1950ca7ba3b09f by correcting >> the partition scheme for the "RouterBoot" section of the flash. >> >> This section is subdivided in several segments, as they are on ar71xx >> RB devices, albeit with different offsets and sizes. The naming convention >> from ar71xx has been preserved. The preferred 'fixed-partitions' DTS >> node syntax is used, with nesting support as introduced in 2a598bbaa3. >> >> The OEM source code also define a "RouterBootFake" partition at the >> beginning of the secondary flash chip: to avoid trouble if OEM ever makes >> use of that space, it is also defined here. > > as discussed on IRC we concluded, that this should be done with a mtd > splitter. > John I’m sorry, we didn’t conclude anything, I believe you demanded it be done so. Unfortunately, after a more careful investigation, I am now convinced this is not the right course of action. Here’s why, in my very humble opinion and limited understanding: - this splitter will be quite intrusive in generic code (currently « mtdsplit » only works with « firmware » and « rootfs » named partitions) - the bootloaders (routerboot and routerboot2) cannot be programmatically splitted: they are raw machine code without a signature - all ramips routerboard machines share the exact same partition scheme which is different from all the ar71xx routerboard machines (which also all share the same scheme) - if I read the OEM source code correctly, it’s likely their ARM-based boards have yet another partition scheme Consequently, a purported splitter will be invasive and full of hardcoded numbers, making its upstream acceptance very unlikely (I anticipate the argument « this should all be done in DTS, especially now that DTS supports nested partitions »). Now, I would like to hope that a correct partition scheme that uses all the OpenWRT-accepted features and follows guidelines would be more likely to be accepted in the source than the currently broken, incorrect and incomplete existing one. Best regards, T. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH procd 1/2] trace: Use properly sized type for PTRACE_GETEVENTMSG
From: Michal Sojka
Without this, on 64-bit systems, ptrace call corrupts memory because
it stores 64bit value to 32bit pid_t variable.
Signed-off-by: Michal Sojka
---
trace/trace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/trace/trace.c b/trace/trace.c
index 27cf108..665c22e 100644
--- a/trace/trace.c
+++ b/trace/trace.c
@@ -211,7 +211,9 @@ static void tracer_cb(struct uloop_process *c, int ret)
(ret >> 8) == (SIGTRAP | (PTRACE_EVENT_CLONE << 8)))
{
struct tracee *child = calloc(1, sizeof(struct tracee));
- ptrace(PTRACE_GETEVENTMSG, c->pid, 0, >proc.pid);
+ unsigned long msg;
+ ptrace(PTRACE_GETEVENTMSG, c->pid, 0, );
+ child->proc.pid = msg;
child->proc.cb = tracer_cb;
ptrace(ptrace_restart, child->proc.pid, 0, 0);
uloop_process_add(>proc);
--
2.18.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH procd 2/2] Allow disabling seccomp or changing the whitelist
From: Michal Sojka Without this change, once a service is started with seccomp, it is impossible to restart it without seccomp or change the whitelist file name. This commit fixes that. Disabling seccomp is as easy as commenting out the "procd_set_param seccomp" line in init.d script. Signed-off-by: Michal Sojka --- service/instance.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/service/instance.c b/service/instance.c index 917b003..c14d348 100644 --- a/service/instance.c +++ b/service/instance.c @@ -637,6 +637,11 @@ instance_config_changed(struct service_instance *in, struct service_instance *in if (in->respawn_timeout != in_new->respawn_timeout) return true; + if ((!in->seccomp && in_new->seccomp) || + (in->seccomp && !in_new->seccomp) || + (in->seccomp && in_new->seccomp && strcmp(in->seccomp, in_new->seccomp))) + return true; + if (!blobmsg_list_equal(>limits, _new->limits)) return true; @@ -957,6 +962,7 @@ instance_config_move(struct service_instance *in, struct service_instance *in_sr in->respawn_timeout = in_src->respawn_timeout; in->name = in_src->name; in->trace = in_src->trace; + in->seccomp = in_src->seccomp; in->node.avl.key = in_src->node.avl.key; free(in->config); -- 2.18.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH procd 1/2] trace: Use properly sized type for PTRACE_GETEVENTMSG
From: Michal Sojka
Without this, on 64-bit systems, ptrace call corrupts memory because
it stores 64bit value to 32bit pid_t variable.
Signed-off-by: Michal Sojka
---
trace/trace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/trace/trace.c b/trace/trace.c
index 27cf108..665c22e 100644
--- a/trace/trace.c
+++ b/trace/trace.c
@@ -211,7 +211,9 @@ static void tracer_cb(struct uloop_process *c, int ret)
(ret >> 8) == (SIGTRAP | (PTRACE_EVENT_CLONE << 8)))
{
struct tracee *child = calloc(1, sizeof(struct tracee));
- ptrace(PTRACE_GETEVENTMSG, c->pid, 0, >proc.pid);
+ unsigned long msg;
+ ptrace(PTRACE_GETEVENTMSG, c->pid, 0, );
+ child->proc.pid = msg;
child->proc.cb = tracer_cb;
ptrace(ptrace_restart, child->proc.pid, 0, 0);
uloop_process_add(>proc);
--
2.18.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] brcm63xx: update DT RedBoot binding for the Inventel Livebox 1
From: Rafał Miłecki
linux,part-probe should be avoided as its only supported with OpenWrt
downstream patch that is going to be dropped eventually.
Signed-off-by: Rafał Miłecki
---
target/linux/brcm63xx/dts/livebox-blue-5g.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/linux/brcm63xx/dts/livebox-blue-5g.dts
b/target/linux/brcm63xx/dts/livebox-blue-5g.dts
index 0bc503c941..7e8d865a4f 100644
--- a/target/linux/brcm63xx/dts/livebox-blue-5g.dts
+++ b/target/linux/brcm63xx/dts/livebox-blue-5g.dts
@@ -69,7 +69,9 @@
reg = <0x1e40 0x80>;
status = "ok";
- linux,part-probe = "RedBoot";
+ partitions {
+ compatible = "redhat,redboot-partitions";
+ };
};
{
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/4] ramips: fix RBM33G partitioning
On 29/07/18 11:07, Thibaut VARÈNE wrote:
This patch improves 5684d087418d176cfdef4e045e1950ca7ba3b09f by correcting
the partition scheme for the "RouterBoot" section of the flash.
This section is subdivided in several segments, as they are on ar71xx
RB devices, albeit with different offsets and sizes. The naming convention
from ar71xx has been preserved. The preferred 'fixed-partitions' DTS
node syntax is used, with nesting support as introduced in 2a598bbaa3.
The OEM source code also define a "RouterBootFake" partition at the
beginning of the secondary flash chip: to avoid trouble if OEM ever makes
use of that space, it is also defined here.
as discussed on IRC we concluded, that this should be done with a mtd
splitter.
John
The resulting partition scheme looks like this:
[ 10.114241] m25p80 spi0.0: w25x40 (512 Kbytes)
[ 10.118708] 1 fixed-partitions partitions found on MTD device spi0.0
[ 10.125049] Creating 1 MTD partitions on "spi0.0":
[ 10.129824] 0x-0x0004 : "RouterBoot"
[ 10.136215] 5 fixed-partitions partitions found on MTD device RouterBoot
[ 10.142894] Creating 5 MTD partitions on "RouterBoot":
[ 10.148032] 0x-0xf000 : "routerboot"
[ 10.154336] 0xf000-0x0001 : "hard_config"
[ 10.160665] 0x0001-0x0001f000 : "routerboot2"
[ 10.167046] 0x0002-0x00021000 : "soft_config"
[ 10.173461] 0x0003-0x00031000 : "bios"
[ 10.190191] m25p80 spi0.1: w25q128 (16384 Kbytes)
[ 10.194950] 2 fixed-partitions partitions found on MTD device spi0.1
[ 10.201271] Creating 2 MTD partitions on "spi0.1":
[ 10.206071] 0x-0x0004 : "RouterBootFake"
[ 10.212746] 0x0004-0x0100 : "firmware"
[ 10.307216] 2 minor-fw partitions found on MTD device firmware
[ 10.313044] 0x0004-0x0022 : "kernel"
[ 10.319002] 0x0022-0x0100 : "rootfs"
[ 10.324906] mtd: device 9 (rootfs) set to be root filesystem
[ 10.330678] 1 squashfs-split partitions found on MTD device rootfs
[ 10.336886] 0x00b4-0x0100 : "rootfs_data"
Leave a note in DTS to explain how the original author selected the SPI speed.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/dts/RBM33G.dts | 69 +-
1 file changed, 54 insertions(+), 15 deletions(-)
diff --git a/target/linux/ramips/dts/RBM33G.dts
b/target/linux/ramips/dts/RBM33G.dts
index 612dc106ed..a02d03818f 100644
--- a/target/linux/ramips/dts/RBM33G.dts
+++ b/target/linux/ramips/dts/RBM33G.dts
@@ -104,18 +104,44 @@
reg = <0>;
spi-max-frequency = <3125000>;
- partition@0 {
- label = "routerboot";
- reg = <0x0 0xf000>;
- read-only;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "RouterBoot";
+ reg = <0x0 0x4>;
+ read-only;
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ routerboot@0 {
+ reg = <0x0 0xf000>;
+ read-only;
+ };
+
+ hard_config: hard_config@f000 {
+ reg = <0xf000 0x1000>;
+ read-only;
+ };
+
+ routerboot2@1 {
+ reg = <0x1 0xf000>;
+ read-only;
+ };
+
+ soft_config@2 {
+ reg = <0x2 0x1000>;
+ };
+
+ bios@3 {
+ reg = <0x3 0x1000>;
+ read-only;
+ };
+ };
};
-
- factory: partition@f000 {
- label = "factory";
- reg = <0xf000 0x71000>;
- read-only;
- };
-
};
w25q128@0 {
@@ -123,17 +149,30 @@
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <1>;
+ // XXX empiric value to obtain actual 10MHz SCK at the chip
spi-max-frequency = <3125000>;
- partition@4 {
- label = "firmware";
- reg = <0x04
Re: [OpenWrt-Devel] how to add/package kernel module?
On 27/07/18 17:26, Torbjorn Jansson wrote: Hello. Probably over a year ago i built a rasperry pi and made a custom build of openwrt and added a small patch for myself to make module for htu21 temp and humidity sensor available. the patch i made i'm not sure if it is correct or not and even if it still works with all the changes that has been done but it would be nice to have the kernel module (kmod-iio-htu21) built and available as an option preferably in some future release. i use the htu21 kernel module with a small shell script to push the data out to an mqtt server for further handling. there is probably more iio modules that could be useful to others but for now i'm happy if i can make a new version of openwrt with the kernel module added and preferably also get it included so i don't need a custom build. below is my old patch. Patch looks ok at first glance, but there are a few formal errors, the Signed-off-by is missing and the patch headline needs to be prefixed and a proper description needs to be written -> https://openwrt.org/submitting-patches John diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index 38b98f3..3770510 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -329,6 +329,29 @@ endef $(eval $(call KernelPackage,iio-dht11)) +define KernelPackage/iio-htu21 + SUBMENU:=$(OTHER_MENU) + DEPENDS:=kmod-i2c-core kmod-iio-core + TITLE:=Measurement Specialties HTU21 humidity & temperature sensor + KCONFIG:= \ + CONFIG_HTU21 \ + CONFIG_IIO_MS_SENSORS_I2C + FILES:= \ + $(LINUX_DIR)/drivers/iio/humidity/htu21.ko \ + $(LINUX_DIR)/drivers/iio/common/ms_sensors/ms_sensors_i2c.ko + AUTOLOAD:=$(call AutoLoad,56,htu21) +endef + +define KernelPackage/iio-htu21/description + support for the Measurement Specialties HTU21 humidity and + temperature sensor. + This driver is also used for MS8607 temperature, pressure & humidity + sensor +endef + +$(eval $(call KernelPackage,iio-htu21)) + + define KernelPackage/lp SUBMENU:=$(OTHER_MENU) TITLE:=Parallel port and line printer support ___ 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
