Re: [OpenWrt-Devel] 18.06.2 branching/builds

[Stijn Segers]

Op woensdag 30 januari 2019 om 18:17 schreef Felix Fietkau 
:

On 2019-01-30 16:58, Stijn Segers wrote:

 Hi Jo, Felix,

 Far be it from me to pretend this issue might have a larger impact 
than

 I myself can assess, but Felix has been bumping mt76 on the 18.06
 branch, and those bumps have broken my 18.06.1+ mt7621 wireless [1]
 (and, judging from Flyspray, at least one other person's as well).

 I have no idea how many people are running both mt7621 and 18.06 
HEAD
 (like me and the other guy), so this might be an isolated issue, 
but I
 do know wireless craps out on me within a few minutes and the AP 
needs
 to be brought up again; it's not just a matter of worse performance 
but

 outright disconnection.

 So I'd like to ask if 18.06.2 could be released with a fix/with 
those

 mt76 rolled back.

Hey Stijn,

Thanks for bringing this to my attention again.
Could you please test the two attached patches individually with the
latest 18.06 branch to see if either of them resolves your issue?

I've been doing a lot of tests lately with both MT7603 and MT7612E on
MT7621, and I have been unable to reproduce your issues so far.

Thanks,

- Felix


Thanks Felix, will give both a shot and report back.

Jo: I kind of hoped to catch Felix on IRC but that didn't happen, in 
hindsight I should have pinged you as well about this, but there's 
probably other bugs pending people would consider showstoppers for a 
point release... Would probably only have delayed it.


Vielen Dank!

Stijn


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

[OpenWrt-Devel] Awaiting moderator approval?

[Stijn Segers]

-- Doorgestuurd bericht --
Van: openwrt-devel-ow...@lists.openwrt.org
Onderwerp: Your message to openwrt-devel awaits moderator approval
Datum: Wed, 30 Jan 2019 07:58:55 -0800
Aan: f...@volatilesystems.org
Your mail to 'openwrt-devel' with the subject

18.06.2 branching/builds

Is being held until the list moderator can review it for approval.

The reason it is being held:

Message has a suspicious header

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


http://lists.infradead.org/mailman/confirm/openwrt-devel/ac7b846299ec898cb837b90eef59bca4715ccbce



Hi,

I've been subscribed to this list for ages and I am getting this 
moderation message now.


I suppose some additional tools have been implemented to combat the 
spam we've seen trickle through, but I'm not sure what this particular 
message is about, nor does it look feasible/desirable to manually 
review every message posted to the ML.


Any feedback by a list moderator would be welcome, since this mail 
hasn't been picked up (it's not listed in the archives, granted, it's 
probably a bit early to raise this), but it might have been lost 
altogether hadn't I CC'ed the people involved.


Thank you

Stijn Segers


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

Re: [OpenWrt-Devel] A second 'make' always rebuilds something

[R. Diez via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

Please find attached a script that automatically downloads and builds twice.
A log file from my laptop is attached too.


I am sorry I forgot the script in my first e-mail (which is apparently awaiting 
moderator approval).

Best regards,
  rdiez


BuildOpenWrt-X86_64-FromScratch.sh
Description: application/shellscript
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] ramips: fix Netgear R6120 LED mapping

[David Bauer]

The R6120 has no 5GHz WLAN LED, the assigned GPIO in fact controls
the WAN LED.

Renames the LED accordingly in the device-tree.
Removes the 5GHz WLAN LED trigger.
Adds the correct WAN port LED trigger.

Signed-off-by: David Bauer 
---
 target/linux/ramips/base-files/etc/board.d/01_leds | 2 +-
 target/linux/ramips/dts/R6120.dts  | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

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 e36f125126..056443c49d 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -248,8 +248,8 @@ mzk-ex750np)
;;
 netgear,r6120)
ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0" 
"0x0f"
+   ucidef_set_led_switch "wan" "wan" "$boardname:green:wan" "switch0" 
"0x10"
ucidef_set_led_wlan "wlan2g" "WiFi 2.4GHz" "$boardname:green:wlan2g" 
"phy0tpt"
-   ucidef_set_led_wlan "wlan5g" "WiFi 5GHz" "$boardname:green:wlan5g" 
"phy1tpt"
;;
 oy-0001)
