Re: OpenWrt 21.02 and 19.07 minor release

[Seo Suchan]

I just noticed 19.07 still looks at dnsmasq 2.80: which was effeced by 
series of vulnerablity CVE-2020-25681 
 ~25685 and need to 
bumped at least to 2.85 like 21.02 as CVE-2021-3448 
 is fixed by 2.85rc1 - 
would just copying 21.02's dnsmasq makefiles (and patches) be enough to 
fix this?


2022-02-13 오전 9:26에 Hauke Mehrtens 이(가) 쓴 글:


Thanks for that information. Do you know about some official statement 
about this?


I fixed some other problems in OpenWrt 21.02:
* Linux: update to latests minor version
* hostapd: backport the patches
* wolfssl: update to recent version
* tcpdump: backport a patch
* mbedtls: update to new LTS version
* glibc: Update to latest minor version

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 and 19.07 minor release

[Rosen Penev]

On Mon, Feb 14, 2022 at 12:00 PM Hauke Mehrtens  wrote:
>
> On 2/13/22 01:26, Hauke Mehrtens wrote:
> > On 2/10/22 16:12, Seo Suchan wrote:
> >> looks like those dnsmasq exploits aren't real
> >>
> >> bugs never looked by human (no commit related by it), but bots
> >> confirmed that thoses look fixed by commit
> >> 011f8cf1d011ade2f9e7231fca3cabfb1e8eaf06
> >>
> >> https://oss-fuzz.com/revisions?job=afl_asan_dnsmasq=202112300601:202201020605
> >> 
> >>
> >>
> >> when I read that commit it looks like 2.86 had bug that faild to build
> >> on gcc 4.8 and it caused fuzzer to get immediately crash, producing
> >> bunch of 'exploits'
> >
> > Thanks for that information. Do you know about some official statement
> > about this?
> >
> > I fixed some other problems in OpenWrt 21.02:
> > * Linux: update to latests minor version
> > * hostapd: backport the patches
> > * wolfssl: update to recent version
> > * tcpdump: backport a patch
> > * mbedtls: update to new LTS version
> > * glibc: Update to latest minor version
>
> The OpenWrt 21.02 and 19.07 branches are looking fine to me.
> I am still waiting for some LuCI backports from Jo and would like to tag
> and build the next minor releases tomorrow or some days later depending
> on when Jo finishes the backports.
>
> @Rosen: You wanted to update ksmbd in the feeds. Is there already a pull
> request and will you merge it or should I merge it shortly before tagging?
https://github.com/openwrt/packages/pull/17866
>
> I asked on the dnsmasq mailing list about the CVEs we saw. My current
> plan is to ignore them.
>
> Is there anything else missing?
>
> Hauke

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

Re: [PATCH 19.07 v2 0/3] wolfssl security updates

[Luiz Angelo Daros de Luca]

> I've started to look at the first vulnerability, but it is not as
> straightforward as I was hoping.  Perhaps Luiz Angelo Daros de Luca,
> reporter and author of the fixes, can help me out with this.

Sure. And I do have interest in getting it fixed. It is both a
security fix (when it does not block what it should) and a bug fix
(when it blocks what it shouldn't). It affects special certificates
with multiple name constraints, used mostly to limit the power of an
internal CA. It is normally not used in public CA.

The fix is a drop-in replacement for the validation function
ConfirmNameConstraints() and a small applicable change to
MatchBaseName(). There are some required commits to get that change
cleanly applied and I don't think it is worth it (a55e94cf6f touches
almost all the tree). I think you can use this standalone backport:

https://github.com/luizluca/wolfssl/commit/ede75f0f0618243147ad8315b8c059ce77c751e7

When applied to 4.7.0, it will have the same final result for
ConfirmNameConstraints() and MatchBaseName() as the upstream patch.

Regards,

Luiz

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

Re: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes

[Mathias Kresin]

2/14/22 11:06, Torsten Duwe:

On Sat, 12 Feb 2022 02:05:17 +0100
Mathias Kresin  wrote:

2/11/22 23:39, kestrel1...@t-online.de:

I created a DTB and image configuration for Micron and non Micron
NAND. This is probably the best way and not supporting just one
NAND type per device. Unfortunately auto detection was not accepted
by the kernel maintainers, so there is no other solution.

I also saw the addition of ubifs. I have not used this so far and I
wonder what the advantage is over using squashfs with overlay?


Let me cite https://en.wikipedia.org/wiki/UBIFS

- tracking NAND flash bad blocks
- providing wear leveling

NAND is a rather unreliable type of flash, hence some special
treatment has to be done to make it last as long as possible.


Yes, I somehow had gotten the impression that UBI was mandatory for
OpenWRT ports to new devices with NAND, so I went that way.

Is sysupgrade prepared for squashfs+overlay as UBI volumes?


Yes, sysupgrade is fine. It's used for the BT Home Hub 5A for example.

Mathias

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

[PATCH 19.07 v2 3/3] wolfssl: build with WOLFSSL_ALT_CERT_CHAINS

[Eneas U de Queiroz]

From: Andre Heider 

"Alternate certification chains, as oppossed to requiring full chain
validataion. Certificate validation behavior is relaxed, similar to
openssl and browsers. Only the peer certificate must validate to a trusted
certificate. Without this, all certificates sent by a peer must be
used in the trust chain or the connection will be rejected."

This fixes e.g. uclient-fetch and curl connecting to servers using a Let's
Encrypt certificate which are cross-signed by the now expired
DST Root CA X3, see [0].

This is the recommended solution from upstream [1].

The binary size increases by ~12.3kb:
1236160 staging_dir/target-mipsel_24kc_musl/usr/lib/libwolfssl.so.4.8.1.39c36f2f
1248704 staging_dir/target-mipsel_24kc_musl/usr/lib/libwolfssl.so.4.8.1.39c36f2f

[0] https://github.com/openwrt/packages/issues/16674
[1] https://github.com/wolfSSL/wolfssl/issues/4443#issuecomment-934926793

