Re: [PATCH] ramips: gpio-ralink: use ngpios, not ralink,num-gpios
Hi Ilya, On Mon, 2021-04-05 at 22:53 -0700, Ilya Lipnitskiy wrote: > DTS properties that match *-gpios are treated specially. > > Use ngpios instead, as most GPIO drivers upstream do. > > Fixes 5.10 DTS errors such as: > OF: /palmbus@30/gpio@600: could not find phandle > > Fixes DTC warnings such as: > Warning (gpios_property): /palmbus@30/gpio@600:ralink,num- > gpios: > Could not get phandle node for (cell 0) > > Signed-off-by: Ilya Lipnitskiy > Cc: Daniel Golle > --- > [...] > diff --git a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink- > add-gpio-driver-for-ralink-SoC.patch b/target/linux/ramips/patches- > 5.10/802-GPIO-MIPS-ralink-add-gpio-driver-for-ralink-SoC.patch > index 141d29f9401c..c173336924d2 100644 > --- a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > driver-for-ralink-SoC.patch > +++ b/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > driver-for-ralink-SoC.patch > @@ -357,7 +357,7 @@ Cc: linux-g...@vger.kernel.org > + return -EINVAL; > + } > + > -+ ngpio = of_get_property(np, "ralink,num-gpios", NULL); > ++ ngpio = of_get_property(np, "ngpios", NULL); I guess you just went for the smallest patch that fixes the errors and warnings? Otherwise, if you use of_property_read_u32() here, you don't have to deal with be32_to_cpu() later on. Based on my recent experience with linux-gpio, I think more things would need to change too, for the driver to be upstream-compatible. But I don't know what your plans are with this driver, so maybe this quick fix is sufficient for OpenWrt. Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
Hauke Mehrtens kirjoitti 7.4.2021 klo 1.29: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. ... In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. Option 2 of merging the LuCI DSA changes and then making the first 21.02-rc sounds good to me. Also the option 1 of doing the rc now would likely be ok, as the only a few targets actually use DSA, so the absence of LuCI support for DSA does not concern that many users. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Like with previous releases, the developers interest mainly stays on the master, and not much happens in the new release branch... It is now 50 days since the 21.02 was branched in February, so a high time to get the rc out. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
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 --- On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: > I found some serious regressions in the luci device config support. > not sure yet how long it'll take to sort out. The netifd uci config > grew so complex that it'll take a while to try all cases > * changing interface settings after previously enabling certain > options results in a brick > * wireless networks with custom ifnames are improperly bridged > * option ipv6 for ppp based protocols is broken because it clashes > with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. Will Wifi 6 support be added to the interface? We have some support for a couple of AX routers, so it would be nice if they can work without manually tweaking things. The underlying structure seems to support it already: https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
On 2021-04-07 12:01, Hannu Nyman wrote: Hauke Mehrtens kirjoitti 7.4.2021 klo 1.29: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. ... In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. Option 2 of merging the LuCI DSA changes and then making the first 21.02-rc sounds good to me. I would also prefer option 2, as I would like to switch to DSA with 21.02. Also the option 1 of doing the rc now would likely be ok, as the only a few targets actually use DSA, so the absence of LuCI support for DSA does not concern that many users. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Like with previous releases, the developers interest mainly stays on the master, and not much happens in the new release branch... It is now 50 days since the 21.02 was branched in February, so a high time to get the rc out. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
On Tue, Apr 6, 2021 at 7:30 PM Hauke Mehrtens wrote: > > Hi, > > How do we want to go forward with OpenWrt 21.02-rc1? > > * I think the base system is ok. > * The http (original wolfssl) problem reported by jow is fixed > * LuCI in the 21.02 branch still misses DSA support, this was merged > into master some time ago as far as I understood. Hi I would suggest to have some commits cherry-picked to 21.02: 920eaab1d8 kernel: DSA roaming fix for Marvell mv88e6xxx af22991e03 build: make sure asm gets built with -DPIC I consider the first commit critical: without it clients get disconnected for 5 minutes when roaming from an affected AP (Omnia, WRT3200, among others) WLAN port to a LAN port (roaming between LAN-connected APs, for example). The second one is needed to build strongswan for x86_64 [1]. The support commits have already been pushed to the 21.02 branch of the packages feed. Eneas [1] https://downloads.openwrt.org/releases/faillogs-21.02/x86_64/packages/strongswan/compile.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
On 07.04.21 12:16, Bas Mevissen via openwrt-devel wrote: Will Wifi 6 support be added to the interface? We have some support for a couple of AX routers, so it would be nice if they can work without manually tweaking things. The underlying structure seems to support it already: https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533 I have a couple of patches pending that I will post the next few days that will make the primary HE features work on 21.02. I converged my home to 3xe8450 John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
On Tue, Apr 6, 2021 at 3:43 PM Hauke Mehrtens wrote: > > [snip] > > If there are some other bugs in the 21.02 branch which are fixed in > master, we can backport the fixed as long as they are not so big. If > there is something missing, just ask on the mainling list. > Hi! I have a oneliner fix for ZyXEL Keenetic Lite rev.B on the GitHub. [0] It would be an average LZMA ERROR 1 fix in the ramips target, but the device's support commit landed on 8 Jul 2020. [1] 21.02 would be it's first release, but it's already unusable due to the LZMA ERROR 1. Please land the fix on master and backport it to the 21.02 release! Thank you, Szabolcs [0]: https://github.com/openwrt/openwrt/pull/3834 [1]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4dc9ad4af8c921494d20b303b6772fc6b5af3a69 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 - realtek and mediatek targets
On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: I found some serious regressions in the luci device config support. not sure yet how long it'll take to sort out. The netifd uci config grew so complex that it'll take a while to try all cases * changing interface settings after previously enabling certain options results in a brick * wireless networks with custom ifnames are improperly bridged * option ipv6 for ppp based protocols is broken because it clashes with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke Hi, Do we want to keep the realtek and mediatek targets in the 21.02 branch and release or do we want to remove them link the ipq807x target? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 (backport request, WireGuard, DSA roaming, iproute2 5.11)
Re:WireGuard - fine by me. Thanks for doing that. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 (backport request, WireGuard, DSA roaming, iproute2 5.11)
On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: I found some serious regressions in the luci device config support. not sure yet how long it'll take to sort out. The netifd uci config grew so complex that it'll take a while to try all cases * changing interface settings after previously enabling certain options results in a brick * wireless networks with custom ifnames are improperly bridged * option ipv6 for ppp based protocols is broken because it clashes with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke Hi, There are requests for some pretty big changes to get merged into 21.02: Bring WireGuard in-tree for 21.02 #3960 https://github.com/openwrt/openwrt/pull/3960 Adding 63482 lines, mostly backported kernel patches. kernel: DSA roaming fix for Marvell mv88e6xxx https://git.openwrt.org/920eaab1d8179035d0ae1047e75cf9a50da6a6eb Adding 1180 lines of kernel patches build: make sure asm gets built with -DPIC https://git.openwrt.org/af22991e03cae55f96b06996df2ff16752cec5d5 iproute2: backport 5.11 update and improvements, related NLS fixes #4025 https://github.com/openwrt/openwrt/pull/4025 multiple patches for packages Are there any objections to backporting these changes? If no one complains I will merge them into 21.02 in on Friday. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 (backport request, WireGuard, DSA roaming, iproute2 5.11)
Hi Hauke, Op woensdag 7 april 2021 om 23u58 schreef Hauke Mehrtens : On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: I found some serious regressions in the luci device config support. not sure yet how long it'll take to sort out. The netifd uci config grew so complex that it'll take a while to try all cases * changing interface settings after previously enabling certain options results in a brick * wireless networks with custom ifnames are improperly bridged * option ipv6 for ppp based protocols is broken because it clashes with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke Hi, There are requests for some pretty big changes to get merged into 21.02: Bring WireGuard in-tree for 21.02 #3960 https://github.com/openwrt/openwrt/pull/3960 Adding 63482 lines, mostly backported kernel patches. kernel: DSA roaming fix for Marvell mv88e6xxx https://git.openwrt.org/920eaab1d8179035d0ae1047e75cf9a50da6a6eb Adding 1180 lines of kernel patches build: make sure asm gets built with -DPIC https://git.openwrt.org/af22991e03cae55f96b06996df2ff16752cec5d5 iproute2: backport 5.11 update and improvements, related NLS fixes #4025 https://github.com/openwrt/openwrt/pull/4025 multiple patches for packages Are there any objections to backporting these changes? If no one complains I will merge them into 21.02 in on Friday. Thanks for getting the RC going. I have been running the WireGuard PR on 21.02 for a few weeks now, no issues here. Same for the iproute2 PR but I have done no specific testing on it (just running pretty default configs on DSA devices). No complaints about that PR either. Cheers Stijn Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 - realtek and mediatek targets
Hi Hauke, Op woensdag 7 april 2021 om 22u27 schreef Hauke Mehrtens : On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: I found some serious regressions in the luci device config support. not sure yet how long it'll take to sort out. The netifd uci config grew so complex that it'll take a while to try all cases * changing interface settings after previously enabling certain options results in a brick * wireless networks with custom ifnames are improperly bridged * option ipv6 for ppp based protocols is broken because it clashes with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke Hi, Do we want to keep the realtek and mediatek targets in the 21.02 branch and release or do we want to remove them link the ipq807x target? A vote for keeping the realtek target here, I have three devices here in production. Very happy with them. The main catch I see with relegating the realtek target to master would be less uptake on the end user side (not everyone will want to run hardware that needs OpenWrt master), but I am unqualified to judge the code quality. All I can say is it runs nicely here (including PoE). Cheers Stijn Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: Activate FORTIFY_SOURCE for MIPS kernel 5.4
CONFIG_FORTIFY_SOURCE=y is already set in the generic kernel
configuration, but it is not working for MIPS on kernel 5.4, support for
MIPS was only added with kernel 5.5, other architectures like aarch64
support FORTIFY_SOURCE already since some time.
This patch adds support for FORTIFY_SOURCE to MIPS with kernel 5.4,
kernel 5.10 already supports this and needs no changes.
This backports one patch from kernel 5.5 and one fix from 5.8 to make
fortify source also work on our kernel 5.4.
The changes are not compatible with the
306-mips_mem_functions_performance.patch patch which was also removed
with kernel 5.10, probably because of the same problems. I think it is
not needed anyway as the compiler should automatically optimize the
calls to memset(), memcpy() and memmove() even when not explicitly
telling the compiler to use the build in variant.
Signed-off-by: Hauke Mehrtens
---
I would like to backport this to 21.02 too.
...-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch | 32 ++
...11-MIPS-Fix-exception-handler-memcpy.patch | 107 ++
.../301-mips_image_cmdline_hack.patch | 2 +-
...CPU_MIPS64-for-remaining-MIPS64-CPUs.patch | 2 +-
.../300-mips_expose_boot_raw.patch| 4 +-
.../306-mips_mem_functions_performance.patch | 106 -
6 files changed, 143 insertions(+), 110 deletions(-)
create mode 100644
target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
create mode 100644
target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
delete mode 100644
target/linux/generic/pending-5.4/306-mips_mem_functions_performance.patch
diff --git
a/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
new file mode 100644
index ..e02f10354376
--- /dev/null
+++
b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
@@ -0,0 +1,32 @@
+From a8d2bb0559b5fefa5173ff4e7496cc6250db2c8a Mon Sep 17 00:00:00 2001
+From: Dmitry Korotin
+Date: Thu, 12 Sep 2019 22:53:45 +
+Subject: [PATCH] mips: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE
+
+FORTIFY_SOURCE detects various overflows at compile and run time.
+(6974f0c4555e ("include/linux/string.h:
+add the option of fortified string.h functions)
+
+ARCH_HAS_FORTIFY_SOURCE means that the architecture can be built and
+run with CONFIG_FORTIFY_SOURCE.
+
+Since mips can be built and run with that flag,
+select ARCH_HAS_FORTIFY_SOURCE as default.
+
+Signed-off-by: Dmitry Korotin
+Signed-off-by: Paul Burton
+Cc: linux-m...@vger.kernel.org
+---
+ arch/mips/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/mips/Kconfig
b/arch/mips/Kconfig
+@@ -7,6 +7,7 @@ config MIPS
+ select ARCH_CLOCKSOURCE_DATA
+ select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
+ select ARCH_HAS_UBSAN_SANITIZE_ALL
++ select ARCH_HAS_FORTIFY_SOURCE
+ select ARCH_SUPPORTS_UPROBES
+ select ARCH_USE_BUILTIN_BSWAP
+ select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
diff --git
a/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
new file mode 100644
index ..5a6725c7a072
--- /dev/null
+++
b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
@@ -0,0 +1,107 @@
+From e01c91a360793298c9e1656a61faceff01487a43 Mon Sep 17 00:00:00 2001
+From: Ben Hutchings
+Date: Sat, 23 May 2020 23:50:34 +0800
+Subject: [PATCH] MIPS: Fix exception handler memcpy()
+
+The exception handler subroutines are declared as a single char, but
+when copied to the required addresses the copy length is 0x80.
+
+When range checks are enabled for memcpy() this results in a build
+failure, with error messages such as:
+
+In file included from arch/mips/mti-malta/malta-init.c:15:
+In function 'memcpy',
+inlined from 'mips_nmi_setup' at arch/mips/mti-malta/malta-init.c:98:2:
+include/linux/string.h:376:4: error: call to '__read_overflow2' declared with
attribute error: detected read beyond size of object passed as 2nd parameter
+ 376 |__read_overflow2();
+ |^~
+
+Change the declarations to use type char[].
+
+Signed-off-by: Ben Hutchings
+Signed-off-by: YunQiang Su
+Signed-off-by: Thomas Bogendoerfer
+---
+ arch/mips/loongson64/common/init.c | 4 ++--
+ arch/mips/mti-malta/malta-init.c | 8
+ arch/mips/pistachio/init.c | 8
+ 3 files changed, 10 insertions(+), 10 deletions(-)
+
+--- a/arch/mips/loongson64/common/init.c
b/arch/mips/loongson64/common/init.c
+@@ -18,10 +18,10 @@ unsigned long __maybe_unused _loongson_a
+ static void __init mips_nmi_setup(void)
+ {
+ void *base;
+- extern char except_vec_nmi;
++ extern char except_vec_nmi[];
+
+ base = (void *)(CAC_BASE + 0x380);
+- memcpy(
Re: [PATCH] kernel: Activate FORTIFY_SOURCE for MIPS kernel 5.4
On Wed, Apr 7, 2021 at 3:26 PM Hauke Mehrtens wrote:
>
> CONFIG_FORTIFY_SOURCE=y is already set in the generic kernel
> configuration, but it is not working for MIPS on kernel 5.4, support for
> MIPS was only added with kernel 5.5, other architectures like aarch64
> support FORTIFY_SOURCE already since some time.
>
> This patch adds support for FORTIFY_SOURCE to MIPS with kernel 5.4,
> kernel 5.10 already supports this and needs no changes.
>
> This backports one patch from kernel 5.5 and one fix from 5.8 to make
> fortify source also work on our kernel 5.4.
>
> The changes are not compatible with the
> 306-mips_mem_functions_performance.patch patch which was also removed
> with kernel 5.10, probably because of the same problems. I think it is
> not needed anyway as the compiler should automatically optimize the
> calls to memset(), memcpy() and memmove() even when not explicitly
> telling the compiler to use the build in variant.
>
> Signed-off-by: Hauke Mehrtens
Acked-by: Rosen Penev
> ---
>
> I would like to backport this to 21.02 too.
Seems good.
>
> ...-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch | 32 ++
> ...11-MIPS-Fix-exception-handler-memcpy.patch | 107 ++
> .../301-mips_image_cmdline_hack.patch | 2 +-
> ...CPU_MIPS64-for-remaining-MIPS64-CPUs.patch | 2 +-
> .../300-mips_expose_boot_raw.patch| 4 +-
> .../306-mips_mem_functions_performance.patch | 106 -
> 6 files changed, 143 insertions(+), 110 deletions(-)
> create mode 100644
> target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
> create mode 100644
> target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
> delete mode 100644
> target/linux/generic/pending-5.4/306-mips_mem_functions_performance.patch
>
> diff --git
> a/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
>
> b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
> new file mode 100644
> index ..e02f10354376
> --- /dev/null
> +++
> b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
> @@ -0,0 +1,32 @@
> +From a8d2bb0559b5fefa5173ff4e7496cc6250db2c8a Mon Sep 17 00:00:00 2001
> +From: Dmitry Korotin
> +Date: Thu, 12 Sep 2019 22:53:45 +
> +Subject: [PATCH] mips: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE
> +
> +FORTIFY_SOURCE detects various overflows at compile and run time.
> +(6974f0c4555e ("include/linux/string.h:
> +add the option of fortified string.h functions)
> +
> +ARCH_HAS_FORTIFY_SOURCE means that the architecture can be built and
> +run with CONFIG_FORTIFY_SOURCE.
> +
> +Since mips can be built and run with that flag,
> +select ARCH_HAS_FORTIFY_SOURCE as default.
> +
> +Signed-off-by: Dmitry Korotin
> +Signed-off-by: Paul Burton
> +Cc: linux-m...@vger.kernel.org
> +---
> + arch/mips/Kconfig | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +--- a/arch/mips/Kconfig
> b/arch/mips/Kconfig
> +@@ -7,6 +7,7 @@ config MIPS
> + select ARCH_CLOCKSOURCE_DATA
> + select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> + select ARCH_HAS_UBSAN_SANITIZE_ALL
> ++ select ARCH_HAS_FORTIFY_SOURCE
> + select ARCH_SUPPORTS_UPROBES
> + select ARCH_USE_BUILTIN_BSWAP
> + select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
> diff --git
> a/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
>
> b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
> new file mode 100644
> index ..5a6725c7a072
> --- /dev/null
> +++
> b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
> @@ -0,0 +1,107 @@
> +From e01c91a360793298c9e1656a61faceff01487a43 Mon Sep 17 00:00:00 2001
> +From: Ben Hutchings
> +Date: Sat, 23 May 2020 23:50:34 +0800
> +Subject: [PATCH] MIPS: Fix exception handler memcpy()
> +
> +The exception handler subroutines are declared as a single char, but
> +when copied to the required addresses the copy length is 0x80.
> +
> +When range checks are enabled for memcpy() this results in a build
> +failure, with error messages such as:
> +
> +In file included from arch/mips/mti-malta/malta-init.c:15:
> +In function 'memcpy',
> +inlined from 'mips_nmi_setup' at arch/mips/mti-malta/malta-init.c:98:2:
> +include/linux/string.h:376:4: error: call to '__read_overflow2' declared
> with attribute error: detected read beyond size of object passed as 2nd
> parameter
> + 376 |__read_overflow2();
> + |^~
> +
> +Change the declarations to use type char[].
> +
> +Signed-off-by: Ben Hutchings
> +Signed-off-by: YunQiang Su
> +Signed-off-by: Thomas Bogendoerfer
> +---
> + arch/mips/loongson64/common/init.c | 4 ++--
> + arch/mips/mti-malta/malta-init.c | 8
> + arch/mips/pistachio/init.c | 8
> + 3 files changed, 10 insertions(+), 10 deletions(-)
> +
> +--- a/arch/mips/lo
Re: [PATCH] ramips: gpio-ralink: use ngpios, not ralink,num-gpios
On Wed, Apr 7, 2021 at 2:46 AM Sander Vanheule wrote: > > Hi Ilya, > > On Mon, 2021-04-05 at 22:53 -0700, Ilya Lipnitskiy wrote: > > DTS properties that match *-gpios are treated specially. > > > > Use ngpios instead, as most GPIO drivers upstream do. > > > > Fixes 5.10 DTS errors such as: > > OF: /palmbus@30/gpio@600: could not find phandle > > > > Fixes DTC warnings such as: > > Warning (gpios_property): /palmbus@30/gpio@600:ralink,num- > > gpios: > > Could not get phandle node for (cell 0) > > > > Signed-off-by: Ilya Lipnitskiy > > Cc: Daniel Golle > > --- > > > > [...] > > > diff --git a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink- > > add-gpio-driver-for-ralink-SoC.patch b/target/linux/ramips/patches- > > 5.10/802-GPIO-MIPS-ralink-add-gpio-driver-for-ralink-SoC.patch > > index 141d29f9401c..c173336924d2 100644 > > --- a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > > driver-for-ralink-SoC.patch > > +++ b/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > > driver-for-ralink-SoC.patch > > @@ -357,7 +357,7 @@ Cc: linux-g...@vger.kernel.org > > + return -EINVAL; > > + } > > + > > -+ ngpio = of_get_property(np, "ralink,num-gpios", NULL); > > ++ ngpio = of_get_property(np, "ngpios", NULL); > > I guess you just went for the smallest patch that fixes the errors and > warnings? Correct, the goal of this patch was just to rename "ralink,num-gpios" to "ngpios". > > Based on my recent experience with linux-gpio, I think more things > would need to change too, for the driver to be upstream-compatible. But > I don't know what your plans are with this driver, so maybe this quick > fix is sufficient for OpenWrt. I wasn't planning on fixing all issues and upstreaming the driver, but may attempt that in the future. Just trying to make a step in the right direction here and save people time so they don't see these errors/warnings. Ilya ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: gpio-ralink: use ngpios, not ralink,num-gpios
Hi! On Thu, Apr 8, 2021 at 6:41 AM Ilya Lipnitskiy wrote: > > On Wed, Apr 7, 2021 at 2:46 AM Sander Vanheule wrote: > > > > Hi Ilya, > > > > On Mon, 2021-04-05 at 22:53 -0700, Ilya Lipnitskiy wrote: > > > DTS properties that match *-gpios are treated specially. > > > > > > Use ngpios instead, as most GPIO drivers upstream do. > > > > > > Fixes 5.10 DTS errors such as: > > > OF: /palmbus@30/gpio@600: could not find phandle > > > > > > Fixes DTC warnings such as: > > > Warning (gpios_property): /palmbus@30/gpio@600:ralink,num- > > > gpios: > > > Could not get phandle node for (cell 0) > > > > > > Signed-off-by: Ilya Lipnitskiy > > > Cc: Daniel Golle > > > --- > > > > > > > [...] > > > > > diff --git a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink- > > > add-gpio-driver-for-ralink-SoC.patch b/target/linux/ramips/patches- > > > 5.10/802-GPIO-MIPS-ralink-add-gpio-driver-for-ralink-SoC.patch > > > index 141d29f9401c..c173336924d2 100644 > > > --- a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > > > driver-for-ralink-SoC.patch > > > +++ b/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > > > driver-for-ralink-SoC.patch > > > @@ -357,7 +357,7 @@ Cc: linux-g...@vger.kernel.org > > > + return -EINVAL; > > > + } > > > + > > > -+ ngpio = of_get_property(np, "ralink,num-gpios", NULL); > > > ++ ngpio = of_get_property(np, "ngpios", NULL); > > > > I guess you just went for the smallest patch that fixes the errors and > > warnings? > Correct, the goal of this patch was just to rename "ralink,num-gpios" > to "ngpios". > > > > > Based on my recent experience with linux-gpio, I think more things > > would need to change too, for the driver to be upstream-compatible. But > > I don't know what your plans are with this driver, so maybe this quick > > fix is sufficient for OpenWrt. > I wasn't planning on fixing all issues and upstreaming the driver, but > may attempt that in the future. Just trying to make a step in the > right direction here and save people time so they don't see these > errors/warnings. This whole driver probably needs a complete rewrite if you want to upstream it. Multiple gpio nodes should be merged into one, bgpio_init should be used to replace our current manual register operations, and this num-gpios is a SoC-specific property, which should be hard-coded in the driver and distinguished using compatible strings. I think current upstream gpio driver for mt7621 is a good start point. It's on my to-do list but I probably won't find any time for it before June. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 - realtek and mediatek targets
Hi, Do we want to keep the realtek and mediatek targets in the 21.02 branch and release or do we want to remove them link the ipq807x target? Hauke keep them for sure. I am running my network on those 2 targets using 21.02 John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 - realtek and mediatek targets
Stijn Segers writes: > A vote for keeping the realtek target here, I have three devices here > in production. Very happy with them. The main catch I see with > relegating the realtek target to master would be less uptake on the > end user side (not everyone will want to run hardware that needs > OpenWrt master), but I am unqualified to judge the code quality. > > All I can say is it runs nicely here (including PoE). I agree. The feature set of the realtek target is pretty complete, and the anticipated fast movement of the target in master has not happened yet. So please keep realtek for 21.02. There is one pending series applicable to realtek which I had hoped to get in before exposing the target to innocent users, but this might be too late by now?: https://patchwork.ozlabs.org/project/openwrt/list/?series=237587 Being able to adjust the "bootpartition" variable is crucial to support console-less installation IMHO. Which makes the target more accessible to non-developers. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