set_wifi_led "$boardname:green:wifi"
diff --git a/target/linux/ramips/dts/R6120.dts 
b/target/linux/ramips/dts/R6120.dts
index 375e400299..9897d8d9e5 100644
--- a/target/linux/ramips/dts/R6120.dts
+++ b/target/linux/ramips/dts/R6120.dts
@@ -55,13 +55,13 @@
gpios = < 9 GPIO_ACTIVE_LOW>;
};
 
-   wlan5 {
-   label = "r6120:green:wlan5g";
+   wan {
+   label = "r6120:green:wan";
gpios = < 8 GPIO_ACTIVE_LOW>;
};
 
-   wlan5_orange {
-   label = "r6120:orange:wlan5g";
+   wan_orange {
+   label = "r6120:orange:wan";
gpios = < 7 GPIO_ACTIVE_LOW>;
};
};
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 3/3] ramips: fix Netgear R6120 switchport numbering

[David Bauer]

The LAN ports of the R6120 are labled in reverse on the casing. Adjust
LuCI switchport numbering accordingly.

Signed-off-by: David Bauer 
---
 target/linux/ramips/base-files/etc/board.d/02_network | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

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 74938121a8..7496926c37 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -107,7 +107,6 @@ ramips_setup_interfaces()
mtc,wr1201|\
mzk-750dhp|\
mzk-w300nh2|\
-   netgear,r6120|\
nixcore-x1-8M|\
nixcore-x1-16M|\
oy-0001|\
@@ -336,6 +335,10 @@ ramips_setup_interfaces()
"0:lan" "1:lan" "2:lan" "3:lan" "6t@eth0"
ucidef_set_interface_wan "usb0"
;;
+   netgear,r6120)
+   ucidef_add_switch "switch0" \
+   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
+   ;;
hc5761)
ucidef_add_switch "switch0" \
"1:lan" "4:lan" "0:wan" "6@eth0"
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 2/3] ramips: fix Netgear R6120 MAC address

[David Bauer]

Currently, the MAC address for the Netgear R6120 is read from the NVRAM
partition. The offset for the MAC address however is not consistent
across devices or firmware versions.

Switch to using the factory partition like all other Netgear devices do.

Signed-off-by: David Bauer 
---
 target/linux/ramips/dts/R6120.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/linux/ramips/dts/R6120.dts 
b/target/linux/ramips/dts/R6120.dts
index 9897d8d9e5..37295814a3 100644
--- a/target/linux/ramips/dts/R6120.dts
+++ b/target/linux/ramips/dts/R6120.dts
@@ -103,7 +103,7 @@
read-only;
};
 
