[OpenWrt-Devel] [PATCH v5] kernel: lantiq: add support for SMP IRQ routing
Some lantiq SoCs have multiple VPE support but no support for the IRQ
routing, so only the first VPE is receiving interrupts. This patch adds
support for rerouting interrupts to the other VPE. Basically it expands
the current ICU driver for the second controller, adds new address
ranges to the devicetree and fixes the interrupt masking on the second
core.
Some reg access locking was added too.
The mode of the operation is that userdefined IRQ affinity CPU mask is
either cycled between VPEs in every IRQ enable call
(AUTO_AFFINITY_ROTATION), or only the first VPE from affinity CPU mask
is used (AUTO_AFFINITY_ROTATION not defined).
Tested on TD-W9980B device (both VPEs used as linux CPUs).
Signed-off-by: Petr Cvek
---
.../0901-add-icu-smp-support.patch| 436 ++
1 file changed, 436 insertions(+)
create mode 100644
target/linux/lantiq/patches-4.14/0901-add-icu-smp-support.patch
diff --git
a/target/linux/lantiq/patches-4.14/0901-add-icu-smp-support.patch
b/target/linux/lantiq/patches-4.14/0901-add-icu-smp-support.patch
new file mode 100644
index 00..eaefdf27a3
--- /dev/null
+++ b/target/linux/lantiq/patches-4.14/0901-add-icu-smp-support.patch
@@ -0,0 +1,436 @@
+--- a/arch/mips/lantiq/irq.c 2019-03-10 20:44:58.755134326 +0100
b/arch/mips/lantiq/irq.c 2019-05-17 05:13:50.302149058 +0200
+@@ -22,14 +22,21 @@
+ #include
+ #include
+ ++/*
++ * If defined, every IRQ enable call will switch the interrupt to
++ * the other VPE. You can limit used VPEs from the userspace.
++ *
++ * If not defined, only the first configured VPE from the userspace
++ * will be used.
++ */
++#define AUTO_AFFINITY_ROTATION
++
+ /* register definitions - internal irqs */
+-#define LTQ_ICU_IM0_ISR 0x
+-#define LTQ_ICU_IM0_IER 0x0008
+-#define LTQ_ICU_IM0_IOSR 0x0010
+-#define LTQ_ICU_IM0_IRSR 0x0018
+-#define LTQ_ICU_IM0_IMR 0x0020
+-#define LTQ_ICU_IM1_ISR 0x0028
+-#define LTQ_ICU_OFFSET(LTQ_ICU_IM1_ISR - LTQ_ICU_IM0_ISR)
++#define LTQ_ICU_ISR 0x
++#define LTQ_ICU_IER 0x0008
++#define LTQ_ICU_IOSR 0x0010
++#define LTQ_ICU_IRSR 0x0018
++#define LTQ_ICU_IMR 0x0020
+ + /* register definitions - external irqs */
+ #define LTQ_EIU_EXIN_C0x
+@@ -49,24 +56,27 @@
+ */
+ #define LTQ_ICU_EBU_IRQ 22
+ +-#define ltq_icu_w32(m, x, y)ltq_w32((x), ltq_icu_membase[m] + (y))
+-#define ltq_icu_r32(m, x) ltq_r32(ltq_icu_membase[m] + (x))
++#define ltq_icu_w32(vpe, m, x, y) \
++ ltq_w32((x), ltq_icu_membase[vpe] + m*0x28 + (y))
++
++#define ltq_icu_r32(vpe, m, x)\
++ ltq_r32(ltq_icu_membase[vpe] + m*0x28 + (x))
+ + #define ltq_eiu_w32(x, y) ltq_w32((x), ltq_eiu_membase + (y))
+ #define ltq_eiu_r32(x)ltq_r32(ltq_eiu_membase + (x))
+ +-/* our 2 ipi interrupts for VSMP */
+-#define MIPS_CPU_IPI_RESCHED_IRQ 0
+-#define MIPS_CPU_IPI_CALL_IRQ 1
+-
+ /* we have a cascade of 8 irqs */
+ #define MIPS_CPU_IRQ_CASCADE 8
+ ++#define MAX_VPES 2
++
+ static int exin_avail;
+ static u32 ltq_eiu_irq[MAX_EIU];
+-static void __iomem *ltq_icu_membase[MAX_IM];
++static void __iomem *ltq_icu_membase[MAX_VPES];
+ static void __iomem *ltq_eiu_membase;
+ static struct irq_domain *ltq_domain;
++static DEFINE_SPINLOCK(ltq_eiu_lock);
++static DEFINE_RAW_SPINLOCK(ltq_icu_lock);
+ static int ltq_perfcount_irq;
+ + int ltq_eiu_get_irq(int exin)
+@@ -78,50 +88,104 @@
+ + void ltq_disable_irq(struct irq_data *d)
+ {
+- u32 ier = LTQ_ICU_IM0_IER;
+- int offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
+- int im = offset / INT_NUM_IM_OFFSET;
++ unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
++ unsigned long im = offset / INT_NUM_IM_OFFSET;
++ unsigned int vpe;
++ unsigned long flags;
+ + offset %= INT_NUM_IM_OFFSET;
+- ltq_icu_w32(im, ltq_icu_r32(im, ier) & ~BIT(offset), ier);
++
++ raw_spin_lock_irqsave(_icu_lock, flags);
++ for_each_present_cpu(vpe) {
++ ltq_icu_w32(vpe, im,
++ ltq_icu_r32(vpe, im, LTQ_ICU_IER) & ~BIT(offset),
++ LTQ_ICU_IER);
++ }
++ raw_spin_unlock_irqrestore(_icu_lock, flags);
+ }
+ + void ltq_mask_and_ack_irq(struct irq_data *d)
+ {
+- u32 ier = LTQ_ICU_IM0_IER;
+- u32 isr = LTQ_ICU_IM0_ISR;
+- int offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
+- int im = offset / INT_NUM_IM_OFFSET;
++ unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
++ unsigned long im = offset / INT_NUM_IM_OFFSET;
++ unsigned int vpe;
++ unsigned long flags;
+ + offset %= INT_NUM_IM_OFFSET;
+- ltq_icu_w32(im, ltq_icu_r32(im, ier) & ~BIT(offset), ier);
+- ltq_icu_w32(im, BIT(offset), isr);
++
++ raw_spin_lock_irqsave(_icu_lock, flags);
++ for_each_present_cpu(vpe) {
++ ltq_icu_w32(vpe, im,
++
Re: [OpenWrt-Devel] [PATCH] libbsd: Fix compilation under ARC
On Fri, May 3, 2019 at 12:11 PM Rosen Penev wrote: > > > On Fri, May 3, 2019 at 11:55 AM, Petr Štetiar wrote: > > Rosen Penev [2019-05-03 10:49:54]: > > > On May 3, 2019, at 10:17, Petr Štetiar wrote: > > Rosen > > Penev [2019-05-01 10:04:45]: > >> The 8 year old file > > does not have any ARC definitions. > > I'm wondering if we need to cary > > another patch forever, thus if it wouldn't be > better to backport > > upstreamed patch and/or bump to fixed upstream version. As I said. This > > file has not been touched in 8 years. Upstream also seems relatively dead. > > According to this https://gitlab.freedesktop.org/libbsd/libbsd it doesn't > seem that much dead to me, as I wouldn't expect that much changes in such > compat library anyway. > > All of the merge requests (what GitLab calls pull requests) except one have > no comments. There are also none that have actually been merged. Added merge request here: https://gitlab.freedesktop.org/libbsd/libbsd/merge_requests/6 > > -- ynezz > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lua: lnum: fix strtoul based number parsing
From: Liangbin Lian
Lua's LNUM patch currently doesn't parse properly certain numbers as
it's visible from the following simple tests.
On x86_64 host (stock Lua 5.1.5, expected output):
$ /usr/bin/lua -e 'print(0x8000); print(0x800); print(0x1)'
2147483648
8796093022208
4294967296
On x86_64 host:
$ staging_dir/hostpkg/bin/lua -e 'print(0x8000); print(0x800);
print(0x1)'
-2147483648
0
0
On x86_64 target:
$ lua -e 'print(0x8000); print(0x800); print(0x1)'
-2147483648
0
0
On ath79 target:
$ lua -e 'print(0x8000); print(0x800); print(0x1)'
-2147483648
8796093022208
4294967296
It's caused by two issues fixed in this patch, first issue is caused by
unhadled strtoul overflow and second one is caused by the cast of
unsigned to signed Lua integer when parsing from hex literal.
Run tested on:
* Zidoo Z9S with RTD1296 CPU (aarch64_cortex-a53)
* qemu/x86_64
* qemu/armvirt_64
* ath79
Signed-off-by: Liangbin Lian
[commit subject/message touches, fixed From to match SOB, fixed another
unhandled case in luaO_str2i, host Lua, package bump]
Signed-off-by: Petr Štetiar
---
This patch originated in https://github.com/openwrt/openwrt/pull/2067 and I'm
sending it for the review and testing to the mailing list as well, since I
consider Lua as a core building block, so the more eyes, the better.
package/utils/lua/Makefile | 2 +-
.../013-lnum-strtoul-parsing-fixes.patch | 48 ++
.../patches/013-lnum-strtoul-parsing-fixes.patch | 48 ++
3 files changed, 97 insertions(+), 1 deletion(-)
create mode 100644
package/utils/lua/patches-host/013-lnum-strtoul-parsing-fixes.patch
create mode 100644
package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch
diff --git a/package/utils/lua/Makefile b/package/utils/lua/Makefile
index c34e569b67a7..077a60fbf3e8 100644
--- a/package/utils/lua/Makefile
+++ b/package/utils/lua/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=lua
PKG_VERSION:=5.1.5
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
diff --git
a/package/utils/lua/patches-host/013-lnum-strtoul-parsing-fixes.patch
b/package/utils/lua/patches-host/013-lnum-strtoul-parsing-fixes.patch
new file mode 100644
index ..7f00c8c3a2df
--- /dev/null
+++ b/package/utils/lua/patches-host/013-lnum-strtoul-parsing-fixes.patch
@@ -0,0 +1,48 @@
+diff --git a/src/lnum.c b/src/lnum.c
+index 1456b6a2ed23..b0632b04c2b7 100644
+--- a/src/lnum.c
b/src/lnum.c
+@@ -127,6 +127,8 @@ static int luaO_str2i (const char *s, lua_Integer *res,
char **endptr_ref) {
+ #else
+ return 0; /* Reject the number */
+ #endif
++} else if (v > LUA_INTEGER_MAX) {
++ return TK_NUMBER;
+ }
+ } else if ((v > LUA_INTEGER_MAX) || (*endptr && (!isspace(*endptr {
+ return TK_NUMBER; /* not in signed range, or has '.', 'e' etc. trailing */
+@@ -310,3 +312,13 @@ int try_unmint( lua_Integer *r, lua_Integer ib ) {
+ return 0;
+ }
+
++#ifdef LONG_OVERFLOW_LUA_INTEGER
++unsigned LUA_INTEGER lua_str2ul( const char *str, char **endptr, int base ) {
++ unsigned long v= strtoul(str, endptr, base);
++ if ( v > LUA_INTEGER_MAX ) {
++errno= ERANGE;
++v= ULONG_MAX;
++ }
++ return (unsigned LUA_INTEGER)v;
++}
++#endif
+diff --git a/src/lnum_config.h b/src/lnum_config.h
+index 19d7a4231a49..1092eead6629 100644
+--- a/src/lnum_config.h
b/src/lnum_config.h
+@@ -141,7 +141,12 @@
+ #endif
+
+ #ifndef lua_str2ul
+-# define lua_str2ul (unsigned LUA_INTEGER)strtoul
++# if LONG_MAX > LUA_INTEGER_MAX
++# define LONG_OVERFLOW_LUA_INTEGER
++unsigned LUA_INTEGER lua_str2ul( const char *str, char **endptr, int base
);
++# else
++# define lua_str2ul (unsigned LUA_INTEGER)strtoul
++# endif
+ #endif
+ #ifndef LUA_INTEGER_MIN
+ # define LUA_INTEGER_MIN (-LUA_INTEGER_MAX -1) /* -2^16|32 */
+--
+1.9.1
+
diff --git a/package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch
b/package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch
new file mode 100644
index ..7f00c8c3a2df
--- /dev/null
+++ b/package/utils/lua/patches/013-lnum-strtoul-parsing-fixes.patch
@@ -0,0 +1,48 @@
+diff --git a/src/lnum.c b/src/lnum.c
+index 1456b6a2ed23..b0632b04c2b7 100644
+--- a/src/lnum.c
b/src/lnum.c
+@@ -127,6 +127,8 @@ static int luaO_str2i (const char *s, lua_Integer *res,
char **endptr_ref) {
+ #else
+ return 0; /* Reject the number */
+ #endif
++} else if (v > LUA_INTEGER_MAX) {
++ return TK_NUMBER;
+ }
+ } else if ((v > LUA_INTEGER_MAX) || (*endptr && (!isspace(*endptr {
+ return TK_NUMBER; /* not in signed range, or has '.', 'e' etc. trailing */
+@@ -310,3 +312,13 @@ int try_unmint( lua_Integer *r, lua_Integer ib ) {
+ return 0;
+ }
+
++#ifdef LONG_OVERFLOW_LUA_INTEGER
++unsigned
Re: [OpenWrt-Devel] [PATCH] mvebu: Add support for kernel 4.19
On Thu, 16 May 2019 22:35:35 +0200 Tomasz Maciej Nowak wrote: > Hi Marek, > > W dniu 16.05.2019 o 20:38, Marek Behún pisze: > > Add support for kernel 4.19 to the mvebu target. > > > > This is the first version, unfortunately I only have Turris Omnia and > > Turris Mox to test this on, and Turris Mox is not yet supported in these > > patches. > > You beat me to it, but not only You > https://github.com/openwrt/openwrt/pull/1646. > Only recently I had time to look at it and this: > https://github.com/tmn505/openwrt/tree/mvebu-4.19 > is my shot at it (based on initial Marko Ratkaj work). I asked Sébastien in > mentioned PR on GitHub if I can send it here. > > Just yesterday and today I got report from owners of WRT1900AC and WRT32X > that their > NAND chips are working: > https://forum.openwrt.org/t/kernel-4-19-upgrade-issue-on-mvebu-target-s/32966/32 > https://forum.openwrt.org/t/kernel-4-19-upgrade-issue-on-mvebu-target-s/32966/34 > So it seems that most difficult devices are working. Unfortunately I don't > have > anything with SFP, so would be nice to know if anything needs to be added. > > > > > So if you guys could try this and give feedback. > > Most of the kept patches are similar and on ESPRESSObin everything seems to > work OK. This is not only ESPRESSObin but also the 32 bit mvebu devices. Ok, I will probably try to merge my changes with those in those pull requests. Should I then open a github pull request? Or send a patch series via email? Marek ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mvebu: Add support for kernel 4.19
On Thu, 16 May 2019 22:35:35 +0200 Tomasz Maciej Nowak wrote: > What I would like to ask is if You've had also link training issues with PCIe > port > and particular Atheros/Qualcomm (AR3890, QCA9890) wifi cards on Turris MOX? > Which we > work around with these patches: > 527-PCI-aardvark-allow-to-specify-link-capability.patch > 528-arm64-dts-armada-3720-espressobin-set-max-link-to-ge.patch > Or do You use different chip vendors? Hi Tomasz, yes, the problematic chipsets are 9880 and 9890. Forcing link to PCIe 1.0 did not help on Turris Mox. After weeks of playing with the card I discovered that it could be solved by tweaking the length of the PERST signal (reset-gpios) in the aardvark driver. This is how I made it work on 4.14 on Turris Mox. On 4.19 it is not needed, but with the new patches by Miquel Raynal which will be in kernel 5.2 or 5.3 (adding support for suspend/resume) this again breaks, because the PERST signal is manipulated differently. I did not solve this issue, but I think it will again be done via the PERST signal. Marek ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mvebu: Add support for kernel 4.19
Hi Marek,
W dniu 16.05.2019 o 20:38, Marek Behún pisze:
> Add support for kernel 4.19 to the mvebu target.
>
> This is the first version, unfortunately I only have Turris Omnia and
> Turris Mox to test this on, and Turris Mox is not yet supported in these
> patches.
You beat me to it, but not only You
https://github.com/openwrt/openwrt/pull/1646.
Only recently I had time to look at it and this:
https://github.com/tmn505/openwrt/tree/mvebu-4.19
is my shot at it (based on initial Marko Ratkaj work). I asked Sébastien in
mentioned PR on GitHub if I can send it here.
Just yesterday and today I got report from owners of WRT1900AC and WRT32X that
their
NAND chips are working:
https://forum.openwrt.org/t/kernel-4-19-upgrade-issue-on-mvebu-target-s/32966/32
https://forum.openwrt.org/t/kernel-4-19-upgrade-issue-on-mvebu-target-s/32966/34
So it seems that most difficult devices are working. Unfortunately I don't have
anything with SFP, so would be nice to know if anything needs to be added.
>
> So if you guys could try this and give feedback.
Most of the kept patches are similar and on ESPRESSObin everything seems to
work OK.
>
> This does not add default config for 4.19, this would also be needed.
There's not much to be added, simple refresh for cortexa9 kernel config should
do,
but cortexa53 and cortexa72 needs this ARM64_SVE added, so it won't error out
when
building.
>
> I manually went through all the patches from 4.14 and removed those
> which are already in 4.19 upstream. Those patches which did not apply I
> patched manually. One of them,
> 524-PCI-aardvark-set-host-and-device-to-the-same-MAX-payload-size.patch,
> could not be applied, because the code in pci-aardvark changed too much.
I reverted the c8e144f8ab ("PCI: aardvark: Convert to use pci_host_probe()")
which
was mostly code cleanup (that's how I understand it), after that the mentioned
patch
could still apply.
> Moreover upstream solved the issue this patch was solving differently
> (via pci-emul-bridge). I did not backport pci-emul-bridge, perhaps this
> would be needed (but is not on Turris Mox with its default PCIe card).
I didn't observe any issues with Aardvark driver from 4.19 with current
patches, so
I think we can leave that for next kernel bump.
What I would like to ask is if You've had also link training issues with PCIe
port
and particular Atheros/Qualcomm (AR3890, QCA9890) wifi cards on Turris MOX?
Which we
work around with these patches:
527-PCI-aardvark-allow-to-specify-link-capability.patch
528-arm64-dts-armada-3720-espressobin-set-max-link-to-ge.patch
Or do You use different chip vendors?
>
> I used new patches for SFP support from Russell King.
>
> Signed-off-by: Marek Behún
> Cc: Russell King
> Cc: Felix Fietkau
> Cc: Hauke Mehrtens
> Cc: Imre Kaloz
> Cc: Jeremiah McConnell
> Cc: Jonas Gorski
> Cc: Kevin Darbyshire-Bryant
> Cc: Koen Vandeputte
> Cc: Michael Gray
> Cc: Rosen Penev
> Cc: Ryan Mounce
> Cc: Stijn Segers
> Cc: Stijn Tintel
> Cc: Tomasz Maciej Nowak
Regards
--
TMN
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] interface-ip: fix find locally addressable target for p2p
Hi, the email replace TAB with SPACE, so apply failed. So, I put the patch file in my server http://167.88.124.64/0001-interface-ip-fix-find-locally-addressable-target-for.patch > > Hi > > On Thu, May 16, 2019 at 5:09 PM Tan Xiaofan wrote: > > > > Hi, I add some explanation to the patch > > > > From 57007eef77f266e40640a2c76aabd56fd37553f7 Mon Sep 17 00:00:00 2001 > > From: xiaofan > > Date: Thu, 16 May 2019 21:12:47 +0800 > > Subject: [PATCH] interface-ip: fix find locally addressable target for p2p > > > > In case of tunnel over PPP(such as gretap over l2tp): tunnel interface > > use PPP's peer address as remote address, netifd script will call > > proto_add_host_dependency function, then netifd will search which device > > can reach to the remote address. Before the patch, netifd don't consider > > the PPP interface can reach to the remote address, so netifd will select > > default route to remote address, it will lead to remote address unreachable. > The patch fails to apply with the updated commit description; please > resend after you've created the patch via git format-patch with the > updated git commit description > > Hans > > > > Signed-off-by: xiaofan > > --- > > interface-ip.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/interface-ip.c b/interface-ip.c > > index 6900cd7..8d5587c 100644 > > --- a/interface-ip.c > > +++ b/interface-ip.c > > @@ -196,6 +196,9 @@ __find_ip_addr_target(struct interface_ip_settings *ip, > > union if_addr *a, bool v > > if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6)) > > continue; > > > > + if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point) > > + return true; > > + > > /* Handle offlink addresses correctly */ > > unsigned int mask = addr->mask; > > if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 && > > -- > > 2.17.1 > > > > > > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] 回复: [PATCH] interface-ip: fix find locally addressable target for p2p
Hi, this is a new patch >From 66c6e2d739daf60c3d4336b6ec8fe24334ee44eb Mon Sep 17 00:00:00 2001 From: xiaofan Date: Fri, 17 May 2019 01:15:11 +0800 Subject: [PATCH] interface-ip: fix find locally addressable target for p2p In case of tunnel over PPP(such as gretap over l2tp): tunnel interface use PPP's peer address as remote address, netifd script will call proto_add_host_dependency function, then netifd will search which device can reach to the remote address. Before the patch, netifd don't consider the PPP interface can reach to the remote address, so netifd will select default route to remote address, it will lead to remote address unreachable. Signed-off-by: xiaofan --- interface-ip.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/interface-ip.c b/interface-ip.c index 6900cd7..8d5587c 100644 --- a/interface-ip.c +++ b/interface-ip.c @@ -196,6 +196,9 @@ __find_ip_addr_target(struct interface_ip_settings *ip, union if_addr *a, bool v if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6)) continue; + if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point) + return true; + /* Handle offlink addresses correctly */ unsigned int mask = addr->mask; if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 && -- 2.17.1 > > Hi > > On Thu, May 16, 2019 at 5:09 PM Tan Xiaofan wrote: > > > > Hi, I add some explanation to the patch > > > > From 57007eef77f266e40640a2c76aabd56fd37553f7 Mon Sep 17 00:00:00 2001 > > From: xiaofan > > Date: Thu, 16 May 2019 21:12:47 +0800 > > Subject: [PATCH] interface-ip: fix find locally addressable target for p2p > > > > In case of tunnel over PPP(such as gretap over l2tp): tunnel interface > > use PPP's peer address as remote address, netifd script will call > > proto_add_host_dependency function, then netifd will search which device > > can reach to the remote address. Before the patch, netifd don't consider > > the PPP interface can reach to the remote address, so netifd will select > > default route to remote address, it will lead to remote address unreachable. > The patch fails to apply with the updated commit description; please > resend after you've created the patch via git format-patch with the > updated git commit description > > Hans > > > > Signed-off-by: xiaofan > > --- > > interface-ip.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/interface-ip.c b/interface-ip.c > > index 6900cd7..8d5587c 100644 > > --- a/interface-ip.c > > +++ b/interface-ip.c > > @@ -196,6 +196,9 @@ __find_ip_addr_target(struct interface_ip_settings *ip, > > union if_addr *a, bool v > >if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6)) > > continue; > > > > + if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point) > > + return true; > > + > >/* Handle offlink addresses correctly */ > >unsigned int mask = addr->mask; > >if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 && > > -- > > 2.17.1 > > > > > > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] interface-ip: fix find locally addressable target for p2p
Hi
On Thu, May 16, 2019 at 5:09 PM Tan Xiaofan wrote:
>
> Hi, I add some explanation to the patch
>
> From 57007eef77f266e40640a2c76aabd56fd37553f7 Mon Sep 17 00:00:00 2001
> From: xiaofan
> Date: Thu, 16 May 2019 21:12:47 +0800
> Subject: [PATCH] interface-ip: fix find locally addressable target for p2p
>
> In case of tunnel over PPP(such as gretap over l2tp): tunnel interface
> use PPP's peer address as remote address, netifd script will call
> proto_add_host_dependency function, then netifd will search which device
> can reach to the remote address. Before the patch, netifd don't consider
> the PPP interface can reach to the remote address, so netifd will select
> default route to remote address, it will lead to remote address unreachable.
The patch fails to apply with the updated commit description; please
resend after you've created the patch via git format-patch with the
updated git commit description
Hans
>
> Signed-off-by: xiaofan
> ---
> interface-ip.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/interface-ip.c b/interface-ip.c
> index 6900cd7..8d5587c 100644
> --- a/interface-ip.c
> +++ b/interface-ip.c
> @@ -196,6 +196,9 @@ __find_ip_addr_target(struct interface_ip_settings *ip,
> union if_addr *a, bool v
>if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6))
> continue;
>
> + if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point)
> + return true;
> +
>/* Handle offlink addresses correctly */
>unsigned int mask = addr->mask;
>if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 &&
> --
> 2.17.1
>
>
>
>
> >
> > Hi,
> >
> > On Thu, May 16, 2019 at 4:01 PM Tan Xiaofan wrote:
> > >
> > > From d0e1cb81b45ec825199d499cda9c8daef94e13a5 Mon Sep 17 00:00:00 2001
> > > From: xiaofan
> > > Date: Thu, 16 May 2019 21:12:47 +0800
> > > Subject: [PATCH] interface-ip: fix find locally addressable target for p2p
> > The patch fails to explain why this change is required and what
> > usecase/problem it fixes.
> >
> > Hans
> > >
> > > Signed-off-by: xiaofan
> > > ---
> > > interface-ip.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/interface-ip.c b/interface-ip.c
> > > index 6900cd7..7ab8643 100644
> > > --- a/interface-ip.c
> > > +++ b/interface-ip.c
> > > @@ -196,6 +196,10 @@ __find_ip_addr_target(struct interface_ip_settings
> > > *ip, union if_addr *a, bool v
> > >if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6))
> > > continue;
> > >
> > > + if (!v6 && addr->point_to_point && a->in.s_addr ==
> > > addr->point_to_point) {
> > > + return true;
> > > + }
> > > +
> > >/* Handle offlink addresses correctly */
> > >unsigned int mask = addr->mask;
> > >if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 &&
> > > --
> > > 2.17.1
> > >
> > >
> > > ___
> > > 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
[OpenWrt-Devel] 回复: [PATCH] interface-ip: fix find locally addressable target for p2p
Hi, I add some explanation to the patch
From 57007eef77f266e40640a2c76aabd56fd37553f7 Mon Sep 17 00:00:00 2001
From: xiaofan
Date: Thu, 16 May 2019 21:12:47 +0800
Subject: [PATCH] interface-ip: fix find locally addressable target for p2p
In case of tunnel over PPP(such as gretap over l2tp): tunnel interface
use PPP's peer address as remote address, netifd script will call
proto_add_host_dependency function, then netifd will search which device
can reach to the remote address. Before the patch, netifd don't consider
the PPP interface can reach to the remote address, so netifd will select
default route to remote address, it will lead to remote address unreachable.
Signed-off-by: xiaofan
---
interface-ip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/interface-ip.c b/interface-ip.c
index 6900cd7..8d5587c 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -196,6 +196,9 @@ __find_ip_addr_target(struct interface_ip_settings *ip,
union if_addr *a, bool v
if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6))
continue;
+ if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point)
+ return true;
+
/* Handle offlink addresses correctly */
unsigned int mask = addr->mask;
if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 &&
--
2.17.1
>
> Hi,
>
> On Thu, May 16, 2019 at 4:01 PM Tan Xiaofan wrote:
> >
> > From d0e1cb81b45ec825199d499cda9c8daef94e13a5 Mon Sep 17 00:00:00 2001
> > From: xiaofan
> > Date: Thu, 16 May 2019 21:12:47 +0800
> > Subject: [PATCH] interface-ip: fix find locally addressable target for p2p
> The patch fails to explain why this change is required and what
> usecase/problem it fixes.
>
> Hans
> >
> > Signed-off-by: xiaofan
> > ---
> > interface-ip.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/interface-ip.c b/interface-ip.c
> > index 6900cd7..7ab8643 100644
> > --- a/interface-ip.c
> > +++ b/interface-ip.c
> > @@ -196,6 +196,10 @@ __find_ip_addr_target(struct interface_ip_settings
> > *ip, union if_addr *a, bool v
> >if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6))
> > continue;
> >
> > + if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point)
> > {
> > + return true;
> > + }
> > +
> >/* Handle offlink addresses correctly */
> >unsigned int mask = addr->mask;
> >if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 &&
> > --
> > 2.17.1
> >
> >
> > ___
> > 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-Devel] [PATCH] interface-ip: fix find locally addressable target for p2p
Hi,
On Thu, May 16, 2019 at 4:01 PM Tan Xiaofan wrote:
>
> From d0e1cb81b45ec825199d499cda9c8daef94e13a5 Mon Sep 17 00:00:00 2001
> From: xiaofan
> Date: Thu, 16 May 2019 21:12:47 +0800
> Subject: [PATCH] interface-ip: fix find locally addressable target for p2p
The patch fails to explain why this change is required and what
usecase/problem it fixes.
Hans
>
> Signed-off-by: xiaofan
> ---
> interface-ip.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/interface-ip.c b/interface-ip.c
> index 6900cd7..7ab8643 100644
> --- a/interface-ip.c
> +++ b/interface-ip.c
> @@ -196,6 +196,10 @@ __find_ip_addr_target(struct interface_ip_settings *ip,
> union if_addr *a, bool v
>if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6))
> continue;
>
> + if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point) {
> + return true;
> + }
> +
>/* Handle offlink addresses correctly */
>unsigned int mask = addr->mask;
>if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 &&
> --
> 2.17.1
>
>
> ___
> 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
[OpenWrt-Devel] 回复: [PATCH] interface-ip: fix find locally addressable target for p2p
Fix code style From 5ab54a6b1fd4c4a721e66727a135b5c03051224e Mon Sep 17 00:00:00 2001 From: xiaofan Date: Thu, 16 May 2019 21:12:47 +0800 Subject: [PATCH] interface-ip: fix find locally addressable target for p2p Signed-off-by: xiaofan --- interface-ip.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/interface-ip.c b/interface-ip.c index 6900cd7..8d5587c 100644 --- a/interface-ip.c +++ b/interface-ip.c @@ -196,6 +196,9 @@ __find_ip_addr_target(struct interface_ip_settings *ip, union if_addr *a, bool v if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6)) continue; + if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point) + return true; + /* Handle offlink addresses correctly */ unsigned int mask = addr->mask; if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 && -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] interface-ip: fix find locally addressable target for p2p
From d0e1cb81b45ec825199d499cda9c8daef94e13a5 Mon Sep 17 00:00:00 2001
From: xiaofan
Date: Thu, 16 May 2019 21:12:47 +0800
Subject: [PATCH] interface-ip: fix find locally addressable target for p2p
Signed-off-by: xiaofan
---
interface-ip.c | 4
1 file changed, 4 insertions(+)
diff --git a/interface-ip.c b/interface-ip.c
index 6900cd7..7ab8643 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -196,6 +196,10 @@ __find_ip_addr_target(struct interface_ip_settings *ip,
union if_addr *a, bool v
if (v6 != ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6))
continue;
+ if (!v6 && addr->point_to_point && a->in.s_addr == addr->point_to_point) {
+ return true;
+ }
+
/* Handle offlink addresses correctly */
unsigned int mask = addr->mask;
if ((addr->flags & DEVADDR_FAMILY) == DEVADDR_INET6 &&
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] ramips: Add support for ZBT WE826-E
ZBT WE826-E is a dual-SIM version of the ZBT WE826. The router has the
following specifications:
- MT7620A (580 MHz)
- 128MB RAM
- 32MB of flash (SPI NOR)
- 5x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM card slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 10x LEDs (4 GPIO-controlled)
- 1x reset button
The following have been tested and working:
- Ethernet switch
- wifi
- miniPCIe slot
- USB port
- microSD slot
- sysupgrade
- reset button
Installation and recovery:
In order to install OpenWRT the first time or recover the router, you
can use the web-based recovery system. Keep the reset button pressed
during boot and access 192.168.1.1 in your browser when your machine
obtains an IP address. Upload the firmware to start the recovery
process.
How to swap SIMs:
You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/gpio13/value. In order for the change to take effect,
you can either use AT-commands (AT+CFUN) or power-cycle the modem (write
0/1 to /sys/class/gpio/gpio14/value).
Signed-off-by: Kristian Evensen
---
v2->v3:
* Remove the old description of the first time installation and point
the user to the web based recovery system instead (thanks Petr Štetiar).
* Add license to DTS (thanks Petr Štetiar).
v1->v2:
* Use generic board/model detection, updated the match in 01_leds and
02_network (thanks Petr Štetiar).
* Changed the device/target device in the Makefile to match the
compatible-string in the DTS (thanks Petr Štetiar).
* Use the user-space gpio-switch alternative instead of gpio-export in
the DTS (thanks Petr Štetiar).
* Update name of flash node in DTS to the more generic "flash0" (thanks
Petr Štetiar).
* Fix image size in the Makefile (thanks Petr Štetiar).
* Group the wifi-LED together with other devices (thanks Petr Štetiar).
* Updated commit message.
* While the device can be ordered without a modem, I imagine most
devices will be delivered with a modem. I have therefore enabled support
for QMI and Option, so that most modems can be used out of the box.
---
.../ramips/base-files/etc/board.d/01_leds | 3 +-
.../ramips/base-files/etc/board.d/02_network | 1 +
.../base-files/etc/board.d/03_gpio_switches | 4 +
target/linux/ramips/dts/ZBT-WE826-E.dts | 84 +++
target/linux/ramips/image/mt7620.mk | 9 ++
5 files changed, 100 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/ZBT-WE826-E.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index fa20ab0714..941b4b109b 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -251,7 +251,8 @@ mr200)
mtc,wr1201)
ucidef_set_led_switch "eth_link" "LAN link" "$boardname:green:eth_link"
"switch0" "0x0f"
;;
-mzk-ex750np)
+mzk-ex750np|\
+zbtlink,zbt-we826-e)
set_wifi_led "$boardname:red:wifi"
;;
netgear,r6120)
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c2646876a2..63bfab2486 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -133,6 +133,7 @@ ramips_setup_interfaces()
youku,yk-l2|\
zbt-ape522ii|\
zbt-we1326|\
+ zbtlink,zbt-we826-e|\
zbtlink,zbt-we3526|\
zbt-we826-16M|\
zbt-we826-32M|\
diff --git a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
index 80e3c4c41f..6119d7c485 100755
--- a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
+++ b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
@@ -24,6 +24,10 @@ ubnt-erx-sfp)
ucidef_add_gpio_switch "poe_power_port3" "PoE Power Port3" "499"
ucidef_add_gpio_switch "poe_power_port4" "PoE Power Port4" "500"
;;
+zbtlink,zbt-we826-e)
+ ucidef_add_gpio_switch "sim_switch" "SIM slot switch" "13"
+ ucidef_add_gpio_switch "power_mpcie" "mPCIe power" "14" "1"
+ ;;
esac
board_config_flush
diff --git a/target/linux/ramips/dts/ZBT-WE826-E.dts
b/target/linux/ramips/dts/ZBT-WE826-E.dts
new file mode 100644
index 00..ce97b03715
--- /dev/null
+++ b/target/linux/ramips/dts/ZBT-WE826-E.dts
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ZBT-WE826.dtsi"
+
+/ {
+ compatible = "zbtlink,zbt-we826-e", "zbtlink,zbt-we826",
"ralink,mt7620a-soc";
+ model = "ZBT-WE826-E";
+
+ /delete-node/ leds;
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: gsm {
+ label = "zbt-we826-e:blue:gsm";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+
+ signal {
+ label =
Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for ZBT WE826-E
Hi, On Thu, May 16, 2019 at 3:17 PM Petr Štetiar wrote: > it's not mandatory, so you're not obliged to do so, but it makes me wonder if > it would be possible to generate factory image which could be flashed with the > same recovery mechanism, thus avoiding the -F in the sysupgrade above > (considered dangerous). If my memory serves me right, then it is possible to use the sysupgrade-images with the recovery mechanism. I will test again and then update the commit message if so. > > > +++ b/target/linux/ramips/dts/ZBT-WE826-E.dts > > @@ -0,0 +1,83 @@ > > +/dts-v1/; > > Please can you consider adding `SPDX-License-Identifier: GPL-2.0-or-later OR > MIT` ? And I thought I had remembered to incorporate all the comments from adding the HDRM200 :) BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for ZBT WE826-E
Kristian Evensen [2019-05-16 15:02:31]: Hi, > The router ships with an older version of OpenWRT, but with a broken web > user interface. In order to install the image, you need to SSH into the > router and run sysupgrade. The default address of the router is > 192.168.1.1, user is root and password admin. Once you are in, run the > following command: > > sysupgrade -n -F > openwrt-ramips-mt7620-zbtlink_zbt-we826-e-squashfs-sysupgrade.bin > > Recovery: > > The router ships with a web-based recovery system. If you need to > recover the router, keep the reset button pressed during boot and access > 192.168.1.1 in your browser when your machine obtains an IP address. > Upload the firmware to start the recovery process. it's not mandatory, so you're not obliged to do so, but it makes me wonder if it would be possible to generate factory image which could be flashed with the same recovery mechanism, thus avoiding the -F in the sysupgrade above (considered dangerous). > +++ b/target/linux/ramips/dts/ZBT-WE826-E.dts > @@ -0,0 +1,83 @@ > +/dts-v1/; Please can you consider adding `SPDX-License-Identifier: GPL-2.0-or-later OR MIT` ? Otherwise LGTM. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] ramips: Add support for ZBT WE826-E
ZBT WE826-E is a dual-SIM version of the ZBT WE826. The router has the
following specifications:
- MT7620A (580 MHz)
- 128MB RAM
- 32MB of flash (SPI NOR)
- 5x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM card slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 10x LEDs (4 GPIO-controlled)
- 1x reset button
The following have been tested and working:
- Ethernet switch
- wifi
- miniPCIe slot
- USB port
- microSD slot
- sysupgrade
- reset button
Installation:
The router ships with an older version of OpenWRT, but with a broken web
user interface. In order to install the image, you need to SSH into the
router and run sysupgrade. The default address of the router is
192.168.1.1, user is root and password admin. Once you are in, run the
following command:
sysupgrade -n -F
openwrt-ramips-mt7620-zbtlink_zbt-we826-e-squashfs-sysupgrade.bin
Recovery:
The router ships with a web-based recovery system. If you need to
recover the router, keep the reset button pressed during boot and access
192.168.1.1 in your browser when your machine obtains an IP address.
Upload the firmware to start the recovery process.
How to swap SIMs:
You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/gpio13/value. In order for the change to take effect,
you can either use AT-commands (AT+CFUN) or power-cycle the modem (write
0/1 to /sys/class/gpio/gpio14/value).
Signed-off-by: Kristian Evensen
---
v1->v2:
* Use generic board/model detection, updated the match in 01_leds and
02_network (thanks Petr Štetiar).
* Changed the device/target device in the Makefile to match the
compatible-string in the DTS (thanks Petr Štetiar).
* Use the user-space gpio-switch alternative instead of gpio-export in
the DTS (thanks Petr Štetiar).
* Update name of flash node in DTS to the more generic "flash0" (thanks
Petr Štetiar).
* Fix image size in the Makefile (thanks Petr Štetiar).
* Group the wifi-LED together with other devices (thanks Petr Štetiar).
* Updated commit message.
* While the device can be ordered without a modem, I imagine most
devices will be delivered with a modem. I have therefore enabled support
for QMI and Option, so that most modems can be used out of the box.
---
.../ramips/base-files/etc/board.d/01_leds | 3 +-
.../ramips/base-files/etc/board.d/02_network | 1 +
.../base-files/etc/board.d/03_gpio_switches | 4 +
target/linux/ramips/dts/ZBT-WE826-E.dts | 83 +++
target/linux/ramips/image/mt7620.mk | 9 ++
5 files changed, 99 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/ZBT-WE826-E.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index fa20ab0714..941b4b109b 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -251,7 +251,8 @@ mr200)
mtc,wr1201)
ucidef_set_led_switch "eth_link" "LAN link" "$boardname:green:eth_link"
"switch0" "0x0f"
;;
-mzk-ex750np)
+mzk-ex750np|\
+zbtlink,zbt-we826-e)
set_wifi_led "$boardname:red:wifi"
;;
netgear,r6120)
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c2646876a2..63bfab2486 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -133,6 +133,7 @@ ramips_setup_interfaces()
youku,yk-l2|\
zbt-ape522ii|\
zbt-we1326|\
+ zbtlink,zbt-we826-e|\
zbtlink,zbt-we3526|\
zbt-we826-16M|\
zbt-we826-32M|\
diff --git a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
index 80e3c4c41f..6119d7c485 100755
--- a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
+++ b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
@@ -24,6 +24,10 @@ ubnt-erx-sfp)
ucidef_add_gpio_switch "poe_power_port3" "PoE Power Port3" "499"
ucidef_add_gpio_switch "poe_power_port4" "PoE Power Port4" "500"
;;
+zbtlink,zbt-we826-e)
+ ucidef_add_gpio_switch "sim_switch" "SIM slot switch" "13"
+ ucidef_add_gpio_switch "power_mpcie" "mPCIe power" "14" "1"
+ ;;
esac
board_config_flush
diff --git a/target/linux/ramips/dts/ZBT-WE826-E.dts
b/target/linux/ramips/dts/ZBT-WE826-E.dts
new file mode 100644
index 00..a1f71c7144
--- /dev/null
+++ b/target/linux/ramips/dts/ZBT-WE826-E.dts
@@ -0,0 +1,83 @@
+/dts-v1/;
+
+#include "ZBT-WE826.dtsi"
+
+/ {
+ compatible = "zbtlink,zbt-we826-e", "zbtlink,zbt-we826",
"ralink,mt7620a-soc";
+ model = "ZBT-WE826-E";
+
+ /delete-node/ leds;
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: gsm {
+ label = "zbt-we826-e:blue:gsm";
+
Re: [OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock
On Tuesday, 14 May 2019 15:42:18 CEST Pavel Kubelun wrote:
> +--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
> b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> +@@ -141,9 +141,9 @@
> + };
> +
> + clocks {
> +- sleep_clk: sleep_clk {
> ++ sleep_clk: gcc_sleep_clk_src {
> + compatible = "fixed-clock";
> +- clock-frequency = <32768>;
> ++ clock-frequency = <32000>;
> + #clock-cells = <0>;
> + };
On Thursday, 16 May 2019 13:18:14 CEST Павел wrote:
[...]
> > And maybe some of these guys also know how to find the ipq40xx clock
> > controller reference or hardware reference. Because I was only able to
> > verify
> > for IPQ8072 that it had a 32.768 KHz sleep clock. But the
> >
>
> If you are completely sure about that, then I guess that they have
> (un)intentionally messed with the clock in QSDK, because they state that
> ipq807x has the same 32000 khz crystal.
> https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/tree/arch/arm64/boot/dts/qcom/qcom-ipq807x-soc.dtsi?h=eggplant#n2055
Confidence is the wrong word. I can only state that this is written in
80-YA727-13 Rev. D (IPQ8072.AP.HK07). Same for other devices like
IPQ8078 AP.HK02, IPQ8074 AP.HK01, ...
But I found in the same document that they call it the "32 KHz sleep clock in"
in one section and and in another table "32.768 KHz sleep clock input to the
IPQ8072" (next to the name "...32K..."). So it is now to the reader to find
out what they meant here in which reference document. So maybe they also meant
32.768 KHz when in the IPQ4019 Watchdog document when they wrote 32 Khz sleep
clock... who knows.
My gut feeling (sorry, not an HW guy) tell me that they are just using a
32.768 KHz clock (from a standard 32.768 KHz oscillator) in all these products
and just shortened it to 32K at some point in the document. And now Gopinath
Sekar wrote 32000 instead of 32768. But I absolutely don't know what actually
is there in HW.
Kind regards,
Sven
[1]
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=d92ec59973484acc86dd24b67f10f8911b4b4b7d
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock
чт, 16 мая 2019 г., 13:05 Sven Eckelmann : > On Wednesday, 15 May 2019 19:16:51 CEST Павел wrote: > [...] > > > Is there any particular reason why > > > this > > > shouldn't be sent upstream and then backported to OpenWrt? > > > > > > > There are no reasons why it shouldn't be sent upstream along with other > > patches. I hope to find someone with datasheet beforehand to verify the > > correct sleep clock rate. > > But you will most likely find the persons with the datasheet when you try > to > upstream it via > > * Andy Gross (maintainer:ARM/QUALCOMM SUPPORT) > * David Brown (maintainer:ARM/QUALCOMM SUPPORT) > * linux-arm-...@vger.kernel.org (open list:ARM/QUALCOMM SUPPORT) > > And maybe some of these guys also know how to find the ipq40xx clock > controller reference or hardware reference. Because I was only able to > verify > for IPQ8072 that it had a 32.768 KHz sleep clock. But the > If you are completely sure about that, then I guess that they have (un)intentionally messed with the clock in QSDK, because they state that ipq807x has the same 32000 khz crystal. https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/tree/arch/arm64/boot/dts/qcom/qcom-ipq807x-soc.dtsi?h=eggplant#n2055 Furthermore, it has been upstreamed... So I'm confused actually what path to choose now. Probably it depends on your level of confidence that ipq8072 definitely has a 32.768 khz rate - it will mean that qsdk is not trustworthy on this matter. "IPQ4018/IPQ4028/IPQ4019/IPQ4029 Watchdog" document states that the > watchdog > runs on a 32 KHz sleep clock. And according to the device tree, the clock > you > modified here is connected to the watchdog. > > And for the device tree bindings: > > * devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED > DEVICE TREE BINDINGS) > * Rob Herring (maintainer:OPEN FIRMWARE AND > FLATTENED DEVICE TREE BINDINGS) > * Mark Rutland (maintainer:OPEN FIRMWARE AND > FLATTENED DEVICE TREE BINDINGS) > > > Besides upstreaming a patch takes time while the next openwrt release > > should be out soon I suppose. > > Good reason to try to upstream it at the same time to OpenWrt and upstream > :) > At least then we could get some feedback from upstream before OpenWrt > ships > something which potentially has negative effects. > > Kind regards, > Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock
On Wednesday, 15 May 2019 19:16:51 CEST Павел wrote: [...] > > Is there any particular reason why > > this > > shouldn't be sent upstream and then backported to OpenWrt? > > > > There are no reasons why it shouldn't be sent upstream along with other > patches. I hope to find someone with datasheet beforehand to verify the > correct sleep clock rate. But you will most likely find the persons with the datasheet when you try to upstream it via * Andy Gross (maintainer:ARM/QUALCOMM SUPPORT) * David Brown (maintainer:ARM/QUALCOMM SUPPORT) * linux-arm-...@vger.kernel.org (open list:ARM/QUALCOMM SUPPORT) And maybe some of these guys also know how to find the ipq40xx clock controller reference or hardware reference. Because I was only able to verify for IPQ8072 that it had a 32.768 KHz sleep clock. But the "IPQ4018/IPQ4028/IPQ4019/IPQ4029 Watchdog" document states that the watchdog runs on a 32 KHz sleep clock. And according to the device tree, the clock you modified here is connected to the watchdog. And for the device tree bindings: * devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) * Rob Herring (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) * Mark Rutland (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) > Besides upstreaming a patch takes time while the next openwrt release > should be out soon I suppose. Good reason to try to upstream it at the same time to OpenWrt and upstream :) At least then we could get some feedback from upstream before OpenWrt ships something which potentially has negative effects. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4] ramips: Add support for Head Weblink HDRM200
Kristian Evensen [2019-05-16 10:19:59]: Hi, > On Wed, May 15, 2019 at 9:21 PM Petr Štetiar wrote: > > Thanks, I've merged it into my staging tree[1], but I had to fix one merge > > conflict in target.mk so please check it if I did it properly. > > Thanks and strange about the conflict + whitespace, as patch applies > cleanly to master and checkpatch does not complain. Just FYI $ git describe reboot-10011-g71ab2c9d1796 $ ../maintainer-tools/patchwork-apply.sh 1100158 Applying: ramips: Add support for Head Weblink HDRM200 /opt/devel/openwrt/openwrt.git/.git/rebase-apply/patch:289: space before tab in indent. uqmi kmod-usb-serial kmod-usb-serial-option ^ | `-- whitespace issue error: patch failed: target/linux/ramips/mt7620/target.mk:4 error: target/linux/ramips/mt7620/target.mk: patch does not apply Patch failed at 0001 ramips: Add support for Head Weblink HDRM200 which was caused by: commit 367813b9b17c50b9e1bc25933a3ccd252c0813e4 Author: Deng Qingfang ramips: mt7620: fix dependencies diff --git a/target/linux/ramips/mt7620/target.mk b/target/linux/ramips/mt7620/target.mk index 544254604e5c..788c9a1dfc1a 100644 --- a/target/linux/ramips/mt7620/target.mk +++ b/target/linux/ramips/mt7620/target.mk @@ -7,7 +7,7 @@ BOARDNAME:=MT7620 based boards FEATURES+=usb CPU_TYPE:=24kc -DEFAULT_PACKAGES += kmod-rt2800-pci kmod-rt2800-soc wpad-basic +DEFAULT_PACKAGES += kmod-rt2800-soc wpad-basic -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4] ramips: Add support for Head Weblink HDRM200
Hi, On Wed, May 15, 2019 at 9:21 PM Petr Štetiar wrote: > Thanks, I've merged it into my staging tree[1], but I had to fix one merge > conflict in target.mk so please check it if I did it properly. Thanks and strange about the conflict + whitespace, as patch applies cleanly to master and checkpatch does not complain. Anyway, target.mk in your staging dir looks good to me. I will proceed with updating the patch for the ZBT-device I created a PR for, based on the work done to get support for the HDRM200 merged. Thanks again, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
