Re: Enabling Wi-Fi on First boot
On 06/07/2021 13:05, Michael Richardson wrote: Henrique de Moraes Holschuh wrote: > So, to safely and responsibly enable wireless by default in a device (or > firmware) you're delivering to a third-party, you need that "per-unit unique > wireless password" per device thing most vendors are doing. > Now, unique per-device passwords are "easy" [2] to do if you're delivering > whole devices, as you can just print a label with the device's unique > password and attach to it or to its documentation. My training session from 2020: https://www.iotsecurityfoundation.org/consumer-iot/ https://www.youtube.com/watch?v=I-wHZ64T-Ps It is mandatory in Brazil for new devices. This is a somewhat recent change here. Default passwords for wireless are not allowed anymore, they must be unique per device, *AND* our standards specifically say you are not to use anything derived from the MAC address or other network-visible information. > It is far less easy when you're delivering just the firmware (openwrt-based), > which the third-party/user will install by herself. At least for generic > devices in the general case. This problem also presents itself for generating HTTPS certificates (which we've discussed at length on this list), and it's particularly acute when attempting to ship Virtual Machine Appliances! (Somehow, cloud-init can help, but I haven't figured out how yet) Security-aside, cloud-init-like solutions (like TR-069, etc) depend on "WAN" always working without initial configuration, as well as the entire trust path required to connect to the "metadata server" never getting bitrotted / changed away until all units in the field have been updated to whatever needed to be changed. And when you look at security (which you *must*), it is all needles and lava, and pitfalls. You first need to solve the problem of setting the system clock with a *trusted* value to even have HTTPS and DNSSEC working (not to mention working *correctly*, so just setting it close enough for the PKI certificates to not be invalid isn't enough unless a domain-expert signed on it!), etc. You can always try to bite the bullet: get the clock ipdate in an insecure way from a *as local as possible* server at a known IP address, and then proceed with 1st boot configuration (which had better be signed with a key you will actually manage to protect, or you're toast). IoTSF's ManySecured WG, at https://manysecured.net/ is trying to figure this part out, and I think we'll shortly have a more open (less IoTSF member-only) ML for discussion. We'd very much like openwrt people involved. Sounds interesting :-) Hopefully core openwrt developers will join. >> This would allow us to relax the security settings for the moment being, >> and discuss and plan them later on. It seems to me there is the general >> desire for having such a feature. > I would very much like to have a config option that allows one to implement > what I described in [2] below -- or something else that could be likewise > used. Basically, a way to append to an already-finished sysupgrade/factory > file some signed configuration data that will resist factory-reset, so that > it is easy/fast to do so at download time without the need to run the image > builder. I also think that this would be a good idea. I think that really, it belongs in the eeprom or in a custom partition that acts in a similiar way. The problem is that one also needs a "really really" factory-reset mode, which *does* erase this data and really goes back to default. That is easy enough to implement -- just require a hundred-second reset button press or something like that. However, because there can be no "default" that requires a static hardcoded default password, not even one that is a realy-really-factory-reset (do it and you're likely afoul of the regulations), you actually need the device to either self-heal somehow *safely*, or lock itself down until it receives a firmware-trusted signed credentials package. Maybe you could have it go into the current openwrt scheme, but a bit more locked down. It depends on the requirements. Here in Brazil, you'd *at the very least* need to get the unit into a "clearly unusable state meant to facilitate technician repair only" that cannot expose the user to local/remote exploitation -- and you'd better clear this with your lawyers, because that might not be enough. No idea about the EU or US. But most likely you'd want to add a "factory provisioning mode" which would be what is the "really-really-factory-reset" thing: it would be far more useful. As an example: down WAN and wireless, up LAN in DHCP mode, firewall for TTL=255 at ethernet frame level, listen only for the provisioning protocol (say: signed blob containing the preset data you'd write to FLASH, over pure TCP, in some sp
[PATCH v7 2/2] dnsmasq: add config option for connmark DNS filtering
This adds uci support to configure connmark based DNS filtering.
Signed-off-by: Etan Kissling
(See
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/015151.html)
Signed-off-by: Etan Kissling
---
v2: Bundle with patch to update dnsmasq.
package/network/services/dnsmasq/files/dnsmasq.init | 12
1 file changed, 12 insertions(+)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index f86b4b04f3..d77780f7d5 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -172,6 +172,10 @@ append_ipset() {
xappend "--ipset=$1"
}
+append_connmark_allowlist() {
+ xappend "--connmark-allowlist=$1"
+}
+
append_interface() {
network_get_device ifname "$1" || ifname="$1"
xappend "--interface=$ifname"
@@ -921,6 +925,14 @@ dnsmasq_start()
config_list_foreach "$cfg" "rev_server" append_rev_server
config_list_foreach "$cfg" "address" append_address
config_list_foreach "$cfg" "ipset" append_ipset
+
+ local connmark_allowlist_enable
+ config_get connmark_allowlist_enable "$cfg" connmark_allowlist_enable 0
+ [ "$connmark_allowlist_enable" -gt 0 ] && {
+ append_parm "$cfg" "connmark_allowlist_enable"
"--connmark-allowlist-enable"
+ config_list_foreach "$cfg" "connmark_allowlist"
append_connmark_allowlist
+ }
+
[ -n "$BOOT" ] || {
config_list_foreach "$cfg" "interface" append_interface
config_list_foreach "$cfg" "notinterface" append_notinterface
--
2.30.1 (Apple Git-130)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v7 1/2] dnsmasq: Update to version 2.86test5
Need this version to add config option for connmark DNS filtering.
Summary of upstream CHANGELOG:
* Handle DHCPREBIND requests in the DHCPv6 server code.
* Fix bug which caused dnsmasq to lose track of processes forked.
* Major rewrite of the DNS server and domain handling code.
* Revise resource handling for number of concurrent DNS queries.
* Improve efficiency of DNSSEC.
* Connection track mark based DNS query filtering.
Signed-off-by: Etan Kissling
---
v3: Refreshed patches.
v4: Fix crash when running multiple dnsmasq instances.
v5: Workaround from v4 is no longer required.
Update to version 2.86test4.
v7: Additional patch no longer needed for update (fix already applied).
Update to version 2.86test5.
package/network/services/dnsmasq/Makefile | 6 +++---
.../patches/100-remove-old-runtime-kernel-support.patch | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/package/network/services/dnsmasq/Makefile
b/package/network/services/dnsmasq/Makefile
index 90a81b5f65..9aa20eb1ea 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -8,13 +8,13 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=dnsmasq
-PKG_UPSTREAM_VERSION:=2.85
+PKG_UPSTREAM_VERSION:=2.86test5
PKG_VERSION:=$(subst test,~~test,$(subst rc,~rc,$(PKG_UPSTREAM_VERSION)))
PKG_RELEASE:=$(AUTORELEASE)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_UPSTREAM_VERSION).tar.xz
-PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
-PKG_HASH:=ad98d3803df687e5b938080f3d25c628fe41c878752d03fbc6199787fee312fa
+PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/test-releases
+PKG_HASH:=789defea3655bca38539c602567b75647ec9ede6746c78f4ccf1da7152b53eea
PKG_LICENSE:=GPL-2.0
PKG_LICENSE_FILES:=COPYING
diff --git
a/package/network/services/dnsmasq/patches/100-remove-old-runtime-kernel-support.patch
b/package/network/services/dnsmasq/patches/100-remove-old-runtime-kernel-support.patch
index b601bce1a9..a143498381 100644
---
a/package/network/services/dnsmasq/patches/100-remove-old-runtime-kernel-support.patch
+++
b/package/network/services/dnsmasq/patches/100-remove-old-runtime-kernel-support.patch
@@ -26,7 +26,7 @@ Signed-off-by: Kevin Darbyshire-Bryant
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
-@@ -1144,7 +1144,7 @@ extern struct daemon {
+@@ -1199,7 +1199,7 @@ extern struct daemon {
int inotifyfd;
#endif
#if defined(HAVE_LINUX_NETWORK)
@@ -35,7 +35,7 @@ Signed-off-by: Kevin Darbyshire-Bryant
#elif defined(HAVE_BSD_NETWORK)
int dhcp_raw_fd, dhcp_icmp_fd, routefd;
#endif
-@@ -1326,9 +1326,6 @@ int read_write(int fd, unsigned char *pa
+@@ -1386,9 +1386,6 @@ int read_write(int fd, unsigned char *pa
void close_fds(long max_fd, int spare1, int spare2, int spare3);
int wildcard_match(const char* wildcard, const char* match);
int wildcard_matchn(const char* wildcard, const char* match, int num);
@@ -140,7 +140,7 @@ Signed-off-by: Kevin Darbyshire-Bryant
my_syslog(LOG_ERR, _("failed to update ipset %s: %s"), setname,
strerror(errno));
--- a/src/util.c
+++ b/src/util.c
-@@ -786,22 +786,3 @@ int wildcard_matchn(const char* wildcard
+@@ -796,22 +796,3 @@ int wildcard_matchn(const char* wildcard
return (!num) || (*wildcard == *match);
}
--
2.30.1 (Apple Git-130)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH luci] luci-mod-network: wireless.js: allow changing the 60 GHz radio's frequency
Hi Alex, thank you for this patch. Based on your submission I pushed a somewhat smaller fix to LuCI master which omits the last two hunks: https://github.com/openwrt/luci/commit/e5626ece12236f6be9dbb6da6eb90fcbb469a1f0 The code related to the `hwmode` option is there for backwards compatibility reasons and should only deal with 11a and 11g. OpenWrt master uses the new `option band` to specify wireless frequency bands and that should be handled correctly already without the additional changes. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH luci] luci-mod-network: wireless.js: allow changing the 60 GHz radio's frequency
The text "Operating frequency" was still on the form, but there was no
drop-down next to it. Also, it was only possible to edit the 60 GHz
radio's settings once: After that, instead of a settings dialog, an
error dialog would appear that said "TypeError: chan.options[0] is
undefined".
"mhz >= 58329" appears to have been a typo. The TP-Link AD7200 reports a
channel at 58320 MHz, exactly where the 802.11 specification says it
should be.
Signed-off-by: Alex Henrie
---
.../luci-static/resources/view/network/wireless.js| 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/wireless.js
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/wireless.js
index 5115a69eb6..35d76d965b 100644
---
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/wireless.js
+++
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/wireless.js
@@ -327,7 +327,7 @@ var CBIWifiFrequencyValue = form.Value.extend({
band = '5g';
else if (data[1][i].mhz >= 5925 &&
data[1][i].mhz <= 7125)
band = '6g';
- else if (data[1][i].mhz >= 58329 &&
data[1][i].mhz <= 69120)
+ else if (data[1][i].mhz >= 58320 &&
data[1][i].mhz <= 69120)
band = '60g';
else
continue;
@@ -375,7 +375,8 @@ var CBIWifiFrequencyValue = form.Value.extend({
this.bands = {
'': [
'2g', '2.4 GHz',
this.channels['2g'].length > 3,
- '5g', '5 GHz',
this.channels['5g'].length > 3
+ '5g', '5 GHz',
this.channels['5g'].length > 3,
+ '60g', '60 GHz',
this.channels['60g'].length > 3
],
'n': [
'2g', '2.4 GHz',
this.channels['2g'].length > 3,
@@ -465,7 +466,9 @@ var CBIWifiFrequencyValue = form.Value.extend({
if (hwval != null) {
this.useBandOption = false;
- if (/a/.test(hwval))
+ if (hwval == '11ad')
+ band.value = '60g';
+ else if (/a/.test(hwval))
band.value = '5g';
else
band.value = '2g';
@@ -554,7 +557,7 @@ var CBIWifiFrequencyValue = form.Value.extend({
if (this.useBandOption)
uci.set('wireless', section_id, 'band', value[1]);
else
- uci.set('wireless', section_id, 'hwmode', (value[1] ==
'2g') ? '11g' : '11a');
+ uci.set('wireless', section_id, 'hwmode', (value[1] ==
'2g') ? '11g' : (value[1] == '60g') ? '11ad' : '11a');
uci.set('wireless', section_id, 'channel', value[2]);
}
--
2.32.0.94.ge083fb24f6
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: X86_64 : 8 CPU limitation on Vanilla release
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 --- Will read the procedure and submit a patch asap. De : openwrt-devel de la part de Alberto Bursi Envoyé : vendredi 9 juillet 2021 14:30 À : openwrt-devel@lists.openwrt.org Objet : Re: X86_64 : 8 CPU limitation on Vanilla release On 09/07/21 10:03, Brice GIBOUDEAU via openwrt-devel wrote: > > Hello, > > I'm reaching out to you about a limitation on the X86_64 target. > > We use this version to operate large scale Wireguard VPNs on VMs and physical > servers (DELL & HP). The actual limitation of 8 CPU is the only reason why we > have to recompile OpenWRT. This 8 CPU limitation makes perfect sense for most > targets to save flash/memory space but x86_64 have less physical limitations > and most CPUs have more than 8 cores/threads. > > Is it an option to raise this limitation to 64 to fit most available CPU on > the market ? > I'm not very use to patch submission but if it's needed I can try to do it. > > What I can see the cost is an overhead 8KB memory and kernel size per extra > CPU so (64-8)x8=448KB addition. X86_64 have less limitations than other > architecture and enabling more CPUs should be ok for this platform. > I think there is no problem to raise CPU core limit on x86_64 target to cover more than 8 cores, it was probably just an old default and nobody has asked to change it yet. When you submit the patch properly see submission rules (1) you should also do the same change in the "config-5.10" file which is the kernel config for the next kernel version. 1. https://openwrt.org/submitting-patches -Alberto ___ 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: X86_64 : 8 CPU limitation on Vanilla release
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 --- Will read the procedure and submit a patch asap. De : openwrt-devel de la part de Alberto Bursi Envoyé : vendredi 9 juillet 2021 14:30 À : openwrt-devel@lists.openwrt.org Objet : Re: X86_64 : 8 CPU limitation on Vanilla release On 09/07/21 10:03, Brice GIBOUDEAU via openwrt-devel wrote: > > Hello, > > I'm reaching out to you about a limitation on the X86_64 target. > > We use this version to operate large scale Wireguard VPNs on VMs and physical > servers (DELL & HP). The actual limitation of 8 CPU is the only reason why we > have to recompile OpenWRT. This 8 CPU limitation makes perfect sense for most > targets to save flash/memory space but x86_64 have less physical limitations > and most CPUs have more than 8 cores/threads. > > Is it an option to raise this limitation to 64 to fit most available CPU on > the market ? > I'm not very use to patch submission but if it's needed I can try to do it. > > What I can see the cost is an overhead 8KB memory and kernel size per extra > CPU so (64-8)x8=448KB addition. X86_64 have less limitations than other > architecture and enabling more CPUs should be ok for this platform. > I think there is no problem to raise CPU core limit on x86_64 target to cover more than 8 cores, it was probably just an old default and nobody has asked to change it yet. When you submit the patch properly see submission rules (1) you should also do the same change in the "config-5.10" file which is the kernel config for the next kernel version. 1. https://openwrt.org/submitting-patches -Alberto ___ 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: [PATCH 19.07 4/4] treewide: mark selected packages nonshared
> -Original Message- > From: Giovanni Giacobbi [mailto:giova...@giacobbi.net] > Sent: Freitag, 9. Juli 2021 09:37 > To: Adrian Schmutzler ; 'Paul Spooren' > ; 'Petr Štetiar' ; openwrt- > de...@lists.openwrt.org > Cc: 'Hannu Nyman' > Subject: Re: [PATCH 19.07 4/4] treewide: mark selected packages nonshared > > On 04/07/2021 14:46, Adrian Schmutzler wrote: > >>>PKG_NAME:=json-c > >>>PKG_VERSION:=0.12.1 > >>> -PKG_RELEASE:=3.1 > >>> +PKG_RELEASE:=3.2 > >> I've never seen a non integer release, is there a special reason for this? > > I've also used this as standard scheme for changes in stable branches. The > advantage is that you immediately see up to which version the changes are > shared with master, and when it starts to deviate. > > What would you do then if the upstream version is bumped, but the > patchset/Makefile would still differ between the master and branch? In this I'd have to think about that. But changing PKG_VERSION or PKG_SOURCE_DATE is rare in release branches. Best Adrian > case, you bump PKG_VERSION to 0.12.2, but if you restart the PKG_RELEASE > from 1 for both the branch and the master you end up with two different > "0.12.2-1" packages in let's say 21.02 and 19.07. > openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] relayd: don't break localhost
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 --- Relayd is adding default route to its routing tables when it's found in DHCP response. Adding default route to routing table associated with loopback interface makes no sense other than breaking localhost so that DNS requests to local dnsmasq and even "ping 127.0.0.1" go to default gateway. This patch prevents insertion of default route into "localhost" policy routing table created by relayd. Signed-off-by: Dmitry Ivanov --- route.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/route.c b/route.c index c552d1f..f7cf815 100644 --- a/route.c +++ b/route.c @@ -243,7 +243,7 @@ rtnl_route_set(struct relayd_host *host, struct relayd_route *route, bool add) rtnl_route_request(rif, host, route, add); } - if (local_route_table) + if (local_route_table && route && route->mask) rtnl_route_request(NULL, host, route, add); } -- 2.30.2 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: X86_64 : 8 CPU limitation on Vanilla release
On 09/07/21 10:03, Brice GIBOUDEAU via openwrt-devel wrote: Hello, I'm reaching out to you about a limitation on the X86_64 target. We use this version to operate large scale Wireguard VPNs on VMs and physical servers (DELL & HP). The actual limitation of 8 CPU is the only reason why we have to recompile OpenWRT. This 8 CPU limitation makes perfect sense for most targets to save flash/memory space but x86_64 have less physical limitations and most CPUs have more than 8 cores/threads. Is it an option to raise this limitation to 64 to fit most available CPU on the market ? I'm not very use to patch submission but if it's needed I can try to do it. What I can see the cost is an overhead 8KB memory and kernel size per extra CPU so (64-8)x8=448KB addition. X86_64 have less limitations than other architecture and enabling more CPUs should be ok for this platform. I think there is no problem to raise CPU core limit on x86_64 target to cover more than 8 cores, it was probably just an old default and nobody has asked to change it yet. When you submit the patch properly see submission rules (1) you should also do the same change in the "config-5.10" file which is the kernel config for the next kernel version. 1. https://openwrt.org/submitting-patches -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] ipq40xx: increase SPI frequency for Zyxel NBG6617
The mx25l25635e supports clock speed up to 50Mhz.
Also remove obsolete "mx25l25635f" hack.
Signed-off-by: Dmitry Tunin
---
.../files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts| 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
index 4d17325c8d..caafc1beb4 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
@@ -210,10 +210,10 @@
status = "okay";
cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
- mx25l25635f@0 {
- compatible = "mx25l25635f", "jedec,spi-nor";
+ flash@0 {
+ compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <2400>;
+ spi-max-frequency = <5000>;
status = "okay";
m25p,fast-read;
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: increase SPI frequency for Zyxel NBG6617 The mx25l25635e supports clock speed up to 50Mhz.
On 09/07/2021 11:15, Dmitry Tunin wrote:
Also remove obsolete "mx25l25635f" hack.
Looks like the subject contains part of the commit message?!
Please try to keep that subject line short enough (like 50-60
letters) so it doesn't wrap on git.openwrt.org / github view.
(while at it please also change the node-name mx25l...@ to flash@)
Thanks
Christian
Signed-off-by: Dmitry Tunin
---
.../ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
index 4d17325c8d..28a299218b 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
@@ -211,9 +211,9 @@
cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
mx25l25635f@0 {
- compatible = "mx25l25635f", "jedec,spi-nor";
+ compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <2400>;
+ spi-max-frequency = <5000>;
status = "okay";
m25p,fast-read;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipq40xx: increase SPI frequency for Zyxel NBG6617 The mx25l25635e supports clock speed up to 50Mhz.
Also remove obsolete "mx25l25635f" hack.
Signed-off-by: Dmitry Tunin
---
.../ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
index 4d17325c8d..28a299218b 100644
--- a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
+++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4018-nbg6617.dts
@@ -211,9 +211,9 @@
cs-gpios = <&tlmm 54 GPIO_ACTIVE_HIGH>;
mx25l25635f@0 {
- compatible = "mx25l25635f", "jedec,spi-nor";
+ compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <2400>;
+ spi-max-frequency = <5000>;
status = "okay";
m25p,fast-read;
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
X86_64 : 8 CPU limitation on Vanilla release
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 --- Hello, I'm reaching out to you about a limitation on the X86_64 target. We use this version to operate large scale Wireguard VPNs on VMs and physical servers (DELL & HP). The actual limitation of 8 CPU is the only reason why we have to recompile OpenWRT. This 8 CPU limitation makes perfect sense for most targets to save flash/memory space but x86_64 have less physical limitations and most CPUs have more than 8 cores/threads. Is it an option to raise this limitation to 64 to fit most available CPU on the market ? I'm not very use to patch submission but if it's needed I can try to do it. What I can see the cost is an overhead 8KB memory and kernel size per extra CPU so (64-8)x8=448KB addition. X86_64 have less limitations than other architecture and enabling more CPUs should be ok for this platform. The change needed is below: --- diff -a target/linux/x86/64/config-5.4.orig target/linux/x86/64/config-5.4 313c313 < CONFIG_NR_CPUS=8 --- > CONFIG_NR_CPUS=64 Regards, MiNuS_89 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07 4/4] treewide: mark selected packages nonshared
On 04/07/2021 14:46, Adrian Schmutzler wrote: PKG_NAME:=json-c PKG_VERSION:=0.12.1 -PKG_RELEASE:=3.1 +PKG_RELEASE:=3.2 I've never seen a non integer release, is there a special reason for this? I've also used this as standard scheme for changes in stable branches. The advantage is that you immediately see up to which version the changes are shared with master, and when it starts to deviate. What would you do then if the upstream version is bumped, but the patchset/Makefile would still differ between the master and branch? In this case, you bump PKG_VERSION to 0.12.2, but if you restart the PKG_RELEASE from 1 for both the branch and the master you end up with two different "0.12.2-1" packages in let's say 21.02 and 19.07. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