-   nvram: partition@6 {
+   partition@6 {
label = "nvram";
reg = <0x6 0x3>;
read-only;
@@ -126,12 +126,12 @@
 
  {
status = "okay";
-   mtd-mac-address = < 0x100b0>;
+   mtd-mac-address = < 0x4>;
mediatek,mtd-eeprom = < 0x2>;
 };
 
  {
-   mtd-mac-address = < 0x100b0>;
+   mtd-mac-address = < 0x4>;
 };
 
  {
@@ -143,7 +143,7 @@
reg = <0x 0 0 0 0>;
mediatek,mtd-eeprom = < 0x28000>;
ieee80211-freq-limit = <500 600>;
-   mtd-mac-address = < 0x100b0>;
+   mtd-mac-address = < 0x4>;
mtd-mac-address-increment = <(2)>;
};
 };
-- 
2.20.1


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

Re: [OpenWrt-Devel] A second 'make' always rebuilds something

[Karl Palsson]

"Daniel F. Dickinson"  wrote:
> On 2019-01-30 5:51 a.m., Jo-Philipp Wich wrote:
> > Hi,
> >
> > please share the exact steps used to trigger the issue. Running a simple
> > "make" after an initial build here does not trigger the recompilation of
> > uci or the kernel.
> >
> > ~ Jo
> >
> And environment (OS, distro, version) please!

After a full build finished, just running "time make" repeatedly
again takes ~5 minutes for me. There's some extra packages in my
tree, but there's _something_ less than ideal. This is on fedora
27 desktop, as of reboot-9214-gb3bd82b041

$ time make
WARNING: Makefile 'package/feeds/routing/nodogsplash/Makefile'
has a dependency on 'libmicrohttpd-no-ssl', which does not exist
 make[1] world
 make[2] target/compile
 make[3] -C target/linux compile
 make[2] diffconfig
 make[2] package/cleanup
 make[2] package/compile
 make[3] -C package/libs/libjson-c host-compile
 make[3] -C package/libs/libubox host-compile
 make[3] -C package/system/opkg host-compile
 make[3] -C package/libs/toolchain compile
 make[3] -C package/libs/libnl-tiny compile
 make[3] -C package/libs/libjson-c compile
 make[3] -C package/utils/lua compile
 make[3] -C package/libs/libubox compile
 make[3] -C package/system/ubus compile
 make[3] -C package/system/uci compile
 make[3] -C package/network/config/netifd compile
 make[3] -C package/firmware/linux-firmware compile
 make[3] -C package/firmware/prism54-firmware compile
 make[3] -C package/kernel/linux compile
 make[3] -C package/system/ubox compile
 make[3] -C package/libs/ncurses host-compile
 make[3] -C package/libs/zlib compile
 make[3] -C package/libs/ncurses compile
 make[3] -C package/utils/util-linux compile
 make[3] -C package/system/fstools compile
 make[3] -C package/system/fwtool host-compile
 make[3] -C package/system/fwtool compile
 make[3] -C package/system/procd compile
 make[3] -C package/system/usign host-compile
 make[3] -C package/system/ucert host-compile
 make[3] -C package/utils/jsonfilter compile
 make[3] -C package/system/openwrt-keyring compile
 make[3] -C package/system/usign compile
 make[3] -C package/base-files compile
 make[3] -C package/boot/uboot-envtools compile
 make[3] -C package/libs/readline compile
 make[3] -C package/devel/gdb compile
 make[3] -C package/devel/strace compile
 make[3] -C package/devel/valgrind compile
 make[3] -C feeds/luci/modules/luci-base host-compile
 make[3] -C package/utils/lua host-compile
 make[3] -C feeds/luci/contrib/package/csstidy host-compile
 make[3] -C feeds/luci/applications/luci-app-commands compile
 make[3] -C feeds/luci/applications/luci-app-diag-core compile
 make[3] -C feeds/luci/applications/luci-app-openvpn compile
 make[3] -C package/libs/mbedtls compile
 make[3] -C package/libs/ustream-ssl compile
 make[3] -C package/network/services/uhttpd compile
 make[3] -C feeds/luci/applications/luci-app-uhttpd compile
 make[3] -C package/libs/libmnl compile
 make[3] -C package/utils/bzip2 compile
 make[3] -C package/libs/gettext compile
 make[3] -C package/libs/libiconv compile
 make[3] -C package/libs/argp-standalone compile
 make[3] -C package/libs/elfutils compile
 make[3] -C package/network/utils/iptables compile
 make[3] -C package/network/utils/iproute2 compile
 make[3] -C package/network/services/wireguard compile
 make[3] -C feeds/luci/protocols/luci-proto-wireguard compile
 make[3] -C feeds/luci/applications/luci-app-wireguard compile
 make[3] -C feeds/luci/libs/luci-lib-ip compile
 make[3] -C feeds/luci/libs/luci-lib-jsonc compile
 make[3] -C feeds/luci/libs/luci-lib-nixio compile
 make[3] -C feeds/luci/contrib/package/lucihttp compile
 make[3] -C package/network/utils/iwinfo compile
 make[3] -C package/system/rpcd compile
 make[3] -C feeds/luci/modules/luci-base compile
 make[3] -C feeds/luci/libs/luci-lib-json compile
 make[3] -C feeds/luci/modules/luci-mod-network compile
 make[3] -C feeds/luci/modules/luci-mod-status compile
 make[3] -C feeds/luci/modules/luci-mod-system compile
 make[3] -C feeds/luci/modules/luci-mod-admin-full compile
 make[3] -C feeds/luci/modules/luci-mod-rpc compile
 make[3] -C feeds/packages/libs/check compile
 make[3] -C /home/karlp/src/owrt_private_feeds/libcbms compile
 make[3] -C /home/karlp/src/owrt_private_feeds/remake_shared compile
 make[3] -C /home/karlp/src/owrt_private_feeds/uglylogging compile
 make[3] -C feeds/packages/net/net-snmp compile
 make[3] -C package/libs/openssl compile
 make[3] -C package/libs/libevent2 compile
 make[3] -C feeds/packages/libs/c-ares compile
 make[3] -C feeds/packages/libs/libcap compile
 make[3] -C feeds/packages/libs/libuv compile
 make[3] -C feeds/packages/libs/libwebsockets compile
 make[3] -C /home/karlp/src/owrt_pub_feeds/net/mosquitto compile
 make[3] -C /home/karlp/src/owrt_pub_feeds/net/mosquitto compile
 make[3] -C /home/karlp/src/owrt_pub_feeds/net/mosquitto compile
 make[3] -C /home/karlp/src/owrt_private_feeds/agent_etactica compile
 make[3] -C feeds/packages/libs/libmodbus compile
 make[3] -C 

Re: [OpenWrt-Devel] 18.06.2 branching/builds

[Felix Fietkau]

On 2019-01-30 16:58, Stijn Segers wrote:
> Hi Jo, Felix,
> 
> Far be it from me to pretend this issue might have a larger impact than
> I myself can assess, but Felix has been bumping mt76 on the 18.06
> branch, and those bumps have broken my 18.06.1+ mt7621 wireless [1]
> (and, judging from Flyspray, at least one other person's as well).
> 
> I have no idea how many people are running both mt7621 and 18.06 HEAD
> (like me and the other guy), so this might be an isolated issue, but I
> do know wireless craps out on me within a few minutes and the AP needs
> to be brought up again; it's not just a matter of worse performance but
> outright disconnection.
> 
> So I'd like to ask if 18.06.2 could be released with a fix/with those
> mt76 rolled back.
Hey Stijn,

Thanks for bringing this to my attention again.
Could you please test the two attached patches individually with the
latest 18.06 branch to see if either of them resolves your issue?

I've been doing a lot of tests lately with both MT7603 and MT7612E on
MT7621, and I have been unable to reproduce your issues so far.

Thanks,

- Felix
diff --git a/mt76x02_dfs.c b/mt76x02_dfs.c
index 19fdcab..57aba62 100644
--- a/mt76x02_dfs.c
+++ b/mt76x02_dfs.c
@@ -885,7 +885,7 @@ mt76x02_dfs_set_domain(struct mt76x02_dev *dev,
if (dfs_pd->region != region) {
tasklet_disable(_pd->dfs_tasklet);
 
-   dev->ed_monitor = region == NL80211_DFS_ETSI;
+   dev->ed_monitor = 0; // region == NL80211_DFS_ETSI;
mt76x02_edcca_init(dev);
 
dfs_pd->region = region;
diff --git a/mt76x02_mac.c b/mt76x02_mac.c
index 166f20b..0c475ad 100644
--- a/mt76x02_mac.c
+++ b/mt76x02_mac.c
@@ -889,6 +889,7 @@ void mt76x02_edcca_init(struct mt76x02_dev *dev)
mt76_set(dev, MT_TXOP_HLDR_ET,
 MT_TXOP_HLDR_TX40M_BLK_EN);
} else {
+   return;
mt76_set(dev, MT_TX_LINK_CFG, MT_TX_CFACK_EN);
mt76_clear(dev, MT_TXOP_CTRL_CFG, MT_TXOP_ED_CCA_EN);
if (is_mt76x2(dev)) {
diff --git a/mt76x2/pci_main.c b/mt76x2/pci_main.c
index 06a26a1..9ef196a 100644
--- a/mt76x2/pci_main.c
+++ b/mt76x2/pci_main.c
@@ -34,8 +34,10 @@ mt76x2_start(struct ieee80211_hw *hw)
 
ieee80211_queue_delayed_work(mt76_hw(dev), >mac_work,
 MT_CALIBRATE_INTERVAL);
+#if 0
ieee80211_queue_delayed_work(mt76_hw(dev), >wdt_work,
 MT_WATCHDOG_TIME);
+#endif
 
set_bit(MT76_STATE_RUNNING, >mt76.state);
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06.2 branching/builds

[Jo-Philipp Wich]

Hi,

unfortunately the tag has already been created and builds are running
are already running and uploading.

We can bump mt76 with the next point release in a few weeks.

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] A second 'make' always rebuilds something

[Daniel F. Dickinson]

On 2019-01-30 5:51 a.m., Jo-Philipp Wich wrote:
> Hi,
>
> please share the exact steps used to trigger the issue. Running a simple
> "make" after an initial build here does not trigger the recompilation of
> uci or the kernel.
>
> ~ Jo
>
And environment (OS, distro, version) please!

Regards,

Daniel


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

[OpenWrt-Devel] [PATCH] Honour NO_COLOR in include/scan.mk

[R. Diez via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


> Could you please send a V2 with the requested change
> to print $(1) without ANSII escape sequences?

Here it goes:

Honour NO_COLOR in Makefile function 'progress' in include/scan.mk, in 
the same way that include/verbose.mk does.



Signed-off-by: R. Diez 
---
 include/scan.mk | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/scan.mk b/include/scan.mk
index e6b21b27b0..d9cd4f7e8c 100644
--- a/include/scan.mk
+++ b/include/scan.mk
@@ -19,9 +19,15 @@ else
 endif

 ifeq ($(IS_TTY),1)
-  define progress
+  ifneq ($(strip $(NO_COLOR)),1)
+define progress
printf "\033[M\r$(1)" >&2;
-  endef
+endef
+  else
+define progress
+   printf "\r$(1)" >&2;
+endef
+  endif
 else
   define progress
:;
--
2.20.1

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

[OpenWrt-Devel] Merged: ramips: fix D-Link DIR-615 H1 switch port mapping

[Jo-Philipp Wich]

Merged into my staging tree at
http://git.openwrt.org/?p=openwrt/staging/jow.git.

Thank you!


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

Re: [OpenWrt-Devel] A second 'make' always rebuilds something

[Jo-Philipp Wich]

Hi,

please share the exact steps used to trigger the issue. Running a simple
"make" after an initial build here does not trigger the recompilation of
uci or the kernel.

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] A second 'make' always rebuilds something

[R. Diez via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


> Please see if you can replicate the same behavior with a
> vanilla OpenWrt build root.

That was a vanilla OpenWrt build root.

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

[OpenWrt-Devel] [RFC] lantiq: SMP interrupts and ethernet driver backport from vanilla v5

[Petr Cvek]

Hello,

I discovered the lantiq xrx200 lacks support for interrupts on secondary
VPE, and I've managed to add this functionality to the kernel, the
second icu controller lives on base address 0x1f880300 and works in the
same way as first. Tested with 4.14.93 kernel, untested patches in the
attachment or on openwrt forum:

https://forum.openwrt.org/t/xrx200-irq-balancing-between-vpes/29732/11

My second submission is a backported xrx200 ethernet driver from vanilla
kernel v5 patched with switch and phy functions. Using kernel napi
polling seems to highly increase the throughput of the network.

Trying to initially increase the throughput of the network I've found
there is an inefficiently setting of DMA burst size. My patch sets this
value to a higher value.

These two patches were tested with 4.14.93 kernel too, there is forum
thread:

https://forum.openwrt.org/t/how-can-we-make-the-lantiq-xrx200-devices-faster/9724/30

RFC for any parallel development info (next version of ethernet driver
will be based on vanilla kernel version?), ideas, testing ...

best regards,
Petr Cvek
--- ./a/arch/mips/lantiq/irq.c	2019-01-30 02:20:35.739994259 +0100
+++ ./b/arch/mips/lantiq/irq.c	2019-01-30 04:30:31.152538191 +0100
@@ -49,8 +49,8 @@
  */
 #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] + (y))
+#define ltq_icu_r32(vpe, m, x)		ltq_r32(ltq_icu_membase[vpe][m] + (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))
@@ -62,11 +62,50 @@
 /* we have a cascade of 8 irqs */
 #define MIPS_CPU_IRQ_CASCADE		8
 
+#define MAX_VPES 2
+
+/*
+ * Convenience Macro.  Should be somewhere generic.
+ */
+#define get_current_vpe()   \
+	((read_c0_tcbind() >> TCBIND_CURVPE_SHIFT) & TCBIND_CURVPE)
+
+
+#if 1	// TODO debug? SMP cores can access at the same time
+#if defined(CONFIG_SMP)
+#define LOCK_VPE() \
+	local_irq_save(flags); \
+	mtflags = dmt()
+
+#define UNLOCK_VPE() \
+	emt(mtflags); \
+	local_irq_restore(flags)
+
+#define LOCK_CORE() \
+	local_irq_save(flags); \
+	mtflags = dvpe()
+
+#define UNLOCK_CORE() \
+	evpe(mtflags); \
+	local_irq_restore(flags)
+#else /* CONFIG_SMP*/
+#define LOCK_VPE()
+#define UNLOCK_VPE()
+#endif /* CONFIG_SMP */
+
+#else	// TODO debug future delete
+#define LOCK_VPE()	(void)flags;(void)mtflags
+#define UNLOCK_VPE()
+#define LOCK_CORE()	(void)flags;(void)mtflags
+#define UNLOCK_CORE()
+#endif
+
 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][MAX_IM];
 static void __iomem *ltq_eiu_membase;
 static struct irq_domain *ltq_domain;
+static DEFINE_SPINLOCK(ltq_eiu_lock);
 static int ltq_perfcount_irq;
 
 int ltq_eiu_get_irq(int exin)
@@ -81,9 +120,14 @@
 	u32 ier = LTQ_ICU_IM0_IER;
 	int offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
 	int im = offset / INT_NUM_IM_OFFSET;
-
+	int vpe = get_current_vpe();
+#if defined(CONFIG_SMP)
+	unsigned long flags, mtflags;
+#endif
 	offset %= INT_NUM_IM_OFFSET;
-	ltq_icu_w32(im, ltq_icu_r32(im, ier) & ~BIT(offset), ier);
+	LOCK_VPE();
+	ltq_icu_w32(vpe, im, ltq_icu_r32(vpe, im, ier) & ~BIT(offset), ier);
+	UNLOCK_VPE();
 }
 
 void ltq_mask_and_ack_irq(struct irq_data *d)
@@ -92,10 +136,16 @@
 	u32 isr = LTQ_ICU_IM0_ISR;
 	int offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
 	int im = offset / INT_NUM_IM_OFFSET;
+	int vpe = get_current_vpe();
+#if defined(CONFIG_SMP)
+	unsigned long flags, mtflags;
+#endif
 
 	offset %= INT_NUM_IM_OFFSET;
-	ltq_icu_w32(im, ltq_icu_r32(im, ier) & ~BIT(offset), ier);
-	ltq_icu_w32(im, BIT(offset), isr);
+	LOCK_VPE();
+	ltq_icu_w32(vpe, im, ltq_icu_r32(vpe, im, ier) & ~BIT(offset), ier);
+	ltq_icu_w32(vpe, im, BIT(offset), isr);
+	UNLOCK_VPE();
 }
 EXPORT_SYMBOL(ltq_mask_and_ack_irq);
 
@@ -104,24 +154,43 @@
 	u32 isr = LTQ_ICU_IM0_ISR;
 	int offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
 	int im = offset / INT_NUM_IM_OFFSET;
+	int vpe = get_current_vpe();
+#if defined(CONFIG_SMP)
+	unsigned long flags, mtflags;
+#endif
 
 	offset %= INT_NUM_IM_OFFSET;
-	ltq_icu_w32(im, BIT(offset), isr);
+	LOCK_VPE();
+	ltq_icu_w32(vpe, im, BIT(offset), isr);
+	UNLOCK_VPE();
 }
 
 void ltq_enable_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;
+	int vpe = get_current_vpe();
+#if defined(CONFIG_SMP)
+	unsigned long flags, mtflags;
+#endif
 
 	offset %= INT_NUM_IM_OFFSET;
-	ltq_icu_w32(im, ltq_icu_r32(im, ier) | BIT(offset), ier);
+	LOCK_VPE();
+
+	// TODO present in the v3.10 kernel, system is OK without it
+	/* Bug fix for fake interrupt */
+	//ltq_icu_w32(vpe, im, BIT(offset), isr);
+
+	ltq_icu_w32(vpe, im, ltq_icu_r32(vpe, im, ier) | BIT(offset), ier);
+	UNLOCK_VPE();
 }
 
 static int 

