[PATCH] fortify-headers: fix compilation with GCC 10.3
For some reason, fortified mempcpy does not work with GCC 10.3. It
worked with GCC 10.2.
Some output with tvheadend:
error: 'mempcpy' undeclared here (not in a function);
did you mean 'memccpy'?
144 | _FORTIFY_FN(mempcpy) void *mempcpy(void *__d,
const void *__s, size_t __n)
| ^~~
note: in definition of macro '_FORTIFY_ORIG'
20 | #define _FORTIFY_ORIG(p,fn)
__typeof__(fn) __orig_##fn __asm__(_FORTIFY_STR(p) #fn)
note: in expansion of macro
'_FORTIFY_FN'
144 | _FORTIFY_FN(mempcpy) void
*mempcpy(void *__d, const void *__s, size_t __n)
In function 'mempcpy':
error: called object '__orig_mempcpy' is not a
function or function pointer
151 | return _orig_mempcpy(__d, __s, __n);
Signed-off-by: Rosen Penev
---
toolchain/fortify-headers/Makefile | 2 +-
toolchain/fortify-headers/patches/010-mempcpy.patch | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 toolchain/fortify-headers/patches/010-mempcpy.patch
diff --git a/toolchain/fortify-headers/Makefile
b/toolchain/fortify-headers/Makefile
index a6151bb2f1..bb67c33c30 100644
--- a/toolchain/fortify-headers/Makefile
+++ b/toolchain/fortify-headers/Makefile
@@ -9,7 +9,7 @@ include $(INCLUDE_DIR)/target.mk
PKG_NAME:=fortify-headers
PKG_VERSION:=1.1
-PKG_RELEASE=1
+PKG_RELEASE=2
PKG_SOURCE_URL:=http://dl.2f30.org/releases
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
diff --git a/toolchain/fortify-headers/patches/010-mempcpy.patch
b/toolchain/fortify-headers/patches/010-mempcpy.patch
new file mode 100644
index 00..8423395da5
--- /dev/null
+++ b/toolchain/fortify-headers/patches/010-mempcpy.patch
@@ -0,0 +1,11 @@
+--- a/include/string.h
b/include/string.h
+@@ -139,7 +139,7 @@ _FORTIFY_FN(strncpy) char *strncpy(char
+ return __orig_strncpy(__d, __s, __n);
+ }
+
+-#ifdef _GNU_SOURCE
++#if 0
+ #undef mempcpy
+ _FORTIFY_FN(mempcpy) void *mempcpy(void *__d, const void *__s, size_t __n)
+ {
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] toolchain: gcc: Update to version 10.3.0
On Sat, Apr 10, 2021 at 3:17 PM Hauke Mehrtens wrote:
>
> Signed-off-by: Hauke Mehrtens
Breaks fortify-headers interestingly enough.
> ---
> toolchain/gcc/Config.version| 2 +-
> toolchain/gcc/common.mk | 4 ++--
> .../patches/{10.2.0 => 10.3.0}/002-case_insensitive.patch | 0
> .../gcc/patches/{10.2.0 => 10.3.0}/010-documentation.patch | 0
> .../patches/{10.2.0 => 10.3.0}/110-Fix-MIPS-PR-84790.patch | 0
> .../gcc/patches/{10.2.0 => 10.3.0}/230-musl_libssp.patch| 0
> .../{10.2.0 => 10.3.0}/300-mips_Os_cpu_rtx_cost_model.patch | 0
> .../{10.2.0 => 10.3.0}/810-arm-softfloat-libgcc.patch | 0
> .../gcc/patches/{10.2.0 => 10.3.0}/820-libgcc_pic.patch | 0
> .../{10.2.0 => 10.3.0}/840-armv4_pass_fix-v4bx_to_ld.patch | 0
> .../patches/{10.2.0 => 10.3.0}/850-use_shared_libgcc.patch | 0
> .../patches/{10.2.0 => 10.3.0}/851-libgcc_no_compat.patch | 0
> .../patches/{10.2.0 => 10.3.0}/870-ppc_no_crtsavres.patch | 0
> .../gcc/patches/{10.2.0 => 10.3.0}/881-no_tm_section.patch | 0
> .../gcc/patches/{10.2.0 => 10.3.0}/900-bad-mips16-crt.patch | 0
> .../gcc/patches/{10.2.0 => 10.3.0}/910-mbsd_multi.patch | 6 +++---
> .../{10.2.0 => 10.3.0}/920-specs_nonfatal_getenv.patch | 0
> .../{10.2.0 => 10.3.0}/930-fix-mips-noexecstack.patch | 0
> .../931-libffi-fix-MIPS-softfloat-build-issue.patch | 0
> ...gotools-fix-compilation-when-making-cross-compiler.patch | 0
> 20 files changed, 6 insertions(+), 6 deletions(-)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/002-case_insensitive.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/010-documentation.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/110-Fix-MIPS-PR-84790.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/230-musl_libssp.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 =>
> 10.3.0}/300-mips_Os_cpu_rtx_cost_model.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 =>
> 10.3.0}/810-arm-softfloat-libgcc.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/820-libgcc_pic.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 =>
> 10.3.0}/840-armv4_pass_fix-v4bx_to_ld.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/850-use_shared_libgcc.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/851-libgcc_no_compat.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/870-ppc_no_crtsavres.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/881-no_tm_section.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/900-bad-mips16-crt.patch
> (100%)
> rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/910-mbsd_multi.patch (96%)
> rename toolchain/gcc/patches/{10.2.0 =>
> 10.3.0}/920-specs_nonfatal_getenv.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 =>
> 10.3.0}/930-fix-mips-noexecstack.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 =>
> 10.3.0}/931-libffi-fix-MIPS-softfloat-build-issue.patch (100%)
> rename toolchain/gcc/patches/{10.2.0 =>
> 10.3.0}/960-gotools-fix-compilation-when-making-cross-compiler.patch (100%)
>
> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> index 967ce9e4892b..4e141477a516 100644
> --- a/toolchain/gcc/Config.version
> +++ b/toolchain/gcc/Config.version
> @@ -14,7 +14,7 @@ config GCC_VERSION
> string
> default "7.5.0" if GCC_VERSION_7
> default "9.3.0" if GCC_VERSION_9
> - default "10.2.0"if GCC_VERSION_10
> + default "10.3.0"if GCC_VERSION_10
> default "8.4.0"
>
> config GCC_USE_IREMAP
> diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
> index 55fad1fcc48d..ef8fd9de47fd 100644
> --- a/toolchain/gcc/common.mk
> +++ b/toolchain/gcc/common.mk
> @@ -40,8 +40,8 @@ ifeq ($(PKG_VERSION),9.3.0)
>PKG_HASH:=71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1
> endif
>
> -ifeq ($(PKG_VERSION),10.2.0)
> - PKG_HASH:=b8dd4368bb9c7f0b98188317ee0254dd8cc99d1e3a18d0ff146c855fe16c1d8c
> +ifeq ($(PKG_VERSION),10.3.0)
> + PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344
> endif
>
> PATCH_DIR=../patches/$(GCC_VERSION)
> diff --git a/toolchain/gcc/patches/10.2.0/002-case_insensitive.patch
> b/toolchain/gcc/patches/10.3.0/002-case_insensitive.patch
> similarity index 100%
> rename from toolchain/gcc/patches/10.2.0/002-case_insensitive.patch
> rename to toolchain/gcc/patches/10.3.0/002-case_insensitive.patch
> diff --git a/toolchain/gcc/patches/10.2.0/010-documentation.patch
> b/toolchain/gcc/patches/10.3.0/010-documentation.patch
> similarity index 100%
> rename from toolchain/gcc/patches/10.2.0/010-documentation.patch
> rename to toolchain/gcc/patches/10.3.0/010-documentation.patch
> diff --git a/toolchain/gcc/patches/10.2.0/110-Fix-MIPS-PR-84790.patch
> b/toolchain/gcc/patches/10.3.0/110-Fix-MIPS-PR-84790.patch
>
firmware-utils: mkmylofw broken since 9. Apr 2021
Hi, since some days my master builds failing for ath79-generic. I was able to narrow it to running "mkmylofw for compex_wpj344-16m". The tool runs till the drive is full, currently my "compex_wpj344-16m- squashfs-cpximg-6a08.bin.new" is 161GB and growing ... Has anyone else seen this? I'll check to see which of the relevant 6 commit trigger this during the next days. Full command is: > let size="$(stat -c%s /mnt/hosts/strike/develop/sven/openwrt/freifunk/ freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/ tmp/freifunk-berlin-sam0815-experimental-nightly-cbbe3507-ath79-generic- compex_wpj344-16m-squashfs-cpximg-6a08.bin)" pad="64* 1024" pad="(pad - (size % pad)) % pad" newsize='size + pad' ; [ $newsize -lt $((0x66)) ] && newsize=0x66 ; /mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk- berlin/openwrt/staging_dir/host/bin/mkmylofw -B WPE72 -i 0x11f6:0x690:0x11f6:0x690 -r 3 -s 0x100 -p0x3:$newsize:al: 0x8006:"OpenWRT":/mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk- berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/tmp/ freifunk-berlin-sam0815-experimental-nightly-cbbe3507-ath79-generic- compex_wpj344-16m-squashfs-cpximg-6a08.bin /mnt/hosts/strike/develop/sven/ openwrt/freifunk/freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/ linux-ath79_generic/tmp/freifunk-berlin-sam0815-experimental-nightly-cbbe3507- ath79-generic-compex_wpj344-16m-squashfs-cpximg-6a08.bin.new Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 1/3] realtek: correct GS110TPP v1 PoE budget, add rtl83xx-poe package
Set the right PoE power budget and add the rtl83xx-poe package to control PoE with OpenWrt. According to multiple sources (Netgear web page [1], Wikidevi [2] and Biot's wiki [3]) this switch has a 120W PoE power budget, not a 130W one. [1] https://www.netgear.com/business/wired/switches/smart-cloud/gs110tpp/ [2] https://wikidevi.wi-cat.ru/Netgear_GS110TPP [3] https://biot.com/switches/gs110tpp Signed-off-by: Stijn Segers --- target/linux/realtek/base-files/etc/board.d/02_network | 2 +- target/linux/realtek/image/Makefile| 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index 1e199db589..b27bed9a63 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -49,7 +49,7 @@ done case $board in netgear,gs110tpp-v1) - ucidef_set_poe 130 "$lan_list" + ucidef_set_poe 120 "$lan_list" ;; zyxel,gs1900-10hp) ucidef_set_poe 77 "$lan_list" diff --git a/target/linux/realtek/image/Makefile b/target/linux/realtek/image/Makefile index 18e5fedb9b..429548391d 100644 --- a/target/linux/realtek/image/Makefile +++ b/target/linux/realtek/image/Makefile @@ -83,6 +83,7 @@ define Device/netgear_gs110tpp-v1 $(Device/netgear_nge) DEVICE_MODEL := GS110TPP DEVICE_VARIANT := v1 + DEVICE_PACKAGES += rtl83xx-poe endef TARGET_DEVICES += netgear_gs110tpp-v1 -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 0/3] realtek: PoE budgets and rtl83xx-poe package
This is a set of assorted fixes and improvements for the realtek target. All patches depend on the rtl83xx-poe package sitting in Patchwork. If we keep the realtek target for 21.02, please backport these from master. Stijn Segers (3): realtek: correct GS110TPP v1 PoE budget, add rtl83xx-poe package realtek: add rtl83xx-poe to GS1900-8HP & GS1900-10HP profile realtek: add PoE budget and rtl83xx-poe package for DGS-1210-10P target/linux/realtek/base-files/etc/board.d/02_network | 5 - target/linux/realtek/image/Makefile| 8 +--- 2 files changed, 9 insertions(+), 4 deletions(-) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 2/3] realtek: add rtl83xx-poe to GS1900-8HP & GS1900-10HP profile
Add the rtl83xx-poe package to the device profiles for the ZyXEL PoE switches that are currently supported: - GS1900-10HP - GS1900-8HP v1 - GS1900-8HP v2 Signed-off-by: Stijn Segers --- target/linux/realtek/image/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/target/linux/realtek/image/Makefile b/target/linux/realtek/image/Makefile index 429548391d..4d34aabd5e 100644 --- a/target/linux/realtek/image/Makefile +++ b/target/linux/realtek/image/Makefile @@ -99,6 +99,7 @@ endef define Device/zyxel_gs1900-10hp $(Device/zyxel_gs1900) DEVICE_MODEL := GS1900-10HP + DEVICE_PACKAGES += rtl83xx-poe ZYXEL_VERS := AAZI endef TARGET_DEVICES += zyxel_gs1900-10hp @@ -114,8 +115,8 @@ define Device/zyxel_gs1900-8hp-v1 $(Device/zyxel_gs1900) DEVICE_MODEL := GS1900-8HP DEVICE_VARIANT := v1 + DEVICE_PACKAGES += rtl83xx-poe ZYXEL_VERS := AAHI - DEVICE_PACKAGES += lua-rs232 endef TARGET_DEVICES += zyxel_gs1900-8hp-v1 @@ -123,8 +124,8 @@ define Device/zyxel_gs1900-8hp-v2 $(Device/zyxel_gs1900) DEVICE_MODEL := GS1900-8HP DEVICE_VARIANT := v2 + DEVICE_PACKAGES += rtl83xx-poe ZYXEL_VERS := AAHI - DEVICE_PACKAGES += lua-rs232 endef TARGET_DEVICES += zyxel_gs1900-8hp-v2 -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 3/3] realtek: add PoE budget and rtl83xx-poe package for DGS-1210-10P
The PoE power budget for the DGS-1210-10P is known to be 65W, so set it. Also add the rtl83xx-poe package to the device profile so we can manage PoE with OpenWrt just like one would with the vendor firmware. Signed-off-by: Stijn Segers --- target/linux/realtek/base-files/etc/board.d/02_network | 3 +++ target/linux/realtek/image/Makefile| 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index b27bed9a63..a65066a522 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -48,6 +48,9 @@ done [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac case $board in +d-link,dgs-1210-10p) + ucidef_set_poe 65 "$lan_list" + ;; netgear,gs110tpp-v1) ucidef_set_poe 120 "$lan_list" ;; diff --git a/target/linux/realtek/image/Makefile b/target/linux/realtek/image/Makefile index 4d34aabd5e..da1b5fb2ed 100644 --- a/target/linux/realtek/image/Makefile +++ b/target/linux/realtek/image/Makefile @@ -56,7 +56,7 @@ endef define Device/d-link_dgs-1210-10p $(Device/d-link_dgs-1210) DEVICE_MODEL := DGS-1210-10P - DEVICE_PACKAGES += lua-rs232 + DEVICE_PACKAGES += rtl83xx-poe endef TARGET_DEVICES += d-link_dgs-1210-10p -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/3] realtek: add rtl83xx-poe for GS1900-8HP & GS1900-10HP
Hi, Op maandag 12 april 2021 om 15u31 schreef Bjørn Mork : Stijn Segers writes: Add the rtl83xx-poe package to the device profiles for the ZyXEL PoE switches that are currently supported: - GS1900-10HP - GS1900-8HP v1 - GS1900-8HP v2 Signed-off-by: Stijn Segers --- This patch depends on the rtl83xx-poe package sitting in Patchwork: https://patchwork.ozlabs.org/project/openwrt/list/?series=233826 Wondering a bit about the status here? Did I miss some change request or is there something else wrong? This package is required to use the PoE feature of the supported switches. Releasing 21.02 without it will probably result in frustrated users looking for a way to use a feature which used to work before they upgraded to OpenWrt. We can easily make it work by default with the rtl83xx-poe package and Stijn's patch. The package works very well, and no one has yet made any alternative implementation in other languages or whatver, as far as I know. I'll be sending in a revised patch set that covers non-ZyXEL devices as well, these patches are rather trivial so would be nice to see them merged. Cheers Stijn Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Regression: commit 2809d0000744 ("kernel: support FIT partition parser on mtdblock devices") breaks mtd-concat
On Mon, Apr 12, 2021 at 06:03:30PM +0200, Koen Vandeputte wrote:
>
> On 12.04.21 17:31, Daniel Golle wrote:
> > On Mon, Apr 12, 2021 at 10:45:14PM +0800, DENG Qingfang wrote:
> > > After the commit, devices with mtd-concat such as HC5962 no longer work.
> > > Several "sysfs: cannot create duplicate filename '/devices/..." warnings
> > > can be seen in kernel log.
> > I'm working on it, currently preparing to reproduce this be also
> > playing with mtd-concat.
>
> Should it help :-)
>
> https://pastebin.com/raw/d069j7wS
Should be fixed by e9c8c834de ("kernel: fix deferred mtdblock registration").
Thanks for reporting!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] realtek: revert to "standard" management configuration
On 4/12/21 2:27 PM, Bjørn Mork wrote: The default management interface should be easy to find for users doing "blind" installations without console access. There are already multiple examples in the forum of advanced early adopters having problems locating the management interface after installing OpenWrt. Requiring tagged VLAN configration to access the initial management interface creates unnecessary hassle at best. Errors on the other end are close to impossible to debug without console access, even for advanced users. Less advanced users might have problems with the concept of VLAN tagging. Limiting management access to a single arbitrary port among up to 52 possible LAN ports makes this even more difficult, for no reason at all. Users might have reasons to use a different port for management. And they might even have difficulties using the OpenWrt selected one. The port might be the wrong type for their management link (e.g copper instead of fibre). Or they might depend on PoE power from a device which they can't reconfigure. User expectations will be based on - OpenWrt defaults for other devices - stock firmware default for the device in question - common default behaviour of similar devices All 3 cases point to a static IP address accessible on the native VLAN of any LAN port. A switch does not have any WAN port. All ports are LAN ports. This changes the default network configuration in line with these expectations. Cc: John Crispin Signed-off-by: Bjørn Mork Acked-by: Hauke Mehrtens --- .../realtek/base-files/etc/board.d/02_network | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index 1e199db5897f..44f1f0a7a5c1 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do lan_list="$lan_list $(basename $lan)" done ucidef_set_bridge_device switch -ucidef_set_interface_wan "$lan_list" -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100 +ucidef_set_interface_lan "$lan_list" lan_mac="" -wan_mac="" label_mac="" case $board in *) - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) label_mac=$lan_mac ;; esac -lan_mac=$(macaddr_setbit_la $wan_mac) - ucidef_set_interface_macaddr "lan" $lan_mac -ucidef_set_interface_macaddr "wan" $wan_mac -ucidef_set_bridge_mac "$wan_mac" -ucidef_set_network_device_mac eth0 $wan_mac +ucidef_set_bridge_mac "$lan_mac" +ucidef_set_network_device_mac eth0 $lan_mac for lan in $lan_list; do ucidef_set_network_device_mac $lan $lan_mac + lan_mac=$(macaddr_setbit_la $lan_mac) lan_mac=$(macaddr_add $lan_mac 1) done [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: lantiq: upstream Linux efforts
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 --- Hi Martin, On Mon, Apr 12, 2021 at 11:59 AM Martin Schiller wrote: [...] > >> This approach however only works when there are active contributors > >> upstream. > >> It brings the benefit of upstream code-reviews though - which in my > >> experience improves the quality of the resulting code. > > I think there's quite a bit of work involved. I don't expect that it'll be an easy task in my opinion the first step is to reject new patches which are not following this approach then we need to work out how to clean up the remaining parts > If you take for example the patch with the configurability of the LEDs > on the phys: > Hauke had already started one or more attempts to bring this upstream > [1], but this was "rejected" with the reason that this belongs in the > LED subsystem. > > Now I found an interesting solution on the mailing list, which > implements this function as hw offloading of the netdev trigger. [2] I think the original author abandoned this (unfortunately) maybe there's not too many issues left with that series? > Furthermore there are some patches for the target lantiq, which > unfortunately don't contain any description and so we have to work out > the deeper sense or necessity of this patch again. yep, agreed. Best regards, Martin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gemini: Bump to kernel v5.10
On 12/04/2021 00:11, Linus Walleij wrote: Only two patches against mainline remains. Switch to v5.10 which works very nicely with all Gemini devices. Signed-off-by: Linus Walleij --- target/linux/gemini/Makefile | 2 +- target/linux/gemini/config-5.10 | 465 ++ ...t-fotg2-add-Gemini-specific-handling.patch | 131 + ...-DIR-685-partition-table-for-OpenWrt.patch | 37 ++ 4 files changed, 634 insertions(+), 1 deletion(-) create mode 100644 target/linux/gemini/config-5.10 create mode 100644 target/linux/gemini/patches-5.10/0001-usb-host-fotg2-add-Gemini-specific-handling.patch create mode 100644 target/linux/gemini/patches-5.10/0002-ARM-dts-Augment-DIR-685-partition-table-for-OpenWrt.patch diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile index d2acb52facf7..95a5a87eaa4d 100644 --- a/target/linux/gemini/Makefile +++ b/target/linux/gemini/Makefile @@ -10,7 +10,7 @@ BOARDNAME:=Cortina Systems CS351x FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part CPU_TYPE:=fa526 -KERNEL_PATCHVER:=5.4 +KERNEL_PATCHVER:=5.10 Hmm, when building this with the BUILDBOT config (CONFIG_BUILDBOT) and throw in the CONFIG_ALL_* for userspace + kernel modules for good measure. It fails with the default world build (without the V=s option) because the following symbols are not yet defined in either the generic or gemini-specific kernel config. CONFIG_COMPAT_32BIT_TIME CONFIG_PCIEASPM CONFIG_MTD_PHYSMAP_IXP4XX CONFIG_GPIO_CDEV_V1 CONFIG_CPU_THERMAL CONFIG_DMA_PERNUMA_CMA At least CPU_THERMAL is also a show-stopper for apm82181 5.10, so should these just be added added as either disabled (# CONFIG_ ... is not set) or in case of CONFIG_PCIEASPM=X (whatever the default is there) in target/linux/generic/config-5.10? Or CPU_THERMAL could be an issue for some high-powered x86 or ARM? Cheers, Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Regression: commit 2809d0000744 ("kernel: support FIT partition parser on mtdblock devices") breaks mtd-concat
On 12.04.21 17:31, Daniel Golle wrote: On Mon, Apr 12, 2021 at 10:45:14PM +0800, DENG Qingfang wrote: After the commit, devices with mtd-concat such as HC5962 no longer work. Several "sysfs: cannot create duplicate filename '/devices/..." warnings can be seen in kernel log. I'm working on it, currently preparing to reproduce this be also playing with mtd-concat. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Should it help :-) https://pastebin.com/raw/d069j7wS Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipq806x: Add "snps,dwmac" to all gmac compatible=
This was introduced to gmac2 and gmac3 in 57ea767a53c1 without fanfare.
There's no indication of why it was added to those devices, but not to
gmac0 or gmac1. It was probably an unintentional omission. It should be
present on all four gmac devices.
This property is considered by
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
stmmac_probe_config_dt.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
b/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
index 221ecd73965a..cbb0231d43ea 100644
--- a/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
+++ b/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
@@ -879,7 +879,7 @@
+
+ gmac0: ethernet@3700 {
+ device_type = "network";
-+ compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3700 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
@@ -902,7 +902,7 @@
+
+ gmac1: ethernet@3720 {
+ device_type = "network";
-+ compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3720 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] ipq806x: dwmac: clear forced speed during probe
On a Ubiquiti UniFi AC HD (ubnt,unifi-ac-hd, UAP-AC-HD, UAP301), a forced speed on gmac1 is set in the QSGMII PCS_ALL_CH_CTL register, presumably by the bootloader (4.3.28), preventing the interface from being usable. The QSDK NSS GMAC driver takes care to clear the forced speed in nss_gmac_qsgmii_dev_init (https://source.codeaurora.org/quic/qsdk/oss/lklm/nss-gmac/tree/ipq806x/nss_gmac_init.c?h=nss at d5bb14925861). gmac1 is connected to the port on the device labeled SECONDARY, and is currently eth0 but will be switched to eth1 by a subsequent patch. By clearing the QSGMII PCS forced speed during dwmac initialization when SGMII is in use, this port becomes usable. This patch is upstreamable, and will be sent upstream after successful testing in OpenWrt. Signed-off-by: Mark Mentovai Build-tested: ipq806x/ubnt,unifi-ac-hd Run-tested: ipq806x/ubnt,unifi-ac-hd --- ...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 33 +++ 1 file changed, 33 insertions(+) create mode 100644 target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch diff --git a/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch b/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch new file mode 100644 index ..6cdbf4d3dc6b --- /dev/null +++ b/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch @@ -0,0 +1,33 @@ +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c +@@ -64,6 +64,17 @@ + #define NSS_COMMON_CLK_DIV_SGMII_100 4 + #define NSS_COMMON_CLK_DIV_SGMII_10 49 + ++#define QSGMII_PCS_ALL_CH_CTL 0x80 ++#define QSGMII_PCS_CH_SPEED_FORCE 0x2 ++#define QSGMII_PCS_CH_SPEED_100x0 ++#define QSGMII_PCS_CH_SPEED_100 0x4 ++#define QSGMII_PCS_CH_SPEED_1000 0x8 ++#define QSGMII_PCS_CH_SPEED_MASK (QSGMII_PCS_CH_SPEED_FORCE | \ ++ QSGMII_PCS_CH_SPEED_10 | \ ++ QSGMII_PCS_CH_SPEED_100 | \ ++ QSGMII_PCS_CH_SPEED_1000) ++#define QSGMII_PCS_CH_SPEED_SHIFT(x) (x * 4) ++ + #define QSGMII_PCS_CAL_LCKDT_CTL 0x120 + #define QSGMII_PCS_CAL_LCKDT_CTL_RST BIT(19) + +@@ -345,6 +356,12 @@ static int ipq806x_gmac_probe(struct pla +0x1ul << QSGMII_PHY_RX_INPUT_EQU_OFFSET | +0x2ul << QSGMII_PHY_CDR_PI_SLEW_OFFSET | +0xCul << QSGMII_PHY_TX_DRV_AMP_OFFSET); ++ ++ regmap_update_bits(gmac->qsgmii_csr, ++ QSGMII_PCS_ALL_CH_CTL, ++ QSGMII_PCS_CH_SPEED_MASK << ++ QSGMII_PCS_CH_SPEED_SHIFT(gmac->id), ++ 0); + } + + plat_dat->has_gmac = true; -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] ipq806x: ubnt,unifi-ac-hd: use on-board PHYs
Unlike many ipq806x devices, Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301)
has no switch on board. Its two Ethernet ports are connected to Atheros
AR8033 PHYs. It is not appropriate to use fixed-link in this
configuration. Instead, configure the correct PHYs in the device tree
configuration to allow the at803x driver to load.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
index 7c2d6c9d1307..70c51b90f316 100644
--- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
@@ -16,6 +16,8 @@
led-running = _dome_blue;
led-upgrade = _dome_blue;
mdio-gpio0 =
+ ethernet0 =
+ ethernet1 =
};
leds {
@@ -229,38 +231,36 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-};
-
- {
- status = "okay";
- phy-mode = "sgmii";
- qcom,id = <2>;
- qcom,emulation = <0>;
- mdiobus = <>;
-
- mtd-mac-address = < 0x0>;
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
- fixed-link {
- speed = <1000>;
- full-duplex;
+ phy5: ethernet-phy@5 {
+ reg = <5>;
};
};
{
status = "okay";
+ mdiobus = <>;
+ phy-handle = <>;
phy-mode = "sgmii";
qcom,id = <1>;
- qcom,emulation = <0>;
- mdiobus = <>;
mtd-mac-address = < 0x6>;
+};
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
+ {
+ status = "okay";
+
+ mdiobus = <>;
+ phy-handle = <>;
+ phy-mode = "sgmii";
+ qcom,id = <2>;
+
+ mtd-mac-address = < 0x0>;
};
{
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] ipq806x: ubnt,unifi-ac-hd: reorder eth0 and eth1
The Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301) has two Ethernet ports,
labeled MAIN and SECONDARY, connected to gmac2 and gmac1, respectively.
The standard probe order results in gmac1/SECONDARY being eth0 and
gmac2/MAIN being eth1. This does not match the stock firmware, is
contrary to user expectation, causes the wrong (high) MAC address to be
used in a bridged configuration (the default for this device), and makes
the gmac2/MAIN port unusable in the preinit environment (such as for
failsafe). Until a recent patch, gmac1/SECONDARY (eth0) was not even
usable.
This reorders the ports so that gmac2/MAIN is eth0, and the now-working
gmac1/SECONDARY is eth1. eth0 has the low MAC address and eth1 has the
high; when bridged, the bridge takes on the correct low MAC address.
This matches the stock firmware. The MAIN port is usable for failsafe
during preinit.
This device does not have a switch on board, so there's no possibility
to remap ports via switch configuration. "ip link set $interface name"
is used instead, during preinit before networking is configured.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../ipq806x/base-files/lib/preinit/04_reorder_eth | 13 +
.../arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts | 4 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
diff --git a/target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
b/target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
new file mode 100644
index ..9f58473617dc
--- /dev/null
+++ b/target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
@@ -0,0 +1,13 @@
+. /lib/functions.sh
+
+preinit_reorder_eth() {
+ case $(board_name) in
+ ubnt,unifi-ac-hd)
+ ip link set eth0 name ethtmp
+ ip link set eth1 name eth0
+ ip link set ethtmp name eth1
+ ;;
+ esac
+}
+
+boot_hook_add preinit_main preinit_reorder_eth
diff --git
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
index 70c51b90f316..672be3ca2c97 100644
--- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
@@ -16,8 +16,8 @@
led-running = _dome_blue;
led-upgrade = _dome_blue;
mdio-gpio0 =
- ethernet0 =
- ethernet1 =
+ ethernet0 =
+ ethernet1 =
};
leds {
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/3] ipq806x: ubnt,unifi-ac-hd: fix Ethernet ports
The Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301) has two Ethernet ports, labeled MAIN and SECONDARY, connected to gmac2 and gmac1, respectively. A dwmac register misconfiguration (QSGMII PCS_ALL_CH_CTL) for gmac1/SECONDARY prevented that port from being usable in OpenWrt. This patch series: - correctly configures that register, - properly configures the on-board PHYs for both interfaces, and - reorders eth0 and eth1 so that gmac2/MAIN is eth0 and gmac1/SECONDARY is eth1. Mark Mentovai (3): ipq806x: dwmac: clear forced speed during probe ipq806x: ubnt,unifi-ac-hd: use on-board PHYs ipq806x: ubnt,unifi-ac-hd: reorder eth0 and eth1 .../base-files/lib/preinit/04_reorder_eth | 13 +++ .../arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts | 38 +-- ...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 33 3 files changed, 65 insertions(+), 19 deletions(-) create mode 100644 target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth create mode 100644 target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Regression: commit 2809d0000744 ("kernel: support FIT partition parser on mtdblock devices") breaks mtd-concat
On Mon, Apr 12, 2021 at 10:45:14PM +0800, DENG Qingfang wrote: > After the commit, devices with mtd-concat such as HC5962 no longer work. > Several "sysfs: cannot create duplicate filename '/devices/..." warnings > can be seen in kernel log. I'm working on it, currently preparing to reproduce this be also playing with mtd-concat. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v5 1/1] ltq-vdsl-app: extent dsl metrics with state_num and power_state_num
On 12/04/2021 12:37, Florian Eckert wrote:
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit adds the missing information.
For this the internal values are mapped to numbers.
* additional JSON output for state_num:
"state_num":
Since not all values are meaningful only the following values are
implemented, this can be extended if the future.
* LSTATE_MAP_EXCEPTION
* LSTATE_MAP_IDLE
* LSTATE_MAP_SILENT
* LSTATE_MAP_HANDSHAKE
* LSTATE_MAP_FULL_INIT
* LSTATE_MAP_SHOWTIME_NO_SYNC
* LSTATE_MAP_SHOWTIME_TC_SYNC
* LSTATE_MAP_RESYNC
* LSTATE_MAP_NOT_INITIALIZED
* additinal JSON output for power_level:
"power_state_num": ,
Since there are not so many here, all are mapped.
* PSTATE_MAP_NA,
* PSTATE_MAP_L0,
* PSTATE_MAP_L1,
* PSTATE_MAP_L2,
* PSTATE_MAP_L3,
Signed-off-by: Florian Eckert
One note below, but in any case, LGTM, so:
Reviewed-by: Andre Heider
---
v5:
After a discussion off the mailing list with Andre Heider, this is now
the favored solution. All other versions have been marked in the patchwork
as superseded.
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 72 +++
1 file changed, 58 insertions(+), 14 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 52b2be20e1..dafa45f77c 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -34,6 +34,12 @@
str = text; \
break;
+#define STR_CASE_MAP(id, text, number) \
+ case id: \
+ str = text; \
+ map = number; \
+ break;
+
#define IOCTL(type, request) \
type out; \
memset(, 0, sizeof(type)); \
@@ -99,6 +105,34 @@ typedef enum {
PROFILE_35B,
} profile_t;
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ LSTATE_MAP_UNKNOWN = 0,
+ LSTATE_MAP_EXCEPTION,
+ LSTATE_MAP_IDLE,
+ LSTATE_MAP_SILENT,
+ LSTATE_MAP_HANDSHAKE,
+ LSTATE_MAP_FULL_INIT,
+ LSTATE_MAP_SHOWTIME_NO_SYNC,
+ LSTATE_MAP_SHOWTIME_TC_SYNC,
+ LSTATE_MAP_RESYNC,
+ LSTATE_MAP_NOT_INITIALIZED,
Except for the last entry, the order matches lantiq's DSL_LineState_t.
Doesn't really matter as long as we don't change these values, but was
there a reason for that?
+};
+
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ PSTATE_MAP_UNKNOWN = -2,
+ PSTATE_MAP_NA,
+ PSTATE_MAP_L0,
+ PSTATE_MAP_L1,
+ PSTATE_MAP_L2,
+ PSTATE_MAP_L3,
+};
+
static DSL_CPE_ThreadCtrl_t thread;
static struct ubus_context *ctx;
static struct blob_buf b;
@@ -306,32 +340,33 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ int map = LSTATE_MAP_UNKNOWN;
const char *str;
switch (out.data.nLineState) {
- STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
- STR_CASE(DSL_LINESTATE_EXCEPTION, "Exception")
+ STR_CASE_MAP(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized",
LSTATE_MAP_NOT_INITIALIZED)
+ STR_CASE_MAP(DSL_LINESTATE_EXCEPTION, "Exception", LSTATE_MAP_EXCEPTION)
STR_CASE(DSL_LINESTATE_NOT_UPDATED, "Not updated")
STR_CASE(DSL_LINESTATE_IDLE_REQUEST, "Idle request")
- STR_CASE(DSL_LINESTATE_IDLE, "Idle")
+ STR_CASE_MAP(DSL_LINESTATE_IDLE, "Idle", LSTATE_MAP_IDLE)
STR_CASE(DSL_LINESTATE_SILENT_REQUEST, "Silent request")
- STR_CASE(DSL_LINESTATE_SILENT, "Silent")
- STR_CASE(DSL_LINESTATE_HANDSHAKE, "Handshake")
+ STR_CASE_MAP(DSL_LINESTATE_SILENT, "Silent", LSTATE_MAP_SILENT)
+ STR_CASE_MAP(DSL_LINESTATE_HANDSHAKE, "Handshake", LSTATE_MAP_HANDSHAKE)
STR_CASE(DSL_LINESTATE_BONDING_CLR, "Bonding CLR")
- STR_CASE(DSL_LINESTATE_FULL_INIT, "Full init")
+ STR_CASE_MAP(DSL_LINESTATE_FULL_INIT, "Full init", LSTATE_MAP_FULL_INIT)
STR_CASE(DSL_LINESTATE_SHORT_INIT_ENTRY, "Short init entry")
STR_CASE(DSL_LINESTATE_DISCOVERY, "Discovery")
STR_CASE(DSL_LINESTATE_TRAINING, "Training")
STR_CASE(DSL_LINESTATE_ANALYSIS, "Analysis")
STR_CASE(DSL_LINESTATE_EXCHANGE, "Exchange")
- STR_CASE(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync")
- STR_CASE(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer sync")
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync", LSTATE_MAP_SHOWTIME_NO_SYNC)
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer
sync", LSTATE_MAP_SHOWTIME_TC_SYNC)
STR_CASE(DSL_LINESTATE_FASTRETRAIN, "Fastretrain")
Re: [PATCH 2/3] realtek: sort the port list numerically
Sander Vanheule writes:
> ls has the -v flag for numerical ("version") sorting:
> # ls
> lan0 lan1 lan10 lan2
> # ls -v
> lan0 lan1 lan2 lan10
Thanks. Was staring at the limited functionality of the busybox sort
app, but didn't think to look at the ls app...
Your variant looks much better.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] realtek: sort the port list numerically
Hi Bjørn,
On Mon, 2021-04-12 at 14:27 +0200, Bjørn Mork wrote:
> Mac adresses are assigned in the order given by the port list. The
> interfaces are also brought up in this order. This target supports
> devices with up to 52 ports. Sorting these alphabetically is very
> confusing, and assigning mac addresses in alphabetic order does not
> match stock firmware behaviour.
>
> There are probably better ways to do the numrical sorting, but this
> was what I came up with...
>
ls has the -v flag for numerical ("version") sorting:
# ls
lan0 lan1 lan10 lan2
# ls -v
lan0 lan1 lan2 lan10
> Signed-off-by: Bjørn Mork
> ---
> target/linux/realtek/base-files/etc/board.d/02_network | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
> b/target/linux/realtek/base-files/etc/board.d/02_network
> index 44f1f0a7a5c1..06293174b0df 100644
> --- a/target/linux/realtek/base-files/etc/board.d/02_network
> +++ b/target/linux/realtek/base-files/etc/board.d/02_network
> @@ -17,10 +17,7 @@ ucidef_set_poe() {
> board=$(board_name)
> board_config_update
>
> -lan_list=""
> -for lan in /sys/class/net/lan*; do
> - lan_list="$lan_list $(basename $lan)"
> -done
> +lan_list=$(for lan in /sys/class/net/lan*; do echo
> "${lan#/sys/class/net/lan}"; done|sort -n|sed -e 's/^/lan/'|xargs)
So (unless my little test was bad) this can be shortened to:
lan_list="$(ls -1 -v /sys/class/net/lan* | xargs -n1
basename)"
Best,
Sander
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Regression: commit 2809d0000744 ("kernel: support FIT partition parser on mtdblock devices") breaks mtd-concat
After the commit, devices with mtd-concat such as HC5962 no longer work. Several "sysfs: cannot create duplicate filename '/devices/..." warnings can be seen in kernel log. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Incomplete Module.symvers file in some SDKs
On Mon, Apr 12, 2021 at 01:37:59PM +0200, Sebastian Kemper wrote:
> What set this off was commit 5ed1e5140a80558ab47fd70410ae3242bed5becf
> ("build: build kernel image before building modules/packages"). Before
> this commit the make target would always include "modules", resulting in
> a MODPOST and a complete Module.symvers file. Since this commit a
> MODPOST of the kernel modules is not guaranteed, which may result in a
> broken SDK.
>
> I think that the first line that the commit changed was probably enough.
> Adding "modules" back to the other two lines will probably fix this
> problem without causing any headache. Probably a comment should be added
> to make people aware that "modules" is there for a reason.
I tried this:
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 4b0b136a03..1b3b4497a2 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -147,12 +147,17 @@ define Kernel/CopyImage
}
endef
+# Always add "modules" so a proper Module.symvers file is written that
+# also contains symbols from the kernel modules. Without these symbols
+# external packages that depend on exported symbols from kernel modules
+# will fail to build.
define Kernel/CompileImage/Default
rm -f $(TARGET_DIR)/init
- +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all)
+ +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all) modules
$(call Kernel/CopyImage)
endef
+# Here as well, always add "modules", see comment above.
ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
define Kernel/CompileImage/Initramfs
$(call Kernel/Configure/Initramfs)
@@ -173,7 +178,7 @@ endif
# ?$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZ4),)
$(if
$(CONFIG_TARGET_INITRAMFS_COMPRESSION_ZSTD),$(STAGING_DIR_HOST)/bin/zstd -T0 -f
-o $(KERNEL_BUILD_DIR)/initrd.cpio.zstd $(KERNEL_BUILD_DIR)/initrd.cpio)
endif
- +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all)
+ +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all) modules
$(call Kernel/CopyImage,-initramfs)
endef
else
With this change a "make -j2 V=s" resulted in a proper Module.symvers file.
Kind regards,
Sebastian
>
> I checked openwrt-21.02, but the commit in question was not applied
> there, so 21.02 is fine.
>
> Any thoughts?
>
> Kind regards,
> Sebastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uci] cli: add option for changing save path
From: Rafał Miłecki
Save path is a directory where config change (delta) files are stored.
Having a custom individual save dir can be used to prevent two (or more)
"uci" cli callers (e.g. bash scripts) from commiting each other changes.
In the following example:
App0App1
uci set system.@system[0].timezone=UTC
uci set
system.@system[0].hostname=OpenWrt
uci commit system
App1 would unintentionally commit changes made by App0. This can be
avoided by at least 1 "uci" cli user specifying a custom -t option.
Signed-off-by: Rafał Miłecki
---
cli.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cli.c b/cli.c
index 267437d..2fce39d 100644
--- a/cli.c
+++ b/cli.c
@@ -167,6 +167,7 @@ static void uci_usage(void)
"\t-N don't name unnamed sections\n"
"\t-p add a search path for config change files\n"
"\t-P add a search path for config change files and use
as default\n"
+ "\t-t set save path for config change files\n"
"\t-q quiet mode (don't print error messages)\n"
"\t-s force strict mode (stop on parser errors,
default)\n"
"\t-S disable strict mode\n"
@@ -706,7 +707,7 @@ int main(int argc, char **argv)
return 1;
}
- while((c = getopt(argc, argv, "c:d:f:LmnNp:P:sSqX")) != -1) {
+ while((c = getopt(argc, argv, "c:d:f:LmnNp:P:qsSt:X")) != -1) {
switch(c) {
case 'c':
uci_set_confdir(ctx, optarg);
@@ -754,6 +755,9 @@ int main(int argc, char **argv)
case 'q':
flags |= CLI_FLAG_QUIET;
break;
+ case 't':
+ uci_set_savedir(ctx, optarg);
+ break;
case 'X':
flags &= ~CLI_FLAG_SHOW_EXT;
break;
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/3] realtek: add rtl83xx-poe for GS1900-8HP & GS1900-10HP
Stijn Segers writes: > Add the rtl83xx-poe package to the device profiles for the > ZyXEL PoE switches that are currently supported: > - GS1900-10HP > - GS1900-8HP v1 > - GS1900-8HP v2 > > Signed-off-by: Stijn Segers > --- > This patch depends on the rtl83xx-poe package sitting in Patchwork: > https://patchwork.ozlabs.org/project/openwrt/list/?series=233826 Wondering a bit about the status here? Did I miss some change request or is there something else wrong? This package is required to use the PoE feature of the supported switches. Releasing 21.02 without it will probably result in frustrated users looking for a way to use a feature which used to work before they upgraded to OpenWrt. We can easily make it work by default with the rtl83xx-poe package and Stijn's patch. The package works very well, and no one has yet made any alternative implementation in other languages or whatver, as far as I know. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] realtek: revert to "standard" management configuration
This has my full support, even as a developer I had trouble getting Realtek devices to work in the default configuration. For OpenWRT users it is very confusing that these devices do not have a standard setup and the user first has to learn about VLANs to make use of the devices. Birger On 12.04.21 14:27, Bjørn Mork wrote: > The default management interface should be easy to find for users > doing "blind" installations without console access. There are > already multiple examples in the forum of advanced early adopters > having problems locating the management interface after installing > OpenWrt. > > Requiring tagged VLAN configration to access the initial management > interface creates unnecessary hassle at best. Errors on the other > end are close to impossible to debug without console access, even > for advanced users. Less advanced users might have problems with > the concept of VLAN tagging. > > Limiting management access to a single arbitrary port among up to > 52 possible LAN ports makes this even more difficult, for no > reason at all. Users might have reasons to use a different port > for management. And they might even have difficulties using the > OpenWrt selected one. The port might be the wrong type for their > management link (e.g copper instead of fibre). Or they might > depend on PoE power from a device which they can't reconfigure. > > User expectations will be based on > - OpenWrt defaults for other devices > - stock firmware default for the device in question > - common default behaviour of similar devices > > All 3 cases point to a static IP address accessible on the native > VLAN of any LAN port. A switch does not have any WAN port. All > ports are LAN ports. > > This changes the default network configuration in line with these > expectations. > > Cc: John Crispin > Signed-off-by: Bjørn Mork > --- > .../realtek/base-files/etc/board.d/02_network | 14 +- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/target/linux/realtek/base-files/etc/board.d/02_network > b/target/linux/realtek/base-files/etc/board.d/02_network > index 1e199db5897f..44f1f0a7a5c1 100644 > --- a/target/linux/realtek/base-files/etc/board.d/02_network > +++ b/target/linux/realtek/base-files/etc/board.d/02_network > @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do > lan_list="$lan_list $(basename $lan)" > done > ucidef_set_bridge_device switch > -ucidef_set_interface_wan "$lan_list" > -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100 > +ucidef_set_interface_lan "$lan_list" > > lan_mac="" > -wan_mac="" > label_mac="" > case $board in > *) > - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) > + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) > label_mac=$lan_mac > ;; > esac > > -lan_mac=$(macaddr_setbit_la $wan_mac) > - > ucidef_set_interface_macaddr "lan" $lan_mac > -ucidef_set_interface_macaddr "wan" $wan_mac > -ucidef_set_bridge_mac "$wan_mac" > -ucidef_set_network_device_mac eth0 $wan_mac > +ucidef_set_bridge_mac "$lan_mac" > +ucidef_set_network_device_mac eth0 $lan_mac > for lan in $lan_list; do > ucidef_set_network_device_mac $lan $lan_mac > + lan_mac=$(macaddr_setbit_la $lan_mac) > lan_mac=$(macaddr_add $lan_mac 1) > done > [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] realtek: sort the port list numerically
Mac adresses are assigned in the order given by the port list. The
interfaces are also brought up in this order. This target supports
devices with up to 52 ports. Sorting these alphabetically is very
confusing, and assigning mac addresses in alphabetic order does not
match stock firmware behaviour.
There are probably better ways to do the numrical sorting, but this
was what I came up with...
Signed-off-by: Bjørn Mork
---
target/linux/realtek/base-files/etc/board.d/02_network | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
b/target/linux/realtek/base-files/etc/board.d/02_network
index 44f1f0a7a5c1..06293174b0df 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -17,10 +17,7 @@ ucidef_set_poe() {
board=$(board_name)
board_config_update
-lan_list=""
-for lan in /sys/class/net/lan*; do
- lan_list="$lan_list $(basename $lan)"
-done
+lan_list=$(for lan in /sys/class/net/lan*; do echo
"${lan#/sys/class/net/lan}"; done|sort -n|sed -e 's/^/lan/'|xargs)
ucidef_set_bridge_device switch
ucidef_set_interface_lan "$lan_list"
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/3] realtek: fix default network configuration
The default network configuration for the realtek target has already given several users serious problems. Being able to install OpenWrt without having console access is important to many users. Not everyone is prepared to solder a header. Being able to locate the management interface after the upgrade is obviously a requirement. This should be as easy as possible, and at most require static IP configuration on the other end. Requiring one specific LAN port is not helpful. Requiring VLAN tagging for initial management is more than just unhelfpul. It is likely to block many users from completin the installation, considering their device "bricked" by OpenWrt. IMHO, the default should be aligned with other OpenWrt targets and stock firmware before the initial release of this target. I therefore request that this patchset is backported to 21.02. Bjørn Mork (3): realtek: revert to "standard" management configuration realtek: sort the port list numerically realtek: use full range of assigned MAC addresses .../realtek/base-files/etc/board.d/02_network | 24 --- 1 file changed, 10 insertions(+), 14 deletions(-) -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] realtek: revert to "standard" management configuration
The default management interface should be easy to find for users doing "blind" installations without console access. There are already multiple examples in the forum of advanced early adopters having problems locating the management interface after installing OpenWrt. Requiring tagged VLAN configration to access the initial management interface creates unnecessary hassle at best. Errors on the other end are close to impossible to debug without console access, even for advanced users. Less advanced users might have problems with the concept of VLAN tagging. Limiting management access to a single arbitrary port among up to 52 possible LAN ports makes this even more difficult, for no reason at all. Users might have reasons to use a different port for management. And they might even have difficulties using the OpenWrt selected one. The port might be the wrong type for their management link (e.g copper instead of fibre). Or they might depend on PoE power from a device which they can't reconfigure. User expectations will be based on - OpenWrt defaults for other devices - stock firmware default for the device in question - common default behaviour of similar devices All 3 cases point to a static IP address accessible on the native VLAN of any LAN port. A switch does not have any WAN port. All ports are LAN ports. This changes the default network configuration in line with these expectations. Cc: John Crispin Signed-off-by: Bjørn Mork --- .../realtek/base-files/etc/board.d/02_network | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index 1e199db5897f..44f1f0a7a5c1 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do lan_list="$lan_list $(basename $lan)" done ucidef_set_bridge_device switch -ucidef_set_interface_wan "$lan_list" -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100 +ucidef_set_interface_lan "$lan_list" lan_mac="" -wan_mac="" label_mac="" case $board in *) - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) label_mac=$lan_mac ;; esac -lan_mac=$(macaddr_setbit_la $wan_mac) - ucidef_set_interface_macaddr "lan" $lan_mac -ucidef_set_interface_macaddr "wan" $wan_mac -ucidef_set_bridge_mac "$wan_mac" -ucidef_set_network_device_mac eth0 $wan_mac +ucidef_set_bridge_mac "$lan_mac" +ucidef_set_network_device_mac eth0 $lan_mac for lan in $lan_list; do ucidef_set_network_device_mac $lan $lan_mac + lan_mac=$(macaddr_setbit_la $lan_mac) lan_mac=$(macaddr_add $lan_mac 1) done [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] realtek: use full range of assigned MAC addresses
Some devices are assigned globally unique MAC addresses for all
ports. These are stored by U-Boot in the second U-Boot enviroment
("sysinfo") as a range of start and end address.
Use the full range if provided.
Signed-off-by: Bjørn Mork
---
target/linux/realtek/base-files/etc/board.d/02_network | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
b/target/linux/realtek/base-files/etc/board.d/02_network
index 06293174b0df..f4daeed93d86 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -22,11 +22,14 @@ ucidef_set_bridge_device switch
ucidef_set_interface_lan "$lan_list"
lan_mac=""
+lan_mac_end=""
label_mac=""
case $board in
*)
- lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
- label_mac=$lan_mac
+ lan_mac=$(mtd_get_mac_ascii u-boot-env2 mac_start)
+ lan_mac_end=$(mtd_get_mac_ascii u-boot-env2 mac_end)
+ label_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+ [ -z "$lan_mac" ] && lan_mac=$label_mac
;;
esac
@@ -35,7 +38,7 @@ ucidef_set_bridge_mac "$lan_mac"
ucidef_set_network_device_mac eth0 $lan_mac
for lan in $lan_list; do
ucidef_set_network_device_mac $lan $lan_mac
- lan_mac=$(macaddr_setbit_la $lan_mac)
+ [ -z "$lan_mac_end" ] || [ "$lan_mac" == "$lan_mac_end" ] &&
lan_mac=$(macaddr_setbit_la $lan_mac)
lan_mac=$(macaddr_add $lan_mac 1)
done
[ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Incomplete Module.symvers file in some SDKs
Hi all,
Some SDKs have a Module.symvers file in
build_dir/target-*/linux-*/linux-5.4.*/ that is missing exported symbols
from kernel modules:
openwrt-sdk-mpc85xx-p1010_gcc-8.4.0_musl.Linux-x86_64
openwrt-sdk-apm821xx-nand_gcc-8.4.0_musl.Linux-x86_64
openwrt-sdk-kirkwood_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-oxnas-ox820_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-mvebu-cortexa9_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-mediatek-mt7629_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-armvirt-32_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-armvirt-64_gcc-8.4.0_musl.Linux-x86_64
Any external kernel module package that depends on any exported symbol
from a linux kernel module will fail to build in these SDKs. For
instance the dahdi-linux package depends on symbols from the kernel's
"echo" module fails:
ERROR: "oslec_create"
[/builder/shared-workdir/build/sdk/build_dir/target-arm_mpcore_musl_eabi/linux-oxnas_ox820/dahdi-linux-3.1.0/drivers/dahdi/dahdi_echocan_oslec.ko]
undefined!
ERROR: "oslec_free"
[/builder/shared-workdir/build/sdk/build_dir/target-arm_mpcore_musl_eabi/linux-oxnas_ox820/dahdi-linux-3.1.0/drivers/dahdi/dahdi_echocan_oslec.ko]
undefined!
This problem is visible on the build bots (some packages are failing to
build) as well as in the CIs used for the external feeds (Github Actions).
The reason for the incomplete Module.symvers file is that when either
Kernel/CompileImage/Default or Kernel/CompileImage/Initramfs (see
include/kernel-defaults.mk) is called and KERNELNAME is given, the make
target may be of the sort which does not prompt the Linux kernel to
MODPOST the modules. For instance when building the
openwrt-sdk-ath79-generic_gcc-8.4.0_musl.Linux-x86_64 sdk KERNELNAME is
not set and the resulting call is this one:
make -C
/home/sk/tmp/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-5.4.109
all
This is visible in the output:
MODPOST 59 modules
The Module.symvers file is complete.
Using the openwrt-sdk-apm821xx-nand_gcc-8.4.0_musl.Linux-x86_64 sdk on
the other hand results in this call (KERNELNAME is uImage).
make -C
/home/sk/tmp/openwrt/build_dir/target-powerpc_464fp_musl/linux-apm821xx_nand/linux-5.4.98
uImage
No MODPOST occurs for the Linux kernel modules. The resulting
Module.symvers file is incomplete.
What set this off was commit 5ed1e5140a80558ab47fd70410ae3242bed5becf
("build: build kernel image before building modules/packages"). Before
this commit the make target would always include "modules", resulting in
a MODPOST and a complete Module.symvers file. Since this commit a
MODPOST of the kernel modules is not guaranteed, which may result in a
broken SDK.
I think that the first line that the commit changed was probably enough.
Adding "modules" back to the other two lines will probably fix this
problem without causing any headache. Probably a comment should be added
to make people aware that "modules" is there for a reason.
I checked openwrt-21.02, but the commit in question was not applied
there, so 21.02 is fine.
Any thoughts?
Kind regards,
Sebastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v5 1/1] ltq-vdsl-app: extent dsl metrics with state_num and power_state_num
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit adds the missing information.
For this the internal values are mapped to numbers.
* additional JSON output for state_num:
"state_num":
Since not all values are meaningful only the following values are
implemented, this can be extended if the future.
* LSTATE_MAP_EXCEPTION
* LSTATE_MAP_IDLE
* LSTATE_MAP_SILENT
* LSTATE_MAP_HANDSHAKE
* LSTATE_MAP_FULL_INIT
* LSTATE_MAP_SHOWTIME_NO_SYNC
* LSTATE_MAP_SHOWTIME_TC_SYNC
* LSTATE_MAP_RESYNC
* LSTATE_MAP_NOT_INITIALIZED
* additinal JSON output for power_level:
"power_state_num": ,
Since there are not so many here, all are mapped.
* PSTATE_MAP_NA,
* PSTATE_MAP_L0,
* PSTATE_MAP_L1,
* PSTATE_MAP_L2,
* PSTATE_MAP_L3,
Signed-off-by: Florian Eckert
---
v5:
After a discussion off the mailing list with Andre Heider, this is now
the favored solution. All other versions have been marked in the patchwork
as superseded.
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 72 +++
1 file changed, 58 insertions(+), 14 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 52b2be20e1..dafa45f77c 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -34,6 +34,12 @@
str = text; \
break;
+#define STR_CASE_MAP(id, text, number) \
+ case id: \
+ str = text; \
+ map = number; \
+ break;
+
#define IOCTL(type, request) \
type out; \
memset(, 0, sizeof(type)); \
@@ -99,6 +105,34 @@ typedef enum {
PROFILE_35B,
} profile_t;
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ LSTATE_MAP_UNKNOWN = 0,
+ LSTATE_MAP_EXCEPTION,
+ LSTATE_MAP_IDLE,
+ LSTATE_MAP_SILENT,
+ LSTATE_MAP_HANDSHAKE,
+ LSTATE_MAP_FULL_INIT,
+ LSTATE_MAP_SHOWTIME_NO_SYNC,
+ LSTATE_MAP_SHOWTIME_TC_SYNC,
+ LSTATE_MAP_RESYNC,
+ LSTATE_MAP_NOT_INITIALIZED,
+};
+
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ PSTATE_MAP_UNKNOWN = -2,
+ PSTATE_MAP_NA,
+ PSTATE_MAP_L0,
+ PSTATE_MAP_L1,
+ PSTATE_MAP_L2,
+ PSTATE_MAP_L3,
+};
+
static DSL_CPE_ThreadCtrl_t thread;
static struct ubus_context *ctx;
static struct blob_buf b;
@@ -306,32 +340,33 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ int map = LSTATE_MAP_UNKNOWN;
const char *str;
switch (out.data.nLineState) {
- STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
- STR_CASE(DSL_LINESTATE_EXCEPTION, "Exception")
+ STR_CASE_MAP(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized",
LSTATE_MAP_NOT_INITIALIZED)
+ STR_CASE_MAP(DSL_LINESTATE_EXCEPTION, "Exception", LSTATE_MAP_EXCEPTION)
STR_CASE(DSL_LINESTATE_NOT_UPDATED, "Not updated")
STR_CASE(DSL_LINESTATE_IDLE_REQUEST, "Idle request")
- STR_CASE(DSL_LINESTATE_IDLE, "Idle")
+ STR_CASE_MAP(DSL_LINESTATE_IDLE, "Idle", LSTATE_MAP_IDLE)
STR_CASE(DSL_LINESTATE_SILENT_REQUEST, "Silent request")
- STR_CASE(DSL_LINESTATE_SILENT, "Silent")
- STR_CASE(DSL_LINESTATE_HANDSHAKE, "Handshake")
+ STR_CASE_MAP(DSL_LINESTATE_SILENT, "Silent", LSTATE_MAP_SILENT)
+ STR_CASE_MAP(DSL_LINESTATE_HANDSHAKE, "Handshake", LSTATE_MAP_HANDSHAKE)
STR_CASE(DSL_LINESTATE_BONDING_CLR, "Bonding CLR")
- STR_CASE(DSL_LINESTATE_FULL_INIT, "Full init")
+ STR_CASE_MAP(DSL_LINESTATE_FULL_INIT, "Full init", LSTATE_MAP_FULL_INIT)
STR_CASE(DSL_LINESTATE_SHORT_INIT_ENTRY, "Short init entry")
STR_CASE(DSL_LINESTATE_DISCOVERY, "Discovery")
STR_CASE(DSL_LINESTATE_TRAINING, "Training")
STR_CASE(DSL_LINESTATE_ANALYSIS, "Analysis")
STR_CASE(DSL_LINESTATE_EXCHANGE, "Exchange")
- STR_CASE(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync")
- STR_CASE(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer sync")
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync", LSTATE_MAP_SHOWTIME_NO_SYNC)
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer
sync", LSTATE_MAP_SHOWTIME_TC_SYNC)
STR_CASE(DSL_LINESTATE_FASTRETRAIN, "Fastretrain")
STR_CASE(DSL_LINESTATE_LOWPOWER_L2, "Lowpower L2")
STR_CASE(DSL_LINESTATE_LOOPDIAGNOSTIC_ACTIVE, "Loopdiagnostic active")
STR_CASE(DSL_LINESTATE_LOOPDIAGNOSTIC_DATA_EXCHANGE, "Loopdiagnostic
data exchange")
STR_CASE(DSL_LINESTATE_LOOPDIAGNOSTIC_DATA_REQUEST, "Loopdiagnostic
data request")
Re: lantiq: upstream Linux efforts
On 2021-04-12 00:24, Hauke Mehrtens wrote: Hi, On 4/11/21 7:51 PM, Martin Blumenstingl wrote: Hello everyone, you are included in this email because you have previously worked on patches for the Lantiq SoCs upstream. In the past updating the kernel version for the lantiq target in OpenWrt was an unpleasant task. There are many out-of-tree patches and some of them are breaking with newer kernel versions. To improve the situation I suggest using Rafał Miłecki's approach also for the lantiq target: He is submitting patches upstream, then backporting them to OpenWrt. That way backports to the -stable tree are for free. Other patches can simply be dropped during the next major kernel version update (instead of having to rework them every time...). I like this approach. I also like this approach. This approach however only works when there are active contributors upstream. It brings the benefit of upstream code-reviews though - which in my experience improves the quality of the resulting code. I think there's quite a bit of work involved. If you take for example the patch with the configurability of the LEDs on the phys: Hauke had already started one or more attempts to bring this upstream [1], but this was "rejected" with the reason that this belongs in the LED subsystem. Now I found an interesting solution on the mailing list, which implements this function as hw offloading of the netdev trigger. [2] @Hauke: what do you think about this? Furthermore there are some patches for the target lantiq, which unfortunately don't contain any description and so we have to work out the deeper sense or necessity of this patch again. [1] https://www.spinics.net/lists/netdev/msg380196.html [2] https://www.spinics.net/lists/linux-leds/msg17241.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