Signed-off-by: Andre Heider 
[bump PKG_RELEASE]
Signed-off-by: David Bauer 
(cherry picked from commit 28d8e6a8711ba78f1684a205e11b0dbd4ff2b2f3)
[adjust to v4.7.0 Makefile]
Signed-off-by: Eneas U de Queiroz 
---
 package/libs/wolfssl/Makefile | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index d123e7a875..4394b9ea4f 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=wolfssl
 PKG_VERSION:=4.7.0-stable
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
@@ -56,7 +56,11 @@ define Package/libwolfssl/config
source "$(SOURCE)/Config.in"
 endef
 
-TARGET_CFLAGS += $(FPIC) -DFP_MAX_BITS=8192 -fomit-frame-pointer
+TARGET_CFLAGS += \
+   $(FPIC) \
+   -fomit-frame-pointer \
+   -DFP_MAX_BITS=8192 \
+   -DWOLFSSL_ALT_CERT_CHAINS
 
 # --enable-stunnel needed for OpenSSL API compatibility bits
 CONFIGURE_ARGS += \

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

[PATCH 19.07 v2 1/3] wolfssl: Fix OCSP request/response verification

[Eneas U de Queiroz]

In the case that the serial number in the OCSP request differs from the
serial number in the OCSP response the error from the comparison was not
resulting in a failed verification.

Signed-off-by: Eneas U de Queiroz 
---
 package/libs/wolfssl/Makefile |   2 +-
 .../patches/200-Fix-CompareOcspReqResp.patch  | 224 ++
 2 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 
package/libs/wolfssl/patches/200-Fix-CompareOcspReqResp.patch

diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index 57fcaa03b2..631576a58e 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=wolfssl
 PKG_VERSION:=4.7.0-stable
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
diff --git a/package/libs/wolfssl/patches/200-Fix-CompareOcspReqResp.patch 
b/package/libs/wolfssl/patches/200-Fix-CompareOcspReqResp.patch
new file mode 100644
index 00..9661a2b752
--- /dev/null
+++ b/package/libs/wolfssl/patches/200-Fix-CompareOcspReqResp.patch
@@ -0,0 +1,224 @@
+From  Mon Sep 17 00:00:00 2001
+From: Hayden Roche 
+Date: Tue, 27 Apr 2021 13:54:43 -0700
+Subject: [PATCH] Fix CompareOcspReqResp.
+
+There was a bug in this function that could cause a match to be reported even
+when the OCSP request and response in fact had a mismatch.
+
+(cherry picked from commit 73076940af8904f98eee085994c176fe1876b95a)
+
+diff --git a/src/ssl.c b/src/ssl.c
+index 14a160dc2..289ffb941 100644
+--- a/src/ssl.c
 b/src/ssl.c