Re: [OpenWrt-Devel] [PATCH] Honour NO_COLOR in include/scan.mk

[Jo-Philipp Wich]

Hi,

> That is true. But, on the other hand, the same routine was not printing
> anything if IS_TTY is not 1. I would say that this is unexpected
> behaviour too. If the log file shows some error, it would be nice to see
> what part was being processed.

this might be, but the scope of this patch was to make the build system
recognize `NO_COLOR` in order to suppress output coloring, so the
implementation of this feature should do exactly that.

> I do not really mind how it is fixed, so long NO_COLOR is honoured.
> Otherwise, I would have to find some script that filters ANSI colour
> codes and the like.

Could you please send a V2 with the requested change to print $(1)
without ANSII escape sequences?

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Honour NO_COLOR in include/scan.mk

[R. Diez via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


> your patch would disable the complete output if NO_COLOR is set.
> That does not seem to meet the expected behavior.

That is true. But, on the other hand, the same routine was not printing 
anything if IS_TTY is not 1. I would say that this is unexpected 
behaviour too. If the log file shows some error, it would be nice to see 
what part was being processed.


I do not really mind how it is fixed, so long NO_COLOR is honoured. 
Otherwise, I would have to find some script that filters ANSI colour 
codes and the like.


Best regards,
  rdiez

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

Re: [OpenWrt-Devel] A second 'make' always rebuilds something

[Jo-Philipp Wich]

Hi,

as far as I know, the Gluon build system is performing various rather
invasive changes to the build system.

Please see if you can replicate the same behavior with a vanilla OpenWrt
build root.

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] A second 'make' always rebuilds something

