[OpenWrt-Devel] [hostapd] AP+STA mode support in Upstream Hostapd
Hi OpenWRT team, This is Sathishkumar working for ath10k WLAN driver and came across below OpenWRT hostapd/wpa_s patches which are added for supporting AP+STA mode in OpenWRT supported platforms. https://github.com/openwrt/openwrt/blob/master/package/network/services/host apd/patches/340-reload_freq_change.patch https://github.com/openwrt/openwrt/blob/master/package/network/services/host apd/patches/360-ctrl_iface_reload.patch https://github.com/openwrt/openwrt/blob/master/package/network/services/host apd/patches/370-ap_sta_support.patch Since these patches are not present in upstream hostapd, we see that during channel switch of root AP, STA VAP of AP+STA mode device goes down since AP VAP is still UP. Above patches uses hostapd ctrl_iface to send STOP_AP and UPDATE commands from wpa_s for seamless channel change of AP VAP whenever there is channel switch on root AP side. We couldnt find the commit message and author for these patches to check if these patches can be upstreamed. Do you have any plan for upstreaming these patches needed for AP+STA mode support ? Some patches have SVN reference which we are not sure how to check for knowing commit message and author. Can you please help here ? Our intention is to try upstreaming these patches either by checking with the author/s of patches or do ourselves if we at least know the commit message and author details. Thanks, Sathishkumar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SHA256 password
Hi Lev, the patch was added to save space. Dropping it will increase the libc size by a few kilobytes. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm2708: Update brcm2708-gpu-fw package
On 27/05/18 13:43, Christo Nedev wrote: Fix brcm2710 image boot issues. please describe the issues and how they are fixed. John Signed-off-by: Christo Nedev --- package/kernel/brcm2708-gpu-fw/Makefile | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/package/kernel/brcm2708-gpu-fw/Makefile b/package/kernel/brcm2708-gpu-fw/Makefile index 9f3d7d3092..73aebd7b5f 100644 --- a/package/kernel/brcm2708-gpu-fw/Makefile +++ b/package/kernel/brcm2708-gpu-fw/Makefile @@ -9,8 +9,8 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=brcm2708-gpu-fw -PKG_VERSION:=2017-08-08 -PKG_RELEASE:=e7ba7ab135f5a68b2c00a919ea9ac8d5528a5d5b +PKG_VERSION:=2018-05-16 +PKG_RELEASE:=0f5f899ccec1c2ef8bba02aa49700b4ec19b4199 PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/$(PKG_NAME)/rpi-firmware-$(PKG_RELEASE) @@ -33,7 +33,7 @@ define Download/bootcode_bin FILE:=$(RPI_FIRMWARE_FILE)-bootcode.bin URL:=$(RPI_FIRMWARE_URL) URL_FILE:=bootcode.bin - HASH:=b5928ef5253774362014f9e7de856397a932514fe1bc5d7f7817a73c0e10e863 + HASH:=c9eb5258766fabf7127e790b257f106e2717f0ccaaed37544b970b0d113956fc endef $(eval $(call Download,bootcode_bin)) @@ -41,7 +41,7 @@ define Download/fixup_dat FILE:=$(RPI_FIRMWARE_FILE)-fixup.dat URL:=$(RPI_FIRMWARE_URL) URL_FILE:=fixup.dat - HASH:=d95fcac57de7ab71e863a115fd60444f6099cb2ea100f4a68b2c606f79e775ed + HASH:=8a6311e73d0f349be9b8424db0644fd8f48aaf721f3f2f487488c83d7316cbdf endef $(eval $(call Download,fixup_dat)) @@ -49,7 +49,7 @@ define Download/fixup_cd_dat FILE:=$(RPI_FIRMWARE_FILE)-fixup_cd.dat URL:=$(RPI_FIRMWARE_URL) URL_FILE:=fixup_cd.dat - HASH:=28f3ec8388df4e0c47489f8370a29ca81dbc536fe7db9978342865b5d093ec36 + HASH:=973b008aae9711d57ddce4f058354fe5a0b4725dd825673f784a2e2754da1f28 endef $(eval $(call Download,fixup_cd_dat)) @@ -57,7 +57,7 @@ define Download/start_elf FILE:=$(RPI_FIRMWARE_FILE)-start.elf URL:=$(RPI_FIRMWARE_URL) URL_FILE:=start.elf - HASH:=8712fb4e241a22f7a33de0f1d420e0fdfff237952aa685c907b91e59c8d487fa + HASH:=8e77c4cce7e44ced609e5046dd55f19cb7656a8ce4694e733b7eb6ecab915fe1 endef $(eval $(call Download,start_elf)) @@ -65,7 +65,7 @@ define Download/start_cd_elf FILE:=$(RPI_FIRMWARE_FILE)-start_cd.elf URL:=$(RPI_FIRMWARE_URL) URL_FILE:=start_cd.elf - HASH:=c600ab34bea389da10aac541bf2f9c62e5f774093b7e1f2f72c4637f9cf3a83c + HASH:=25223b479b7aca1d74c6f7a1829aba69fd14906ca5b25ae12571fe71ea2c5a4a endef $(eval $(call Download,start_cd_elf)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SHA256 password
On 29 May 2018 at 19:24, Lev wrote: > Hi list, > > > Is this patch still needed for the latest musl? > > 901-crypt_size_hack.patch > I removed this patch over a year ago. Since then I have been successfully building images for my WXR-1900DHP and running LEDE/OpenWrt with SHA256 and SHA512 working perfectly. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/5] ath79: add TP-Link TL-WR740N/ND v2 port
On 29.05.2018 21:08, Alex Maclean wrote: + ucidef_set_led_wlan "wlan" "WLAN" "$boardname:green:wlan" "phy0tpt" thank you for the tiny split, you can trigger this in dts, please have a look at the PR's on github ! Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] Missing skb->dst with flow offloading
Hey Pablo, Some OpenWRT people have reported to me that there's a crash when enabling flow offloading, because I rely on skb_dst(skb) being non-null in ndo_start_xmit. The fix in my code for this is very simple: - mtu = dst_mtu(skb_dst(skb)); + dst = skb_dst(skb); + mtu = dst ? dst_mtu(dst) : dev->mtu; I can make this change, but I wanted to be certain first that omitting the dst in the skb is intentional on your part. (If so, there might be other drivers to fix as well.) In tracing this, it looks like a packet that's forwarded from a flow offloaded interface to a virtual interface gets diverted immediately via neigh_xmit, where it is then passed to a virtual interface via dev_queue_xmit. I can't see anywhere along this path a call to skb_dst_set. Perhaps this is intended, as flow offloading is supposed to skip the routing table? Or is there an oversight in the new flow offloading code? I'd appreciate your input, so that I can make the appropriate change -- or not -- to my code. Regards, Jason ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] SHA256 password
Hi list, Is this patch still needed for the latest musl? 901-crypt_size_hack.patch Thanks, Levente -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Fix WiFi after 5f7396ebef09b224edf08b0bda113613a42f0928
Rosen Penev wrote: > That commit exposed a bug in the DTS files used by mt7621 where > the wrong reg value for pcie1 (and potentially pcie2) was being > used. This was causing WiFi failures for interfaces in pcie1. > > eg. 2.4GHz working but not 5GHz. > > As all of these dts entries are already specified in > mt7621.dtsi, remove them. > > Signed-off-by: Rosen Penev > --- > target/linux/ramips/dts/DIR-860L-B1.dts | 4 > target/linux/ramips/dts/EW1200.dts | 4 > target/linux/ramips/dts/FIREWRT.dts | 4 > target/linux/ramips/dts/HC5962.dts | 4 > target/linux/ramips/dts/Newifi-D1.dts| 4 > target/linux/ramips/dts/Newifi-D2.dts| 4 > target/linux/ramips/dts/PBR-M1.dts | 4 > target/linux/ramips/dts/R6220.dts| 4 > target/linux/ramips/dts/RE350.dts| 4 > target/linux/ramips/dts/RE6500.dts | 4 > target/linux/ramips/dts/SAP-G3200U3.dts | 4 > target/linux/ramips/dts/SK-WB8.dts | 4 > target/linux/ramips/dts/TL-WR902ACV3.dts | 2 -- > target/linux/ramips/dts/WF-2881.dts | 4 > target/linux/ramips/dts/WITI.dtsi| 4 > target/linux/ramips/dts/WNDR3700V5.dts | 4 > target/linux/ramips/dts/WR1200JS.dts | 4 > target/linux/ramips/dts/WSR-1166.dts | 4 > target/linux/ramips/dts/WSR-600.dts | 4 > target/linux/ramips/dts/ZBT-WE1326.dts | 4 Confirmed this fixes missing 2.4g radios on WE1326. Sincerely, Karl Palsson signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LEDE 17.01.5 release planning
On 05/24/2018 09:06 PM, Hauke Mehrtens wrote: > We would like to create a lede 17.01.5 release soon, the last release, > lede 17.01.4, was done on 18. October 2017 which was a long time ago. > We are planning to do the build by end of next week, around 2. June 2018. > > This release would be build form the lede-17.01 stable branch and > contain all the fixes which are in this branch. > For me this branch looks quite good, if there are any patches missing in > the lede-17.01 branch which you think should be backported from the > current master branch then please highlight this now, so we can have a > look at this. > > I will update the kernel used in lede-17.01 to the latest version from > the stable 4.4 kernel line sometime beginning next week. > > Please also report any regression which is in the current lede-17.01 > branch compared to the lede 17.01.4 release. > > Please do not hesitate to re report some request that something should > be backported from master or some regression compared to lede-17.01, if > it looks like they got ignored and didn't got a response. > > All the developers can cherry picking some commits from master by them > self. ;-) > > The versions of the packages can be found here: > https://sdwalker.github.io/uscan/index-17.01.html > > The current snapshot build from the lede-17.01 branch can be found here: > https://downloads.lede-project.org/releases/17.01-SNAPSHOT/ > I went through the commits done to master and found these two which look like they should be backports: brcm47xx: add switch port mapping to Asus WL-500W https://git.openwrt.org/7ac238fc9855d20f0cfbc5754a1f9591438abfe3 mvebu: Add support for WRT3200ACM with new NAND flash https://git.openwrt.org/4b486e32fb34567fe8b04aea552225db699813e1 In addition I would like to change most of the URLs in lede-17.01.5 from lede-project.org to openwrt.org. If lede 17.01 also has the performance problems with ustream-ssl, I would also activate the TLS session cache for the 17.01.5 release and probably update mbedtsl to version 2.7.3 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wifi on ZBT-WE1326 broken after commit 5f7396ebef09
Kristian Evensen wrote: > Hello, > > On Tue, May 29, 2018 at 5:24 PM, Kristian Evensen > wrote: > > Carrying a local revert of the commit in question is always a > > possibility (and does not seem to have any unintentional > > side-effects), but I would rather try to fix the problem properly. > > Does anyone have any suggestions on where to look? > > Banging my head in the wall for some hours seems to have > resulted in a solution. > > The default PCIe interrupt mapping in mt7621.dtsi is wrong for > WE1326. After taking a look at which IRQs were set up before > commit 5f7396ebef09, I noticed that the IRQs in mt7621.dtsi. > After adding the following to the pcie-node of ZBT-WE1326.dts, > wifi is working fine: > > interrupt-map = <0x1 0 0 1 GIC_SHARED 24 > IRQ_TYPE_LEVEL_HIGH>, > <0x2 0 0 1 GIC_SHARED 25 > IRQ_TYPE_LEVEL_HIGH>; > > I will prepare and submit a patch. There were a few people on this today it seems :) See also https://github.com/openwrt/mt76/issues/173 and https://forum.lede-project.org/t/mt76-stopped-working-with-latest-updates/14623/41 There's a patch at the bottom of that from mangix/neheb that removes from overrides that just set 0s, and that fixed it for my we1326 Sincerely, Karl P signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH netifd] system-linux: make encaplimit configurable for ip6 tunnels (FS#1501)
Make encapsulation limit of IP6 tunnels configurable for the ds-lite/map
proto shell handlers as not all ISPs support the destination option header
containing the tunnel encapsulation limit value as reported in FS#1501.
The IP6 tunnel specific setting encaplimit is parsed as a nested json
data object; setting it to ignore disables the insertion of the
destination option header while a value from 0 till 255 sets the
tunnel encapsulation limit accordingly in the destination option header.
Signed-off-by: Hans Dedecker
---
system-linux.c | 51 +--
system.c | 10 ++
system.h | 7 +++
3 files changed, 50 insertions(+), 18 deletions(-)
diff --git a/system-linux.c b/system-linux.c
index 2a108e2..0127b01 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -2300,7 +2300,6 @@ static int system_add_ip6_tunnel(const char *name, const
unsigned int link,
nla_put_u8(nlm, IFLA_IPTUN_PROTO, IPPROTO_IPIP);
nla_put_u8(nlm, IFLA_IPTUN_TTL, (ttl) ? ttl : 64);
- nla_put_u8(nlm, IFLA_IPTUN_ENCAP_LIMIT, 4);
struct in6_addr in6buf;
if ((cur = tb[TUNNEL_ATTR_LOCAL])) {
@@ -2319,26 +2318,41 @@ static int system_add_ip6_tunnel(const char *name,
const unsigned int link,
nla_put(nlm, IFLA_IPTUN_REMOTE, sizeof(in6buf), );
}
-#ifdef IFLA_IPTUN_FMR_MAX
if ((cur = tb[TUNNEL_ATTR_DATA])) {
- struct blob_attr *dcur;
- unsigned drem, fmrcnt = 0;
- struct nlattr *fmrs = nla_nest_start(nlm, IFLA_IPTUN_FMRS);
+ struct blob_attr *tb_data[__IPIP6_DATA_ATTR_MAX];
- if (!fmrs) {
- ret = -ENOMEM;
- goto failure;
- }
+ blobmsg_parse(ipip6_data_attr_list.params,
__IPIP6_DATA_ATTR_MAX, tb_data,
+ blobmsg_data(cur), blobmsg_len(cur));
- blobmsg_for_each_attr(dcur, cur, drem) {
- if (blobmsg_type(dcur) != BLOBMSG_TYPE_ARRAY ||
- strcmp(blobmsg_name(dcur), "fmrs") ||
- blobmsg_check_array(dcur,
BLOBMSG_TYPE_UNSPEC) <= 0)
- continue;
+ if ((cur = tb_data[IPIP6_DATA_ENCAPLIMIT])) {
+ char *str = blobmsg_get_string(cur);
+
+ if (strcmp(str, "ignore")) {
+ char *e;
+ unsigned encap_limit = strtoul(str, , 0);
+
+ if (e == str || *e || encap_limit > 255) {
+ ret = -EINVAL;
+ goto failure;
+ }
+ nla_put_u8(nlm, IFLA_IPTUN_ENCAP_LIMIT,
encap_limit);
+ } else
+ nla_put_u32(nlm, IFLA_IPTUN_FLAGS,
IP6_TNL_F_IGN_ENCAP_LIMIT);
+ }
+
+#ifdef IFLA_IPTUN_FMR_MAX
+ if ((cur = tb_data[IPIP6_DATA_FMRS])) {
struct blob_attr *rcur;
- unsigned rrem;
- blobmsg_for_each_attr(rcur, dcur, rrem) {
+ unsigned rrem, fmrcnt = 0;
+ struct nlattr *fmrs = nla_nest_start(nlm,
IFLA_IPTUN_FMRS);
+
+ if (!fmrs) {
+ ret = -ENOMEM;
+ goto failure;
+ }
+
+ blobmsg_for_each_attr(rcur, cur, rrem) {
struct blob_attr *tb_fmr[__FMR_DATA_ATTR_MAX],
*tb_cur;
struct in6_addr ip6prefix;
struct in_addr ip4prefix;
@@ -2390,10 +2404,11 @@ static int system_add_ip6_tunnel(const char *name,
const unsigned int link,
nla_nest_end(nlm, rule);
}
+
+ nla_nest_end(nlm, fmrs);
}
- nla_nest_end(nlm, fmrs);
- }
#endif
+ }
nla_nest_end(nlm, infodata);
nla_nest_end(nlm, linkinfo);
diff --git a/system.c b/system.c
index e236e96..f96708d 100644
--- a/system.c
+++ b/system.c
@@ -79,6 +79,16 @@ const struct uci_blob_param_list sixrd_data_attr_list = {
.params = sixrd_data_attrs,
};
+static const struct blobmsg_policy ipip6_data_attrs[__SIXRD_DATA_ATTR_MAX] = {
+ [IPIP6_DATA_ENCAPLIMIT] = { .name = "encaplimit", .type =
BLOBMSG_TYPE_STRING },
+ [IPIP6_DATA_FMRS] = { .name = "fmrs", .type = BLOBMSG_TYPE_ARRAY },
+};
+
+const struct uci_blob_param_list ipip6_data_attr_list = {
+ .n_params = __IPIP6_DATA_ATTR_MAX,
+ .params = ipip6_data_attrs,
+};
+
static const struct blobmsg_policy fmr_data_attrs[__FMR_DATA_ATTR_MAX] = {
[FMR_DATA_PREFIX6] = { .name = "prefix6", .type = BLOBMSG_TYPE_STRING },
[OpenWrt-Devel] [PATCH 2/2] odhcp6c: make ds-lite tunnel encapsulation limit support configurable (FS#1501)
Be compatible with ISPs which don't support the destination option header
containing
the tunnel encapsulation limit as reported in FS#1501 for dynamic created
ds-lite
interfaces.
Setting the uci parameter encaplimit_dslite to ignore; allows to disable the
insertion
of the destination option header for the dynamic created ds-lite interface.
Otherwise the tunnel encapsulation limit value can be set to a value from 0
till 255
by setting the encaplimit_dslite uci parameter accordingly.
Signed-off-by: Hans Dedecker
---
package/network/ipv6/odhcp6c/Makefile| 2 +-
package/network/ipv6/odhcp6c/files/dhcpv6.script | 1 +
package/network/ipv6/odhcp6c/files/dhcpv6.sh | 6 --
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/package/network/ipv6/odhcp6c/Makefile
b/package/network/ipv6/odhcp6c/Makefile
index 4ecafc9276..64656dfd77 100644
--- a/package/network/ipv6/odhcp6c/Makefile
+++ b/package/network/ipv6/odhcp6c/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=odhcp6c
-PKG_RELEASE:=11
+PKG_RELEASE:=12
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/odhcp6c.git
diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.script
b/package/network/ipv6/odhcp6c/files/dhcpv6.script
index 3171013966..00393ff6b7 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.script
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.script
@@ -183,6 +183,7 @@ setup_interface () {
json_add_string tunlink "$INTERFACE"
[ -n "$ZONE_DSLITE" ] || ZONE_DSLITE=$ZONE
[ -n "$ZONE_DSLITE" ] && json_add_string zone "$ZONE_DSLITE"
+ [ -n "$ENCAPLIMIT_DSLITE" ] && json_add_string encaplimit
"$ENCAPLIMIT_DSLITE"
[ -n "$IFACE_DSLITE_DELEGATE" ] && json_add_boolean delegate
"$IFACE_DSLITE_DELEGATE"
json_close_object
ubus call network add_dynamic "$(json_dump)"
diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.sh
b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
index 919872fe8e..2962dccdaa 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.sh
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
@@ -19,6 +19,7 @@ proto_dhcpv6_init_config() {
proto_config_add_array 'ip6prefix:list(ip6addr)'
proto_config_add_string iface_dslite
proto_config_add_string zone_dslite
+ proto_config_add_string encaplimit_dslite
proto_config_add_string iface_map
proto_config_add_string zone_map
proto_config_add_string iface_464xlat
@@ -48,8 +49,8 @@ proto_dhcpv6_setup() {
local config="$1"
local iface="$2"
- local reqaddress reqprefix clientid reqopts defaultreqopts noslaaconly
forceprefix extendprefix norelease ip6prefix ip6prefixes iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass sendopts delegate zone_dslite
zone_map zone_464xlat zone soltimeout fakeroutes sourcefilter
keep_ra_dnslifetime ra_holdoff
- json_get_vars reqaddress reqprefix clientid reqopts defaultreqopts
noslaaconly forceprefix extendprefix norelease iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass delegate zone_dslite zone_map
zone_464xlat zone soltimeout fakeroutes sourcefilter keep_ra_dnslifetime
ra_holdoff
+ local reqaddress reqprefix clientid reqopts defaultreqopts noslaaconly
forceprefix extendprefix norelease ip6prefix ip6prefixes iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass sendopts delegate zone_dslite
zone_map zone_464xlat zone encaplimit_dslite soltimeout fakeroutes sourcefilter
keep_ra_dnslifetime ra_holdoff
+ json_get_vars reqaddress reqprefix clientid reqopts defaultreqopts
noslaaconly forceprefix extendprefix norelease iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass delegate zone_dslite zone_map
zone_464xlat zone encaplimit_dslite soltimeout fakeroutes sourcefilter
keep_ra_dnslifetime ra_holdoff
json_for_each_item proto_dhcpv6_add_prefix ip6prefix ip6prefixes
# Configure
@@ -98,6 +99,7 @@ proto_dhcpv6_setup() {
[ -n "$zone_map" ] && proto_export "ZONE_MAP=$zone_map"
[ -n "$zone_464xlat" ] && proto_export "ZONE_464XLAT=$zone_464xlat"
[ -n "$zone" ] && proto_export "ZONE=$zone"
+ [ -n "$encaplimit_dslite" ] && proto_export
"ENCAPLIMIT_DSLITE=$encaplimit_dslite"
[ "$fakeroutes" != "0" ] && proto_export "FAKE_ROUTES=1"
[ "$sourcefilter" = "0" ] && proto_export "NOSOURCEFILTER=1"
[ "$extendprefix" = "1" ] && proto_export "EXTENDPREFIX=1"
--
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ds-lite: make tunnel encapsulation limit support configurable (FS#1501)
Be compatible with ISPs which don't support the destination option header
containing
the tunnel encapsulation limit as reported in FS#1501.
Setting the uci parameter encaplimit to ignore; allows to disable the insertion
of the destination option header in the ds-lite packets.
Otherwise the tunnel encapsulation limit value can be set to a value from 0
till 255
by setting the encaplimit_dslite uci parameter accordingly.
If no encaplimit value is specified the default value is 4 as before.
Signed-off-by: Hans Dedecker
---
package/network/ipv6/ds-lite/Makefile| 2 +-
package/network/ipv6/ds-lite/files/dslite.sh | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
mode change 100755 => 100644 package/network/ipv6/ds-lite/files/dslite.sh
diff --git a/package/network/ipv6/ds-lite/Makefile
b/package/network/ipv6/ds-lite/Makefile
index 58e7156b95..4393d35877 100644
--- a/package/network/ipv6/ds-lite/Makefile
+++ b/package/network/ipv6/ds-lite/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=ds-lite
PKG_VERSION:=7
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_LICENSE:=GPL-2.0
include $(INCLUDE_DIR)/package.mk
diff --git a/package/network/ipv6/ds-lite/files/dslite.sh
b/package/network/ipv6/ds-lite/files/dslite.sh
old mode 100755
new mode 100644
index 2485a424dc..e9a0544690
--- a/package/network/ipv6/ds-lite/files/dslite.sh
+++ b/package/network/ipv6/ds-lite/files/dslite.sh
@@ -15,8 +15,8 @@ proto_dslite_setup() {
local link="ds-$cfg"
local remoteip6
- local mtu ttl peeraddr ip6addr tunlink zone weakif
- json_get_vars mtu ttl peeraddr ip6addr tunlink zone weakif
+ local mtu ttl peeraddr ip6addr tunlink zone weakif encaplimit
+ json_get_vars mtu ttl peeraddr ip6addr tunlink zone weakif encaplimit
[ -z "$peeraddr" ] && {
proto_notify_error "$cfg" "MISSING_ADDRESS"
@@ -68,6 +68,9 @@ proto_dslite_setup() {
json_add_string local "$ip6addr"
json_add_string remote "$peeraddr"
[ -n "$tunlink" ] && json_add_string link "$tunlink"
+ json_add_object 'data'
+ json_add_string encaplimit "${encaplimit:-4}"
+ json_close_object
proto_close_tunnel
proto_add_data
@@ -97,6 +100,7 @@ proto_dslite_init_config() {
proto_config_add_string "tunlink"
proto_config_add_int "mtu"
proto_config_add_int "ttl"
+ proto_config_add_string "encaplimit"
proto_config_add_string "zone"
proto_config_add_string "weakif"
}
--
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
On Tue, May 29, 2018 at 8:57 PM, Kevin Darbyshire-Bryant wrote: > Oh lordy, that horrible device as exhibited in the netgear DGN3500. Talk > about magic values > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=42120bd7f323ff7170b32a5fd4674babd8b184bc Yeah I even copied that init sequence over to this driver, however I actually think I have the LED activity somewhat under control in this new driver as those registers were kind-of-sort-of documented in the vendor code drop. It turns out the D-Link thing I am playing with doesn't even have any LEDs mounted so I can't test it though. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: Fix pcie interrupt mapping for ZBT WE1326
Commit 5f7396ebef09 ("ramips: improve interrupt mapping") changed how
pcie interrupts are mapped for mt7621. The default interrupt mapping in
mt7621.dtsi is incorrect for the ZBT WE1326, causing wifi not to work.
This commit updates the WE1326 DTS with the correct interrupt mapping,
restoring wifi.
Signed-off-by: Kristian Evensen
---
target/linux/ramips/dts/ZBT-WE1326.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/linux/ramips/dts/ZBT-WE1326.dts
b/target/linux/ramips/dts/ZBT-WE1326.dts
index 6cbab66307..72707192a2 100644
--- a/target/linux/ramips/dts/ZBT-WE1326.dts
+++ b/target/linux/ramips/dts/ZBT-WE1326.dts
@@ -84,6 +84,9 @@
{
status = "okay";
+ interrupt-map = <0x1 0 0 1 GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>,
+ <0x2 0 0 1 GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;
+
pcie0 {
mt76@0,0 {
reg = <0x 0 0 0 0>;
--
2.14.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wifi on ZBT-WE1326 broken after commit 5f7396ebef09
Hello, On Tue, May 29, 2018 at 5:24 PM, Kristian Evensen wrote: > Carrying a local revert of the commit in question is always a > possibility (and does not seem to have any unintentional > side-effects), but I would rather try to fix the problem properly. > Does anyone have any suggestions on where to look? Banging my head in the wall for some hours seems to have resulted in a solution. The default PCIe interrupt mapping in mt7621.dtsi is wrong for WE1326. After taking a look at which IRQs were set up before commit 5f7396ebef09, I noticed that the IRQs in mt7621.dtsi. After adding the following to the pcie-node of ZBT-WE1326.dts, wifi is working fine: interrupt-map = <0x1 0 0 1 GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>, <0x2 0 0 1 GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>; I will prepare and submit a patch. BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On 29 May 2018, at 19:41, Linus Walleij wrote: > > On Tue, May 29, 2018 at 2:24 PM, Andrew Lunn wrote: > >> Did you look at the switch end? I found a datasheet for the >> 8366/8369. Register at 0x0050, P8GCR. It has two bits for RGMII >> delays. > > Unfortunately this datasheet is not applicable to RTL8366RB. > > RTL documentation and model numbers are a complete mess > around the time when this chip came out, unfortunately... I even > started to implement using that datasheet and had to toss a bunch > of stuff away. > > There might not even be a proper datasheet for RTL8366RB, > I'm afraid. The best we have is different (3 different AFAICT) > vendor code drops. Here is one drop over at DD-WRT: > https://svn.dd-wrt.com//browser/src/linux/universal/linux-3.2/drivers/net/ethernet/raeth/rb > > As you can see, the RTL8366RB vendor driver consists of > a hacked version of their RTL8368S driver, so apparently those > two ASICs are similar, they even kept the same filenames. > > For example the register defintions: > https://svn.dd-wrt.com/browser/src/linux/universal/linux-3.2/drivers/net/ethernet/raeth/rb/rtl8368s_reg.h > >> With RGMII delays, you have 3 'choices'. >> >> 1) The hardware design includes the delay, by zig-zagging the clock >> line to make it longer. >> 2) The 'MAC' side does the delay. >> 3) The 'PHY' side does the delay. >> >> I normally recommend the PHY side doing it, because that's what most >> board do. Gives us some consistency. But it does not really >> matter. Just make sure one side, and only once side is inserting the >> delays. > > Makes sense! But I haven't found anything applicable in the > RTL8366RB registers. > > There are some jam tables with magic values written all over > the place that have no documentation, I fear this is one of the > settings poked around with there. > > However, even if this router did not come with any code for > the RTL8366RB driver, I disassembled the binary to verify > that they use the same magic jam table, so the ASIC is > initialized in the same way. > > Yours, > Linus Walleij > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/listinfo/openwrt-devel Oh lordy, that horrible device as exhibited in the netgear DGN3500. Talk about magic values https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=42120bd7f323ff7170b32a5fd4674babd8b184bc Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with OpenPGP --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
On Tue, May 29, 2018 at 2:24 PM, Andrew Lunn wrote: > Did you look at the switch end? I found a datasheet for the > 8366/8369. Register at 0x0050, P8GCR. It has two bits for RGMII > delays. Unfortunately this datasheet is not applicable to RTL8366RB. RTL documentation and model numbers are a complete mess around the time when this chip came out, unfortunately... I even started to implement using that datasheet and had to toss a bunch of stuff away. There might not even be a proper datasheet for RTL8366RB, I'm afraid. The best we have is different (3 different AFAICT) vendor code drops. Here is one drop over at DD-WRT: https://svn.dd-wrt.com//browser/src/linux/universal/linux-3.2/drivers/net/ethernet/raeth/rb As you can see, the RTL8366RB vendor driver consists of a hacked version of their RTL8368S driver, so apparently those two ASICs are similar, they even kept the same filenames. For example the register defintions: https://svn.dd-wrt.com/browser/src/linux/universal/linux-3.2/drivers/net/ethernet/raeth/rb/rtl8368s_reg.h > With RGMII delays, you have 3 'choices'. > > 1) The hardware design includes the delay, by zig-zagging the clock > line to make it longer. > 2) The 'MAC' side does the delay. > 3) The 'PHY' side does the delay. > > I normally recommend the PHY side doing it, because that's what most > board do. Gives us some consistency. But it does not really > matter. Just make sure one side, and only once side is inserting the > delays. Makes sense! But I haven't found anything applicable in the RTL8366RB registers. There are some jam tables with magic values written all over the place that have no documentation, I fear this is one of the settings poked around with there. However, even if this router did not come with any code for the RTL8366RB driver, I disassembled the binary to verify that they use the same magic jam table, so the ASIC is initialized in the same way. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/5] ath79: add tiny subtarget
Signed-off-by: Alex Maclean --- target/linux/ath79/Makefile | 2 +- target/linux/ath79/image/Makefile | 3 + target/linux/ath79/image/common-tp-link.mk| 84 +++ target/linux/ath79/image/generic-tp-link.mk | 79 + target/linux/ath79/image/tiny-tp-link.mk | 2 + target/linux/ath79/tiny/config-default| 14 .../linux/ath79/tiny/profiles/00-default.mk | 9 ++ target/linux/ath79/tiny/target.mk | 6 ++ 8 files changed, 120 insertions(+), 79 deletions(-) create mode 100644 target/linux/ath79/image/common-tp-link.mk create mode 100644 target/linux/ath79/image/tiny-tp-link.mk create mode 100644 target/linux/ath79/tiny/config-default create mode 100644 target/linux/ath79/tiny/profiles/00-default.mk create mode 100644 target/linux/ath79/tiny/target.mk diff --git a/target/linux/ath79/Makefile b/target/linux/ath79/Makefile index e331cb4210..6add24a72a 100644 --- a/target/linux/ath79/Makefile +++ b/target/linux/ath79/Makefile @@ -4,7 +4,7 @@ ARCH:=mips BOARD:=ath79 BOARDNAME:=Atheros ATH79 (DTS) CPU_TYPE:=24kc -SUBTARGETS:=generic +SUBTARGETS:=generic tiny FEATURES:=ramdisk source-only diff --git a/target/linux/ath79/image/Makefile b/target/linux/ath79/image/Makefile index 792548657e..cd136b23b9 100644 --- a/target/linux/ath79/image/Makefile +++ b/target/linux/ath79/image/Makefile @@ -70,4 +70,7 @@ include ./generic.mk include ./generic-tp-link.mk include ./generic-ubnt.mk endif +ifeq ($(SUBTARGET),tiny) +include ./tiny-tp-link.mk +endif $(eval $(call BuildImage)) diff --git a/target/linux/ath79/image/common-tp-link.mk b/target/linux/ath79/image/common-tp-link.mk new file mode 100644 index 00..1dd5a289f2 --- /dev/null +++ b/target/linux/ath79/image/common-tp-link.mk @@ -0,0 +1,84 @@ +DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT TPLINK_HEADER_VERSION TPLINK_BOARD_NAME + +define rootfs_align +$(patsubst %-256k,0x4,$(patsubst %-128k,0x2,$(patsubst %-64k,0x1,$(patsubst squashfs%,0x4,$(patsubst root.%,%,$(1)) +endef + +# combine kernel and rootfs into one image +# mktplinkfw +# is "sysupgrade" or "factory" +# +# -a align the rootfs start on an bytes boundary +# -j add jffs2 end-of-filesystem markers +# -s strip padding from end of the image +# -X reserve bytes in the firmware image (hexval prefixed with 0x) +define Build/mktplinkfw + -$(STAGING_DIR_HOST)/bin/mktplinkfw \ + -H $(TPLINK_HWID) -W $(TPLINK_HWREV) -F $(TPLINK_FLASHLAYOUT) -N OpenWrt -V $(REVISION) \ + -m $(TPLINK_HEADER_VERSION) \ + -k $(IMAGE_KERNEL) \ + -r $@ \ + -o $@.new \ + -j -X 0x4 \ + -a $(call rootfs_align,$(FILESYSTEM)) \ + $(wordlist 2,$(words $(1)),$(1)) \ + $(if $(findstring sysupgrade,$(word 1,$(1))),-s) && mv $@.new $@ || rm -f $@ +endef + +# mktplinkfw-combined +# +# -c combined image +define Build/mktplinkfw-combined + $(STAGING_DIR_HOST)/bin/mktplinkfw \ + -H $(TPLINK_HWID) -W $(TPLINK_HWREV) -F $(TPLINK_FLASHLAYOUT) -N OpenWrt -V $(REVISION) $(1) \ + -m $(TPLINK_HEADER_VERSION) \ + -k $@ \ + -o $@.new \ + -s -S \ + -c + @mv $@.new $@ +endef + +define Device/tplink + TPLINK_HWREV := 0x1 + TPLINK_HEADER_VERSION := 1 + LOADER_TYPE := gz + KERNEL := kernel-bin | append-dtb | lzma + KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | tplink-v1-header + IMAGES := sysupgrade.bin factory.bin + IMAGE/sysupgrade.bin := append-rootfs | mktplinkfw sysupgrade | append-metadata + IMAGE/factory.bin := append-rootfs | mktplinkfw factory +endef + +define Device/tplink-nolzma + $(Device/tplink) + LOADER_FLASH_OFFS := 0x22000 + COMPILE := loader-$(1).gz + COMPILE/loader-$(1).gz := loader-okli-compile + KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 | loader-okli $(1) + KERNEL_INITRAMFS := kernel-bin | append-dtb | gzip | tplink-v1-header +endef + +define Device/tplink-4m + $(Device/tplink-nolzma) + TPLINK_FLASHLAYOUT := 4M + IMAGE_SIZE := 3904k +endef + +define Device/tplink-4mlzma + $(Device/tplink) + TPLINK_FLASHLAYOUT := 4Mlzma + IMAGE_SIZE := 3904k +endef + +define Device/tplink-8m + $(Device/tplink-nolzma) + TPLINK_FLASHLAYOUT := 8M + IMAGE_SIZE := 7936k +endef + +define Device/tplink-8mlzma +$(Device/tplink) + TPLINK_FLASHLAYOUT := 8Mlzma + IMAGE_SIZE := 7936k +endef diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 8a0388a7ff..0b4659abea 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -1,82 +1,5 @@ -DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT TPLINK_HEADER_VERSION TPLINK_BOARD_NAME +include ./common-tp-link.mk -define rootfs_align -$(patsubst %-256k,0x4,$(patsubst
[OpenWrt-Devel] [PATCH 5/5] ath79: add TP-Link TL-WR703N port
Signed-off-by: Alex Maclean
---
.../ath79/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/dts/ar9331_tl-wr703n.dts | 139 ++
target/linux/ath79/image/tiny-tp-link.mk | 10 ++
3 files changed, 150 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_tl-wr703n.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index cc4498ffc5..0d0ddb3987 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -9,6 +9,7 @@ ath79_setup_interfaces()
case "$board" in
"avm,fritz300e"|\
+ "tplink,tl-wr703n"|\
"ubnt,unifi")
ucidef_set_interface_lan "eth0"
;;
diff --git a/target/linux/ath79/dts/ar9331_tl-wr703n.dts
b/target/linux/ath79/dts/ar9331_tl-wr703n.dts
new file mode 100644
index 00..70f94ed4cb
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_tl-wr703n.dts
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9331.dtsi"
+
+/ {
+ compatible = "tplink,tl-wr703n", "qca,ar9331";
+ model = "TP-Link TL-WR703N";
+
+ aliases {
+ serial0 =
+ led-status = _system;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x200>;
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ led_system: system {
+ label = "tl-wr703n:blue:system";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ reg_usb_vbus: reg_usb_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+};
+
+ {
+ status = "okay";
+ num-cs = <1>;
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ reg = <0x0 0x2>;
+ label = "u-boot";
+ read-only;
+ };
+
+ firmware: partition@2 {
+ reg = <0x2 0x3d>;
+ label = "firmware";
+ };
+
+ art: partition@3f {
+ reg = <0x3f 0x1>;
+ label = "art";
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ phy-handle = <>;
+
+ mtd-mac-address = < 0x1fc00>;
+
+ gmac-config {
+ device = <>;
+
+ switch-phy-addr-swap = <0>;
+ switch-phy-swap = <0>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ phy-mode = "mii";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ dr_mode = "host";
+ vbus-supply = <_usb_vbus>;
+ status = "okay";
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ mtd-cal-data = < 0x1000>;
+ mtd-mac-address = < 0x1fc00>;
+};
diff --git a/target/linux/ath79/image/tiny-tp-link.mk
b/target/linux/ath79/image/tiny-tp-link.mk
index 09180bd678..e6d5feefc5 100644
--- a/target/linux/ath79/image/tiny-tp-link.mk
+++ b/target/linux/ath79/image/tiny-tp-link.mk
@@ -1,6 +1,16 @@
include ./common-tp-link.mk
+define Device/tl-wr703n
+ $(Device/tplink-4mlzma)
+ ATH_SOC := ar9331
+ DEVICE_TITLE := TP-Link TL-WR703N
+ DEVICE_PACKAGES := kmod-usb-chipidea2
+ TPLINK_HWID := 0x07030101
+ SUPPORTED_DEVICES := tplink,tl-wr703n tl-wr703n
+endef
+TARGET_DEVICES += tl-wr703n
+
define Device/tl-wr740n-v2
$(Device/tplink-4m)
ATH_SOC := ar7240
--
2.17.0
___
openwrt-devel mailing
[OpenWrt-Devel] [PATCH 4/5] ath79: add TP-Link TL-WR740N/ND v2 port
Signed-off-by: Alex Maclean
---
.../ath79/base-files/etc/board.d/01_leds | 8 +
.../ath79/base-files/etc/board.d/02_network | 6 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
.../linux/ath79/dts/ar7240_tl-wr740n-v2.dts | 174 ++
target/linux/ath79/image/tiny-tp-link.mk | 9 +
5 files changed, 198 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7240_tl-wr740n-v2.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds
b/target/linux/ath79/base-files/etc/board.d/01_leds
index 70d27bc29b..cede279c7f 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -21,6 +21,14 @@ case "$board" in
"glinet,ar150")
ucidef_set_led_wlan "wlan" "WLAN" "gl-ar150:orange:wlan" "phy0tpt"
;;
+"tplink,tl-wr740n-v2")
+ ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
+ ucidef_set_led_switch "lan1" "LAN1" "$boardname:green:lan1" "switch0"
"0x02"
+ ucidef_set_led_switch "lan2" "LAN2" "$boardname:green:lan2" "switch0"
"0x04"
+ ucidef_set_led_switch "lan3" "LAN3" "$boardname:green:lan3" "switch0"
"0x08"
+ ucidef_set_led_switch "lan4" "LAN4" "$boardname:green:lan4" "switch0"
"0x10"
+ ucidef_set_led_wlan "wlan" "WLAN" "$boardname:green:wlan" "phy0tpt"
+ ;;
"tplink,tl-wr1043nd-v1")
ucidef_set_led_usbdev "usb" "USB" "tp-link:green:usb" "1-1"
ucidef_set_led_wlan "wlan" "WLAN" "tp-link:green:wlan" "phy0tpt"
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 12176c1877..cc4498ffc5 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -19,6 +19,12 @@ ath79_setup_interfaces()
"0@eth0" "2:lan:1" "3:lan:2" "4:lan:3" "5:lan:4" "1:wan"
;;
+ "tplink,tl-wr740n-v2")
+ ucidef_set_interfaces_lan_wan "eth1.1" "eth0"
+ ucidef_add_switch "switch0" \
+ "0@eth1" "1:lan" "2:lan" "3:lan" "4:lan"
+ ;;
+
"tplink,tl-wr1043nd-v1")
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index c09dca11d7..498cc4e6cb 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -54,6 +54,7 @@ case "$FIRMWARE" in
"tplink,tl-wdr4300")
ath9k_eeprom_extract "art" 20480 1088
;;
+ "tplink,tl-wr740n-v2"|\
"ubnt,unifi")
ath9k_eeprom_extract "art" 4096 2048
;;
diff --git a/target/linux/ath79/dts/ar7240_tl-wr740n-v2.dts
b/target/linux/ath79/dts/ar7240_tl-wr740n-v2.dts
new file mode 100644
index 00..f86cb50d47
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_tl-wr740n-v2.dts
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar7240.dtsi"
+
+/ {
+ compatible = "tplink,tl-wr740n-v2", "qca,ar7240";
+ model = "TP-Link TL-WR740N v2";
+
+ aliases {
+ led-status = _system;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x200>;
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pins>;
+
+ led_system: system {
+ label = "tl-wr740n-v2:green:system";
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ };
+
+ lan1 {
+ label = "tl-wr740n-v2:green:lan1";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+
+ lan2 {
+ label = "tl-wr740n-v2:green:lan2";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+
+ lan3 {
+ label = "tl-wr740n-v2:green:lan3";
+ gpios = < 15
[OpenWrt-Devel] [PATCH 2/5] ath79: add AR7240 dtsi
Signed-off-by: Alex Maclean
---
target/linux/ath79/dts/ar7240.dtsi | 66 ++
1 file changed, 66 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7240.dtsi
diff --git a/target/linux/ath79/dts/ar7240.dtsi
b/target/linux/ath79/dts/ar7240.dtsi
new file mode 100644
index 00..6805d1a786
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240.dtsi
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar724x.dtsi"
+
+/ {
+ usb_phy: usb-phy {
+ compatible = "qca,ar7200-usb-phy";
+
+ reset-names = "usb-phy", "usb-ohci-dll";
+ resets = < 4>, < 3>;
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+};
+
+ {
+ usb: usb@1b00 {
+ compatible = "generic-ohci";
+ reg = <0x1b00 0x1000>;
+
+ interrupts = <3>;
+
+ resets = < 5>;
+ reset-names = "usb-host";
+
+ phy-names = "usb-phy";
+ phys = <_phy>;
+
+ status = "disabled";
+ };
+};
+
+ {
+ builtin-switch;
+};
+
+ {
+ compatible = "qca,ar7240-eth", "syscon";
+
+ pll-data = <0x0011 0x1099 0x00991099>;
+
+ resets = < 8>, < 9>;
+ reset-names = "phy", "mac";
+};
+
+ {
+ builtin-switch;
+};
+
+ {
+ compatible = "qca,ar7240-eth", "syscon";
+
+ pll-data = <0x0011 0x1099 0x00991099>;
+
+ resets = < 12>, < 13>;
+ reset-names = "phy", "mac";
+
+ phy-mode = "gmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
--
2.17.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/5] ath79: add pinmux node to ar724x.dtsi
Signed-off-by: Alex Maclean
---
target/linux/ath79/dts/ar724x.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/target/linux/ath79/dts/ar724x.dtsi
b/target/linux/ath79/dts/ar724x.dtsi
index fe1b4eb681..b2844bf179 100644
--- a/target/linux/ath79/dts/ar724x.dtsi
+++ b/target/linux/ath79/dts/ar724x.dtsi
@@ -64,6 +64,21 @@
#interrupt-cells = <2>;
};
+ pinmux: pinmux@18040028 {
+ compatible = "pinctrl-single";
+
+ reg = <0x18040028 0x8>;
+
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x1>;
+ #pinctrl-cells = <2>;
+
+ jtag_disable_pins: pinmux_jtag_disable_pins {
+ pinctrl-single,bits = <0x0 0x1 0x1>;
+ };
+ };
+
pll: pll-controller@1805 {
compatible = "qca,ar7240-pll", "syscon";
reg = <0x1805 0x3c>;
--
2.17.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: Fix WiFi after 5f7396ebef09b224edf08b0bda113613a42f0928
That commit exposed a bug in the DTS files used by mt7621 where the wrong
reg value for pcie1 (and potentially pcie2) was being used. This was
causing WiFi failures for interfaces in pcie1.
eg. 2.4GHz working but not 5GHz.
As all of these dts entries are already specified in mt7621.dtsi, remove
them.
Signed-off-by: Rosen Penev
---
target/linux/ramips/dts/DIR-860L-B1.dts | 4
target/linux/ramips/dts/EW1200.dts | 4
target/linux/ramips/dts/FIREWRT.dts | 4
target/linux/ramips/dts/HC5962.dts | 4
target/linux/ramips/dts/Newifi-D1.dts| 4
target/linux/ramips/dts/Newifi-D2.dts| 4
target/linux/ramips/dts/PBR-M1.dts | 4
target/linux/ramips/dts/R6220.dts| 4
target/linux/ramips/dts/RE350.dts| 4
target/linux/ramips/dts/RE6500.dts | 4
target/linux/ramips/dts/SAP-G3200U3.dts | 4
target/linux/ramips/dts/SK-WB8.dts | 4
target/linux/ramips/dts/TL-WR902ACV3.dts | 2 --
target/linux/ramips/dts/WF-2881.dts | 4
target/linux/ramips/dts/WITI.dtsi| 4
target/linux/ramips/dts/WNDR3700V5.dts | 4
target/linux/ramips/dts/WR1200JS.dts | 4
target/linux/ramips/dts/WSR-1166.dts | 4
target/linux/ramips/dts/WSR-600.dts | 4
target/linux/ramips/dts/ZBT-WE1326.dts | 4
target/linux/ramips/dts/ZBT-WG2626.dts | 4
21 files changed, 82 deletions(-)
diff --git a/target/linux/ramips/dts/DIR-860L-B1.dts
b/target/linux/ramips/dts/DIR-860L-B1.dts
index 5dfc1eeaef..5edf721740 100644
--- a/target/linux/ramips/dts/DIR-860L-B1.dts
+++ b/target/linux/ramips/dts/DIR-860L-B1.dts
@@ -115,8 +115,6 @@
pcie0 {
mt76@0,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0x2000>;
ieee80211-freq-limit = <500 600>;
};
@@ -124,8 +122,6 @@
pcie1 {
mt76@1,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0>;
ieee80211-freq-limit = <240 250>;
};
diff --git a/target/linux/ramips/dts/EW1200.dts
b/target/linux/ramips/dts/EW1200.dts
index 84c4f72cb6..bf2ed15e84 100644
--- a/target/linux/ramips/dts/EW1200.dts
+++ b/target/linux/ramips/dts/EW1200.dts
@@ -97,8 +97,6 @@
pcie0 {
mt76@0,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0x8000>;
ieee80211-freq-limit = <500 600>;
};
@@ -106,8 +104,6 @@
pcie1 {
mt76@1,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0x>;
ieee80211-freq-limit = <240 250>;
};
diff --git a/target/linux/ramips/dts/FIREWRT.dts
b/target/linux/ramips/dts/FIREWRT.dts
index 262dbb5f57..bfa05d5304 100644
--- a/target/linux/ramips/dts/FIREWRT.dts
+++ b/target/linux/ramips/dts/FIREWRT.dts
@@ -92,8 +92,6 @@
pcie0 {
mt76@0,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0x8000>;
ieee80211-freq-limit = <500 600>;
};
@@ -101,8 +99,6 @@
pcie1 {
mt76@1,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0x>;
ieee80211-freq-limit = <240 250>;
};
diff --git a/target/linux/ramips/dts/HC5962.dts
b/target/linux/ramips/dts/HC5962.dts
index c6fc7cb154..72b22e2d64 100644
--- a/target/linux/ramips/dts/HC5962.dts
+++ b/target/linux/ramips/dts/HC5962.dts
@@ -121,8 +121,6 @@
pcie0 {
mt76@0,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0x>;
ieee80211-freq-limit = <240 250>;
};
@@ -130,8 +128,6 @@
pcie1 {
mt76@1,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
mediatek,mtd-eeprom = < 0x8000>;
ieee80211-freq-limit = <500 600>;
};
diff --git a/target/linux/ramips/dts/Newifi-D1.dts
b/target/linux/ramips/dts/Newifi-D1.dts
index f5c7c91362..4659f85278 100644
--- a/target/linux/ramips/dts/Newifi-D1.dts
+++ b/target/linux/ramips/dts/Newifi-D1.dts
@@ -116,8 +116,6 @@
pcie0 {
mt76@0,0 {
- reg = <0x 0 0 0
[OpenWrt-Devel] [PATCH] ath10k-firmware: Fix two more typos
Actually tested with a local build instead of with scp'ing the firmware. Signed-off-by: Rosen Penev --- package/firmware/ath10k-firmware/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 35f6013947..c2b4000671 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -442,14 +442,14 @@ define Package/ath10k-firmware-qca6174/install $(INSTALL_DATA) \ $(PKG_BUILD_DIR)/QCA6174/hw2.1/board-2.bin \ $(1)/lib/firmware/ath10k/QCA6174/hw2.1/ - $(INSTALL_DATA) + $(INSTALL_DATA) \ $(PKG_BUILD_DIR)/QCA6174/hw2.1/firmware-5.bin_SW_RM.1.1.1-00157-QCARMSWPZ-1 \ $(1)/lib/firmware/ath10k/QCA6174/hw2.1/firmware-5.bin $(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA6174/hw3.0 $(INSTALL_DATA) \ $(PKG_BUILD_DIR)/QCA6174/hw3.0/board-2.bin \ $(1)/lib/firmware/ath10k/QCA6174/hw3.0/ - $(INSTALL_DATA) + $(INSTALL_DATA) \ $(PKG_BUILD_DIR)/QCA6174/hw3.0/4.4.1.c1/firmware-6.bin_RM.4.4.1.c1-00042-QCARMSWP-1 \ $(1)/lib/firmware/ath10k/QCA6174/hw3.0/firmware-6.bin endef -- 2.17.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 18.06 bug: Flow Offload Active Connections
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 29/05/2018 17:55, Jaap Buurman wrote: Dear all, Whenever flow offload is enabled (either software or hardware) I can see many many active connections on the Luci overview page. It can go up to thousands of active connections. Looking in the "connections" part of the "realtime graphs" in Luci shows me that even connections with devices that turned off hours ago are still active. So for some reasons old connections are not leaving the conntrack table. Turning off flow offload fixes these issues right away. I am currently running the latest 18.06 snapshot on a dir-860l. Hopefully this is useful information for debugging. Yours sincerely, Jaap Buurman Hi I can confirm I have same bug on wrt3200acm. Thanks Tapper ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k-firmware: Fix typo in last commit
On Tue, May 29, 2018 at 9:25 AM, Hannu Nyman wrote: > Mathias Kresin wrote on Mon May 28 09:44:34 PDT 2018: >> >> Shouldn't it be "$(INSTALL_DATA) \", similar to all the other install >> defines? > > > Yep. And there are two of those. On lines 445 and 452. > I fixed this locally but forgot to send patch. Will do so soon. > (the "typo fix" just removed the third one, the extra one) > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] 18.06 bug: Flow Offload Active Connections
Dear all, Whenever flow offload is enabled (either software or hardware) I can see many many active connections on the Luci overview page. It can go up to thousands of active connections. Looking in the "connections" part of the "realtime graphs" in Luci shows me that even connections with devices that turned off hours ago are still active. So for some reasons old connections are not leaving the conntrack table. Turning off flow offload fixes these issues right away. I am currently running the latest 18.06 snapshot on a dir-860l. Hopefully this is useful information for debugging. Yours sincerely, Jaap Buurman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath10k-firmware: Fix typo in last commit
Mathias Kresin wrote on Mon May 28 09:44:34 PDT 2018: Shouldn't it be "$(INSTALL_DATA) \", similar to all the other install defines? Yep. And there are two of those. On lines 445 and 452. (the "typo fix" just removed the third one, the extra one) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] Prenota le tue vacanze a Vieste Marina e risparmia
Se non visualizzi correttamente la newsletter clicca qui Camping Village Vieste Marina ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] ath79: Add compatible strings for tp-link partition parser
After reading the code I found an ugly way to pass art location by defining
meaningless nodes somewhere with only a label inside it.
So my final dts here:
spiflash: spi-nor@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
spi-max-frequency = <10400>;
reg = <0>;
partitions {
compatible = "tp-link";
uboot: whatever1 {
label = "u-boot";
};
art: whatever2 {
label = "art";
};
};
};
Still wondering if there could be other better solutions for this :(
Chuanhong Guo 于2018年5月29日周二 下午11:07写道：
> This patch allows using tp-link parser by defining 'partitions' node
inside m25p80 node as follow:
> partitions {
> compatible = "tp-link";
> };
> Signed-off-by: Chuanhong Guo
> ---
> Resend this patch due to the missing commit message :(
> .../ath79/files/drivers/mtd/tplinkpart.c | 23 +++
> 1 file changed, 23 insertions(+)
> diff --git a/target/linux/ath79/files/drivers/mtd/tplinkpart.c
b/target/linux/ath79/files/drivers/mtd/tplinkpart.c
> index 1b94163b83..8da5c4168e 100644
> --- a/target/linux/ath79/files/drivers/mtd/tplinkpart.c
> +++ b/target/linux/ath79/files/drivers/mtd/tplinkpart.c
> @@ -9,6 +9,7 @@
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -209,16 +210,36 @@ static int tplink_parse_64k_partitions(struct
mtd_info *master,
>TPLINK_64K_KERNEL_OFFS);
> }
> +#ifdef CONFIG_OF
> +static const struct of_device_id parse_tplink_match_table[] = {
> + { .compatible = "tp-link" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, parse_tplink_match_table);
> +
> +static const struct of_device_id parse_tplink_64k_match_table[] = {
> + { .compatible = "tp-link-64k" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, parse_tplink_64k_match_table);
> +#endif
> +
> static struct mtd_part_parser tplink_parser = {
> .owner = THIS_MODULE,
> .parse_fn = tplink_parse_partitions,
> .name = "tp-link",
> +#ifdef CONFIG_OF
> + .of_match_table = parse_tplink_match_table,
> +#endif
> };
> static struct mtd_part_parser tplink_64k_parser = {
> .owner = THIS_MODULE,
> .parse_fn = tplink_parse_64k_partitions,
> .name = "tp-link-64k",
> +#ifdef CONFIG_OF
> + .of_match_table = parse_tplink_64k_match_table,
> +#endif
> };
> static int __init tplink_parser_init(void)
> @@ -233,3 +254,5 @@ module_init(tplink_parser_init);
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Gabor Juhos ");
> +MODULE_ALIAS("tp-link");
> +MODULE_ALIAS("tp-link-64k");
> --
> 2.17.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] Wifi on ZBT-WE1326 broken after commit 5f7396ebef09
Hi,
Some days ago I pulled master, built an image and installed it on my
ZBT-WE1326 router. After installing the image, I noticed that wifi is
broken. When looking at dmesg, mt76 reports:
[ 14.479853] mt76x2e :01:00.0: MCU message 1 (seq 1) timed out
I initially suspected mt76, but wifi turned out to work fine on other
devices using the mt76-driver (like the ZBT WG3526). I then started a
bisect, and I found out that 5f7396ebef09 ("ramips: improve interrupt
mapping") is the bad commit. Starting from this commit, wifi on the
WE1326 does not work any more.
Since WE1326 and WG3526 is very similar (or supposed to be at least),
I tried to make the DTS' (more) in sync. When I have seen the "MCU ...
timed out" message before, it has usually been because the pinctrl
group was missing entry. However, making the group of the WE1326 match
that of WG3526 had no effect. I also tried to enable the all the other
possible group entries, but no change.
Carrying a local revert of the commit in question is always a
possibility (and does not seem to have any unintentional
side-effects), but I would rather try to fix the problem properly.
Does anyone have any suggestions on where to look?
Thanks in advance for any help,
Kristian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][RESEND] ath79: Add compatible strings for tp-link partition parser
This patch allows using tp-link parser by defining 'partitions' node inside
m25p80 node as follow:
partitions {
compatible = "tp-link";
};
Signed-off-by: Chuanhong Guo
---
Resend this patch due to the missing commit message :(
.../ath79/files/drivers/mtd/tplinkpart.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/target/linux/ath79/files/drivers/mtd/tplinkpart.c
b/target/linux/ath79/files/drivers/mtd/tplinkpart.c
index 1b94163b83..8da5c4168e 100644
--- a/target/linux/ath79/files/drivers/mtd/tplinkpart.c
+++ b/target/linux/ath79/files/drivers/mtd/tplinkpart.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -209,16 +210,36 @@ static int tplink_parse_64k_partitions(struct mtd_info
*master,
TPLINK_64K_KERNEL_OFFS);
}
+#ifdef CONFIG_OF
+static const struct of_device_id parse_tplink_match_table[] = {
+ { .compatible = "tp-link" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, parse_tplink_match_table);
+
+static const struct of_device_id parse_tplink_64k_match_table[] = {
+ { .compatible = "tp-link-64k" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, parse_tplink_64k_match_table);
+#endif
+
static struct mtd_part_parser tplink_parser = {
.owner = THIS_MODULE,
.parse_fn = tplink_parse_partitions,
.name = "tp-link",
+#ifdef CONFIG_OF
+ .of_match_table = parse_tplink_match_table,
+#endif
};
static struct mtd_part_parser tplink_64k_parser = {
.owner = THIS_MODULE,
.parse_fn = tplink_parse_64k_partitions,
.name = "tp-link-64k",
+#ifdef CONFIG_OF
+ .of_match_table = parse_tplink_64k_match_table,
+#endif
};
static int __init tplink_parser_init(void)
@@ -233,3 +254,5 @@ module_init(tplink_parser_init);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Gabor Juhos ");
+MODULE_ALIAS("tp-link");
+MODULE_ALIAS("tp-link-64k");
--
2.17.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: Add compatible strings for tp-link partition parser
Signed-off-by: Chuanhong Guo
---
PS: I tested this patch on ar9331-based pisen ts-d084 and it works correctly.
But it seemed that I have no way to tell ethernet and wifi drivers about where
mac address and ART data is.
Is there any solution for this problem?
.../ath79/files/drivers/mtd/tplinkpart.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/target/linux/ath79/files/drivers/mtd/tplinkpart.c
b/target/linux/ath79/files/drivers/mtd/tplinkpart.c
index 1b94163b83..8da5c4168e 100644
--- a/target/linux/ath79/files/drivers/mtd/tplinkpart.c
+++ b/target/linux/ath79/files/drivers/mtd/tplinkpart.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -209,16 +210,36 @@ static int tplink_parse_64k_partitions(struct mtd_info
*master,
TPLINK_64K_KERNEL_OFFS);
}
+#ifdef CONFIG_OF
+static const struct of_device_id parse_tplink_match_table[] = {
+ { .compatible = "tp-link" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, parse_tplink_match_table);
+
+static const struct of_device_id parse_tplink_64k_match_table[] = {
+ { .compatible = "tp-link-64k" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, parse_tplink_64k_match_table);
+#endif
+
static struct mtd_part_parser tplink_parser = {
.owner = THIS_MODULE,
.parse_fn = tplink_parse_partitions,
.name = "tp-link",
+#ifdef CONFIG_OF
+ .of_match_table = parse_tplink_match_table,
+#endif
};
static struct mtd_part_parser tplink_64k_parser = {
.owner = THIS_MODULE,
.parse_fn = tplink_parse_64k_partitions,
.name = "tp-link-64k",
+#ifdef CONFIG_OF
+ .of_match_table = parse_tplink_64k_match_table,
+#endif
};
static int __init tplink_parser_init(void)
@@ -233,3 +254,5 @@ module_init(tplink_parser_init);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Gabor Juhos ");
+MODULE_ALIAS("tp-link");
+MODULE_ALIAS("tp-link-64k");
--
2.17.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wireguard & hw flow offload incompatibility
Dear Jason, The initial technical explanation unfortunately went over my head, since I am not that technical myself. But I will do my best to provide the required information. First of all, sorry for the confusion that I may have caused, but this happens with both the hardware version of the flow offload implementation and the software version, so it doesn't seem to be caused by any vendor specific (hardware) logic. So it is probably easier to focus on the software version for now. Also, in case that wasn't fully clear, both the flow offloading feature and the wireguard interface are both running on the router itself. What exactly do you mean with the kernel source of these boxes? As far as I understand, Lede/OpenWRT uses the upstream 4.14 kernel in this build (4.14.43 in the one I am running atm) with Lede/OpenWRT specific patches. The patches that enable flow offloading support for the 4.14 kernel can be found in these 2 folders: https://github.com/openwrt/openwrt/tree/openwrt-18.06/target/linux/generic/backport-4.14 https://github.com/openwrt/openwrt/tree/openwrt-18.06/target/linux/generic/pending-4.14 One important thing is that the upstream flow offloading code uses nftables, while Lede/OpenWRT uses iptables. Hence flow offload support has been backported to iptables, which also might be a contribution to this bug. I'm not even sure what dst entries are exactly, but I found one patch that is supposed to fix dst entries. Perhaps it is incomplete or contains a bug?: https://github.com/openwrt/openwrt/commit/c89e338fe68fd5af61b80ef37c55a657721c6542 I will try to cross-compile wireguard with your suggested patch tomorrow or the day after tomorrow depending on my time schedule. I will report back whether it solves this issue. Thank you very much. Yours sincerely, Jaap Buurman On Tue, May 29, 2018 at 2:38 PM, Jason A. Donenfeld wrote: > Hey Felix, > > Per the below thread, I've been digging around trying to see what's > going on. Apparently packets are hitting a virtual network interface's > ndo_start_xmit with no dst when hardware offloading enabled. I assume > that the path is something along the lines of a packet coming in on > one of these hardware accelerated NICs and then being forwarded to the > wireguard interface, which expects the dst. I found your > ndo_flow_offload patchset, and I suspect that might have something to > do with this. Any insights on dsts disappearing in skbs? > > Thanks, > Jason > > On Tue, May 29, 2018 at 2:14 PM, Jason A. Donenfeld wrote: >> Hi Jaap, >> >> Thanks for the clarification. I downloaded the binary for that >> hardware and triaged where the bug occurs [1]. This patch [2] should >> probably fix it, but I'm rather surprised to see situations in which a >> skb is missing a dst entry in ndo_start_xmit; this might point to >> deeper kernel bugs in this hardware offloading feature, or some >> alternative mechanism for routing being used when hardware offloading >> is on. So I'm hesitant to merge this just yet, because perhaps this is >> better handled in the compat layer, if it is in fact vendor silliness. >> Do you have a link to the kernel source of these boxes? I'd like to >> see what exactly the vendor is doing. And if you could try [2] and see >> if that still crashes, this would be most appreciated. >> >> Thanks, >> Jason >> >> [1] https://data.zx2c4.com/openwrt-mips-offloading-bug.png >> [2] https://א.cc/Am4tZ0n8 >> >> On Tue, May 29, 2018 at 1:59 PM, Jaap Buurman wrote: >>> Dear Jason, >>> >>> This isn't a regression. This is simply the first time this has been >>> observed. (hw) flow offload is a new feature, and hence this >>> interaction with wireguard is also new. >>> >>> Yours sincerely, >>> >>> Jaap >>> >>> On Tue, May 29, 2018 at 1:54 PM, Jason A. Donenfeld wrote: Hi Jaap, Thanks for the report. Is this a _new_ bug in _new_ version of WireGuard that wasn't there before. Or is this the first time you've observed this? Thanks, Jason >> >> Original Mail == >> >>> Dear all, >>> >>> When running a wireguard interface on the latest Lede master branch, >>> the router will crash as soon as traffic hits the wireguard interface >>> while (hw) flow offloading is enabled. I am not sure whether this is a >>> bug with wireguard, hw flow offload, both or neither, so I am >>> reporting the bug to both mailinglists. A more detailed description >>> plus a properly formatted stack trace can be found on Lede's bug >>> tracker: https://bugs.openwrt.org/index.php?do=details_id=1539 >>> >>> If you require any additional information, please do not hesitate to >>> contact me. Thank you very much in advance. >>> >>> Yours sincerely, >>> >>> Jaap Buurman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On 29 May 2018, at 08:57, David Woodhouse wrote: > > On Mon, 2018-05-28 at 14:08 +, Kevin Darbyshire-Bryant via openwrt- > devel wrote: >> >> I have a local-ish ‘tame’ ISP (AAISP) who might let me visit the >> office and try a test line there… but I’d have to book & arrange it. >> >> Or I could get a second line installed at home for £130+ for a >> month. H. Would be good to have a UK based tester of >> ADSL/BT/Openwrt compatibility. > > I used to, but I've also upgraded to VDSL. > > I note that the bug at > https://bugs.openwrt.org/index.php?do=details_id=1567 even > *mentions* that it looks similar in some ways to FS#1247... but doesn't > include the PPP debug information requested in the latter. Mauro? > > And is it just PPPoA, or also PPPoEoA (i.e. BR2684)? In 24 hours I’ll hit the go button on £130 to get a 2nd line installed here at home with ADSL on BT’s network using AAISP. That way I can be sat in front of a HH5a (with serial access if it really comes to that) and hopefully answer any questions that are flung my way. Anyone who has a better alternative has until 14:00 GMT Wednesday 30th May to stop me. Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A signature.asc Description: Message signed with OpenPGP --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wireguard & hw flow offload incompatibility
Hey Felix, Per the below thread, I've been digging around trying to see what's going on. Apparently packets are hitting a virtual network interface's ndo_start_xmit with no dst when hardware offloading enabled. I assume that the path is something along the lines of a packet coming in on one of these hardware accelerated NICs and then being forwarded to the wireguard interface, which expects the dst. I found your ndo_flow_offload patchset, and I suspect that might have something to do with this. Any insights on dsts disappearing in skbs? Thanks, Jason On Tue, May 29, 2018 at 2:14 PM, Jason A. Donenfeld wrote: > Hi Jaap, > > Thanks for the clarification. I downloaded the binary for that > hardware and triaged where the bug occurs [1]. This patch [2] should > probably fix it, but I'm rather surprised to see situations in which a > skb is missing a dst entry in ndo_start_xmit; this might point to > deeper kernel bugs in this hardware offloading feature, or some > alternative mechanism for routing being used when hardware offloading > is on. So I'm hesitant to merge this just yet, because perhaps this is > better handled in the compat layer, if it is in fact vendor silliness. > Do you have a link to the kernel source of these boxes? I'd like to > see what exactly the vendor is doing. And if you could try [2] and see > if that still crashes, this would be most appreciated. > > Thanks, > Jason > > [1] https://data.zx2c4.com/openwrt-mips-offloading-bug.png > [2] https://א.cc/Am4tZ0n8 > > On Tue, May 29, 2018 at 1:59 PM, Jaap Buurman wrote: >> Dear Jason, >> >> This isn't a regression. This is simply the first time this has been >> observed. (hw) flow offload is a new feature, and hence this >> interaction with wireguard is also new. >> >> Yours sincerely, >> >> Jaap >> >> On Tue, May 29, 2018 at 1:54 PM, Jason A. Donenfeld wrote: >>> Hi Jaap, >>> >>> Thanks for the report. Is this a _new_ bug in _new_ version of >>> WireGuard that wasn't there before. Or is this the first time you've >>> observed this? >>> >>> Thanks, >>> Jason > > Original Mail == > >> Dear all, >> >> When running a wireguard interface on the latest Lede master branch, >> the router will crash as soon as traffic hits the wireguard interface >> while (hw) flow offloading is enabled. I am not sure whether this is a >> bug with wireguard, hw flow offload, both or neither, so I am >> reporting the bug to both mailinglists. A more detailed description >> plus a properly formatted stack trace can be found on Lede's bug >> tracker: https://bugs.openwrt.org/index.php?do=details_id=1539 >> >> If you require any additional information, please do not hesitate to >> contact me. Thank you very much in advance. >> >> Yours sincerely, >> >> Jaap Buurman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wireguard & hw flow offload incompatibility
Hi Jaap, Thanks for the clarification. I downloaded the binary for that hardware and triaged where the bug occurs [1]. This patch [2] should probably fix it, but I'm rather surprised to see situations in which a skb is missing a dst entry in ndo_start_xmit; this might point to deeper kernel bugs in this hardware offloading feature, or some alternative mechanism for routing being used when hardware offloading is on. So I'm hesitant to merge this just yet, because perhaps this is better handled in the compat layer, if it is in fact vendor silliness. Do you have a link to the kernel source of these boxes? I'd like to see what exactly the vendor is doing. And if you could try [2] and see if that still crashes, this would be most appreciated. Thanks, Jason [1] https://data.zx2c4.com/openwrt-mips-offloading-bug.png [2] https://א.cc/Am4tZ0n8 On Tue, May 29, 2018 at 1:59 PM, Jaap Buurman wrote: > Dear Jason, > > This isn't a regression. This is simply the first time this has been > observed. (hw) flow offload is a new feature, and hence this > interaction with wireguard is also new. > > Yours sincerely, > > Jaap > > On Tue, May 29, 2018 at 1:54 PM, Jason A. Donenfeld wrote: >> Hi Jaap, >> >> Thanks for the report. Is this a _new_ bug in _new_ version of >> WireGuard that wasn't there before. Or is this the first time you've >> observed this? >> >> Thanks, >> Jason Original Mail == > Dear all, > > When running a wireguard interface on the latest Lede master branch, > the router will crash as soon as traffic hits the wireguard interface > while (hw) flow offloading is enabled. I am not sure whether this is a > bug with wireguard, hw flow offload, both or neither, so I am > reporting the bug to both mailinglists. A more detailed description > plus a properly formatted stack trace can be found on Lede's bug > tracker: https://bugs.openwrt.org/index.php?do=details_id=1539 > > If you require any additional information, please do not hesitate to > contact me. Thank you very much in advance. > > Yours sincerely, > > Jaap Buurman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
On Tue, May 29, 2018 at 10:49:46AM +0200, Linus Walleij wrote: > On Mon, May 28, 2018 at 8:20 PM, Andrew Lunn wrote: > > On Mon, May 28, 2018 at 07:47:48PM +0200, Linus Walleij wrote: > >> This is a second RFC version of the DSA driver for Realtek > >> RTL8366x especially RTL8366RB. > >> > >> I've been beating my head against this one and I'm not really > >> clear on why my ethernet frames are not coming through to the > >> CPU port on the chip. > >> > >> It appears when using ethtool -S on the ports that packets > >> are passing fine into the router fabric and through to the > >> CPU port but the ethernet driver where the fixed link is > >> connected refuse to accept the packages. > > > > Hi Linus > > > > Have you played with RGMII delays? > > No not like I changed them or anything... the SoC has some > set-up for skew and delay on the nanosecond level, but I used the > vendor defaults, verified to be the same in their custom > kernel tree. Hi Linus Did you look at the switch end? I found a datasheet for the 8366/8369. Register at 0x0050, P8GCR. It has two bits for RGMII delays. With RGMII delays, you have 3 'choices'. 1) The hardware design includes the delay, by zig-zagging the clock line to make it longer. 2) The 'MAC' side does the delay. 3) The 'PHY' side does the delay. I normally recommend the PHY side doing it, because that's what most board do. Gives us some consistency. But it does not really matter. Just make sure one side, and only once side is inserting the delays. Andrew ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] mvebu: fix broken console on WRT32X (venom)
From: Michael Gray
The console bootarg is being corrupted on boot, causing various issues
including broken sysupgrade.
Utilising the bootargs mangle patch from other targets, hardcode the console
arguments and fetch the rootfs from the bootloader.
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock8
Bootloader command line (ignored): console= root=/dev/mtdblock8
Please cherry pick to 18.06 too
Signed-off-by: Michael Gray
---
changes since v1:
- Modified patch 006 to be mvebu specific. Now passes the bootloader cmdline
on if no append-rootblock stanza is found
---
target/linux/mvebu/config-4.14| 1 +
.../arm/boot/dts/armada-385-linksys-venom.dts | 6 +
...Mangle-bootloader-s-kernel-arguments.patch | 201 ++
3 files changed, 208 insertions(+)
create mode 100644
target/linux/mvebu/patches-4.14/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
diff --git a/target/linux/mvebu/config-4.14 b/target/linux/mvebu/config-4.14
index a48a3c8c5e..694ecdfb82 100644
--- a/target/linux/mvebu/config-4.14
+++ b/target/linux/mvebu/config-4.14
@@ -42,6 +42,7 @@ CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_ARM_CRYPTO=y
CONFIG_ARM_ERRATA_720789=y
diff --git
a/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
b/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
index ea44c8f0d2..00a4ee9f39 100644
---
a/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
+++
b/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
@@ -46,7 +46,13 @@
model = "Linksys WRT32X";
compatible = "linksys,venom", "linksys,armada385", "marvell,armada385",
"marvell,armada380";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ stdout-path = "serial0:115200n8";
+ append-rootblock = "root=/dev/mtdblock";
};
+};
{
wan_amber@0 {
diff --git
a/target/linux/mvebu/patches-4.14/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
b/target/linux/mvebu/patches-4.14/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
new file mode 100644
index 00..53275607e0
--- /dev/null
+++
b/target/linux/mvebu/patches-4.14/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
@@ -0,0 +1,201 @@
+From 71270226b14733a4b1f2cde58ea9265caa50b38d Mon Sep 17 00:00:00 2001
+From: Adrian Panella
+Date: Thu, 9 Mar 2017 09:37:17 +0100
+Subject: [PATCH 67/69] generic: Mangle bootloader's kernel arguments
+
+The command-line arguments provided by the boot loader will be
+appended to a new device tree property: bootloader-args.
+If there is a property "append-rootblock" in DT under /chosen
+and a root= option in bootloaders command line it will be parsed
+and added to DT bootargs with the form: XX.
+Only command line ATAG will be processed, the rest of the ATAGs
+sent by bootloader will be ignored.
+This is usefull in dual boot systems, to get the current root partition
+without afecting the rest of the system.
+
+Signed-off-by: Adrian Panella
+
+This patch has been modified to be mvebu specific. The original patch
+did not pass the bootloader cmdline on if no append-rootblock stanza
+was found, resulting in blank cmdline and failure to boot.
+
+Signed-off-by: Michael Gray
+---
+ arch/arm/Kconfig| 11 +
+ arch/arm/boot/compressed/atags_to_fdt.c | 72 -
+ init/main.c | 16
+ 3 files changed, 98 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/Kconfig
b/arch/arm/Kconfig
+@@ -1948,6 +1948,17 @@ config ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEN
+ The command-line arguments provided by the boot loader will be
+ appended to the the device tree bootargs property.
+
++config ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE
++ bool "Append rootblock parsing bootloader's kernel arguments"
++ help
++The command-line arguments provided by the boot loader will be
++appended to a new device tree property: bootloader-args.
++If there is a property "append-rootblock" in DT under /chosen
++and a root= option in bootloaders command line it will be parsed
++and added to DT bootargs with the form: XX.
++Only command line ATAG will be processed, the rest of the ATAGs
++sent by bootloader will be ignored.
++
+ endchoice
+
+ config CMDLINE
+--- a/arch/arm/boot/compressed/atags_to_fdt.c
b/arch/arm/boot/compressed/atags_to_fdt.c
+@@ -3,6 +3,8 @@
+
+ #if defined(CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND)
+ #define do_extend_cmdline 1
++#elif defined(CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE)
++#define do_extend_cmdline 1
+ #else
+ #define do_extend_cmdline 0
Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
On Mon, May 28, 2018 at 8:20 PM, Andrew Lunn wrote:
> On Mon, May 28, 2018 at 07:47:48PM +0200, Linus Walleij wrote:
>> This is a second RFC version of the DSA driver for Realtek
>> RTL8366x especially RTL8366RB.
>>
>> I've been beating my head against this one and I'm not really
>> clear on why my ethernet frames are not coming through to the
>> CPU port on the chip.
>>
>> It appears when using ethtool -S on the ports that packets
>> are passing fine into the router fabric and through to the
>> CPU port but the ethernet driver where the fixed link is
>> connected refuse to accept the packages.
>
> Hi Linus
>
> Have you played with RGMII delays?
No not like I changed them or anything... the SoC has some
set-up for skew and delay on the nanosecond level, but I used the
vendor defaults, verified to be the same in their custom
kernel tree.
It's this stuff from the DTS:
+ conf0 {
+ pins = "V8 GMAC0
RXDV", "T10 GMAC1 RXDV";
+ skew-delay = <0>;
+ };
+ conf1 {
+ pins = "Y7 GMAC0 RXC",
"Y11 GMAC1 RXC";
+ skew-delay = <15>;
+ };
+ conf2 {
+ pins = "T8 GMAC0
TXEN", "W11 GMAC1 TXEN";
+ skew-delay = <7>;
+ };
+ conf3 {
+ pins = "U8 GMAC0 TXC";
+ skew-delay = <11>;
+ };
+ conf4 {
+ pins = "V11 GMAC1 TXC";
+ skew-delay = <10>;
+ };
Yours,
Linus Walleij
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] MMAP memory out of sync on AR71xx Rambutan (8devices) board.
I posted the issue on the alsa-devel mailing list and they are pushing a patch that allows the snd_usb_audio module to pass the parameter use_vmalloc=0. That causes the snd_usb_audio driver to use DMA coherent memory for the pcm buffer, which always mmaps() correctly to userspace in all my tests. The patch is queued for 4.18. Here is the patch + conversation from alsa-devel: http://mailman.alsa-project.org/pipermail/alsa-devel/2018-May/136408.html The problem seems to be memory coherence on MIPS. I haven't figured out yet, how mmap() can work without issues when the ELF loader mmaps() libraries for example, but mmap() fails in my mmaptest kernel module when simply mapping a single page. As far as I tested, mmap() always works when memory is mapped by the filesystem code. However, I am going to expand my mmaptest utils to debug this. There should be a better fix than using DMA coherent memory... BTW: Is someone using X on the affected MIPS devices ? The problem should exist there as well, because X heavily relies on mmap() for rendering. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050
On Mon, 2018-05-28 at 14:08 +, Kevin Darbyshire-Bryant via openwrt- devel wrote: > > I have a local-ish ‘tame’ ISP (AAISP) who might let me visit the > office and try a test line there… but I’d have to book & arrange it. > > Or I could get a second line installed at home for £130+ for a > month. H. Would be good to have a UK based tester of > ADSL/BT/Openwrt compatibility. I used to, but I've also upgraded to VDSL. I note that the bug at https://bugs.openwrt.org/index.php?do=details_id=1567 even *mentions* that it looks similar in some ways to FS#1247... but doesn't include the PPP debug information requested in the latter. Mauro? And is it just PPPoA, or also PPPoEoA (i.e. BR2684)? smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050
2018-05-28 15:49 GMT+03:00 Mauro Mozzarelli : > Hello, > > > I reported https://bugs.openwrt.org/index.php?do=details_id=1567 Another user reported on IRC it is related to the kernel bump to 4.14. He is aware of the issue since a few weeks (at the time k4.14 was optional), but didn't created a bugreport since he had to create an account for the bugtracker... On a first glance it kind of looks like a regression in the linux kernel. > > Which is a blocking issue for BT Home Hub 5 as pppoa no longer connects. Is > anyone looking into it? Most likely not, as it requires a line with PPPoA which isn't that common. PPPoE works still fine. Your best bet is to bisect kernel 4.9 to 4.14 to find the commit which breaks PPPoA. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