+@@ -6503,7 +6503,7 @@ WOLFSSL_API int 
wolfSSL_CertManagerCheckOCSPResponse(WOLFSSL_CERT_MANAGER *cm,
+ {
+ int ret;
+ 
+-WOLFSSL_ENTER("wolfSSL_CertManagerCheckOCSP_Staple");
++WOLFSSL_ENTER("wolfSSL_CertManagerCheckOCSPResponse");
+ if (cm == NULL || response == NULL)
+ return BAD_FUNC_ARG;
+ if (cm->ocspEnabled == 0)
+diff --git a/tests/api.c b/tests/api.c
+index 6b3af3092..72bfc9aae 100644
+--- a/tests/api.c
 b/tests/api.c
+@@ -1091,6 +1091,170 @@ static int test_cm_load_ca_file(const char* 
ca_cert_file)
+ }
+ #endif /* !NO_FILESYSTEM && !NO_CERTS */
+ 
++static void test_wolfSSL_CertManagerCheckOCSPResponse(void)
++{
++#ifdef HAVE_OCSP
++/* Need one of these for wolfSSL_OCSP_REQUEST_new. */
++#if defined(OPENSSL_ALL) || defined(WOLFSSL_NGINX) || \
++defined(WOLFSSL_HAPROXY) || defined(WOLFSSL_APACHE_HTTPD) || \
++defined(HAVE_LIGHTY)
++WOLFSSL_CERT_MANAGER* cm = NULL;
++/* Captured with Wireshark using ocsp.test. */
++byte response[] = {
++0x30, 0x82, 0x06, 0x3b, 0x0a, 0x01, 0x00, 0xa0, 0x82, 0x06, 0x34, 
0x30, 0x82, 0x06, 0x30, 0x06,
++0x09, 0x2b, 0x06, 0x01, 0x05, 0x05, 0x07, 0x30, 0x01, 0x01, 0x04, 
0x82, 0x06, 0x21, 0x30, 0x82,
++0x06, 0x1d, 0x30, 0x81, 0xbf, 0xa2, 0x16, 0x04, 0x14, 0x21, 0x29, 
0x0a, 0x15, 0x08, 0xdd, 0x79,
++0x01, 0x7c, 0xa3, 0xc6, 0x11, 0xe9, 0xbf, 0x8a, 0x33, 0x82, 0x53, 
0xc4, 0x0c, 0x18, 0x0f, 0x32,
++0x30, 0x32, 0x31, 0x30, 0x34, 0x32, 0x37, 0x32, 0x30, 0x32, 0x35, 
0x35, 0x36, 0x5a, 0x30, 0x6f,
++0x30, 0x6d, 0x30, 0x45, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 
0x02, 0x1a, 0x05, 0x00, 0x04,
++0x14, 0x9c, 0x4c, 0x71, 0x15, 0xc3, 0x02, 0x19, 0xca, 0x36, 0xdc, 
0xb9, 0x8b, 0x21, 0x33, 0x00,
++0x4c, 0xa4, 0xa7, 0x8e, 0xd3, 0x04, 0x14, 0xdd, 0xb3, 0xe7, 0x6d, 
0xa8, 0x2e, 0xe8, 0xc5, 0x4e,
++0x6e, 0xcf, 0x74, 0xe6, 0x75, 0x3c, 0x94, 0x15, 0xce, 0xe8, 0x1d, 
0x02, 0x0c, 0x6f, 0x9c, 0x01,
++0x78, 0x1c, 0x21, 0x80, 0x32, 0x25, 0x4a, 0x73, 0x2b, 0x80, 0x00, 
0x18, 0x0f, 0x32, 0x30, 0x32,
++0x31, 0x30, 0x34, 0x32, 0x37, 0x32, 0x30, 0x32, 0x35, 0x35, 0x36, 
0x5a, 0xa0, 0x11, 0x18, 0x0f,
++0x32, 0x30, 0x32, 0x31, 0x30, 0x35, 0x30, 0x31, 0x32, 0x30, 0x32, 
0x35, 0x35, 0x36, 0x5a, 0xa1,
++0x23, 0x30, 0x21, 0x30, 0x1f, 0x06, 0x09, 0x2b, 0x06, 0x01, 0x05, 
0x05, 0x07, 0x30, 0x01, 0x02,
++0x04, 0x12, 0x04, 0x10, 0xc0, 0x42, 0x27, 0x55, 0xaf, 0xc4, 0x5c, 
0x34, 0xe1, 0xc8, 0xef, 0x5b,
++0x31, 0xb1, 0x78, 0xe9, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 
0x86, 0xf7, 0x0d, 0x01, 0x01,
++0x0b, 0x05, 0x00, 0x03, 0x82, 0x01, 0x01, 0x00, 0x54, 0x1b, 0x9e, 
0x10, 0x0f, 0x82, 0x2c, 0x8e,
++0xd7, 0xdd, 0xf2, 0xec, 0x9c, 0x6c, 0x04, 0x5d, 0x57, 0x69, 0xcd, 
0x30, 0x1b, 0xe8, 0xd4, 0x5d,
++0xd4, 0x03, 0x97, 0xd1, 0x33, 0x78, 0x34, 0xdb, 0xc2, 0x4c, 0xc1, 
0x8a, 0xee, 0xc7, 0x18, 0x6a,
++0xe3, 0x6d, 0x59, 0x1b, 0xed, 0xf5, 0x87, 0xff, 0x9d, 0x11, 0xff, 
0x5a, 0xa5, 0x12, 0x93, 0x0e,
++0xc7, 0x67, 0xa4, 0x37, 0xb2, 0x8b, 0xba, 0xab, 0xe1, 0x29, 0x33, 
0xe9, 0xf8, 0x10, 0x1d, 0xbf,
++0x7c, 0x2b, 0x2e, 0x2e, 0x0b, 0x58, 0x5d, 0x8e, 0x0c, 0x44, 0xe2, 
0x1d, 0x73, 0x2a, 0x8a, 0x6a,
++0xc9, 0x4e, 0x2f, 0x7c, 0xa0, 

[PATCH 19.07 v2 2/3] wolfssl: Fix CVE-2021-38597

[Eneas U de Queiroz]

OCSP verification issue when response is for a certificate with no
relation to the chain in question BUT that response contains the NoCheck
extension which effectively disables ALL verification of that one cert.

Signed-off-by: Eneas U de Queiroz 
---
 package/libs/wolfssl/Makefile |  2 +-
 ...-handling-of-OCSP-no-check-extension.patch | 49 +++
 2 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 
package/libs/wolfssl/patches/210-OCSP-improve-handling-of-OCSP-no-check-extension.patch

diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index 631576a58e..d123e7a875 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=wolfssl
 PKG_VERSION:=4.7.0-stable
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
diff --git 
a/package/libs/wolfssl/patches/210-OCSP-improve-handling-of-OCSP-no-check-extension.patch
 
b/package/libs/wolfssl/patches/210-OCSP-improve-handling-of-OCSP-no-check-extension.patch
new file mode 100644
index 00..6fb62b2033
--- /dev/null
+++ 
b/package/libs/wolfssl/patches/210-OCSP-improve-handling-of-OCSP-no-check-extension.patch
@@ -0,0 +1,49 @@
+From  Mon Sep 17 00:00:00 2001
+From: Sean Parkinson 
+Date: Fri, 16 Jul 2021 12:19:39 +1000
+Subject: [PATCH] OCSP: improve handling of OCSP no check extension
+
+(cherry picked from commit f93083be72a3b3d956b52a7ec13f307a27b6e093)
+
+diff --git a/wolfcrypt/src/asn.c b/wolfcrypt/src/asn.c
+index bbf71e3c1..966035f5b 100644
+--- a/wolfcrypt/src/asn.c
 b/wolfcrypt/src/asn.c
+@@ -9751,9 +9751,13 @@ int ParseCertRelative(DecodedCert* cert, int type, int 
verify, void* cm)
+ }
+ 
+ #ifdef HAVE_OCSP
+-/* trust for the lifetime of the responder's cert*/
+-if (cert->ocspNoCheckSet && verify == VERIFY_OCSP)
+-verify = NO_VERIFY;
++if (verify == VERIFY_OCSP_CERT) {
++/* trust for the lifetime of the responder's cert*/
++if (cert->ocspNoCheckSet)
++verify = VERIFY;
++else
++verify = VERIFY_OCSP;
++}
+ #endif
+ /* advance past extensions */
+ cert->srcIdx = cert->sigIndex;
+@@ -17542,7 +17546,7 @@ static int DecodeBasicOcspResponse(byte* source, 
word32* ioIndex,
+ 
+ /* Don't verify if we don't have access to Cert Manager. */
+ ret = ParseCertRelative(, CERT_TYPE,
+-noVerify ? NO_VERIFY : VERIFY_OCSP, cm);
++noVerify ? NO_VERIFY : VERIFY_OCSP_CERT, cm);
+ if (ret < 0) {
+ WOLFSSL_MSG("\tOCSP Responder certificate parsing failed");
+ FreeDecodedCert();
+diff --git a/wolfssl/wolfcrypt/asn.h b/wolfssl/wolfcrypt/asn.h
+index e412c1d06..e3cddf5b4 100644
+--- a/wolfssl/wolfcrypt/asn.h
 b/wolfssl/wolfcrypt/asn.h
+@@ -589,6 +589,7 @@ enum VerifyType {
+ VERIFY_OCSP = 3,
+ VERIFY_NAME = 4,
+ VERIFY_SKIP_DATE = 5,
++VERIFY_OCSP_CERT = 6,
+ };
+ 
+ #ifdef WOLFSSL_CERT_EXT

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

[PATCH 19.07 v2 0/3] wolfssl security updates

[Eneas U de Queiroz]

Since a straight version bump is not feasible, I'm applying a couple of
cherry-picks of security fixes:

73076940a Fix CompareOcspReqResp
f93083be7 OCSP: improve handling of OCSP no check extension
  (CVE-2021-38597)

Also included in the series is a patch to build the library with
the "Alternate certificate validation" option WOLFSSL_ALT_CERT_CHAINS,
allowing uclient-fetch to connect to servers using the default Let's
Encrypt chain that contains the certificate cross-signed by the expired
DST Root CA X3 certificate.

The original series was made when 4.8.1 was the current version in
master.  Since then, some more low-severity vulnerabilities were
discovered: [1]

- Issue with incorrectly validating a certificate that has multiple
  subject alternative names when given a name constraint. In the case
  where more than one subject alternative name is used in the
  certificate, previous versions of wolfSSL could incorrectly validate
  the certificate. Users verifying certificates with multiple
  alternative names and name constraints, are recommended to either use
  the certificate verify callback to check for this case or update the
  version of wolfSSL used. Fixed in 5.0.0.

- Hang with DSA signature creation when a specific q value is used in a
  maliciously crafted key. If a DSA key with an invalid q value of
  either 1 or 0 was decoded and used for creating a signature, it would
  result in a hang in wolfSSL. Users that are creating signatures with
  DSA and are using keys supplied from an outside source are affected.
  Fixed in 5.0.0.

- Client side session resumption issue once the session resumption cache
  has been filled up. The hijacking of a session resumption has been
  demonstrated so far with only non verified peer connections. That is
  where the client is not verifying the server’s CA that it is
  connecting to. There is the potential though for other cases involving
  proxies that are verifying the server to be at risk.

- CVE-2021-44718: Potential for DoS attack on a wolfSSL client due to
  processing hello packets of the incorrect side. This affects only
  connections using TLS v1.2 or less that have also been compromised by
  a man in the middle attack.  A CVE was reserved, but apparently not
  publicized yet.

High-severity CVE-2022-23408 is not included because it affects versions
5.0.0 and 5.1.0 only.

I've started to look at the first vulnerability, but it is not as
straightforward as I was hoping.  Perhaps Luiz Angelo Daros de Luca,
reporter and author of the fixes, can help me out with this.

Applying a large series of fixes may end up creating a new vulnerability
if not done correctly, so we may need to consider the version bump
again.  The ABI version may create trouble for people running opkg
update, but WolfSSL was not the core TLS library in 19.07 yet.

Nonetheless, this series includes the one high-severity vulnerability
(according to wolfssl [1]) CV-2021-38597, and can be applied before we
decide what to do next.

Cheers,

Eneas

---

v2:
 - Apply two security patches instead of bumping to 4.8.1
 - Added patch to build with alternate certificate validation

[1] https://www.wolfssl.com/docs/security-vulnerabilities/

Andre Heider (1):
  wolfssl: build with WOLFSSL_ALT_CERT_CHAINS

Eneas U de Queiroz (2):
  wolfssl: Fix OCSP request/response verification
  wolfssl: Fix CVE-2021-38597

 package/libs/wolfssl/Makefile |   8 +-
 .../patches/200-Fix-CompareOcspReqResp.patch  | 224 ++
 ...-handling-of-OCSP-no-check-extension.patch |  49 
 3 files changed, 279 insertions(+), 2 deletions(-)
 create mode 100644 
package/libs/wolfssl/patches/200-Fix-CompareOcspReqResp.patch
 create mode 100644 
package/libs/wolfssl/patches/210-OCSP-improve-handling-of-OCSP-no-check-extension.patch


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

Re: bcm63xx kernel 5.10

[Paul Spooren]

> It works quite fine, and it's harmless.

I’d do that and bump the target to 5.10. that should give us a good chance to 
fork soonish

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

Re: bcm63xx kernel 5.10

[Daniel González Cabanelas]

El lun, 14 feb 2022 a las 20:34, Florian Fainelli
() escribió:
>
> On 2/14/22 11:07 AM, Hauke Mehrtens wrote:
> > On 2/4/22 00:48, Hauke Mehrtens wrote:
> >> Hi,
> >>
> >> We would like to switch the bcm63xx target to kernel 5.10. Paul
> >> created a pull request for that:
> >> https://github.com/openwrt/openwrt/pull/4616
> >>
> >> There is still a problem with Macronix NAND flash chips, see the
> >> comments from the pull request.
> >>
> >> Could someone please have a look into this problem.
> >>
> >> Does this change in the upstream kernel help?
> >> https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530
> >>
> >>
> >> Hauke
> >
> > Hi,
> >
> > I read that Daniel's device is now completely broken, probably
> > bootloader was overwritten.
> >
> > The bcm63xx target is the last one using kernel 5.4. We would like to
> > remove kernel 5.4 support from OpenWrt master soon and branch off the
> > next major release. How do we want to go forward with this topic?
> >
> > Should we apply this hack?
>
> I would be inclined to apply this hack and make it bcm63xx specific
> unless other platforms suffer from that problem.
>
> Meanwhile, I would reach out to the MTD maintainers to understand what
> is going on, mentioning what we have found, which is that the brcmnand
> controller prior to version 4.0 does not support the {GET,SET}_FEATURES
> command.
>
> Daniel, any hope of recovering your device somehow?

Not sure, right now without a NAND programmer I can use another router
(AD1018) to recover this one, wiring the NAND pads on the alive to the
dead one, to make a recovery booting from SPI a copy of Openwrt.
It might also be posible to locate the JTAG tests points on the board,
and then with OpenOCD initialize the CPU to load the RAM bootloader,
and then load an OpenWrt RAM firmware to finally flash sane
bootloaders ROM+RAM into the NAND flash. But I have no idea how to
initialize a BCM63268 CPU using OpenOCD in the case I was able to
locate the JTAG pinout.

About this patch:

--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -323,7 +323,7 @@

macronix_nand_fix_broken_get_timings(chip);
macronix_nand_onfi_init(chip);
-   macronix_nand_block_protection_support(chip);
+   //macronix_nand_block_protection_support(chip);
macronix_nand_deep_power_down_support(chip);

return 0;

It works quite fine, and it's harmless.

Regards
Daniel.

> --
> Florian

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

Re: [PATCH v4 0/3] ramips: mt7621-dts: fix dtc warning, links and pinctrl

[Arınç ÜNAL]

Please don't merge. Even though it's good to go, I'd like to make this 
patch series more organised and include more fixes on the mt7621 
devicetrees.


Arınç

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

Re: [PATCH] ipq40xx: limit available radio channels for GL.iNet GL-B2200

[Christian Lamparter]

Hi,

On Mon, Feb 14, 2022 at 2:29 PM Enrico Mioso  wrote:
> [0.470732] pci :01:00.0: [168c:0056] type 00 class 0x028000
> [   10.587378] ath10k 5.15 driver, optimized for CT firmware, probing pci 
> device: 0x56.
> [   10.588306] ath10k_pci :01:00.0: enabling device (0140 -> 0142)
> [   10.594929] ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2 irq_mode 
> 0 reset_mode 0
> [   11.631567] ath10k_pci :01:00.0: qca9888 hw2.0 target 0x0100 
> chip_id 0x sub :
> [   11.631622] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 tracing 0 
> dfs 1 testmode 0
> [   11.644152] ath10k_pci :01:00.0: firmware ver 
> 10.4b-ct-9888-fW-13-5ae337bb1 api 5 features 
> mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT
>  crc32 59e741e7
> [   11.934144] ath10k_pci :01:00.0: board_file api 2 bmi_id N/A crc32 
> 6535d835
> [   13.376455] ath10k_pci :01:00.0: 10.4 wmi init: vdevs: 16  peers: 48  
> tid: 96
> [   13.376509] ath10k_pci :01:00.0: msdu-desc: 2500  skid: 32
> [   13.430886] ath10k_pci :01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 
> T 186  msdu-desc: 2500  sw-crypt: 0 ct-sta: 0'
> [   13.431809] ath10k_pci :01:00.0: wmi print 'free: 114572 iram: 12644 
> sram: 29508'
> [   13.628632] ath10k_pci :01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal 
> file max-sta 32 raw 0 hwcrypto 1

Thank you! This ID matches a 9888 V2. It booted with the "cal file"
with no problem.

Cheers,
Christian

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

Re: OpenWrt 21.02 and 19.07 minor release

[Hauke Mehrtens]

On 2/13/22 01:26, Hauke Mehrtens wrote:

On 2/10/22 16:12, Seo Suchan wrote:

looks like those dnsmasq exploits aren't real

bugs never looked by human (no commit related by it), but bots 
confirmed that thoses look fixed by commit 
011f8cf1d011ade2f9e7231fca3cabfb1e8eaf06


https://oss-fuzz.com/revisions?job=afl_asan_dnsmasq=202112300601:202201020605 
 



when I read that commit it looks like 2.86 had bug that faild to build 
on gcc 4.8 and it caused fuzzer to get immediately crash, producing 
bunch of 'exploits'


Thanks for that information. Do you know about some official statement 
about this?


I fixed some other problems in OpenWrt 21.02:
* Linux: update to latests minor version
* hostapd: backport the patches
* wolfssl: update to recent version
* tcpdump: backport a patch
* mbedtls: update to new LTS version
* glibc: Update to latest minor version


The OpenWrt 21.02 and 19.07 branches are looking fine to me.
I am still waiting for some LuCI backports from Jo and would like to tag 
and build the next minor releases tomorrow or some days later depending 
on when Jo finishes the backports.


@Rosen: You wanted to update ksmbd in the feeds. Is there already a pull 
request and will you merge it or should I merge it shortly before tagging?


I asked on the dnsmasq mailing list about the CVEs we saw. My current 
plan is to ignore them.


Is there anything else missing?

Hauke

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

Re: bcm63xx kernel 5.10

[Florian Fainelli]

On 2/14/22 11:07 AM, Hauke Mehrtens wrote:
> On 2/4/22 00:48, Hauke Mehrtens wrote:
>> Hi,
>>
>> We would like to switch the bcm63xx target to kernel 5.10. Paul
>> created a pull request for that:
>> https://github.com/openwrt/openwrt/pull/4616
>>
>> There is still a problem with Macronix NAND flash chips, see the
>> comments from the pull request.
>>
>> Could someone please have a look into this problem.
>>
>> Does this change in the upstream kernel help?
>> https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530
>>
>>
>> Hauke
> 
> Hi,
> 
> I read that Daniel's device is now completely broken, probably
> bootloader was overwritten.
> 
> The bcm63xx target is the last one using kernel 5.4. We would like to
> remove kernel 5.4 support from OpenWrt master soon and branch off the
> next major release. How do we want to go forward with this topic?
> 
> Should we apply this hack?

I would be inclined to apply this hack and make it bcm63xx specific
unless other platforms suffer from that problem.

Meanwhile, I would reach out to the MTD maintainers to understand what
is going on, mentioning what we have found, which is that the brcmnand
controller prior to version 4.0 does not support the {GET,SET}_FEATURES
command.

Daniel, any hope of recovering your device somehow?
-- 
Florian

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

Re: bcm63xx kernel 5.10

[Hauke Mehrtens]

On 2/4/22 00:48, Hauke Mehrtens wrote:

Hi,

We would like to switch the bcm63xx target to kernel 5.10. Paul created 
a pull request for that:

https://github.com/openwrt/openwrt/pull/4616

There is still a problem with Macronix NAND flash chips, see the 
comments from the pull request.


Could someone please have a look into this problem.

Does this change in the upstream kernel help?
https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 



Hauke


Hi,

I read that Daniel's device is now completely broken, probably 
bootloader was overwritten.


The bcm63xx target is the last one using kernel 5.4. We would like to 
remove kernel 5.4 support from OpenWrt master soon and branch off the 
next major release. How do we want to go forward with this topic?


Should we apply this hack?
---
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -323,7 +323,7 @@

macronix_nand_fix_broken_get_timings(chip);
macronix_nand_onfi_init(chip);
-   macronix_nand_block_protection_support(chip);
+   //macronix_nand_block_protection_support(chip);
macronix_nand_deep_power_down_support(chip);

return 0;
---
https://github.com/openwrt/openwrt/pull/4616
Will this workaround the problem?
Can we expect a real fix soon?

Should we remove the bcm63xx target for from the next release?

If the hack works, I would prefer to apply it and switch bcm63xx to 
kernel 5.10 too. If someone finds a real fix for the problem we should 
apply the real fix and remove the hack.


Hauke

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

Re: [PATCH] ipq40xx: limit available radio channels for GL.iNet GL-B2200

[Enrico Mioso]

Hello!!

Here are the logs! :)

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.10.87 (mrkiko@mStation) 
(arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2.0 r18394+1-962c585580) 
11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Wed Dec 22 19:13:00 2021
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: GL.iNet GL-B2200
[0.00] Memory policy: Data cache writealloc
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x8000-0x9fff]
[0.00]   HighMem  empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8000-0x87df]
[0.00]   node   0: [mem 0x87e0-0x87ff]
[0.00]   node   0: [mem 0x8800-0x9fff]
[0.00] Initmem setup node 0 [mem 0x8000-0x9fff]
[0.00] On node 0 totalpages: 131072
[0.00]   Normal zone: 1152 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 131072 pages, LIFO batch:31
[0.00] percpu: Embedded 15 pages/cpu s30732 r8192 d22516 u61440
[0.00] pcpu-alloc: s30732 r8192 d22516 u61440 alloc=15*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 129920