[R. Diez via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

Hi all:

I am helping build Freifunk images (based on Gluon, which is based on 
OpenWrt) and we have very long build times. That is the reason why I am 
taking a closer look.


I just checked out OpenWrt HEAD and built a standard x86_64 image with 
the following command:


make NO_COLOR=1 IS_TTY=0 V=s --output-sync=recurse -j 5 If I run the same command again, without touching anything, it takes 5 
minutes. I would not expect anything to get rebuilt at all.


It is hard to know from the very long log file what files have been 
overwritten, or why something is being rebuilt. These 2 lines from the 
build log are an indication that something is being modified or recompiled:


touch 
/home/rdiez/rdiez/temp/freifunk/openwrt/git-repo/build_dir/target-x86_64_musl/linux-x86_64/linux-4.14.96/.configured


[  5%] Building C object CMakeFiles/uci.dir/libuci.c.o

Before I dig anymore in this issue:

1) Is this a known limitation in the build logic?

2) Would something like "repeatable builds" help? For example, I wonder 
if each build embeds the current timestamp, and therefore running 'make' 
always ends up rebuilding the final image.


Thanks in advance,
  rdiez

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

Re: [OpenWrt-Devel] [PATCH] openwrt-18.06: ar71xx: Fix 5 GHz MAC address for Archer C60 v2