[0.00] Kernel command line: rootfsname=rootfs rootwait 
root=/dev/mmcblk0p2 rw rootwait clk_ignore_unused
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, 
linear)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] Memory: 506832K/524288K available (6164K kernel code, 601K 
rwdata, 1548K rodata, 1024K init, 237K bss, 17456K reserved, 0K cma-reserved, 
0K highmem)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] rcu: Hierarchical RCU implementation.
[0.00]  Tracing variant of Tasks RCU enabled.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 
jiffies.
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] random: get_random_bytes called from start_kernel+0x360/0x50c 
with crng_init=0
[0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
[0.09] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps every 
4398046511096ns
[0.25] Switching to timer-based delay loop, resolution 20ns
[0.000248] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 96.00 BogoMIPS (lpj=48)
[0.000273] pid_max: default: 32768 minimum: 301
[0.000459] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, 
linear)
[0.000480] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, 
linear)
[0.001477] CPU: Testing write buffer coherency: ok
[0.001770] qcom_scm: convention: smc legacy
[0.002513] Setting up static identity map for 0x8030 - 0x8030003c
[0.002646] rcu: Hierarchical SRCU implementation.
[0.002853] dyndbg: Ignore empty _ddebug table in a 
CONFIG_DYNAMIC_DEBUG_CORE build
[0.003114] smp: Bringing up secondary CPUs ...
[0.006201] smp: Brought up 1 node, 4 CPUs
[0.006226] SMP: Total of 4 processors activated (384.00 BogoMIPS).
[0.006235] CPU: All CPU(s) started in SVC mode.
[0.011441] VFP support v0.3: implementor 41 architecture 2 part 30 variant 
7 rev 5
[0.011606] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.011636] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[0.011868] pinctrl core: initialized pinctrl subsystem
[0.013091] NET: Registered protocol family 16
[0.013482] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.014609] thermal_sys: Registered thermal governor 'step_wise'
[0.015003] cpuidle: using governor ladder
[0.015063] cpuidle: using governor menu
[0.041279] cryptd: max_cpu_qlen set to 1000
[0.044876] usbcore: registered new interface driver usbfs
[0.044950] usbcore: registered new interface driver hub
[0.045011] usbcore: registered new device driver usb
[0.045061] pps_core: LinuxPPS API ver. 1 registered
[0.045073] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti 

[0.045100] PTP clock support registered
[0.046828] clocksource: Switched to clocksource arch_sys_counter
[0.047779] NET: Registered protocol family 2
[0.047953] IP idents hash table 

Re: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes

[Torsten Duwe]

On Sat, 12 Feb 2022 02:05:17 +0100
Mathias Kresin  wrote:

> 
> 2/11/22 23:39, kestrel1...@t-online.de:
> > Hi,
> > 
> > I have created a new PR:
> > https://github.com/openwrt/openwrt/pull/5074
> > 
> > Which also includes a remote processor framework kernel module,

Cramming it all into one big commit makes it hard to review and test.
LKML is therefore pretty strict to receive minimal changes that do not
break anything (-> bisect); I tried to transform the required changes
accordingly.

The WiFi system has the same architecture, sure, so it can be compiled
by the same toolchain. OTOH, the main system has everything but WiFi,
and the secondary system has nothing but WiFi, so I doubt that
compiling both kernels from one source is a good thing, unless the
kernel code memory can be physically shared (haven't checked), or the
whole kernel can be properly modularised.
This should be discussed first, and in the meantime discrete support
patches for the main system should be acceptable.

[...]

> > Looking at your submitted patches, many fritzbox devices have
> > different NAND manufacturers.

The question is, does their geometry differ across specimen of the same
model? Maybe with different manufacturing runs?

> >  So the best way is to support all.

No contradiction from my side.

> > I created a DTB and image configuration for Micron and non Micron
> > NAND. This is probably the best way and not supporting just one
> > NAND type per device. Unfortunately auto detection was not accepted
> > by the kernel maintainers, so there is no other solution.
> > 
> > I also saw the addition of ubifs. I have not used this so far and I
> > wonder what the advantage is over using squashfs with overlay?
> 
> Let me cite https://en.wikipedia.org/wiki/UBIFS
> 
> - tracking NAND flash bad blocks
> - providing wear leveling
> 
> NAND is a rather unreliable type of flash, hence some special
> treatment has to be done to make it last as long as possible.

Yes, I somehow had gotten the impression that UBI was mandatory for
OpenWRT ports to new devices with NAND, so I went that way.

Is sysupgrade prepared for squashfs+overlay as UBI volumes?

Torsten


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

Re: [PATCH v3 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet

[Arınç ÜNAL]

On 14/02/2022 12:30, Sander Vanheule wrote:

On Sun, 2022-02-13 at 19:23 +0300, Arınç ÜNAL wrote:

On 13/02/2022 17:14, Sander Vanheule wrote:

[snip]


Are you sure this is the only way to make this work? Overwriting a
default in this
many
files doesn't make it look like a great default. This is probably
happening because
these


This is actually a minority of devicetrees. 26 opposed to 156 (minus
devicetrees that #include any of the 26 devicetrees) which use all 3 pin
groups on ethernet.

It's also upstreamed so I'd like to stick with it as much as I can.
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=0a93c0d75809582893e82039143591b9265b520e


files already specify rgmii2 to be used with the GPIO function, and
you're causing
some
sort of race as to what setting gets applied in the end, by adding
rmgii2_pins to the
default state for the  node.


Agreed:

[    1.177349] rt2880-pinmux pinctrl: pin io22 already requested by
pinctrl; cannot claim for 1e10.ethernet
[    1.196966] rt2880-pinmux pinctrl: pin-22 (1e10.ethernet) status -
22
[    1.210312] rt2880-pinmux pinctrl: could not request pin 22 (io22)
from group rgmii2  on device rt2880-pinmux
[    1.230058] mtk_soc_eth 1e10.ethernet: Error applying setting,
reverse things back
[    1.245853] mtk_soc_eth: probe of 1e10.ethernet failed with error -
22

That's why I overwrite the property without it for the 26 devicetrees.


An alternative would be to add the rgmii2 configuration to _default
node only on the
devices where it is actually required.

     _default {
 gpio {
 groups = /* gpio groups */
 function = "gpio";
 };
 
 gmac1 {

 groups = "rgmii2";
 function = "rgmii2";
 };
     };


That would mean I'd have to do this on ~70 devicetrees (instead of 26 as
originally proposed) which I'm going to mux PHY 0 or 4 to GMAC1 with my
next patch.


That doesn't sound great either.



Secondly, the default mode for the rgmii2 pin group is the SoC function
(which is "rgmii2") and not gpio. To add to this, the majority of the
devicetrees use the SoC function for rgmii2 so we're already doing the
most minimal changes with the current patch.


Not sure what you mean by this. So the "rgmii2" function is normally the
default, but you want to make this explicit by adding it the the  node?


It's not explicitly giving it the rgmii2 function (since it's already 
there on mt7621.dtsi) but rather have the rgmii2 pin group called from 
the ethernet node so traffic can flow on the rgmii2 bus. I explained 
this in detail on my response to Bjørn here:


http://lists.openwrt.org/pipermail/openwrt-devel/2022-February/037939.html
http://lists.openwrt.org/pipermail/openwrt-devel/2022-February/037949.html



_default does not refer to the SoC's default HW state, but to the device's
actual configuration. To be really 'clean', I would say the "default" state (as
in 'pinctrl-names = "default"') of the GPIO node should be the one indicating
which groups are to be configured as GPIO, as _default is the "default"
state of the pin controller. But such a change is probably out of scope for this
patch series.


Correct.











What would make more sense to me, is if the rgmii settings could be
enabled in the
gmac-s
themselves:

   {
  pinctrl-names = "default";
  pinctrl-0 = <_pins>, <_pins>;
  }
  
   {

  /* Has state = "disabled" by default */
  pinctrl-names = "default";
  pinctrl-0 = <_pins>, <_pins>;
  }

That way, if the pinctrl-s are processed properly, the rgmii2_pins
setting would be
applied automatically when gmac1 is enabled. mdio_pins would be applied
when either
(or
both) gmac-s is (are) active.


This is also what I thought would be best but unfortunately that won't
work. Please read the responses on this thread:
https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd...@arinc9.com/T/


Right, I think you've pointed this out already a few times.Sorry for the
noise, I should've re-read that thread before replying. :)

Since these gmac-s are always internal to the SoC, pinctrl properties should
make sense
there. Did you investigate why these settings don't get applied?


No, and I don't think I'm capable of doing so (not much of a code reader
I'm not).


I had a brief look at the code (elixir.bootlin.org is very convenient for
browsing the kernel), and it appears that while 'ethernet' is probed by the
kernel as a proper device, the gmac nodes aren't. That means you don't get the
automatic kernel machinery that comes associated with device probing, which
includes pinctrl configuration. The gmac nodes are probed by the ethernet driver
itself, and although that performs pinctrl operations on the main device
('ethernet' node), it doesn't do this for the gmac-s. It probably could do this,
but I have no idea whether that would be acceptable, and is 

Re: [PATCH v3 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet

[Sander Vanheule]

On Sun, 2022-02-13 at 19:23 +0300, Arınç ÜNAL wrote:
> On 13/02/2022 17:14, Sander Vanheule wrote:
> 
> [snip]
> 
> > > > Are you sure this is the only way to make this work? Overwriting a
> > > > default in this
> > > > many
> > > > files doesn't make it look like a great default. This is probably
> > > > happening because
> > > > these
> > > 
> > > This is actually a minority of devicetrees. 26 opposed to 156 (minus
> > > devicetrees that #include any of the 26 devicetrees) which use all 3 pin
> > > groups on ethernet.
> > > 
> > > It's also upstreamed so I'd like to stick with it as much as I can.
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=0a93c0d75809582893e82039143591b9265b520e
> > > 
> > > > files already specify rgmii2 to be used with the GPIO function, and
> > > > you're causing
> > > > some
> > > > sort of race as to what setting gets applied in the end, by adding
> > > > rmgii2_pins to the
> > > > default state for the  node.
> > > 
> > > Agreed:
> > > 
> > > [    1.177349] rt2880-pinmux pinctrl: pin io22 already requested by
> > > pinctrl; cannot claim for 1e10.ethernet
> > > [    1.196966] rt2880-pinmux pinctrl: pin-22 (1e10.ethernet) status -
> > > 22
> > > [    1.210312] rt2880-pinmux pinctrl: could not request pin 22 (io22)
> > > from group rgmii2  on device rt2880-pinmux
> > > [    1.230058] mtk_soc_eth 1e10.ethernet: Error applying setting,
> > > reverse things back
> > > [    1.245853] mtk_soc_eth: probe of 1e10.ethernet failed with error -
> > > 22
> > > 
> > > That's why I overwrite the property without it for the 26 devicetrees.
> > 
> > An alternative would be to add the rgmii2 configuration to _default
> > node only on the
> > devices where it is actually required.
> > 
> >     _default {
> > gpio {
> > groups = /* gpio groups */
> > function = "gpio";
> > };
> >     
> > gmac1 {
> > groups = "rgmii2";
> > function = "rgmii2";
> > };
> >     };
> 
> That would mean I'd have to do this on ~70 devicetrees (instead of 26 as 
> originally proposed) which I'm going to mux PHY 0 or 4 to GMAC1 with my 
> next patch.

That doesn't sound great either.


> Secondly, the default mode for the rgmii2 pin group is the SoC function 
> (which is "rgmii2") and not gpio. To add to this, the majority of the 
> devicetrees use the SoC function for rgmii2 so we're already doing the 
> most minimal changes with the current patch.

Not sure what you mean by this. So the "rgmii2" function is normally the
default, but you want to make this explicit by adding it the the  node?

_default does not refer to the SoC's default HW state, but to the device's
actual configuration. To be really 'clean', I would say the "default" state (as
in 'pinctrl-names = "default"') of the GPIO node should be the one indicating
which groups are to be configured as GPIO, as _default is the "default"
state of the pin controller. But such a change is probably out of scope for this
patch series.

> 
> > 
> > > 
> > > > 
> > > > What would make more sense to me, is if the rgmii settings could be
> > > > enabled in the
> > > > gmac-s
> > > > themselves:
> > > > 
> > > >   {
> > > >  pinctrl-names = "default";
> > > >  pinctrl-0 = <_pins>, <_pins>;
> > > >  }
> > > >  
> > > >   {
> > > >  /* Has state = "disabled" by default */
> > > >  pinctrl-names = "default";
> > > >  pinctrl-0 = <_pins>, <_pins>;
> > > >  }
> > > > 
> > > > That way, if the pinctrl-s are processed properly, the rgmii2_pins
> > > > setting would be
> > > > applied automatically when gmac1 is enabled. mdio_pins would be applied
> > > > when either
> > > > (or
> > > > both) gmac-s is (are) active.
> > > 
> > > This is also what I thought would be best but unfortunately that won't
> > > work. Please read the responses on this thread:
> > > https://lore.kernel.org/netdev/83a35aa3-6cb8-2bc4-2ff4-64278bbcd...@arinc9.com/T/
> > 
> > Right, I think you've pointed this out already a few times.Sorry for the
> > noise, I should've re-read that thread before replying. :)
> > 
> > Since these gmac-s are always internal to the SoC, pinctrl properties should
> > make sense
> > there. Did you investigate why these settings don't get applied?
> 
> No, and I don't think I'm capable of doing so (not much of a code reader 
> I'm not).

I had a brief look at the code (elixir.bootlin.org is very convenient for
browsing the kernel), and it appears that while 'ethernet' is probed by the
kernel as a proper device, the gmac nodes aren't. That means you don't get the
automatic kernel machinery that comes associated with device probing, which
includes pinctrl configuration. The gmac nodes are probed by the ethernet driver
itself, and although that performs pinctrl operations on the main device
('ethernet' node), it doesn't do this for the gmac-s. It probably could do 

Re: [PATCH] ipq40xx: limit available radio channels for GL.iNet GL-B2200

[Enrico Mioso]

Hi!!

Sory for me taking so long to answer, and provide the information.

I promise I'll do so at the end of the week; youcan find some bootlogs in the 
GitHub PR from where I started, but I'll provide fresh logs at the end of the 
week, since I will also need to test DS transition for this board.
In the meantime, you may have a look at:
https://github.com/openwrt/openwrt/issues/4691

Thanks for your help! :)

On Fri, 11 Feb 2022, Christian Lamparter wrote:


Date: Fri, 11 Feb 2022 18:06:21
From: Christian Lamparter 
To: Enrico Mioso , openwrt-devel@lists.openwrt.org
Subject: Re: [PATCH] ipq40xx: limit available radio channels for GL.iNet
GL-B2200

On 11/02/2022 10:46, Enrico Mioso wrote:

The PCIe and built-in 5GHZ radios are meant to operate on different
frequency bands. The hardware enforces this via RF filters.
Add this information to allow software enforcing it as well.
Credits to Piotr Dymacz for the invaluable help.

Signed-off-by: Enrico Mioso 
---
Also due to the nature of this patch, testing it might not be easy.
Still, applying it shoudn't cause issues, as the only uncertainty is 
whether we will need to stricter the limits. So I think this should go in.


Somewhat related question: (though, it's about the board itself)

Do you have the board? Can you tell me the pciid of the PCIe ath10k chip,
or a bootlog?

I'm asking because when I was converting it to nvmem
(see commit cfc13c44595db591092859fc6adc71f1d8159c50),
I noticed that the board-data-extraction used the
WAVE-1 files. However GL.iNet says it's a WAVE-2 9886 chip.

Thanks,
Christian


---
  .../ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts   | 2 ++
  1 file changed, 2 insertions(+)

diff --git 
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts 
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts

index 243dcb84d6..754af7c820 100644
--- 
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts
+++ 
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts

@@ -367,6 +367,7 @@
nvmem-cell-names = "calibration";
nvmem-cells = <_art_9000>;
qcom,ath10k-calibration-variant = "GL-B2200";
+   ieee80211-freq-limit = <545 590>;
};
};
  };
@@ -383,4 +384,5 @@
nvmem-cell-names = "pre-calibration";
nvmem-cells = <_art_5000>;
qcom,ath10k-calibration-variant = "GL-B2200";
+   ieee80211-freq-limit = <510 540>;
  };





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