[Jo-Philipp Wich]

Hi,

this patch should go through master first. It currently does not apply
there.

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Merged: mbedtls: update to 2.14.1 for 18.06

[Jo-Philipp Wich]

Merged into openwrt-18.06 at
http://git.openwrt.org/?p=openwrt/openwrt.git.

Thank you!


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

Re: [OpenWrt-Devel] GSoC 2019 application

[Andreas Bräu]

Hi there,

that's a reminder! :)

Please do not forget to add your new ideas to our projects page. At the
moment there are only 11 ideas specific for GSoC 2019.

Thank you and best regards,

Andi

On 03.01.19 17:55, Andreas Bräu wrote:
> Hi there,
>
> I wish you all a happy new year. I hope you had a good time over
> Christmas and New Year.
>
> A new year also means there will be a new Google Summer of Code. It will
> be the 15th edition!
>
> The application period will start in a few days on January 15.
>
> If we want to apply again and to be successful, we need to add some
> fresh ideas to our projects page before our application:
> https://projects.freifunk,net 
>
> You can add, edit or delete your ideas via
> GitHub: 
> https://github.com/freifunk/projects.freifunk.net-contents/tree/master/collections/_projects
>
> We should also delete ideas that are obsolete now.
>
> If you have any questions, please tell me!
>
> Best regards,
>
> Andi



—
Andreas Bräu

XMPP: andibr...@jabber.weimarnetz.de 
Twitter:@evAltenberga 
Blog:https://blog.andi95.de 
PGP:0xB7E04818



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel