Re: Question to recent Qualcomm CVEs

2024-05-03 Thread Sven Eckelmann 
On Thursday, 2 May 2024 09:25:03 CEST Sven Eckelmann wrote:
> On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote:
> > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote:
> > > It's quite strange that they updated 2.5.0.1 branch first but my
> > > understanding that there should be updates for the newer 2.7.0.1 branch
> > > as well (2.7.0.1 branch is also in linux-firmware).
> > 
> > Yes, I also told them in the support ticket that this is from an older 
> > branch 
> > than what is currently shipped in linux-firmware.git. But they told me 
> > that they are working on newer versions (whatever that means) - but they 
> > wanted to  handle first the update to ATH.11.4 (2.5.0.x) and then 
> > step-by-step release it for newer firmware branches. It seem like that 
> > would be 
> > up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP 
> > SoCs.
> 
> Just as info: The non-public QCA ticket was simply closed on Tuesday (without 
> having any upload which works for Robert and is from the same/newer branch 
> than what is currently in linux-firmware.git). So maybe we are actually out 
> of 
> luck.

Now they are (indirectly) claiming that WLAN.HK.2.9.0.1-* is for ath12k. You 
can actually read the response like everything newer than WLAN.HK.2.5.0.1-* is 
for ath12k. Maybe I missed something and somebody can point out my error. Btw. 
their ATH.11.5 release already a newer version than WLAN.HK.2.5.0.1-*.

And maybe someone else known why there is a WLAN.HK.2.11.0.1-* and 
WLAN.HK.2.10.0.1-* [1] for IPQ9574 but not for any other 802.11ax HW. Maybe it 
has to do with the fact that it is used together with 802.11be HW (PCIe, 
QCN9274?) and is therefore still actively maintained?

Kind regards,
Sven

[1]  
https://github.com/quic/upstream-wifi-fw/tree/main/ath11k-firmware/IPQ9574/hw1.0

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Question to recent Qualcomm CVEs

2024-05-02 Thread Sven Eckelmann 
On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote:
> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote:
> > It's quite strange that they updated 2.5.0.1 branch first but my
> > understanding that there should be updates for the newer 2.7.0.1 branch
> > as well (2.7.0.1 branch is also in linux-firmware).
> 
> Yes, I also told them in the support ticket that this is from an older branch 
> than what is currently shipped in linux-firmware.git. But they told me 
> that they are working on newer versions (whatever that means) - but they 
> wanted to  handle first the update to ATH.11.4 (2.5.0.x) and then 
> step-by-step release it for newer firmware branches. It seem like that would 
> be 
> up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP 
> SoCs.

Just as info: The non-public QCA ticket was simply closed on Tuesday (without 
having any upload which works for Robert and is from the same/newer branch 
than what is currently in linux-firmware.git). So maybe we are actually out of 
luck.

Kind regards,
Sven



signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Question to recent Qualcomm CVEs

2024-04-29 Thread Sven Eckelmann 
On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote:
> It's quite strange that they updated 2.5.0.1 branch first but my
> understanding that there should be updates for the newer 2.7.0.1 branch
> as well (2.7.0.1 branch is also in linux-firmware).

Yes, I also told them in the support ticket that this is from an older branch 
than what is currently shipped in linux-firmware.git. But they told me 
that they are working on newer versions (whatever that means) - but they 
wanted to  handle first the update to ATH.11.4 (2.5.0.x) and then 
step-by-step release it for newer firmware branches. It seem like that would be 
up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP 
SoCs.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Question to recent Qualcomm CVEs

2024-02-26 Thread Sven Eckelmann 
On Monday, 26 February 2024 15:50:44 CET Felix Fietkau wrote:
[...]
>> The Qualcomm bulletin[1] says "Patches are being actively
> > shared with OEMs".
> > 
> > Were these bugfixes made available for OpenWRT? Is there an established
> > procedure for such cases, where closed-source firmware gets bugfixes?
[...]
> > [1]
> > https://docs.qualcomm.com/product/publicresources/securitybulletin/
december-2023-bulletin.html
> 
> The fixes were not shared with OpenWrt. Qualcomm does not care about 
> OpenWrt support for their platforms.

I've asked (using their qualcomm-cdmatech-support portal) for an official 
release of their WiFi firmware with all gathered bugfixes via 
linux-firmware.git. I got statements that the ath10k firmware is no longer 
supported + ath11k firmware is not developed further. But for some of them it 
is possible to request a release of the firmwares via Kalle's repositories. 
But also that Kalle's repositories are now replaced. Which seems to be 
confirmed by Kalle's statement [1] regarding the firmware-N.bin files on 
ath...@lists.infradead.org .

The new positions for firmware files were not revealed but I found a couple of 
places [2,3,4,5] in my search.

And to the request to get the latest versions released via linux-firmware.git 
(or maybe even only in Kalle's repositories), I got (some weeks ago) the 
answer "Let me check with our team.".

It is rather hard to make statements about Qualcomm  - simply because it is 
not just a single person and I have no idea about the internal structures. But 
it doesn't seem to be the highest priority (for the "internal team"?) to make 
fixes available for everyone. I still hope that it is just delayed due to some 
unfortunate circumstances. But this is just the current state.

Kind regards,
Sven

[1] https://lore.kernel.org/r/87bk8inesm@kernel.org
[2] https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware
[3] https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware
[4] https://git.codelinaro.org/clo/ath-firmware/ath12k-firmware
[5] https://github.com/quic/upstream-wifi-fw

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] dnsmasq: mark global ubus context as closed after fork

2023-11-18 Thread Sven Eckelmann 
If the dnsmasq process forks to handle TCP connections, it closes the ubus
context. But instead of changing the daemon wide pointer to NULL, only the
local variable was adjusted - and this portion of the code was even dropped
(dead store) by some optimizing compilers.

It makes more sense to change the daemon->ubus pointer because various
functions are already checking it for NULL. It is also the behavior which
ubus_destroy() implements.

Fixes: d8b33dad0bb7 ("dnsmasq: add support for monitoring and modifying dns 
lookup results via ubus")
Signed-off-by: Sven Eckelmann 
---
Changes in v2:
- added missing word "checking" in commit message. Thanks
  Eric 
---
 package/network/services/dnsmasq/patches/200-ubus_dns.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/dnsmasq/patches/200-ubus_dns.patch 
b/package/network/services/dnsmasq/patches/200-ubus_dns.patch
index 8a70bb8bdf..ccbe70ab9c 100644
--- a/package/network/services/dnsmasq/patches/200-ubus_dns.patch
+++ b/package/network/services/dnsmasq/patches/200-ubus_dns.patch
@@ -210,7 +210,7 @@
 +return;
 +
 +  ubus_free(ubus);
-+  ubus = NULL;
++  daemon->ubus = NULL;
 +}
 +
  static int ubus_handle_metrics(struct ubus_context *ctx, struct ubus_object 
*obj,

---
base-commit: 9062e5faaedc03823ee419fe34de1de73f48babc
change-id: 20231118-dnsmasq_drop_ubus_null-69661a68d342

Best regards,
-- 
Sven Eckelmann 


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

[PATCH] dnsmasq: mark global ubus context as closed after fork

2023-11-18 Thread Sven Eckelmann 
If the dnsmasq process forks to handle TCP connections, it closes the ubus
context. But instead of changing the daemon wide pointer to NULL, only the
local variable was changed - and this code portion was even dropped as
dead-store by some optimizing compilers.

It makes more sense to change the daemon->ubus pointer to NULL because
various functions are already it for NULL. It is also the behavior which
ubus_destroy() implements.

Fixes: d8b33dad0bb7 ("dnsmasq: add support for monitoring and modifying dns 
lookup results via ubus")
Signed-off-by: Sven Eckelmann 
---
 package/network/services/dnsmasq/patches/200-ubus_dns.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/dnsmasq/patches/200-ubus_dns.patch 
b/package/network/services/dnsmasq/patches/200-ubus_dns.patch
index 8a70bb8bdf..ccbe70ab9c 100644
--- a/package/network/services/dnsmasq/patches/200-ubus_dns.patch
+++ b/package/network/services/dnsmasq/patches/200-ubus_dns.patch
@@ -210,7 +210,7 @@
 +return;
 +
 +  ubus_free(ubus);
-+  ubus = NULL;
++  daemon->ubus = NULL;
 +}
 +
  static int ubus_handle_metrics(struct ubus_context *ctx, struct ubus_object 
*obj,

---
base-commit: 9062e5faaedc03823ee419fe34de1de73f48babc
change-id: 20231118-dnsmasq_drop_ubus_null-ae5b5f062cb7

Best regards,
-- 
Sven Eckelmann 


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

uboot-envtools: Don't preserve configs after sysupgrade

2022-10-18 Thread Sven Eckelmann 
For devices with a NAND and a NOR chip, it was noticed that the order of
initialization can be different between various kernel versions (4.4 vs.
5.4). As result, the mtd index changes for the u-boot-env partition - but
the uboot-envtool still kept the old partition index.

And since some devices write (for example during sysupgrade) to the
u-boot-env, a unrelated partition would be overwritten. This would often
brick the device.

For example, a device with dualboot_datachk upgrade procedure with kernel A
(first intializes NOR and then NAND) which is upgrade to kernel B (first
initializes NAND and then NOR) would end up in a bricket state because the
device:

1. kernel A is (factory) installed on device
2. firstboot scripts initialize /etc/fw_env.config to point to mtd6
3. kernel B is installed on device via sysupgrade (no extra options)
   * during upgrade some information is written to mtd6 (u-boot-env)
4. firstboot script will not do anything when kernel B booted
   -> /etc/fw_env.config still points to mtd6 (now the "0:RPM" partition)
5. sysupgrade is started again
   * some information should be written to u-boot-env but the upgrade
 script will now overwrite some important information of "0:RPM" (mtd6)
6. boot fails because the secondary bootload is unable to load the iamge
   from 0:RPM. u-boot will then never be started because the SBL caused
   a panic before it was event tried to load it.

This scenario cannot happen when the /etc/fw_env.config is not preserved
and instead autogenerated after each firmware installation.

There might still be a good reason to restore the values from uci in case
there is no code to auto-generate the settings.

Fixes: 7f00e5ffc671 ("uboot-envtools: update to 2012.04.01")
Signed-off-by: Sven Eckelmann 

---

The safest method to reproduce the problem without killing your system is
to use a board which usually doesn't use fw_setenv but has an accessible
u-boot-env.

1. flash the device with your test firmware
2. check that fw_printenv works
3. write bogus values in your u-boot-env configuration:

 echo '/dev/mtd99 0x0 0x0001 0x0001 1' > /etc/fw_env.config
 uci set ubootenv.@ubootenv[0].dev='/dev/mtd6'
 uci commit ubootenv

4. sysupgrade the device
5. check if fw_printenv works again

diff --git a/package/boot/uboot-envtools/Makefile 
b/package/boot/uboot-envtools/Makefile
index 
6840b9c586be1b6f41b72b18138143bd695dbfe6..ca76f528f8f93be46268f8132f50f93bc33025ea
 100644
--- a/package/boot/uboot-envtools/Makefile
+++ b/package/boot/uboot-envtools/Makefile
@@ -58,12 +58,6 @@ MAKE_FLAGS += \
no-dot-config-targets=envtools \
envtools
 
-define Package/uboot-envtools/conffiles
-/etc/config/ubootenv
-/etc/fw_env.config
-/etc/fw_sys.config
-endef
-
 define Package/uboot-envtools/install
$(INSTALL_DIR) $(1)/usr/sbin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/tools/env/fw_printenv $(1)/usr/sbin
diff --git a/package/boot/uboot-envtools/files/apm821xx 
b/package/boot/uboot-envtools/files/apm821xx
index 
e73aaab7a0d73a4856d24ae20a39458797c8beb1..06241449717769b1e531763b597b9b980d14150d
 100644
--- a/package/boot/uboot-envtools/files/apm821xx
+++ b/package/boot/uboot-envtools/files/apm821xx
@@ -1,4 +1,4 @@
-[ -e /etc/config/ubootenv ] && exit 0
+rm -f /etc/fw_env.config
 
 touch /etc/config/ubootenv
 
@@ -9,17 +9,19 @@ board=$(board_name)
 
 case "$board" in
 meraki,mr24)
+   ubootenv_clear_uci_config
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4000" "0x4000" "4"
ubootenv_add_uci_config "/dev/mtd2" "0x0" "0x4000" "0x4000" "4"
;;
 meraki,mx60)
-   ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x2" "4"
+   ubootenv_set_uci_config "/dev/mtd1" "0x0" "0x2" "0x2" "4"
;;
 netgear,wndap620|\
 netgear,wndap660)
-   ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4000" "0x4000" "4"
+   ubootenv_set_uci_config "/dev/mtd1" "0x0" "0x4000" "0x4000" "4"
;;
 wd,mybooklive)
+   ubootenv_clear_uci_config
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000" "1"
ubootenv_add_uci_config "/dev/mtd1" "0x1000" "0x1000" "0x1000" "1"
;;
diff --git a/package/boot/uboot-envtools/files/ath79 
b/package/boot/uboot-envtools/files/ath79
index 
d9e504bf8949a5ef93e1641d01334fc61523bd68..194176527c84ed5c0418f3dc5940645a75f03c55
 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -2,7 +2,7 @@
 # Copyright (C) 2011-2014 OpenWrt.org
 #
 
-[ -e /etc/config/uboote

[PATCH] uboot-envtools: Fix format of autogenerated sectors

2022-09-29 Thread Sven Eckelmann 
The sector number must be stored in hex. Otherwise, the number (like 16)
will be parsed as hex and any write to the partition will end up with an
error like:

  MTD erase error on /dev/mtd5: Invalid argument

Fixes: 9adfeccd8415 ("uboot-envtools: Add support for IPQ806x AP148 and DB149")
Fixes: 54b275c8ed3a ("ipq40xx: add target")
Signed-off-by: Sven Eckelmann 
---
 package/boot/uboot-envtools/files/ipq40xx | 1 +
 package/boot/uboot-envtools/files/ipq806x | 1 +
 2 files changed, 2 insertions(+)

diff --git a/package/boot/uboot-envtools/files/ipq40xx 
b/package/boot/uboot-envtools/files/ipq40xx
index e45e26dcc7..823a33ca1b 100644
--- a/package/boot/uboot-envtools/files/ipq40xx
+++ b/package/boot/uboot-envtools/files/ipq40xx
@@ -26,6 +26,7 @@ ubootenv_mtdinfo () {
fi
 
sectors=$(( $ubootenv_size / $mtd_erase ))
+   sectors=$(printf "0x%x" $sectors )
echo /dev/$mtd_dev 0x0 $ubootenv_size $mtd_erase $sectors
 }
 
diff --git a/package/boot/uboot-envtools/files/ipq806x 
b/package/boot/uboot-envtools/files/ipq806x
index a8285d1452..77dfefbcd8 100644
--- a/package/boot/uboot-envtools/files/ipq806x
+++ b/package/boot/uboot-envtools/files/ipq806x
@@ -26,6 +26,7 @@ ubootenv_mtdinfo () {
fi
 
sectors=$(( $ubootenv_size / $mtd_erase ))
+   sectors=$(printf "0x%x" $sectors )
echo /dev/$mtd_dev 0x0 $ubootenv_size $mtd_erase $sectors
 }
 
-- 
2.34.1


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

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

2022-06-29 Thread Sven Eckelmann 
On Wednesday, 29 June 2022 21:37:43 CEST Christian Marangi wrote:
> On Wed, Jun 29, 2022 at 09:32:14PM +0200, Sven Eckelmann wrote:
> > On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
> > [...]
> > > A node name change is required for the new patch to work. Since we are
> > > not aware of device that use cmdline as partition parser, I converted
> > > each device that use nvmem-cells to the new format.
> > 
> > I am not 100% if you reference here the mtdparts from cmdline or something 
> > else. If the former is the case then please perform a
> > "git grep 'partitions are passed via bootloader'".
> >
> 
> Problem is that it's not that easy... I notice that comment on some
> ipq40xx dts but many ath79 device have fixed-partition defined and still
> use cmdlinepart with no comments about it... guess how we discovered that
> when the nvmem migration was done.

Ah, I think you meant "we are not always aware whether a device uses cmdline
as partition parser" and not "we are not aware of device that use cmdline as 
partition parser". At least this would make more sense here.

Other question regarding the changes in 11-ath10k-caldata: You've dropped the 
caldata_extract in various places which would usually copy the pre-cal (or 
cal) data from the ART partition to /lib/firmware/$FIRMWARE. But I see in 
various places that there are things like ath10k_patch_mac still in there. 
Take for example linksys,ea8500:


linksys,ea8500)
-   caldata_extract "art" 0x5000 0x2f20
ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii devinfo 
hw_mac_addr) 2) 
;;

I thought that a "pre-calibration" nvmem-cell would then be used by ath10k to 
get the (pre-)cal data [1]. So it doesn't make a lot of sense to me that there 
is now still a ath10k_patch_mac which tries to operate on 
/lib/firmware/$FIRMWARE (which should not exist). The script section shouldn't 
be called in the first place because the "pre-calibration" nvmem-cell has a 
higher priority in ath10k, right? I can also see the changes
to qcom-ipq8064-eax500.dtsi but no mac address fix.

Kind regards,
Sven

[1] 
https://patchwork.kernel.org/project/linux-wireless/patch/20211016234609.1568317-1-chunk...@gmail.com/#24559755

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [REQUEST] Review changes for new nvmem patch for dynamic partition

2022-06-29 Thread Sven Eckelmann 
On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
[...]
> A node name change is required for the new patch to work. Since we are
> not aware of device that use cmdline as partition parser, I converted
> each device that use nvmem-cells to the new format.

I am not 100% if you reference here the mtdparts from cmdline or something 
else. If the former is the case then please perform a
"git grep 'partitions are passed via bootloader'".

But I am currently not 100% sure why cmdline is so special here.

Kind regards,
Sven 

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: nvmem: Defining cells on mtd created by mtdparts

2021-10-12 Thread Sven Eckelmann 
On Tuesday, 12 October 2021 20:24:46 CEST Pratyush Yadav wrote:
[...]
> I have been wanting to fix this problem for a while but just never got 
> around to it. I was thinking about either extending the mtdparts syntax 
> to maybe add nvmem cell information in there or adding a separate 
> cmdline argument that complements mtdparts with nvmem cell info. Dunno 
> if either of these would work well though...

At least for the devices I have in mind, this doesn't seem to be a good 
solution. The devices are shipped since years and the bootloader isn't updated 
with firmware updates. So changing to a different mtdparts might sometimes not 
be easily possible.

But this might help in situations which don't have this limitation.

> > Ansuel Smith just proposed in OpenWrt [1] a workaround. It basically adds a 
> > minimal fixed-partitions parser to the mtd cmdlinepart parser (responsible 
> > for 
> > the mtdparts=) that tries to find the matching (size + offset) 
> > fixed-partition 
> > from the devicetree. The code in mtd_device_parse_register
> > (add_mtd_partitions -> add_mtd_device -> mtd_nvmem_add) will then 
> > automatically take care of the rest.
> 
> I don't quite see how this helps. You say that some devices don't have a 
> device tree at all so how would you even match the fixed partition? And 
> this of course doesn't solve the problem where you might want nvmem 
> cells with a partition layout that is different from the one in device 
> tree.

I personally had a different thing in mind. The situation for OpenWrt's ath79 
target (and Linux's ath79) is that they use DTs and some of these devices are 
still using some information which are not part of the device tree. But the
DT partitions for the nvmem-cells MUST match the ones in mtdparts

But you are right, this will definitely not solve situations when there is no 
DT used. And didn't say that I needed a solution for this - I was (hopefully) 
always referring to devices which use mtdparts (which can also be used with 
devices which are using DTs)

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: nvmem: Defining cells on mtd created by mtdparts

2021-10-11 Thread Sven Eckelmann 
On Sunday, 10 October 2021 14:53:13 CEST Sven Eckelmann wrote:
[...]
> Since there are most likely more devices out there which use mtdparts, I 
> would 
> guess that there might already be a strategy out there which can be used to 
> define the nvmem-provider for mtdparts defined partitions. At least I saw 
> that 
> Bartosz Golaszewski added all the mtd devices automatically as nvmem provider 
> in c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem 
> API"). So there might also be something for nvmem-cells to find the correct 
> mtd instead of relying on the fixed-partitions registration + of_node (which 
> doesn't exist because it comes from mtdparts and not devicetree).

Ansuel Smith just proposed in OpenWrt [1] a workaround. It basically adds a 
minimal fixed-partitions parser to the mtd cmdlinepart parser (responsible for 
the mtdparts=) that tries to find the matching (size + offset) fixed-partition 
from the devicetree. The code in mtd_device_parse_register
(add_mtd_partitions -> add_mtd_device -> mtd_nvmem_add) will then 
automatically take care of the rest.

Kind regards,
Sven

[1] https://github.com/openwrt/openwrt/pull/4664#issuecomment-939567963

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

nvmem: Defining cells on mtd created by mtdparts

2021-10-10 Thread Sven Eckelmann 
Hi,

OpenWrt switched [1] their MAC address (from flash) retrieval code from their 
mtd-mac-address based solution [2] to nvmem-cells. The mtd-mac-address based 
solution had the benefit that it could find the correct partition by using 
get_mtd_device_nm - which was label based. So a lookup for a partition which 
was defined via mtdparts was absolutely no problem. This doesn't seem to be
the case for nvmem - at least not how it is integrated at the moment in
OpenWrt.

This means that the performed switch broke the vendor defined MAC addresses 
when the u-boot must dynamically define the partitions via mtdpart - and where 
fixed-partitions are not possible in the DT. The bootloaders used by the ath79 
usually have no devicetree support and cannot modify the device tree (beside 
the problem to get the sources for these bootloaders). These devices will now 
only have random mac addresses.

Since there are most likely more devices out there which use mtdparts, I would 
guess that there might already be a strategy out there which can be used to 
define the nvmem-provider for mtdparts defined partitions. At least I saw that 
Bartosz Golaszewski added all the mtd devices automatically as nvmem provider 
in c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem 
API"). So there might also be something for nvmem-cells to find the correct 
mtd instead of relying on the fixed-partitions registration + of_node (which 
doesn't exist because it comes from mtdparts and not devicetree).

Right now nvmem_cell_get (actually __nvmem_device_get) in 
nvmem_get_mac_address just return -517 (EPROBE_DEFER). So the nvmem_device is 
not yet registered - which absolutely makes sense when mtdparts is used. 
of_nvmem_find will just not be able to find the of_node for this partition
via bus_find_device_by_of_node because there is no such of_node for mtdparts 
partitions.

Kind regards,
Sven

[1] https://github.com/openwrt/openwrt/pull/4041
[2] 
https://github.com/openwrt/openwrt/commit/5ae2e786395c7f9db0167ebe875be5df9502d8d8

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ath10k: qca4019: FW crash on 5GHz when baseEepHeader.nonLinearTxFir == 1

2021-09-22 Thread Sven Eckelmann 
On Friday, 17 September 2021 18:25:35 CEST Sven Eckelmann wrote:
[...]
> Interestingly, the crash disappeared when I've changed 
> baseEepHeader.nonLinearTxFir (offset 0xc2 in the BDF) from 1 to 0.
> 
> The device itself was using firmware 10.4-3.6-00140 (the version currently in 
> linux-firmware) - a working firmware is 10.4-3.5.3-00078. I also wanted to 
> "bisected" when this problem was introduced but there are only these two 
> recent firmware version available in Kalle's ath10k-firmware repository.

In case somebody wants to try it out, here is the config.seed for OpenWrt 
21.02.0:

CONFIG_TARGET_ipq40xx=y
CONFIG_TARGET_ipq40xx_generic=y
CONFIG_TARGET_ipq40xx_generic_DEVICE_plasmacloud_pa1200=y
CONFIG_ATH10K_LEDS=y
CONFIG_PACKAGE_ath10k-firmware-qca4019=y
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct is not set
# CONFIG_PACKAGE_firewall is not set
CONFIG_PACKAGE_ipq-wifi-plasmacloud_pa1200=y
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
# CONFIG_TARGET_ROOTFS_INITRAMFS is not set
CONFIG_PACKAGE_kmod-hwmon-core=y
CONFIG_PACKAGE_kmod-ipt-conntrack=y
CONFIG_PACKAGE_kmod-ipt-nat=y
CONFIG_PACKAGE_kmod-nf-conntrack6=y
CONFIG_PACKAGE_kmod-nf-nat=y

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

ath10k: qca4019: FW crash on 5GHz when baseEepHeader.nonLinearTxFir == 1

2021-09-17 Thread Sven Eckelmann 
Hi,

I've just wanted to test openwrt-21.02 (with ath10k-firmware-qca4019 + kmod-
ath10k) on an Plasma Cloud PA1200 router. While this device worked fine in the 
past, with this upgrade (to the newest firmware from linux-firmware), the 5GHz 
radio firmware seems to crash whenever I set it up via `ifconfig wlan1 up`:

ath10k_ahb a80.wifi: firmware crashed! (guid 
9e36ee82-4d2c-4c63-b20b-609a1eaca30c)
ath10k_ahb a80.wifi: qca4019 hw1.0 target 0x0100 chip_id 0x003b00ff 
sub :
ath10k_ahb a80.wifi: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
ath10k_ahb a80.wifi: firmware ver 10.4-3.6-00140 api 5 features 
no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 ba79b746
ath10k_ahb a80.wifi: board_file api 2 bmi_id 0:17 crc32 5f400efc
ath10k_ahb a80.wifi: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file 
max-sta 512 raw 0 hwcrypto 1
ath10k_ahb a80.wifi: firmware register dump:
ath10k_ahb a80.wifi: [00]: 0x000B 0x15B3 0x009C3C27 0x00975B31
ath10k_ahb a80.wifi: [04]: 0x009C3C27 0x00060530 0x0018 0x004176B8
ath10k_ahb a80.wifi: [08]: 0x00405A50 0x00412A30 0x 0x
ath10k_ahb a80.wifi: [12]: 0x0009 0x 0x009B9742 0x009B974F
ath10k_ahb a80.wifi: [16]: 0x00971238 0x009B9742 0x 0x
ath10k_ahb a80.wifi: [20]: 0x409C3C27 0x004053DC 0x0D2C 0x00405A60
ath10k_ahb a80.wifi: [24]: 0x809C3E13 0x0040543C 0x 0xC09C3C27
ath10k_ahb a80.wifi: [28]: 0x809B9AC5 0x0040547C 0x00412A30 0x0040549C
ath10k_ahb a80.wifi: [32]: 0x809B8ECD 0x0040549C 0x0001 0x00412A30
ath10k_ahb a80.wifi: [36]: 0x809B8FF3 0x004054CC 0x00412838 0x0014
ath10k_ahb a80.wifi: [40]: 0x809BEF98 0x0040551C 0x0041627C 0x0002
ath10k_ahb a80.wifi: [44]: 0x80986D47 0x0040553C 0x0041627C 0x00416A88
ath10k_ahb a80.wifi: [48]: 0x809CBB0A 0x0040559C 0x0041ACC0 0x
ath10k_ahb a80.wifi: [52]: 0x809864EE 0x0040560C 0x0041ACC0 0x0001
ath10k_ahb a80.wifi: [56]: 0x809CA8A4 0x0040564C 0x0041ACC0 0x0001
ath10k_ahb a80.wifi: Copy Engine register dump:
ath10k_ahb a80.wifi: [00]: 0x0004a000  14  14   3   3
ath10k_ahb a80.wifi: [01]: 0x0004a400  16  16  22  23
ath10k_ahb a80.wifi: [02]: 0x0004a800   3   3   2   3
ath10k_ahb a80.wifi: [03]: 0x0004ac00  15  15  15  15
ath10k_ahb a80.wifi: [04]: 0x0004b000   4   4  44   4
ath10k_ahb a80.wifi: [05]: 0x0004b400   3   3   2   3
ath10k_ahb a80.wifi: [06]: 0x0004b800   1   1   1   1
ath10k_ahb a80.wifi: [07]: 0x0004bc00   1   1   1   1
ath10k_ahb a80.wifi: [08]: 0x0004c000   0   0 127   0
ath10k_ahb a80.wifi: [09]: 0x0004c400   0   0   0   0
ath10k_ahb a80.wifi: [10]: 0x0004c800   0   0   0   0
ath10k_ahb a80.wifi: [11]: 0x0004cc00   0   0   0   0
ath10k_ahb a80.wifi: failed to update channel list: -108
ath10k_ahb a80.wifi: failed to set pdev regdomain: -108
ath10k_ahb a80.wifi: failed to create WMI vdev 0: -108
ieee80211 phy1: Hardware restart was requested

Interestingly, the crash disappeared when I've changed 
baseEepHeader.nonLinearTxFir (offset 0xc2 in the BDF) from 1 to 0.

The device itself was using firmware 10.4-3.6-00140 (the version currently in 
linux-firmware) - a working firmware is 10.4-3.5.3-00078. I also wanted to 
"bisected" when this problem was introduced but there are only these two 
recent firmware version available in Kalle's ath10k-firmware repository.

Does anybody know more about it?

Kind regards,
Sven

bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=PlasmaCloud-PA1200.bin
Description: Binary data


signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ath79: sysupgrade format policy for ar71xx migrations

2021-01-02 Thread Sven Eckelmann 
On Saturday, 2 January 2021 15:22:38 CET David Bauer wrote:
> sorry for the late reply.
> 
> Firs to fall, there is no real policy on that one, as OpenWrt itself does not
> advertise support for cross-target upgrades. It might work, or it might not.

Thanks for the reply. But the option 3 was already pushed to OpenWrt master.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] images: Revert "fix boot failures on NAND with small sub pages"

2020-12-04 Thread Sven Eckelmann 
This reverts commit ee76bd11bbe7 ("images: fix boot failures on NAND with
small sub pages") which broke (besides telling otherwise in the commit
message) the boot after sysupgrade on some NOR based devices.

The NOR flash rootfs images stored in a sysupgrade.tar must end with the
JFFS2 marker. Otherwise, devices like OpenMesh A42/A62 are not able to
calculate the md5sum of the fixed squashfs part and store it inside the
u-boot-env.

But the commit ee76bd11bbe7 ("images: fix boot failures on NAND with small
sub pages") adds up to 1020 0x00 bytes after the 0xdead0de EOF marker. The
calculated md5sum will be wrong due do this change and u-boot will fail to
boot the newly flashed device with a message like:

  Validating MD5Sum of 'vmlinux'...
  Passed!
  Validating MD5Sum of 'rootfs'...
  Failed!
  583a1b7b54b8601efa64ade42742459b != 8850ee812dfd7638e94083329d5d2781

  Data validation failed!

Cc: Russell Senior 
Cc: Jonas Gorski 
Signed-off-by: Sven Eckelmann 
---
I've originally submitted another hack on top of the original hack to avoid
this additional padding when the JFFS2 post-padding mark was detected.

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

But I was not yet able to get feedback from the original author.
---
 scripts/functions.sh  | 26 --
 scripts/sysupgrade-tar.sh | 13 +
 scripts/ubinize-image.sh  | 37 +++--
 3 files changed, 16 insertions(+), 60 deletions(-)
 delete mode 100644 scripts/functions.sh

diff --git a/scripts/functions.sh b/scripts/functions.sh
deleted file mode 100644
index 9a7fcde627..00
--- a/scripts/functions.sh
+++ /dev/null
@@ -1,26 +0,0 @@
-#!/bin/sh
-
-
-get_magic_word() {
-   dd if=$1 bs=4 count=1 2>/dev/null | od -A n -N 4 -t x1 | tr -d ' '
-}
-
-get_fs_type() {
-   local magic_word="$(get_magic_word "$1")"
-
-   case "$magic_word" in
-   "3118"*)
-   echo "ubifs"
-   ;;
-   "68737173")
-   echo "squashfs"
-   ;;
-   *)
-   echo "unknown"
-   ;;
-   esac
-}
-
-round_up() {
-   echo "$$1 + ($2 - 1))/ $2) * $2))"
-}
diff --git a/scripts/sysupgrade-tar.sh b/scripts/sysupgrade-tar.sh
index b93b2584bb..d1d627a96e 100755
--- a/scripts/sysupgrade-tar.sh
+++ b/scripts/sysupgrade-tar.sh
@@ -1,7 +1,5 @@
 #!/bin/sh
 
-. $TOPDIR/scripts/functions.sh
-
 board=""
 kernel=""
 rootfs=""
@@ -55,16 +53,7 @@ fi
 
 mkdir -p "${tmpdir}/sysupgrade-${board}"
 echo "BOARD=${board}" > "${tmpdir}/sysupgrade-${board}/CONTROL"
-if [ -n "${rootfs}" ]; then
-   case "$( get_fs_type ${rootfs} )" in
-   "squashfs")
-   dd if="${rootfs}" of="${tmpdir}/sysupgrade-${board}/root" 
bs=1024 conv=sync
-   ;;
-   *)
-   cp "${rootfs}" "${tmpdir}/sysupgrade-${board}/root"
-   ;;
-   esac
-fi
+[ -z "${rootfs}" ] || cp "${rootfs}" "${tmpdir}/sysupgrade-${board}/root"
 [ -z "${kernel}" ] || cp "${kernel}" "${tmpdir}/sysupgrade-${board}/kernel"
 
 mtime=""
diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
index c6f8bcefe5..32bd5ca326 100755
--- a/scripts/ubinize-image.sh
+++ b/scripts/ubinize-image.sh
@@ -1,7 +1,5 @@
 #!/bin/sh
 
-. $TOPDIR/scripts/functions.sh
-
 part=""
 ubootenv=""
 ubinize_param=""
@@ -11,6 +9,16 @@ outfile=""
 err=""
 ubinize_seq=""
 
+get_magic_word() {
+   dd if=$1 bs=2 count=1 2>/dev/null | od -A n -N 2 -t x1 | tr -d ' '
+}
+
+is_ubifs() {
+   if [ "$( get_magic_word $1 )" = "3118" ]; then
+   echo "1"
+   fi
+}
+
 ubivol() {
volid=$1
name=$2
@@ -24,7 +32,7 @@ ubivol() {
echo "vol_name=$name"
if [ "$image" ]; then
echo "image=$image"
-   [ -n "$size" ] && echo "vol_size=${size}"
+   [ -n "$size" ] && echo "vol_size=${size}MiB"
else
echo "vol_size=1MiB"
fi
@@ -35,10 +43,7 @@ ubivol() {
 
 ubilayout() {
local vol_id=0
-   local rootsize=
-   local autoresize=
-   local rootfs_type="$( get_fs_type "$2" )"
-
+   local root_is_ubifs="$( is_ubifs "$2" )"
if [ "$1" = "ubootenv" ]; then
ubivol $vol_id ubootenv
vol_id=$(( $vol_id + 1 ))
@@ -58,28 +63,16 @@ ubilayout() {
 
size="$part"
 
-   ubivol $vol_id "$name" "$image" &qu

Re: ath79: sysupgrade format policy for ar71xx migrations

2020-11-24 Thread Sven Eckelmann 
On Tuesday, 24 November 2020 08:58:04 CET Sven Eckelmann wrote:
[...]
> Now to the actual question:

I will just add some extra info to the options shown below. Maybe it makes 
then more sense why I've added two gluon developers to the Cc.

> What should the OpenMesh devices use as images for ath79:
> 
> 1. CE01 factory + sysupgrade-tar (like the OpenMesh IPQ40xx devices)

This would say this makes definitely sense for new devices. But in freifunk-
gluon's context, this would mean that the autoupdater cannot automatically 
upgrade from ar71xx to ath79.

So if this is preferred, then there is at least a manual way to upgrade a 
freifunk-gluon node to ath79. And this would be a "good" opportunity to get 
rid of the CE01 upgrade code.

But maybe there is also a solution for this in gluon's context. David and 
Matthias might know more about this.

> 2. CE01 factory + CE01 sysupgrade (like ar71xx)

At the moment, I would rather drop the factory image and not use this option. 
This would (in my eyes) only be necessary when some tools are not able to deal 
with the metadata at the end of the sysupgrade image.

> 3. CE01 sysupgrade (like ar71xx but avoid having two files with the same 
>content)

With this option, we would (hopefully) have a clean upgrade path with 
freifunk-gluon's autoupdater. The dualboot_datachk sysupgrade code can be 
adjusted to just work with CE01 images by creating some kind of hybrid between 
the old upgrade/openmesh.sh and the new upgrade/dualboot_datachk.sh. Or the 
old upgrade/openmesh.sh (minus some unnecessary steps) can just be reused.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

ath79: sysupgrade format policy for ar71xx migrations

2020-11-24 Thread Sven Eckelmann 
Hi,

I am currently a little bit unsure about the preferred sysupgrade format when 
an ar71xx device is re-added as ath79 device. I know that there is a migration 
guide for users [1] but I didn't see one for developers.

First a little bit of background: The OpenMesh devices used the combined 
extended image format (CE01) for its factory image (used internally by their 
firmware) and the support for sysupgrade was added by Gabor Juhos and Marek 
Lindner. Support for this CE01 format was also added to ap51-flash - used 
since this point as primary method to flash these kind of devices over the 
network. These devices are using a bootloader which checks the vmlinux + 
rootfs partition before it boots it and switches to the "other" (recovery) 
area if the check failed. And they write to the currently not used area during 
a sysupgrade (+ change the boot order in u-boot).

But Matthias Schiffer (in gluon context) didn't like that there was only a 
factory image  but not sysupgrade image. So I've added a sysupgrade image as 
copy of the CE01 factory image. But this ended up as a problem when the first 
OpenMesh IPQ40xx devices were added. Mathias Kresin didn't like that there is 
(mostly) the same file as factory and sysupgrade file on the servers and that 
the sysupgrade file is not using something more common like sysupgrade-tar 
[2] to store kernel+rootfs in separate chunks. So he helped to implemented the 
sysupgrade-tar support for this kind of dual boot NOR devices and left the 
CE01 images as factory image for the IPQ40xx devices.

The OpenMesh company doesn't exist anymore since a while and they cannot be 
(officially) bought anymore. But various Freifunk installations are using 
these devices. So I have some interest in getting (at least parts) of these 
devices working for a while. At least when the dualboot bootloader partition 
selection problem is fixed [3] and the NOR flash size is big enough.


Now to the actual question: 

What should the OpenMesh devices use as images for ath79:

1. CE01 factory + sysupgrade-tar (like the OpenMesh IPQ40xx devices)
2. CE01 factory + CE01 sysupgrade (like ar71xx)
3. CE01 sysupgrade (like ar71xx but avoid having two files with the same 
   content)

Kind regards,
Sven

[1] https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79
[2] Just as info: The sysupgrade-tar script is now creating unbootable images 
for IPQ40xx OpenMesh devices in OpenWrt master
https://github.com/openwrt/openwrt/pull/3616
[3] https://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032261.html

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ath79 subtarget with cmdline from bootloader

2020-11-23 Thread Sven Eckelmann 
On Monday, 3 August 2020 00:49:40 CET SAn via openwrt-devel wrote:
> The LibreRouter uses a dual-boot scheme that relies on the bootloader 
> configuring the kernel cmdline. At ar71xx 18.06 it was possible to select per 
> device if the cmdline from the bootloader has to be honored (using 
> patch-cmdline).
> AFAIK there is no such possibility on ath79.

There should be the possibility to fix this by dropping the bootargs property 
from the /chosen/ node. But the MIPS kernel code had a bug which was recently 
fixed upstream [1]. The fix must still be integrated [2] into OpenWrt.

The only code necessary in the dts is:

/ {
chosen {
/delete-property/ bootargs;
};
};

I hope this helps you.

Kind regards,
Sven

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7784cac697351f0cc0a4bb619594c0c99348c5aa
[2] (pending because I have to walk to the office to pick up my P300 test 
 devices)

https://github.com/ecsv/openwrt/commit/6e4750615dee12c3fd8ce14174fd91fc18fac498



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

[PATCH] mac80211: Fix wpa_supplicant config removal ubus call

2020-10-22 Thread Sven Eckelmann 
If mac80211_setup_supplicant() is called with enabled=0 then it should just
destroy the interface and remove the configuration from wpa_supplicant. But
the ubus method call always returned

  Command failed: Method not found

because the actual name of the method is "config_remove".

Fixes: b5516603dd90 ("mac80211: more wifi reconf related fixes")
Signed-off-by: Sven Eckelmann 
---
 package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 42144375b4..c8e952b7a3 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -627,7 +627,7 @@ mac80211_setup_supplicant() {
local spobj="$(ubus -S list | grep wpa_supplicant.${ifname})"
 
[ "$enable" = 0 ] && {
-   ubus call wpa_supplicant.${phy} config_del 
"{\"iface\":\"$ifname\"}"
+   ubus call wpa_supplicant.${phy} config_remove 
"{\"iface\":\"$ifname\"}"
ip link set dev "$ifname" down
iw dev "$ifname" del
return 0
-- 
2.28.0


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

Re: [gluon] Re: [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround

2020-08-17 Thread Sven Eckelmann 
On Monday, 17 August 2020 10:39:00 CEST Bjørn Mork wrote:
> Linus Lüssing  writes:
[...]
> This is not a bug.  They are deliberately breaking IPv6 because they
> consider this a feature.  You should not try to work around such issues.
> It is a fight you cannot win.  Any workaround will only encourage them
> to come up with new ways to break IPv6.

Who are "they" and where is this information coming from? And what do they 
gain from breaking IPv6? Wouldn't it be easier for them just to disable IPv6 
than adding random looking bugs?

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ipq40xx: essedma: Disable TCP segmentation offload for IPv6

2020-06-09 Thread Sven Eckelmann 
It was noticed that the the whole MAC can hang when transferring data from
one ar40xx port (WAN ports) to the CPU and from the CPU back to another
ar40xx port (LAN ports). The CPU was doing only NATing in that process.

Usually, the problem first starts with a simple data corruption:

  $ wget 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso
 -O /dev/null
  ...
  Connecting to saimei.ftp.acc.umu.se 
(saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected.
  ...
  Read  error at byte 48807936/352321536 (Decryption has failed.). Retrying.

But after a short while, the whole MAC will stop to react. No traffic can
be transported anymore from the CPU port from/to the AR40xx PHY/switch and
the MAC has to be resetted.

Signed-off-by: Sven Eckelmann 
---
v2:
* move the changes directly to
  
target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c

The problem was first observed on OpenWrt 18.06 and OpenWrt 19.07. It would
be good that the patch (or maybe even a better one) is "backported". This
actually means copying the one from the v1 [1] to the correct ipq40xx patch
folder and then refresh the patch.

Thanks

[1] 
https://patchwork.ozlabs.org/project/openwrt/patch/20200609132304.31669-1-s...@narfation.org/

 .../drivers/net/ethernet/qualcomm/essedma/edma_axi.c  | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git 
a/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
 
b/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
index b619bbbab9..96a82b3116 100644
--- 
a/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
+++ 
b/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
@@ -970,17 +970,14 @@ static int edma_axi_probe(struct platform_device *pdev)
edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM
  | NETIF_F_HW_VLAN_CTAG_TX
  | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_SG |
- NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GRO;
+ NETIF_F_TSO | NETIF_F_GRO;
edma_netdev[i]->hw_features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM |
NETIF_F_HW_VLAN_CTAG_RX
-   | NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 |
-   NETIF_F_GRO;
+   | NETIF_F_SG | NETIF_F_TSO | NETIF_F_GRO;
edma_netdev[i]->vlan_features = NETIF_F_HW_CSUM | NETIF_F_SG |
-  NETIF_F_TSO | NETIF_F_TSO6 |
-  NETIF_F_GRO;
+  NETIF_F_TSO | NETIF_F_GRO;
edma_netdev[i]->wanted_features = NETIF_F_HW_CSUM | NETIF_F_SG |
-NETIF_F_TSO | NETIF_F_TSO6 |
-NETIF_F_GRO;
+NETIF_F_TSO | NETIF_F_GRO;
 
 #ifdef CONFIG_RFS_ACCEL
edma_netdev[i]->features |=  NETIF_F_RXHASH | NETIF_F_NTUPLE;
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH] ipq40xx: essedma: Disable TCP segmentation offload for IPv6

2020-06-09 Thread Sven Eckelmann 
On Tuesday, 9 June 2020 15:23:04 CEST Sven Eckelmann wrote:
[...]
> The problem was first observed on OpenWrt 18.06 and OpenWrt 19.07. It would
> be good that this patch (or maybe even a better one) is copied to these
> versions (and then refreshed).
> 
> Thanks
> 
>  ...le-TCP-segmentation-offload-for-IPv6.patch | 46 +++
>  1 file changed, 46 insertions(+)
>  create mode 100644 
> target/linux/ipq40xx/patches-5.4/712-essedma-Disable-TCP-segmentation-offload-for-IPv6.patch

Ok, master doesn't use a patch file anymore to integrated the essedma
driver. Everything was moved to 
target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/

A simpler patch will follow in a second.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq40xx: essedma: Disable TCP segmentation offload for IPv6

2020-06-09 Thread Sven Eckelmann 
It was noticed that the the whole MAC can hang when transferring data from
one ar40xx port (WAN ports) to the CPU and from the CPU back to another
ar40xx port (LAN ports). The CPU was doing only NATing in that process.

Usually, the problem first starts with a simple data corruption:

  $ wget 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso
 -O /dev/null
  ...
  Connecting to saimei.ftp.acc.umu.se 
(saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected.
  ...
  Read  error at byte 48807936/352321536 (Decryption has failed.). Retrying.

But after a short while, the whole MAC will stop to react. No traffic can
be transported anymore from the CPU port from/to the AR40xx PHY/switch and
the MAC has to be resetted.

Signed-off-by: Sven Eckelmann 
---
The problem was first observed on OpenWrt 18.06 and OpenWrt 19.07. It would
be good that this patch (or maybe even a better one) is copied to these
versions (and then refreshed).

Thanks

 ...le-TCP-segmentation-offload-for-IPv6.patch | 46 +++
 1 file changed, 46 insertions(+)
 create mode 100644 
target/linux/ipq40xx/patches-5.4/712-essedma-Disable-TCP-segmentation-offload-for-IPv6.patch

diff --git 
a/target/linux/ipq40xx/patches-5.4/712-essedma-Disable-TCP-segmentation-offload-for-IPv6.patch
 
b/target/linux/ipq40xx/patches-5.4/712-essedma-Disable-TCP-segmentation-offload-for-IPv6.patch
new file mode 100644
index 00..1b165d0051
--- /dev/null
+++ 
b/target/linux/ipq40xx/patches-5.4/712-essedma-Disable-TCP-segmentation-offload-for-IPv6.patch
@@ -0,0 +1,46 @@
+From: Sven Eckelmann 
+Date: Tue, 9 Jun 2020 14:08:44 +0200
+Subject: essedma: Disable TCP segmentation offload for IPv6
+
+It was noticed that the the whole MAC can hang when transferring data from
+one ar40xx port (WAN ports) to the CPU and from the CPU back to another
+ar40xx port (LAN ports). The CPU was doing only NATing in that process.
+
+Usually, the problem first starts with a simple data corruption:
+
+  $ wget 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso
 -O /dev/null
+  ...
+  Connecting to saimei.ftp.acc.umu.se 
(saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected.
+  ...
+  Read  error at byte 48807936/352321536 (Decryption has failed.). Retrying.
+
+But after a short while, the whole MAC will stop to react. No traffic can
+be transported anymore from the CPU port from/to the AR40xx PHY/switch and
+the MAC has to be resetted.
+
+Signed-off-by: Sven Eckelmann 
+
+--- a/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
 b/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
+@@ -970,17 +970,14 @@ static int edma_axi_probe(struct platfor
+   edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM
+ | NETIF_F_HW_VLAN_CTAG_TX
+ | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_SG |
+-NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GRO;
++NETIF_F_TSO | NETIF_F_GRO;
+   edma_netdev[i]->hw_features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM |
+   NETIF_F_HW_VLAN_CTAG_RX
+-  | NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 |
+-  NETIF_F_GRO;
++  | NETIF_F_SG | NETIF_F_TSO | NETIF_F_GRO;
+   edma_netdev[i]->vlan_features = NETIF_F_HW_CSUM | NETIF_F_SG |
+- NETIF_F_TSO | NETIF_F_TSO6 |
+- NETIF_F_GRO;
++ NETIF_F_TSO | NETIF_F_GRO;
+   edma_netdev[i]->wanted_features = NETIF_F_HW_CSUM | NETIF_F_SG |
+-   NETIF_F_TSO | NETIF_F_TSO6 |
+-   NETIF_F_GRO;
++   NETIF_F_TSO | NETIF_F_GRO;
+ 
+ #ifdef CONFIG_RFS_ACCEL
+   edma_netdev[i]->features |=  NETIF_F_RXHASH | NETIF_F_NTUPLE;
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-25 Thread Sven Eckelmann 
On Monday, 25 May 2020 11:22:13 CEST Sven Eckelmann wrote:
[...]
> And it still can with this OpenWrt version. But it doesn't seem to happen 
> with 
> the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000 
> commits inbetween. So no idea what changed (just a timing thing or an actual 
> fix - no idea).

Seems like there is a fix which solves some lost interrupt problems for 
IPQ40xx. Without this change, I see the reported problem. And with the patch, 
it is gone. Or in commits:

* creates timeout problems: 46b949a067e5 ("ipq40xx: enlarge PCIe BAR size")
* works fine: 18e942b6c4e5 ("ipq40xx: fix pcie msi IRQ trigger level")

If you look in the git logs [1], you can see that the working commit is a 
child of the broken one. So at least from my point of view, my initial report 
is no blocker anymore for Sebastian's patch (or Kalle's version of it).

Btw. OpenWrt is automatically assigning a trigger (phy*tpt) for these LEDs.

Kind regards,
Sven

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=log;h=18e942b6c4e51a5a717a121697a63f3f98d93b19

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-25 Thread Sven Eckelmann 
On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote:
[...]
> could somone clarify the state here and why it was dropped?
> the original patch i wrote does exclude the soc chipsets, but the patch 
> was later reorganized and some part have been rewritten
> so i'm not sure if it covers the scenario mentioned here, which i did 
[...]
> > This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
> > add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
> > firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:

Just noticed that there was a copy and paste error in my message. The 5GHz was 
an QCA9888 [1,2] and not an QCA4019. Otherwise the _pci error wouldn't have 
made 
any sense.

And I can only say at the moment (remember that this was observer 14 months 
ago), that it could be reproduced easily on IPQ40xx with an QCA9888 and the 
given config running OpenWrt reboot-9440-g0f89c17b57. The diffconfig (seed) of 
the installation was:

CONFIG_TARGET_ipq40xx=y
CONFIG_TARGET_ipq40xx_generic=y
CONFIG_TARGET_ipq40xx_generic_DEVICE_openmesh_a62=y
CONFIG_ATH10K_LEDS=y
CONFIG_PACKAGE_ath10k-firmware-qca4019=y
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct is not set
CONFIG_PACKAGE_ath10k-firmware-qca9888=y
# CONFIG_PACKAGE_ath10k-firmware-qca9888-ct is not set
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
# CONFIG_PACKAGE_kmod-hwmon-core is not set

And it still can with this OpenWrt version. But it doesn't seem to happen with 
the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000 
commits inbetween. So no idea what changed (just a timing thing or an actual 
fix - no idea).

Btw. the wireless config was given in the original mail [2,3]

Kind regards,
Sven

[1] https://openwrt.org/toh/hwdata/open-mesh/open-mesh_a62
[2] https://patchwork.kernel.org/patch/10723033/#22502191
[3] https://patchwork.kernel.org/patch/10327075/#22502179

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] uci: fix options list of section after type change

2019-05-17 Thread Sven Eckelmann 
A section can store its name in the same memory region as the section
(after the actual section object). The object is then reallocated when the
type is later changed via an uci_set. But the original address of the
section is (indirectly) stored in the section list, the object and the
object list (HEAD) of this section.

But only the section list was fixed in commit 4fb6a564b8ee ("clean up
uci_set") after the realloc finished. Traversing the object list or
accessing the section pointer caused heap-use-after-free errors.

Reported-by: Charlemagne Lasse 
Fixes: 4fb6a564b8ee ("clean up uci_set")
Signed-off-by: Sven Eckelmann 
---
v2:
 - drop unnecessary include of stdbool.h in cli.c

 list.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/list.c b/list.c
index 25aec56..78efbaf 100644
--- a/list.c
+++ b/list.c
@@ -182,6 +182,32 @@ static void uci_fixup_section(struct uci_context *ctx, 
struct uci_section *s)
s->e.name = uci_strdup(ctx, buf);
 }
 
+/* fix up option list HEAD pointers and pointer to section in options */
+static void uci_section_fixup_options(struct uci_section *s, bool no_options)
+{
+   struct uci_element *e;
+
+   if (no_options) {
+   /*
+* enforce empty list pointer state (s->next == s) when original
+* section had no options in the first place
+*/
+   uci_list_init(>options);
+   return;
+   }
+
+   /* fix pointers to HEAD at end/beginning of list */
+   uci_list_fixup(>options);
+
+   /* fix back pointer to section in options */
+   uci_foreach_element(>options, e) {
+   struct uci_option *o;
+
+   o = uci_to_option(e);
+   o->section = s;
+   }
+}
+
 static struct uci_section *
 uci_alloc_section(struct uci_package *p, const char *type, const char *name)
 {
@@ -713,10 +739,15 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
char *s = uci_strdup(ctx, ptr->value);
 
if (ptr->s->type == uci_dataptr(ptr->s)) {
+   /* drop the in-section storage of type name */
+   bool no_options;
+
+   no_options = uci_list_empty(>s->options);
ptr->last = NULL;
ptr->last = uci_realloc(ctx, ptr->s, sizeof(struct 
uci_section));
ptr->s = uci_to_section(ptr->last);
uci_list_fixup(>s->e.list);
+   uci_section_fixup_options(ptr->s, no_options);
} else {
free(ptr->s->type);
}
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH] uci: test: use valgrind to detect memory corruptions

2019-05-17 Thread Sven Eckelmann 
On Friday, 17 May 2019 11:44:25 CEST Charlemagne Lasse wrote:
> uci is currently a highly problematic software and its library & lua
> bindings cannot be used without corrupting or leaking memory

heap-use-after-free - yes. But I cannot find the memory leak report/test. This 
is what I am currently searching for in some downstream project.

The test scripts work fine after adding 
https://patchwork.ozlabs.org/patch/1100999/

#
# Performing tests
#
test_import
test_export
test_get_parsing
test_get_section_index_parsing
test_get_option
test_get_option_multiline
test_get_section
test_set_parsing
test_set_named_section
test_set_nonexisting_option
test_set_nonexisting_option_multiline
test_set_existing_option
test_set_existing_option_multiline
test_add_section
test_get_parsing
test_get_parsing_multiline_package
test_get_parsing_multiline_section
test_get_parsing_multiline_option
test_batch_set
test_batch_comments
test_revert_section
test_revert_option
test_revert_option_multiline
test_revert_option_long
test_add_list_config
test_add_list_get
test_add_list_show
test_add_list_changes
test_del_list
test_del_list_multiline
test_add_delta
test_changes_tailing_parts
test_changes_missing_value

#
# Test report
#
tests passed:   112 100%
tests failed: 0   0%
tests skipped:0   0%
tests total:112 100%

> To notice such problems faster, start the uci testsuite with the
> valgrind memory checker.

Patch doesn't apply (adding it manually works).

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] uci: fix options list of section after type change

2019-05-17 Thread Sven Eckelmann 
A section can store its name in the same memory region as the section
(after the actual section object). The object is then reallocated when the
type is later changed via an uci_set. But the original address of the
section is (indirectly) stored in the section list, the object and the
object list (HEAD) of this section.

But only the section list was fixed in commit 4fb6a564b8ee ("clean up
uci_set") after the realloc finished. Traversing the object list or
accessing the section pointer caused heap-use-after-free errors.

Reported-by: Charlemagne Lasse 
Fixes: 4fb6a564b8ee ("clean up uci_set")
Signed-off-by: Sven Eckelmann 
---
 cli.c  |  1 +
 list.c | 31 +++
 2 files changed, 32 insertions(+)

diff --git a/cli.c b/cli.c
index f8b45db..9ffd45c 100644
--- a/cli.c
+++ b/cli.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "uci.h"
diff --git a/list.c b/list.c
index 25aec56..78efbaf 100644
--- a/list.c
+++ b/list.c
@@ -182,6 +182,32 @@ static void uci_fixup_section(struct uci_context *ctx, 
struct uci_section *s)
s->e.name = uci_strdup(ctx, buf);
 }
 
+/* fix up option list HEAD pointers and pointer to section in options */
+static void uci_section_fixup_options(struct uci_section *s, bool no_options)
+{
+   struct uci_element *e;
+
+   if (no_options) {
+   /*
+* enforce empty list pointer state (s->next == s) when original
+* section had no options in the first place
+*/
+   uci_list_init(>options);
+   return;
+   }
+
+   /* fix pointers to HEAD at end/beginning of list */
+   uci_list_fixup(>options);
+
+   /* fix back pointer to section in options */
+   uci_foreach_element(>options, e) {
+   struct uci_option *o;
+
+   o = uci_to_option(e);
+   o->section = s;
+   }
+}
+
 static struct uci_section *
 uci_alloc_section(struct uci_package *p, const char *type, const char *name)
 {
@@ -713,10 +739,15 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
char *s = uci_strdup(ctx, ptr->value);
 
if (ptr->s->type == uci_dataptr(ptr->s)) {
+   /* drop the in-section storage of type name */
+   bool no_options;
+
+   no_options = uci_list_empty(>s->options);
ptr->last = NULL;
ptr->last = uci_realloc(ctx, ptr->s, sizeof(struct 
uci_section));
ptr->s = uci_to_section(ptr->last);
uci_list_fixup(>s->e.list);
+   uci_section_fixup_options(ptr->s, no_options);
} else {
free(ptr->s->type);
}
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock

2019-05-16 Thread Sven Eckelmann 
On Tuesday, 14 May 2019 15:42:18 CEST Pavel Kubelun wrote:
> +--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
>  b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> +@@ -141,9 +141,9 @@
> +   };
> + 
> +   clocks {
> +-  sleep_clk: sleep_clk {
> ++  sleep_clk: gcc_sleep_clk_src {
> +   compatible = "fixed-clock";
> +-  clock-frequency = <32768>;
> ++  clock-frequency = <32000>;
> +   #clock-cells = <0>;
> +   };

On Thursday, 16 May 2019 13:18:14 CEST Павел wrote:
[...]
> > And maybe some of these guys also know how to find the ipq40xx clock
> > controller reference or hardware reference. Because I was only able to
> > verify
> > for IPQ8072 that it had a 32.768 KHz sleep clock. But the
> >
> 
> If you are completely sure about that, then I guess that they have
> (un)intentionally messed with the clock in QSDK, because they state that
> ipq807x has the same 32000 khz crystal.
> https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/tree/arch/arm64/boot/dts/qcom/qcom-ipq807x-soc.dtsi?h=eggplant#n2055

Confidence is the wrong word. I can only state that this is written in 
80-YA727-13 Rev. D (IPQ8072.AP.HK07). Same for other devices like 
IPQ8078 AP.HK02, IPQ8074 AP.HK01, ...

But I found in the same document that they call it the "32 KHz sleep clock in" 
in one section and and in another table "32.768 KHz sleep clock input to the 
IPQ8072" (next to the name "...32K..."). So it is now to the reader to find 
out what they meant here in which reference document. So maybe they also meant 
32.768 KHz when in the IPQ4019 Watchdog document when they wrote 32 Khz sleep 
clock... who knows.

My gut feeling (sorry, not an HW guy) tell me that they are just using a 
32.768 KHz clock (from a standard 32.768 KHz oscillator) in all these products 
and just shortened it to 32K at some point in the document. And now Gopinath 
Sekar wrote 32000 instead of 32768. But I absolutely don't know what actually 
is there in HW.

Kind regards,
Sven

[1] 
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=d92ec59973484acc86dd24b67f10f8911b4b4b7d

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4] ipq40xx: fix sleep clock

2019-05-16 Thread Sven Eckelmann 
On Wednesday, 15 May 2019 19:16:51 CEST Павел wrote:
[...]
> > Is there any particular reason why
> > this
> > shouldn't be sent upstream and then backported to OpenWrt?
> >
> 
> There are no reasons why it shouldn't be sent upstream along with other
> patches. I hope to find someone with datasheet beforehand to verify the
> correct sleep clock rate.

But you will most likely find the persons with the datasheet when you try to 
upstream it via 

* Andy Gross  (maintainer:ARM/QUALCOMM SUPPORT)
* David Brown  (maintainer:ARM/QUALCOMM SUPPORT)
* linux-arm-...@vger.kernel.org (open list:ARM/QUALCOMM SUPPORT)

And maybe some of these guys also know how to find the ipq40xx clock 
controller reference or hardware reference. Because I was only able to verify 
for IPQ8072 that it had a 32.768 KHz sleep clock. But the 
"IPQ4018/IPQ4028/IPQ4019/IPQ4029 Watchdog" document states that the watchdog 
runs on a 32 KHz sleep clock. And according to the device tree, the clock you 
modified here is connected to the watchdog.

And for the device tree bindings:

* devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE 
BINDINGS)
* Rob Herring  (maintainer:OPEN FIRMWARE AND FLATTENED 
DEVICE TREE BINDINGS)
* Mark Rutland  (maintainer:OPEN FIRMWARE AND FLATTENED 
DEVICE TREE BINDINGS)

> Besides upstreaming a patch takes time while the next openwrt release
> should be out soon I suppose.

Good reason to try to upstream it at the same time to OpenWrt and upstream :)
At least then we could get some feedback from upstream before OpenWrt ships 
something which potentially has negative effects.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath10k TPC reg. domain incorrect?

2019-05-14 Thread Sven Eckelmann 
On Monday, 13 May 2019 22:58:00 CEST Sam Samy wrote:
>  I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri
> band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios
> (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working
> fine except one problem in 5Ghz. On both the 5Ghz radios the RSSI is
> pretty low on any 5Ghz channel I put it in.  In one feet range I see -60dB
> RSSI, where as the stock firmware that came with the AP gives an RSSI
> of -36dB at one foot distance.The downstream transmit rates are MCS8/9
> for most part. The 2Ghz is working fine.

It could be the boarddata which contains more than the targetpower and CTLs 
(and thus not necessarily visible in tpc_stats). As first check, test whether 
your board-2.bin has the md5sum 34c1e73e609a27eb9848fdc89cbc2be7 for 
/lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin. Also check that the correct
BDF (with the variant string is loaded). But this should only affect 
the QCA4019 5GHz PHY because the QCA9886 boarddata is generated here using the 
pre-cal data from art (unsure whether this is valid or not for this board and 
bootup sequence).

You can just check with the ath10k-bdencoder [0] from qca-swiss-army-knife 
whether the board files from board-2.bin are the ones which also your stock 
firmware is loading.

The next big problem are filters in the rx/tx chains [1]. The ieee80211-freq-
limit in the DTS file should assist you and not allow you to chose the wrong 
channel/frequency for a specific PHY. But maybe the author accidentally 
switched the settings in the board and actually wanted the lower 5GHz channels 
on the SoC 5GHz PHY and the the upper 5GHz channels on the PCIe card? This 
would be at least worth a try.

> What is the reg. domains 0x20 and 0x58 value points to?

It is 20 (0x14) and not 0x20. Same for 58 (0x3a)

Btw. the regd numbers from QCA can be checked in regd_common.h [2]. The 
mapping in regDomainPairs is not necessarily correct because someone has to 
take them from the newest proprietary driver and use them to update the ath*k 
stuff.

>   Looks like ./sys/kernel/debug/ieee80211/phy2/ath10k/cal_data is junk
> for both the 5Ghz radios even though the
> pre-cal-pci-:01:00.0.bin/pre-cal-ahb-a80.wifi.bin is correct.

Yes, the implemented method for reading the data is not correct for the
wave 2 cards (and maybe also other). You can try the attached hack. At 
least this worked in 2017 when I've poked around in the stuff with 
Christian Lamparter.

Kind regards,
Sven

[0] 
https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder
[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=41a86debe3c0a01e075e749d0bb1c6d631e35c32
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers/net/wireless/ath/regd_common.h?id=5fad78689a9229d08ea11af53e48de3c2a845ea3#n29diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 43e3443..0687a3f 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -509,6 +509,38 @@ static int ath10k_push_board_ext_data(struct ath10k *ar, const void *data,
 	return 0;
 }
 
+static int ath10k_debug_cal_data_fetch(struct ath10k *ar)
+{
+	u32 board_data_size = ar->hw_params.fw.board_size;
+	u32 address;
+	int ret;
+	printk("%s:%u\n", __func__, __LINE__);
+
+	ret = ath10k_bmi_read32(ar, hi_board_data, );
+	if (ret) {
+		ath10k_err(ar, "could not read board data addr (%d)\n", ret);
+		goto exit;
+	}
+
+	ret = ath10k_bmi_read_memory(ar, address, ar->debug.cal_data,
+  min_t(u32, board_data_size,
+	ar->hw_params.cal_data_len));
+	if (ret) {
+		ath10k_warn(ar, "failed to read calibration data: %d\n", ret);
+		return ret;
+	}
+
+	ret = ath10k_bmi_write32(ar, hi_board_data_initialized, 1);
+	if (ret) {
+		ath10k_err(ar, "could not write board data bit (%d)\n", ret);
+		goto exit;
+	}
+	printk("%s:%u\n", __func__, __LINE__);
+
+exit:
+	return ret;
+}
+
 static int ath10k_download_board_data(struct ath10k *ar, const void *data,
   size_t data_len)
 {
@@ -704,7 +736,6 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
 
 	return 0;
 }
-
 static int ath10k_download_and_run_otp(struct ath10k *ar)
 {
 	u32 result, address = ar->hw_params.patch_load_addr;
@@ -746,6 +777,8 @@ static int ath10k_download_and_run_otp(struct ath10k *ar)
 		return ret;
 	}
 
+	ath10k_debug_cal_data_fetch(ar);
+
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot otp execute result %d\n", result);
 
 	if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index fa72ef5..451bd59 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1437,47 +1437,12 @@ static const struct file_operations fops_fw_dbglog = {
 	.llseek = default_llseek,
 };
 
-static int

Re: [OpenWrt-Devel] [PATCH] ath79: Add missing read-only properties

2019-05-10 Thread Sven Eckelmann 
On Thursday, 9 May 2019 13:50:39 CEST Adrian Schmutzler wrote:
> diff --git a/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts b/
target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts
> index 1e3cf40f71..fa74cf2344 100644
> --- a/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts
> +++ b/target/linux/ath79/dts/qca9558_openmesh_om5p-ac-v2.dts
> @@ -114,6 +114,7 @@
> partition@1 {
> label = "u-boot-env";
> reg = <0x04 0x01>;
> +   read-only;
> };
>  
> partition@2 {

I think this device is in a weird state for ath79 but following info would be 
relevant when it would support flash installations and sysupgrade like under 
ar71xx:

This device needs to write access to the u-boot-env to switch the firmware 
partition and adjust the kernel + (static part of) rootfs checksums during 
syspgrade.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

2019-03-16 Thread Sven Eckelmann 
On Saturday, 16 March 2019 13:18:48 CET Xuebing Wang wrote:
[...]
> 1)  Firmware inside QSDK (QCA closed source?) for AP-DK04.1-C1 based 
> routers.
> 2)  Firmware from kvalo/linux-firmware
> 
> Are these "2 lines" of firmware essentially the same?

They should at least be quite similar. Maybe Kalle knows more about it. But I 
am not sure whether he is allowed to disclose this information to the public.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WPJ428HV board - OpenWRT

2019-03-15 Thread Sven Eckelmann 
On Thursday, 14 March 2019 22:39:54 CET Lloyed Emmanuel wrote:
[...]
> I have loaded  the following OpenWRT firmware to  WPJ428HV boards.
> 
> http://downloads.openwrt.org/releases/18.06.2/targets/ipq40xx/generic/openwrt-18.06.2-ipq40xx-compex_wpj428-squashfs-sysupgrade.bin
> 
> and I followed your steps in the following website
> 
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2796ab85ed5097d91623e60abf22325bd9086407
> 
> Everything is working fine but I am losing configuration when the board is 
> rebooted or restarted. What could be reasons for losing configurations?
> Any idea on how to fix this issue?

overlayfs could not be mounted or rootfs_data wasn't created in the first 
place.

You can solve it by figuring out why this wasn't done and then fix the 
underlying problem.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

2019-03-10 Thread Sven Eckelmann 
On Sunday, 10 March 2019 18:03:51 CET Ben Greear wrote:
[...]
> > [2] 
> > https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5
> 
> So, both of the patches above need to be applied to ath10k-ct 4.19 driver?
> 
> > [3] https://patchwork.ozlabs.org/patch/1051204/
> 
> I can apply this one to the 4.19 ath10k-ct driver too, I just am not using 
> 4.19 internally,
> so...well, no local testing.

Both were examples were the behavior of ath10k and ath10k-ct in OpenWrt were 
out of sync for a while. Both should now behave the same because Hauke/
Christian added them. But similar problems might happen in the future. Both
will hopefully find their way in the official ath10k driver (patchwork one 
is - I've tried to poke Kalle regarding the first one from PR 1862).


Regarding the second patch in PR 1862:

You should at least think about how to handle your private rate modification 
code. It conflicts with the official way to set the mgmt/mcast/bcast rates.
The second patch in the PR 1862 is just a workaround for this default
(mis)behavior of ath10k-ct. Maybe you have a different behavior in mind but
at least by default, it should not set an arbitrary mcast_rate for
meshpoint/ibss interfaces when the user specified something else via
OpenWrt's mcast_rate in /etc/config/wireless.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

2019-03-10 Thread Sven Eckelmann 
On Sunday, 10 March 2019 05:52:00 CET Xuebing Wang wrote:
[...]
> Are there anyone building 802.11s routers based on tag 18.06.1, 18.06.2 
> or branch openwrt-18.06?

Most(?) companies and community projects just throw the 802.11s forwarding/
routing part away and are running their preferred Layer2/Layer3 mesh protocol 
(bmxd/6/7, olsrd(2), babeld, batman-adv, ...) over it. But yes, they are still 
require the meshpoint interface support in ath10k+firmware.

A project I am more familiar (and is using 18.06.x) is freifunk-gluon [1]. 
They just select the ath10k-firmware-* (from kvalo/linux-firmware) for 
meshpoint setups and ath10k-firmware*-ct for IBSS setups.

As far as I know, this will still be possible with OpenWrt 19.xx). And this 
should also work the same when you want to run 802.11s+HWMP over it.

> I noticed that in OpenWRT master branch ath10k-ct and 
> ath10k-firmware-qca4019-ct are enabled by default, but they are not 
> enabled in tag 18.06.2.

Regarding ath10k vs. ath10k-ct - yes, this is a rather unfortunate situation 
that we have two different drivers. ath10k-ct is basically ath10k with a  
~7000 lines patch on top. You just have to keep in mind that there are some 
hacks in it which may break standard ath10k/mac80211 features [2]. So you 
cannot always assume that this can be reported to the ath10k people. And some 
of the changes in the mac80211 ath10k could be missing in ath10k-ct [3,4]. So 
you have to figure out yourself which driver better fits your needs.

Kind regards,
Sven

[1] https://github.com/freifunk-gluon/gluon
[2] 
https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5
[3] https://patchwork.ozlabs.org/patch/1051204/
[4] https://github.com/openwrt/openwrt/pull/1077

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2019-02-26 Thread Sven Eckelmann 
On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
> From: Sebastian Gottschall 
> 
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
> chipsets with on chipset connected led's using WMI Firmware API.  The LED
> device will get available named as "ath10k-phyX" at sysfs and can be 
> controlled
> with various triggers.  adds also debugfs interface for gpio control.
> 
> Signed-off-by: Sebastian Gottschall 
> Reviewed-by: Steve deRosier 
> [kvalo: major reorg and cleanup]
> Signed-off-by: Kalle Valo 


This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k 
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz) 
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:

[  221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout, 
restarting hardware
[  221.744056] ieee80211 phy0: Hardware restart was requested
[  225.130829] ath10k_pci :01:00.0: failed to receive control response 
completion, polling..
[  226.170824] ath10k_pci :01:00.0: Service connect timeout
[  226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
[  226.252248] ath10k_pci :01:00.0: Could not init core: -110

This was tested on an A62 with following wireless config:

config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
option htmode 'VHT80'
option disabled '0'
option country US

config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/soc/a00.wifi'
option htmode 'HT20'
option disabled '0'
option country US

config wifi-device 'radio2'
option type 'mac80211'
option channel '149'
option hwmode '11a'
option path 'platform/soc/a80.wifi'
option htmode 'VHT80'
option disabled '0'
option country US

config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none'

config wifi-iface 'mesh1'
option device 'radio1'
option ifname 'mesh1'
option network 'nwi_mesh1'
option mode 'mesh'
option mesh_id 'TestMesh'
option encryption 'none'


config wifi-iface 'mesh2'
option device 'radio2'
option ifname 'mesh2'
option network 'nwi_mesh2'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

2019-02-25 Thread Sven Eckelmann 
On Monday, 25 February 2019 20:25:25 CET Sven Eckelmann wrote:
> On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote:
> > >> Mesh is broken using ath10k-ct?
> > >> https://bugs.openwrt.org/index.php?do=details_id=2123
[...]
> Can you check if following works for you (add it as patch to 
> package/kernel/mac80211/patches/ath/ and hope that my MUA didn't
> reformat the patch):

Or better test the PRs [1,2] which incorporate a proposed patch [3] from 
Pradeep.

Kind regards,
Sven

[1] https://github.com/openwrt/openwrt/pull/1861
[2] https://github.com/openwrt/openwrt/pull/1862
[3] https://patchwork.kernel.org/patch/10723033/

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

2019-02-25 Thread Sven Eckelmann 
On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote:
> >> Mesh is broken using ath10k-ct?
> >> https://bugs.openwrt.org/index.php?do=details_id=2123
[...]
> * The "classic" drivers/firmware fail on or after the indicated commit
> 
>  CONFIG_PACKAGE_ath10k-firmware-qca9887=y
>  CONFIG_PACKAGE_kmod-ath10k=y
>  # CONFIG_PACKAGE_kmod-ath10k-ct is not set
> 
> 
> That the CT drivers/firmware don't support 802.11s mesh
> isn't really an OpenWrt issue.
> 
> That there is a regression in overall system capability
> that "kills" connectivity is a signficant concern.

* Can you confirm that it works with ath10k-ct but not with ath10k?
* And can you confirm that changing encryption to none has no effect on the 
  problem.
* Can you confirm that reverting commit cd93b83ad927 ("ath10k: support for 
  multicast rate control") [1] in ath10k fixes this problem?
* Can you confirm that manually setting mcast_rate to 18000  in the mesh wifi-
  iface fixes the problem?

config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option mcast_rate '18000' 
option encryption 'none'

* can you confirm that it lo

It looks for me like mac80211 is trying to set the mcast_rate which is 
interpreted by ath10k in ath10k_bss_info_changed as 11 Mbit/s (CCK). Which is 
of course not supported on 5GHz. So all your pretty little broadcast/multicast 
packets end up in nirvana.

Problem here is that rateidx is -1. Which means that it cannot just programmed 
up by us.

Can you check if following works for you (add it as patch to 
package/kernel/mac80211/patches/ath/ and hope that my MUA didn't
reformat the patch):

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index b73c23d4ce86..85c6d820e8c4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5778,6 +5778,10 @@ static void ath10k_bss_info_changed(struct ieee80211_hw 
*hw,
band = def.chan->band;
rateidx = vif->bss_conf.mcast_rate[band] - 1;
 
+   /* fallback to lowest rate when mcast_rate == -1 */
+   if (rateidx < 0)
+   rateidx = 0;
+
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
rateidx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;


Kind regards,
Sven

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cd93b83ad927b2c7979e0add0343ace59328b461

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [B.A.T.M.A.N.] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

2019-02-25 Thread Sven Eckelmann 
On Monday, 25 February 2019 09:03:52 CET Кирилл Луконин wrote:
> But what about ELP interval parameter?
> As I think, it should be covered by UCI config too.

Please first provide a batctl patch to support this setting. Then we can 
discuss the uci integration.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

2019-02-24 Thread Sven Eckelmann 
On Monday, 25 February 2019 02:24:56 CET Gui Iribarren wrote:
> have you considered, to simplify backwards compatibility, to keep proto 
> "batadv" as it currently is (hardif) and naming "batadv_mesh" the new proto?

It was one of the goals to *not* name the batadv hardif interface proto 
"batadv". And I wanted to have the batman-adv interface proto named "batadv" 
because this is the rtnl kind string. So you actually create batman-adv 
meshifs using:

   ip link add dev bat0 type batadv

But we can call this proto also "batadv_meshif" if there is a strong 
preference for this name.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

2019-02-24 Thread Sven Eckelmann 
batman-adv allows to configure three different objects:

* batadv hardif

  - network interface used by batadv meshif to transport the batman-adv
packets
  - its master interface is set to the batadv meshif

* batadv (meshif/softif)

  - virtual interface that emulates a normal 802.3 interface on top
  - encapsulates traffic and forwards it via the batadv hardifs

* batadv vlan

  - potential VLAN ID on top of batadv meshif
  - allows filtering of traffic from specific VIDs

While batadv vlan objects were already represented as an own proto
"batadv_vlan", the batadv meshif could never be fully configured using
/etc/config/network. Instead, parts of its configuration were stored in
/etc/config/batman_adv and some in the interfaces with the "batadv" proto.

To increase the confusion, the "batadv" proto wasn't used to define the
batadv meshif but to identify batadv (slave) hardifs. The batman-adv
meshifs were also never created directly but only when a hardif was
configured. The actual modification of the configuration settings was then
applied using a hotplug script hack. The batadv meshif network interface
could therefore only be created when an hardif was available and not
manipulated with ifup/ifdown. Also `/etc/init.d/network reload` didn't
modify the batadv meshif interface configuration correctly.

The "batadv" is now renamed to "batadv_hardif" and a new "batadv" proto is
used to configure the main (meshif) network interface with all its
configuration.

A simple network configuration with WiFi & ethernet interfaces and static
IP on top of bat0 would look like:

  # batadv meshif bat0
  config interface 'bat0'
option proto 'batadv'
option routing_algo 'BATMAN_IV'
option aggregated_ogms 1
option ap_isolation 0
option bonding 0
option fragmentation 1
#option gw_bandwidth '1/2000'
option gw_mode 'off'
#option gw_sel_class 20
option log_level 0
option orig_interval 1000
option bridge_loop_avoidance 1
option distributed_arp_table 1
option multicast_mode 1
option network_coding 0
option hop_penalty 30
option isolation_mark '0x/0x'

  # add *single* wifi-iface with network bat0_hardif_wlan as hardif to bat0
  config interface 'bat0_hardif_wlan'
option mtu '1536'
option proto 'batadv_hardif'
option master 'bat0'
# option ifname is filled out by the wifi-iface

  # add eth0 as hardif to bat0
  config interface 'bat0_hardif_eth0'
option proto 'batadv_hardif'
option master 'bat0'
option ifname 'eth0'
option mtu '1536'

  # configure IP on bat0
  config interface 'bat0_lan'
option ifname 'bat0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

Signed-off-by: Sven Eckelmann 
---
Cc: Matthias Schiffer 
Cc: openwrt-devel@lists.openwrt.org
Cc: Gui Iribarren 
Cc: Moritz Warning 

Changes depend on https://github.com/openwrt-routing/packages/pull/451
---
 batman-adv/Makefile   |   2 +-
 batman-adv/files/etc/config/batman-adv|  20 
 .../files/etc/hotplug.d/net/99-batman-adv |  12 --
 .../etc/uci-defaults/99-migrate-batadv_hardif |  97 +++
 batman-adv/files/lib/batman-adv/config.sh |  69 ---
 batman-adv/files/lib/netifd/proto/batadv.sh   | 112 +++---
 .../files/lib/netifd/proto/batadv_hardif.sh   |  40 +++
 7 files changed, 235 insertions(+), 117 deletions(-)
 delete mode 100644 batman-adv/files/etc/config/batman-adv
 delete mode 100644 batman-adv/files/etc/hotplug.d/net/99-batman-adv
 create mode 100755 batman-adv/files/etc/uci-defaults/99-migrate-batadv_hardif
 delete mode 100644 batman-adv/files/lib/batman-adv/config.sh
 create mode 100755 batman-adv/files/lib/netifd/proto/batadv_hardif.sh

diff --git a/batman-adv/Makefile b/batman-adv/Makefile
index 82af6c7..b250888 100644
--- a/batman-adv/Makefile
+++ b/batman-adv/Makefile
@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk
 PKG_NAME:=batman-adv
 
 PKG_VERSION:=2019.0
-PKG_RELEASE:=2
+PKG_RELEASE:=3
 PKG_HASH:=3e97d8a771cdbd7b2df42c52b88e071eaa58b5d28eb4e17a4b13b6698debbdc0
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
diff --git a/batman-adv/files/etc/config/batman-adv 
b/batman-adv/files/etc/config/batman-adv
deleted file mode 100644
index 21138cb..000
--- a/batman-adv/files/etc/config/batman-adv
+++ /dev/null
@@ -1,20 +0,0 @@
-
-config 'mesh' 'bat0'
-   #option 'aggregated_ogms' 1
-   #option 'ap_isolation' 0
-   #option 'bonding' 0
-   #option 'fragmentation' 1
-   #option 'gw_bandwidth' '1/2000'
-   #option 'gw_mode' 'off'
-   #option 'gw_sel_class' 20
-   #option 'log_level' 0
-   #option 'orig_interval' 1000
-   #option 'bridge_loop_avoidance' 1
-   #opt

Re: [OpenWrt-Devel] 5GHz wifi is broken

2019-02-18 Thread Sven Eckelmann 
On Saturday, 16 February 2019 22:36:18 CET Christian Lamparter wrote:
> @Ben can you please take a peek into your wave-1 firmware and check if the 
> mgmt_rate WMI (WMI_10X_VDEV_PARAM_MGMT_RATE) is supported, or if there is
> a bad interaction somewhere else?

I am using the same driver and ath10k-firmware-qca988x-ct on an OM5P-ACv2 with 
reboot-9393-gd0b45962ef. It seems to  work here for me with following 
configuration:

config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'pci:00/:00:00.0'
option htmode 'VHT80'
option disabled '0'

config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'psk'
option key 'supersecret'

config wifi-iface 'default_radio2'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt5'
option encryption 'psk'
option key 'supersecret2'

config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/qca955x_wmac'
option htmode 'HT20'
option disabled '1'

config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'

So it should work in theory. I personally (and some Freifunk Communities) need 
it more for 2.4GHz PHYs (Dakota). But also playing around with the rates for 
the QCA988X PHY (radio0) seems to work for me:

list supported_rates '24000'
list supported_rates '48000'
list supported_rates '54000'
list basic_rate '24000'
list basic_rate '54000'

and the management rates (captured by a second device) are 24MBit/s.

So I would guess that it is something very specific (yeah, I know step 6 of 
"six stages of debugging": How did that ever work?). Having some way to 
reproduce it could be helpful - just do as Ben said to better understand the 
problem.

And we have a different user which also complained about something like this 
on Tp-Link Archer C60 V2 - but both radios were not working anymore. If this 
is true and related the it doesn't sound to me like this is strictly a 
ath10k(-ct) problem - one of the radios is ath9k. But who knows.

@Ben, the patch (or actually the whole series) is basically the upstream way 
to change the rate for management/broadcast/multicast frames. It is not using 
debugfs to communicate with the driver but just the events from mac80211. So 
it is less flexible in what you can do but works automatically. The broadcast 
multicast parts are in the kernel (and OpenWrt) for a while and these two 
patches just add the missing management rates part. They just wait for an 
BSS_CHANGED_BASIC_RATES event in ath10k_bss_info_changed and find the lowest 
basic rate + set this as management rate. Similar behavior to what ath9k & co 
are doing automatically with minstrel(_ht).

The implementation is a best effort implementation - if it fails to set the 
rate via WMI then it will print a warning and continue. I personally don't 
like how the control flow works in this patch. It just returns from 
ath10k_bss_info_changed even when some other parts (not yet existing in the 
current code) still might have to be run. But this is just how it was 
implemented and how Kalle Valo accepted it.

But the WMI part of the ath10k firmware (called by your debugfs interface and 
this upstream patch) is the same.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OM2P ImageBuilder

2019-02-14 Thread Sven Eckelmann 
On Thursday, 14 February 2019 13:07:42 CET Conca Ten wrote:
[...]
> regarding your exchange at 
> [OpenWrt-Devel] ar71xx: OM2P ImageBuilder no firmware when BIN_DIR used
> 
> I've tried to use https://chef.aparcar.org  to 
> generate a flashable firmware with added packages for Netgear WNDR3700v4 and 
> encountered the same problem.

Please install the fix from https://github.com/openwrt/openwrt/pull/1815 and 
then create the image again.

> Is there an easy way to combine the created/resulting files to a flashable 
> systemupgrade.tar?
> The resulting files available:
> openwrt-18.06.2-b94158c9fb50ef9-ar71xx-nand-device-wndr3700v4.manifest
> openwrt-18.06.2-b94158c9fb50ef9-ar71xx-nand-root.squashfs
> openwrt-18.06.2-b94158c9fb50ef9-ar71xx-nand-uImage-lzma.bin
> openwrt-18.06.2-b94158c9fb50ef9-ar71xx-nand-vmlinux-lzma.elf
> openwrt-18.06.2-b94158c9fb50ef9-ar71xx-nand-vmlinux.bin
> openwrt-18.06.2-b94158c9fb50ef9-ar71xx-nand-vmlinux.elf
> openwrt-18.06.2-b94158c9fb50ef9-ar71xx-nand-vmlinux.lzma
> sha256sums

Nothing which I would recommend. But the instructions can be found in 
target/linux/ar71xx/image/legacy.mk [1]. But it is most likely a lot
easier to fix the imagebuilder.

Kind regards,
Sven

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/image/legacy.mk;h=363e0956c79968d14f1fbd31a502a9b940db1648;hb=880f8e6d32871ade7d2bb2ec541eea113183e9a9#l1019


signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx: OM2P ImageBuilder no firmware when BIN_DIR used

2019-02-11 Thread Sven Eckelmann 
On Friday, 1 February 2019 13:03:42 CET Paul Spooren wrote:
> Hi all,
> 
> thanks to this[0] bug report I found that the ar71xx/generic
> ImageBuilder doesn't create any firmware images for profile OM2P when
> used with BIN_DIR.
> 
> My first guess is that it's somewhat related to a hard coded destination
> which doesn't handle BIN_DIR. At the very end of an "successful" build log:
> 
> > if [ -e 
> > "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-factory.bin"
> >  ]; then cp 
> > "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-factory.bin"
> >  
> > "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-sysupgrade.bin";
> >  fi

Ehrm, no. These things are not hardcoded but your make just filled the 
placeholders before it prints it and sends it to your $SHELL.

The legacy build script is basically calling this helper:

define Image/Build/OpenMesh
-sh $(TOPDIR)/scripts/om-fwupgradecfg-gen.sh \
"$(4)" \
"$(BUILD_DIR)/fwupgrade.cfg-$(4)" \
"$(KDIR_TMP)/vmlinux-$(2).uImage" \
"$(KDIR)/root.$(1)"
-sh $(TOPDIR)/scripts/combined-ext-image.sh \
"$(4)" "$(call factoryname,$(1),$(2))" \
"$(BUILD_DIR)/fwupgrade.cfg-$(4)" "fwupgrade.cfg" \
"$(KDIR_TMP)/vmlinux-$(2).uImage" "kernel" \
"$(KDIR)/root.$(1)" "rootfs"
if [ -e "$(call factoryname,$(1),$(2))" ]; then \
cp "$(call factoryname,$(1),$(2))" "$(call 
sysupname,$(1),$(2))"; \
fi
endef

The output files are defined using:

define sysupname
$(call imgname,$(1),$(2))-sysupgrade.bin
endef

define factoryname
$(call imgname,$(1),$(2))-factory.bin
endef


And the imgname is:

define imgname
$(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(call rootfs_type,$(1))
endef


At least it looks to me like BIN_DIR is used. But yes, the second parameter to 
scripts/combined-ext-image.sh in the make output is really using something 
which is definitely not containing the user supplied BIN_DIR but the standard 
BIN_DIR from rules.mk.

If you replace the factoryname with imgname in this line (or directly 
$(BIN_DIR)), you will also see that it is not using the user supplied BIN_DIR.

You can also see this problem when you select "Linksys WRT400N" or "Zcomax 
ZCN-1523H-5-16" - which are also using factoryname/imgname. But also devices 
like "ALFA AP96"/"Atheros AP96", which are using the default "RKuImage", have 
this problem. Something tells me that all(?) legacy build scripts are 
affected. At least it works fine with ap121f from the non-legacy devices.

I would guess that this is caused by the way SingleProfile is defined and how 
it interacts with LegacyDevice (include/image-legacy.mk) vs. Device
(include/image.mk). If you look carefully, you will notice that legacy devices 
spawn a new sub-make - non-legacy devices don't do that.

You can try the attached mini-patch [1] to check whether this is your problem. 

Kind regards,
Sven

[1] https://github.com/openwrt/openwrt/pull/1815From: Sven Eckelmann 
Date: Mon, 11 Feb 2019 16:26:42 +0100
Subject: build: Accept BIN_DIR parameter for legacy-images

BIN_DIR can be set to overwrite the output path for new images. This is an
advertised feature for the imagebuilder and is used by systems like
LibreMesh's chef.

The legacy images are build using a new sub-make which doesn't receive the
variable overwrites of the parent make process. As result, the BIN_DIR is
automatically defined to the default value from rules.mk. The images will
therefore not be placed in the output path which was selected by the user.

Providing BIN_DIR as an explicit variable override to the sub-make works
around this problem.

Fixes: 26c771452cd8 ("image.mk: add LegacyDevice wrapper to allow legacy image building code to be used for device profiles")
Reported-by: Paul Spooren 
Signed-off-by: Sven Eckelmann 

diff --git a/include/image.mk b/include/image.mk
index a2b106d909831411c99a725c959c05f1df912ec9..b01cd2bf6848ebdba90f87850a9e9cbdad4233e5 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -581,7 +581,7 @@ define BuildImage
 		$(call Image/Prepare)
 
 legacy-images-prepare-make: image_prepare
-		$(MAKE) legacy-images-prepare
+		$(MAKE) legacy-images-prepare BIN_DIR="$(BIN_DIR)"

Re: [OpenWrt-Devel] ath9k: Max 3 dBi gain for FCC (365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch)

2018-11-28 Thread Sven Eckelmann 
On Dienstag, 31. Juli 2018 10:57:03 CET Sven Eckelmann wrote:
> Hi,
> 
> I've just checked the FCC "antenna reduction workaround" patch [1] in ath9k. 
> The code uses twicepower (.5 dB unit used by QCA) and uses 6 (3dBi) as 
> allowed 
> gain for FCC. The comment also states "FCC allows maximum antenna gain of 
> 3 dBi".
> 
> Where does the 3dBi come from? 15.247(b)(4) talks about 6 dBi [2]:
> 
> > (4) The conducted output power limit
> > specified in paragraph (b) of this section
> > is based on the use of antennas
> > with directional gains that do not exceed
> > 6 dBi. Except as shown in paragraph
> > (c) of this section, if transmitting
> > antennas of directional gain greater
> > than 6 dBi are used, the conducted
> > output power from the intentional radiator
> > shall be reduced below the stated
> > values in paragraphs (b)(1), (b)(2),
> > and (b)(3) of this section, as appropriate,
> > by the amount in dB that the
> > directional gain of the antenna exceeds
> > 6 dBi.
> 
> Btw. I am not sure whether all countries which use the FCC DFS rules also use 
> the same antenna gain limits. But let us assume for now that this is ok.
> 
> Kind regards,
>   Sven
> 
> 
> [1] 
> https://github.com/openwrt/openwrt/blob/81542331cb1827650f3abd69375d964d0ce2d050/package/kernel/mac80211/patches/365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch
> [2] 
> https://www.gpo.gov/fdsys/pkg/CFR-2013-title47-vol1/pdf/CFR-2013-title47-vol1-sec15-247.pdf

Ping

Kind regards,
Sven


signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

2018-08-28 Thread Sven Eckelmann 
On Dienstag, 28. August 2018 17:26:36 CEST Wang guilin wrote:
> Hi,Sven
>  I am using the QCA9886 chip for the first time. I saw the example you 
> gave.
>  I think the following code should be deleted.
>  ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin  
> /lib/firmware/ath10k/QCA9888/hw2.0/board.bin

But you also have to submit the correct BDF to Kalle Valo when it is not the 
same as the default one. Right now the board-2.bin provides:

* bus=pci,bmi-chip-id=0,bmi-board-id=16.bin created size: 12064
* bus=pci,bmi-chip-id=0,bmi-board-id=17.bin created size: 12064
* bus=pci,bmi-chip-id=0,bmi-board-id=18.bin created size: 12064
* bus=pci,bmi-chip-id=0,bmi-board-id=23.bin created size: 12064
* bus=pci,bmi-chip-id=0,bmi-board-id=24.bin created size: 12064
* bus=pci,bmi-chip-id=0,bmi-board-id=25.bin created size: 12064
* bus=pci,bmi-chip-id=0,bmi-board-id=16,variant=OM-A62.bin created size: 12064

As you can see, the OpenMesh A62 used the reference board with the 
bmi-board-id=16 but required some changes in the BDF. Thus I had to 
submit the modified bus=pci,bmi-chip-id=0,bmi-board-id=16,variant=OM-A62.bin 
to Kalle for integration in QCA9888/hw2.0/board-2.bin of 
https://github.com/kvalo/ath10k-firmware.

And then you have to tell ath10k to load the BDF with the variant=
string and not the one without it.


Of course, I don't know whether you had to change anything in the BDF or not. 
So I cannot say whether it is enough for you to just delete this symlink.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

2018-08-28 Thread Sven Eckelmann 
On Dienstag, 28. August 2018 09:38:39 CEST John Crispin wrote:
> > +gl-x1200)
> > +   ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:green:wlan2g" 
> > "phy1tpt"
> > +   ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" 
> > "phy0tpt"
> > +   ;;
> 
> this section aswell as several other places in this patch is not 
> alphabetically ordered. please fix all occurrences

And this section could also be merged together with the gl-ar750s section.

> > +   gl-x1200)
> > +   ath10kcal_extract "art" 20480 12064
> > +   ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
> > +   /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
> > +   ath10kcal_patch_mac $(macaddr_add $(cat 
> > /sys/class/net/eth0/address) +1)
> > +   ;;
[...]
> > +  DEVICE_PACKAGES := kmod-ath10k ath10k-firmware-qca9887 kmod-usb-core \
> > +   kmod-usb2 kmod-usb-storage

Is the 5GHz now a QCA9888 or a QCA9887? And why are you linking the pre-cal 
data to board.bin? QCA9888 has its BDF stored in the board-2.bin [1] (selected 
by 
the bmi from the OTP and the variant string from DT/SMBIOS) and per device 
pre-cal data is stored in /lib/firmware/ath10k/pre-cal-*.bin. The OTP is then
merging both and applying extra modifications on top of it. The result is then
automatically given to the actual QCA9888 firmware.

See for example the OpenMesh A62 for an device with an QCA9888. As you may 
notice, it is using device tree - something which ar71xx is not using. But the 
new target ath79 does.

Kind regards,
Sven

[1] https://github.com/openwrt/openwrt/pull/713#issuecomment-369511149

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

2018-08-27 Thread Sven Eckelmann 
On Montag, 27. August 2018 19:12:58 CEST wellnw wrote:
> +   },/* {
> +.desc   = "right",
> +.type   = EV_KEY,
> +.code   = BTN_0,
> +.debounce_interval  = GL_AR750S_KEYS_DEBOUNCE_INTERVAL,
> +.gpio   = GL_AR750S_GPIO_BTN_RIGHT,
> +.active_low = 1,
> +   }, */

Looks like this should also not be in this patch. Or why else would this be in 
a comment block?

> +#if 0
> +static struct i2c_gpio_platform_data gl_x1200_i2c_gpio_data = {
> +.sda_pin= GL_AR750S_GPIO_I2C_SDA,
> +.scl_pin= GL_AR750S_GPIO_I2C_SCL,
> +};
> +
> +static struct platform_device gl_x1200_i2c_gpio_device = {
> +.name   = "i2c-gpio",
> +.id = 0,
> +.dev = {
> +.platform_data  = _x1200_i2c_gpio_data,
> +   }
> +
> +};
> +#endif

Same here

> +   //platform_device_register(_ar750s_i2c_gpio_device);

And here

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200

2018-08-27 Thread Sven Eckelmann 
On Montag, 27. August 2018 19:12:58 CEST wellnw wrote:
> @@ -282,6 +283,8 @@ CONFIG_ATH79=y
>  # CONFIG_ATH79_PCI_ATH9K_FIXUP is not set
>  # CONFIG_ATH79_ROUTERBOOT is not set
>  CONFIG_ATH79_WDT=y
> +CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
>  CONFIG_CEVT_R4K=y
>  CONFIG_CLKDEV_LOOKUP=y
>  CONFIG_CLONE_BACKWARDS=y

Looks like this should not be in this patch.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ath9k: Max 3 dBi gain for FCC (365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch)

2018-07-31 Thread Sven Eckelmann 
Hi,

I've just checked the FCC "antenna reduction workaround" patch [1] in ath9k. 
The code uses twicepower (.5 dB unit used by QCA) and uses 6 (3dBi) as allowed 
gain for FCC. The comment also states "FCC allows maximum antenna gain of 
3 dBi".

Where does the 3dBi come from? 15.247(b)(4) talks about 6 dBi [2]:

> (4) The conducted output power limit
> specified in paragraph (b) of this section
> is based on the use of antennas
> with directional gains that do not exceed
> 6 dBi. Except as shown in paragraph
> (c) of this section, if transmitting
> antennas of directional gain greater
> than 6 dBi are used, the conducted
> output power from the intentional radiator
> shall be reduced below the stated
> values in paragraphs (b)(1), (b)(2),
> and (b)(3) of this section, as appropriate,
> by the amount in dB that the
> directional gain of the antenna exceeds
> 6 dBi.

Btw. I am not sure whether all countries which use the FCC DFS rules also use 
the same antenna gain limits. But let us assume for now that this is ok.

Kind regards,
Sven


[1] 
https://github.com/openwrt/openwrt/blob/81542331cb1827650f3abd69375d964d0ce2d050/package/kernel/mac80211/patches/365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch
[2] 
https://www.gpo.gov/fdsys/pkg/CFR-2013-title47-vol1/pdf/CFR-2013-title47-vol1-sec15-247.pdf

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/4] ipq40xx: fix OpenMesh A62 dtc warnings

2018-06-08 Thread Sven Eckelmann 
On Donnerstag, 7. Juni 2018 17:36:57 CEST Christian Lamparter wrote:
> Warning (pci_bridge): Node /soc/pci@4000/pcie@0 missing ranges for PCI 
> bridge (or not a bridge)
> Warning (pci_bridge): Node /soc/pci@4000/pcie@0 missing bus-range for PCI 
> bridge
> Warning (pci_bridge): Node /soc/pci@4000/pcie@0/ath10k@0,0 node name is 
> not "pci" or "pcie"
> Warning (pci_bridge): Node /soc/pci@4000/pcie@0/ath10k@0,0 missing ranges 
> for PCI bridge (or not a bridge)
> Warning (pci_bridge): Node /soc/pci@4000/pcie@0/ath10k@0,0 incorrect 
> #address-cells for PCI bridge
> Warning (pci_bridge): Node /soc/pci@4000/pcie@0/ath10k@0,0 incorrect 
> #size-cells for PCI bridge
> Warning (pci_bridge): Node /soc/pci@4000/pcie@0/ath10k@0,0 missing 
> bus-range for PCI bridge
> Warning (unit_address_format): Failed prerequisite 'pci_bridge'
> Warning (pci_device_reg): Failed prerequisite 'pci_bridge'
> Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge'
> 
> Cc: Sven Eckelmann 
> Signed-off-by: Christian Lamparter 
> ---


Tested-by: Sven Eckelmann 

Kind regards,
Sven


signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: pass hostapd control socket to mesh-mode supplicant

2018-06-04 Thread Sven Eckelmann 
On Montag, 4. Juni 2018 13:17:10 CEST Daniel Hernandez wrote:
> Hello 
> 
> Any clue if these fixes are going to make it into Openwrt / LEDE  18.06 . So 
> I can begin testing. 

They are part of openwrt-18.06-snapshot.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: pass hostapd control socket to mesh-mode supplicant

2018-04-13 Thread Sven Eckelmann 
On Freitag, 13. April 2018 01:41:31 CEST Daniel Golle wrote:
> Unlike when operating in Ad-Hoc mode, we apparently need to pass the
> hostapd control socket interface to wpa_supplicant when using 802.11s
> mesh mode.
> 
> There also seems to still be something wrong with the logic setting
> channel and (v)htmode parameters when using AP + mesh...

I haven't tested the current state but this was basically breaking encrypted 
mesh + AP (AP never came up). Problem was the code (OpenWrt specific) in 
wpa_supplicant which called STOP_AP via this socket.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] (V)HT mode selection for meshpoint (was "ath10k + ap + encryption")

2018-04-09 Thread Sven Eckelmann 
On Mittwoch, 6. Dezember 2017 22:26:09 CEST Sven Eckelmann wrote:
> On Mittwoch, 6. Dezember 2017 18:52:01 CET Daniel Hernandez wrote:
> > So  been running this mesh  patch  on  4  routers in my home for  over a 
> > month and  it  works  great !  
> > Reporting my  feedback to  see  if  it can  be  in the next  release  of  
> > LEDE  .
> 
> Felix Fietkau worked hard to get something into LEDE. I think all(?)  
> relevant 
> changes [1] are now in LEDE master (added 21 days ago). So you could try the 
> current master and send him some feedback.
...[

We have now noticed that your related change [1] will create a VHT80 mesh 
interface when you specified VHT40 in for the wifi-device. For example like 
the this configuration:

config wifi-device 'radio1'
option type 'mac80211'
option channel '44'
option disabled '0'
option beacon_int '100'
option distance '300'
option path 'platform/soc/a80.wifi'
option htmode 'VHT40'
option noscan '1'
option ldpc '0'
option hwmode '11na'
option txpower '26'

config wifi-iface 'wmesh3'
option device 'radio1'
option ifname 'mesh3'
option network 'mesh3'
option mode 'mesh'
option mesh_id 'mesh'
option disabled '0'
option mcast_rate '18000'
option mesh_ttl '1'
option mesh_fwding '0'
option region_disable '0'
option macaddr 'AE:86:74:AB:77:F5'
option encryption 'psk2'
option key 'fb719b4e5ecd1bca734c1af1b59d28c7'

The new interface then looks like:

phy#1
Interface mesh3
ifindex 8
wdev 0x10003
addr ae:86:74:ab:77:f5
type mesh point
channel 44 (5220 MHz), width: 80 MHz, center1: 5210 MHz
txpower 23.00 dBm

Problem is here that max_oper_chwidth is not parsed by 
wpa_supplicant_join_mesh and instead overwritten by it. It will therefore just 
use the highest oper mode it can use for the selected frequency. And because 
vht is also overwritten, the same will happen with HT40.

Kind regards,
Sven

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d91494eedf06ac6b31c1aa9f7172871b16af96c8

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH ipq 2/2] ipq40xx: Fix A42 eth port aliases/mac addresses

2018-03-13 Thread Sven Eckelmann 
The OpenMesh A42 uses labels next to the ethernet ports to identify the
first and second ethernet port. The first ethernet port's MAC address is
also printed prominently on the label in the center of the housing.

The board can also be powered up only using POE. It is therefore likely
that the ethernet cable to the internet is attached to the first ethernet
port which is also the active POE port. For a firmware without automatic
internet detection (like OpenWrt), it is therefore logical to use this port
as the default WAN port.

The configuration for each port are:

first ethernet port:

* phy_mdio_addr: 4
* QCA8072 port bit: BIT(5)
* u-boot mac address entry: ethaddr
* active POE

second ethernet port:

* phy_mdio_addr: 3
* QCA8072 port bit: BIT(4)
* u-boot mac address entry: eth1addr

As Mark Rutland pointed out [1], user-accessible ports with well defined
labels should be mapped accordingly with the aliases. This is mostly done
already by qcom-ipq4019.dtsi which maps ethernet0 to  and 
Only the gmac0 and gmac1 entries have to be adjusted accordingly to use the
correct configurations for the ports.

Not configuring the gmac entries as shown above, doesn't only affect the
names of the virtual interface names but also swaps the mac addresses of
the ports. The first ethernet port will then no longer use the mac address
which is printed on the device.

[1] https://patchwork.kernel.org/patch/9133903/

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
I was informed that the patch
<https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commit;h=9a6d5bd049568e175d45415f51b3cf569ebd7479>
was not actually from Christian Lamparter. His original patch
<https://github.com/chunkeey/LEDE-IPQ40XX/commit/847c09d2b53684180297bdb056bda08f1cf8>
didn't contain the gmac0 <-> gmac1 swap. So I have to apologize to him for
wasting his time while trying to discuss changes which he actually didn't
do.

Btw. I don't have a good picture at the moment but you can check some photo
from heise to see some of the labels
<https://www.heise.de/ct/zcontent/18/03-hocmsmeta/1517536820829720/contentimages/image-1516109563177267.jpg>
---
 target/linux/ipq40xx/base-files/etc/board.d/02_network| 2 +-
 .../ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4018-a42.dts | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network 
b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index 8e9a1889d1..d25a039f2d 100755
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -33,7 +33,7 @@ glinet,gl-b1300)
"0u@eth0" "3:lan" "4:lan"
;;
 openmesh,a42)
-   ucidef_set_interfaces_lan_wan "eth0" "eth1"
+   ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
 
 meraki,mr33)
diff --git 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4018-a42.dts 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4018-a42.dts
index 3d56a6ef52..fcc22276ba 100644
--- a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4018-a42.dts
+++ b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4018-a42.dts
@@ -210,6 +210,14 @@
 };
 
  {
+   qcom,phy_mdio_addr = <4>;
+   qcom,poll_required = <1>;
+   qcom,forced_speed = <1000>;
+   qcom,forced_duplex = <1>;
+   vlan_tag = <2 0x20>;
+};
+
+ {
qcom,phy_mdio_addr = <3>;
qcom,poll_required = <1>;
qcom,forced_speed = <1000>;
-- 
2.11.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH ipq 1/2] ipq40xx: Use exact SoC name in A42 DTS name

2018-03-13 Thread Sven Eckelmann 
The naming scheme of ipq40xx DTS files was adjusted with the switch to the
new IPQ40xx target. This was not done correctly for the OpenMesh A42 which
is actually an IPQ4018 and not an IPQ4019.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 .../arch/arm/boot/dts/{qcom-ipq4019-a42.dts => qcom-ipq4018-a42.dts}| 0
 target/linux/ipq40xx/image/Makefile | 2 +-
 target/linux/ipq40xx/patches-4.14/069-arm-boot-add-dts-files.patch  | 2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/{qcom-ipq4019-a42.dts 
=> qcom-ipq4018-a42.dts} (100%)

diff --git 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-a42.dts 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4018-a42.dts
similarity index 100%
rename from 
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-a42.dts
rename to target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4018-a42.dts
diff --git a/target/linux/ipq40xx/image/Makefile 
b/target/linux/ipq40xx/image/Makefile
index 0c4b971eeb..1abbb404d7 100644
--- a/target/linux/ipq40xx/image/Makefile
+++ b/target/linux/ipq40xx/image/Makefile
@@ -90,7 +90,7 @@ TARGET_DEVICES += meraki_mr33
 
 define Device/openmesh_a42
$(call Device/FitImageLzma)
-   DEVICE_DTS := qcom-ipq4019-a42
+   DEVICE_DTS := qcom-ipq4018-a42
BLOCKSIZE := 64k
SUPPORTED_DEVICES := openmesh,a42
DEVICE_TITLE := OpenMesh A42
diff --git a/target/linux/ipq40xx/patches-4.14/069-arm-boot-add-dts-files.patch 
b/target/linux/ipq40xx/patches-4.14/069-arm-boot-add-dts-files.patch
index 8f0f473e30..b472c122d0 100644
--- a/target/linux/ipq40xx/patches-4.14/069-arm-boot-add-dts-files.patch
+++ b/target/linux/ipq40xx/patches-4.14/069-arm-boot-add-dts-files.patch
@@ -14,8 +14,8 @@ Signed-off-by: John Crispin <j...@phrozen.org>
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
++  qcom-ipq4018-a42.dtb \
 +  qcom-ipq4018-rt-ac58u.dtb \
-+  qcom-ipq4019-a42.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
 +  qcom-ipq4019-ap.dk04.1-c1.dtb \
 +  qcom-ipq4019-fritz4040.dtb \
-- 
2.11.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH ipq 0/2] ipq40xx: OpenMesh A42 adjustments

2018-03-13 Thread Sven Eckelmann 
Hi,

I was informed by Christian Lamparter that the ipq806x will be modified
and a new target ipq40xx will be created [1]. During this process, the
files were cleaned up (good thing) and some things were swapped (not so
good).

I have created these two patches to inform the authors of the
ipq40xx-split. They were also uploaded to github.

Kind regards,
Sven

[1] 
https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=shortlog;h=refs/heads/ipq
[2] https://github.com/ecsv/openwrt/tree/ipq-rebuttal

Sven Eckelmann (2):
  ipq40xx: Use exact SoC name in A42 DTS name
  ipq40xx: Fix A42 eth port aliases/mac addresses

 target/linux/ipq40xx/base-files/etc/board.d/02_network| 2 +-
 .../arm/boot/dts/{qcom-ipq4019-a42.dts => qcom-ipq4018-a42.dts}   | 8 
 target/linux/ipq40xx/image/Makefile   | 2 +-
 .../linux/ipq40xx/patches-4.14/069-arm-boot-add-dts-files.patch   | 2 +-
 4 files changed, 11 insertions(+), 3 deletions(-)
 rename target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/{qcom-ipq4019-a42.dts 
=> qcom-ipq4018-a42.dts} (96%)

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

Re: [OpenWrt-Devel] Reducing the root file system in openwrt

2018-03-07 Thread Sven Eckelmann 
On Mittwoch, 7. März 2018 17:30:31 CET Arjav Parikh wrote:
[...]
> I tried to remove those files by removing its entry from
> root-ipq806x/usr/lib/opkg/info/wigig-firmware.list assuming that on
> next build these files wont appear but still the files are there in
> /lib/firmware directory.

Is this a new package? Newer heard about wigig-firmware. Maybe this isn't 
actually OpenWrt from openwrt.org. But when it is, then you should not modify 
the generated root directory but just go into `make menuconfig` and deselect 
the wigig-firmware entry.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT

2018-02-09 Thread Sven Eckelmann 
On Freitag, 9. Februar 2018 09:05:02 CET Sven Eckelmann wrote:
[...]
> > In OpenWRT 15.01 we are building 7.3MB large images and have just
> > enought space for configs.
> > In LEDE 17.01 is max size ~6.5MB and we are not able to build our
> > images, because we cannot strip more packages, now we are on 6.8MB.
> 
> Why do you think that you are now using only 6.8MB? The fw_max_len for 8Mlzma 
> devices is 8126464 bytes in mktplinkfw.c. So your final image would be 
> 8376020 
> bytes large and thus it is rejected by mktplinkfw.
[...]

Btw. the image sizes in mktplinkfw also include the reserved space of 
262144 bytes. See the option -X in Build/mktplinkfw [1]. My use of the term 
"final image" might therefore be a little bit misleading - it is just the size 
which mktplinkfw calculates including the reserved space. But this hasn't 
changed since Chaos Calmer [2].

And I just saw that Matthias Schiffer also integrated his ar71xx target in 
OpenWrt. So you might want to check his patch [3] to get a little bit inspired.

Kind regards,
Sven

[1] 
https://github.com/openwrt/openwrt/blob/9a08c104e2f2418f580f4ef218d890ea768f7a23/target/linux/ar71xx/image/common-tp-link.mk#L32
[2] 
https://github.com/openwrt/chaos_calmer/blob/2adad7714eebf89db7471bfd8d014b36c1e56b22/target/linux/ar71xx/image/Makefile#L59
[3] 
https://github.com/openwrt/openwrt/commit/0cd5e85e7ad621223b0787e66d8ad20fb2694135

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT

2018-02-09 Thread Sven Eckelmann 
On Freitag, 9. Februar 2018 01:36:49 CET Jakub Jančo wrote:
> Hello,
> 
> is there any reason why LEDE needs more empty space in firmware for
> TP-link tl-wr1043nd v3 ?

OpenWrt master should show you the exact same error message. OpenWrt 15.05 is 
quite outdated.

> In OpenWRT 15.01 we are building 7.3MB large images and have just
> enought space for configs.
> In LEDE 17.01 is max size ~6.5MB and we are not able to build our
> images, because we cannot strip more packages, now we are on 6.8MB.

Why do you think that you are now using only 6.8MB? The fw_max_len for 8Mlzma 
devices is 8126464 bytes in mktplinkfw.c. So your final image would be 8376020 
bytes large and thus it is rejected by mktplinkfw. The dd before that is from 
something else (the append-rootfs when I am not mistaken).

You might now need to start to remove more things (stuff which cannot be 
configured but has to be patched) - for example remove unused mach files from 
the kernel build, remove unused drivers from the kernel, remove unused symbols 
from large libraries (+ elf sections per function/data + elf section garbage 
collection during the link), get rid of things which you don't actually use 
(opkg?), ...

ar71xx-tiny from from gluon [1] could maybe also give you some inspiration.

Kind regards,
Sven

[1] https://github.com/freifunk-gluon/gluon
(for example grep for no_opkg)

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] IPQ8064: Remove GMAC/Ethernet Support

2018-01-30 Thread Sven Eckelmann 
On Dienstag, 30. Januar 2018 14:08:28 CET Arjav Parikh wrote:
> Hi Team,
> 
> I am working on Qualcomm IPQ8064 SOC for one of my project and I want
> to remove the Ethernet and GMAC support from Linux as I am not using
> Ethernet PHY in my project.
> 
> The purpose for removing the support from kernel is because on random
> basis my board gets crash during Linux Boot Up and everytime the crash
> point comes when it tries to unload ath_hal driver under NSS GMAC. To
> confirm my doubt I checked this image in another board having IPQ8064
> with Ethernet PHY and the same image is working.
>
> qca_nss_drv: Unknown symbol nss_gmac_receive (err 0)
[...]

ath_hal driver? qca_nss_drv? This doesn't sound like OpenWrt. Please ask QCA 
first to upstream their stuff to Linux+OpenWrt - otherwise OpenWrt will not 
have the the components which create problems for you - and thus cannot help 
you. :)

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/8] caldata-utils: new package to manipulate ath10k

2017-03-08 Thread Sven Eckelmann 
On Donnerstag, 31. März 2016 19:48:20 CET Adrian Panella wrote:
> >From df9a676bb3ba225f0fd6621dbaeec945baf3153d Mon Sep 17 00:00:00 2001
> From: Adrian Panella 
> Date: Wed, 30 Mar 2016 23:31:06 -0600
> Subject: [PATCH 12/15] caldata-utils: new package to manipulate ath10k
>   calibration data
> 
> Signed-off-by: Adrian Panella 
> ---
>   package/utils/caldata-utils/Makefile  |  60 +
>   package/utils/caldata-utils/src/Makefile  |   8 ++
>   package/utils/caldata-utils/src/caldata.c | 213 
> ++
>   package/utils/caldata-utils/src/caldata.h |  42 ++
>   package/utils/caldata-utils/src/utils.c   |  72 ++
>   5 files changed, 395 insertions(+)
>   create mode 100644 package/utils/caldata-utils/Makefile
>   create mode 100644 package/utils/caldata-utils/src/Makefile
>   create mode 100644 package/utils/caldata-utils/src/caldata.c
>   create mode 100644 package/utils/caldata-utils/src/caldata.h
>   create mode 100644 package/utils/caldata-utils/src/utils.c

I know that the patch submitted here is in a broken state. But was there any
decision made what will be done about this problem in general?

This will become a problem again on IPQ4019 when somebody must patch the mac 
address in the pre-cal data. The OTP firmware binary of ath10k will simply 
reject its content when the checksum in the pre-cal data is incorrect.

This reject will happen when the PARAM_FLASH_SECTION_ALL parameter is sent to 
the OTP [1] (step 4). Instead it will then use the boarddata from board-2.bin 
which was send to the device in step 3. It is then missing most calibration 
data which is specific to this single board.

Kind regards,
Sven

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d9195ea19e4854d7daa11688b01905e244aead9

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices

2016-11-11 Thread Sven Eckelmann 
From: Jaylin Yu <jaylin...@open-mesh.com>

OpenMesh devices have often LEDs which are not yet used by OpenWrt. These
should still be available as disabled LEDs in the system configuration for
easier modification.

Signed-off-by: Jaylin Yu <jaylin...@open-mesh.com>
[sven.eckelm...@open-mesh.com: Remove LEDs already specified via diag.sh,
 add wifi/status LEDs]
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds | 27 ++
 1 file changed, 27 insertions(+)

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index d11369c..ec27e5b 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -328,6 +328,16 @@ mr18)
 
 mr600)
ucidef_set_led_wlan "wlan58" "WLAN58" "mr600:green:wlan58" "phy0tpt"
+   ucidef_set_led_default "wps" "WPS" "mr600:blue:wps" "0"
+   ;;
+
+mr600v2)
+   ucidef_set_led_default "wlan24-red" "WLAN 2.4GHz (red)" 
"mr600:red:wlan24" "0"
+   ucidef_set_led_default "wlan24-yellow" "WLAN 2.4GHz (yellow)" 
"mr600:yellow:wlan24" "0"
+   ucidef_set_led_wlan "wlan24-green" "WLAN 4GHz (green)" 
"mr600:green:wlan24" "phy1tpt"
+   ucidef_set_led_default "wlan5-red" "WLAN 5GHz (red)" "mr600:red:wlan58" 
"0"
+   ucidef_set_led_default "wlan5-yellow" "WLAN 5GHz (yellow)" 
"mr600:yellow:wlan58" "0"
+   ucidef_set_led_wlan "wlan5-green" "WLAN 5GHz (green)" 
"mr600:green:wlan58" "phy0tpt"
;;
 
 mr1750 | \
@@ -335,6 +345,8 @@ mr1750v2)
ucidef_set_led_netdev "lan" "LAN" "mr1750:blue:wan" "eth0"
ucidef_set_led_wlan "wlan58" "WLAN58" "mr1750:blue:wlan58" "phy0tpt"
ucidef_set_led_wlan "wlan24" "WLAN24" "mr1750:blue:wlan24" "phy1tpt"
+   ucidef_set_led_default "status-red" "Status (red)" "mr900:red:wifi" "0"
+   ucidef_set_led_default "status-green" "Status (green)" 
"mr900:green:wifi" "0"
;;
 
 mr900 | \
@@ -396,17 +408,32 @@ om2p-hsv3 | \
 om2p-lc)
ucidef_set_led_netdev "port1" "port1" "om2p:blue:wan" "eth0"
ucidef_set_led_netdev "port2" "port2" "om2p:blue:lan" "eth1"
+   ucidef_set_led_default "wlan-red" "WLAN (red)" "om2p:red:wifi" "0"
+   ucidef_set_led_default "wlan-yellow" "WLAN (yellow)" "om2p:yellow:wifi" 
"0"
+   ucidef_set_led_default "wlan-green" "WLAN (green)" "om2p:green:wifi" "0"
;;
 
 om5p | \
 om5p-an)
ucidef_set_led_netdev "port1" "port1" "om5p:blue:wan" "eth0"
ucidef_set_led_netdev "port2" "port2" "om5p:blue:lan" "eth1"
+   ucidef_set_led_default "wlan-red" "WLAN (red)" "om5p:red:wifi" "0"
+   ucidef_set_led_default "wlan-yellow" "WLAN (yellow)" "om5p:yellow:wifi" 
"0"
+   ucidef_set_led_default "wlan-green" "WLAN (green)" "om5p:green:wifi" "0"
;;
 
 om5p-ac)
ucidef_set_led_netdev "port1" "port1" "om5pac:blue:lan" "eth0"
ucidef_set_led_netdev "port2" "port2" "om5pac:blue:wan" "eth1"
+   ucidef_set_led_default "wlan-red" "WLAN (red)" "om5pac:red:wifi" "0"
+   ucidef_set_led_default "wlan-yellow" "WLAN (yellow)" 
"om5pac:yellow:wifi" "0"
+   ucidef_set_led_default "wlan-green" "WLAN (green)" "om5pac:green:wifi" 
"0"
+   ;;
+
+om5p-acv2)
+   ucidef_set_led_default "wlan-red" "WLAN (red)" "om5pac:red:wifi" "0"
+   ucidef_set_led_default "wlan-yellow" "WLAN (yellow)" 
"om5pac:yellow:wifi" "0"
+   ucidef_set_led_default "wlan-green" "WLAN (green)" "om5pac:green:wifi" 
"0"
;;
 
 omy-g1)
-- 
2.10.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] LED uci policy for not actively used LEDs

2016-11-10 Thread Sven Eckelmann 
Hi,

how should non-actively used LEDs be handled in regards of entries in uci 
system.*. I saw some entries in target/linux/ar71xx/base-files/etc/board.d/
01_leds with calls to ucidef_set_led_default with the default parameter set to 
0. But not all LEDs have an entry in either 01_leds or diag.sh - not even with 
a default setting.

I am now assuming (just for this argument) that the mentioned LEDs with an 
explicit "default" value of 0 would be set to off anyway. Thus this entry 
would only create an entry in /etc/config/system like 

config led 'led_wlan_red'
option name 'WLAN LED (red)'
option sysfs 'om2p:red:wifi'
option default '0'

My question is now whether having an entry of controllable LEDs of a system in 
/etc/config/system is preferred or not.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] base-files: Prefer busybox arp over /proc/net/arp alias

2016-11-10 Thread Sven Eckelmann 
From: Marek Lindner <marek.lind...@open-mesh.com>

A firmware compiled with BUSYBOX_CONFIG_ARP should also use by default the
arp binary from busybox. Otherwise the extra functionality the user
requested can only be used when running arp with the path to the binary.

Signed-off-by: Marek Lindner <marek.lind...@open-mesh.com
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 package/base-files/files/etc/profile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/etc/profile 
b/package/base-files/files/etc/profile
index f241ab2..0118e25 100644
--- a/package/base-files/files/etc/profile
+++ b/package/base-files/files/etc/profile
@@ -20,7 +20,7 @@ alias ll='ls -alF --color=auto'
 
 [ -z "$KSH_VERSION" -o \! -s /etc/mkshrc ] || . /etc/mkshrc
 
-[ -x /usr/bin/arp ] || arp() { cat /proc/net/arp; }
+[ -x /usr/bin/arp -o -x /sbin/arp ] || arp() { cat /proc/net/arp; }
 [ -x /usr/bin/ldd ] || ldd() { LD_TRACE_LOADED_OBJECTS=1 $*; }
 
 [ -n "$FAILSAFE" ] || {
-- 
2.10.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?

2016-09-19 Thread Sven Eckelmann 
On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote:
[...]
> > We're testing encrypted AP + Mesh quite successfully right now with
> > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> > Which chip are you using? I can poke the firmware guys for possibility
> > of getting a 10.4.3.2 firmware build for it.
> 
> Hi Thomas,
> 
> thanks for the hint! We are using an older QCA9882. I assume your firmware
> will not work for this one? If you can poke the firmware guys, that would
> be great.
> :)
> 
> We also want to test the 70.52 firmware version next, maybe there were some
> changes since the .42 we used.

I have just checked it with 10.2.4.70.54:

   | 802.11s encrypted | 802.11s unencrypted
---+---+
AP encrypted   | AP doesn't beacon | works
AP unencrypted | AP doesn't beacon | works

I've also checked 10.2.4.70.12-2 (doesn't seem to support encrypted mesh at 
all) and with rawmode=1 (makes no difference).

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC v2 6/6] ar71xx: Reset QCA955x SGMII link on speed change

2016-06-27 Thread Sven Eckelmann 
On Tuesday 05 April 2016 15:32:13 Sven Eckelmann wrote:
> From: Sven Eckelmann <sven.eckelm...@open-mesh.com>
>
> The SGMII link of the QCA955x seems to be unstable when the PHY changes the
> link speed. Reseting the SGMII and the PHY management control seems to
> resolve this problem.
>
> This was observed with an AR8033 and QCA9558
>
> Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
> ---
> v2:
>  - Split into multiple patches and adjust slightly to look more like an
>OpenWrt patch
>
> The code of this RFC is not meant to be an actual patch. It should show
> what the u-boot for QCA955x does and what seemed to work(tm) in my limited
> tests. It would be interesting to know whether this was also noticed by
> other people and how they fixed it (when they fixed it).

Just because asked if this is also required for the RGMII - short answer:
yes, it is.

Slightly longer answer: Yes, the link seems to desync(?) too when RGMII
changes the link speed. Unfortunately, there is also no real fix and the
workaround is even more terrible. The basic idea behind it is that the PHY has
to be changed into its digital loopback mode on each link change. And then the
SoC has to transfer some ethernet frames to the PHY and check if it receives
these packets again. If not, then it has to toggle the TX_INVERT bit of
ETH_CFG and retest. If it still doesn't work then the only solution for the
SoC is to jump out of the window (this part is not yet implemented).

I have just implemented a PoC in case somebody wants to play around with it.
Not that I would recommend that to anyone.

Kind regards,
SvenFrom: Sven Eckelmann <s...@narfation.org>
Date: Tue, 26 Apr 2016 16:14:47 +0200
Subject: [RFC 7/6] ag71xx: Test link on QCA955x for PHY connectivity problems

The link between MAC and PHY on a QCA955x tends to break down after carrier
changes. This can be worked around by setting the PHY (AR803x only
supported) into digital loopback mode and then sending packets via this
link. If no data is returned then the TX_INVERT bit has to be toggled to
get the link working again.

No information was received from QCA what actually is broken.
---
 .../linux/ar71xx/files/arch/mips/ath79/dev-eth.c   |  44 +++-
 .../ar71xx/files/arch/mips/ath79/mach-mr1750.c |   1 +
 .../ar71xx/files/arch/mips/ath79/mach-om5pac.c |   2 +
 .../ar71xx/files/arch/mips/ath79/mach-om5pacv2.c   |   2 +
 .../mips/include/asm/mach-ath79/ag71xx_platform.h  |   2 +
 .../drivers/net/ethernet/atheros/ag71xx/ag71xx.h   |  13 +
 .../net/ethernet/atheros/ag71xx/ag71xx_main.c  | 283 +
 .../net/ethernet/atheros/ag71xx/ag71xx_phy.c   |  17 +-
 .../999-dont-set-down-on-loopback.patch|  30 +++
 .../999-dont-set-down-on-loopback.patch|  30 +++
 .../999-dont-set-down-on-loopback.patch|  30 +++
 11 files changed, 451 insertions(+), 3 deletions(-)
 create mode 100644 target/linux/generic/patches-3.18/999-dont-set-down-on-loopback.patch
 create mode 100644 target/linux/generic/patches-4.1/999-dont-set-down-on-loopback.patch
 create mode 100644 target/linux/generic/patches-4.4/999-dont-set-down-on-loopback.patch

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
index b43c80a..d1d3be7 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
@@ -373,10 +373,50 @@ static void ar934x_set_speed_ge0(int speed)
 	iounmap(base);
 }

+static u32 qca955x_get_eth_pll(unsigned int mac, int speed)
+{
+	struct ag71xx_platform_data *pdata;
+	struct ath79_eth_pll_data *pll_data;
+	u32 pll_val;
+	u32 tx_invert = 0;
+
+	switch (mac) {
+	case 0:
+		pll_data = _eth0_pll_data;
+		pdata = _eth0_data;
+		break;
+	case 1:
+		pll_data = _eth1_pll_data;
+		pdata = _eth1_data;
+		break;
+	default:
+		BUG();
+	}
+
+	switch (speed) {
+	case SPEED_10:
+		pll_val = pll_data->pll_10;
+		break;
+	case SPEED_100:
+		pll_val = pll_data->pll_100;
+		break;
+	case SPEED_1000:
+		pll_val = pll_data->pll_1000;
+		break;
+	default:
+		BUG();
+	}
+
+	/* toggle TX_INVERT when required by ag71xx */
+	if (pdata->tx_invert_war && pdata->tx_invert_active)
+		tx_invert =  BIT(31);
+
+	return pll_val ^ tx_invert;
+}
 static void qca955x_set_speed_xmii(int speed)
 {
 	void __iomem *base;
-	u32 val = ath79_get_eth_pll(0, speed);
+	u32 val = qca955x_get_eth_pll(0, speed);

 	base = ioremap_nocache(AR71XX_PLL_BASE, AR71XX_PLL_SIZE);
 	__raw_writel(val, base + QCA955X_PLL_ETH_XMII_CONTROL_REG);
@@ -386,7 +426,7 @@ static void qca955x_set_speed_xmii(int speed)
 static void qca955x_set_speed_sgmii(int speed)
 {
 	void __iomem *base;
-	u32 val = ath79_get_eth_pll(1, speed);
+	u32 val = qca955x_get_eth_pll(1, speed);

 	base = ioremap_nocache(AR71XX_PLL_BASE, AR71XX_PLL_SIZE);
 	__raw_writel(val, base + QCA955X_PLL_ETH_SG

[OpenWrt-Devel] [PATCH CC 13/13] ar71xx: add MR1750v2 to the MR1750 profile

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624548/

 target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk 
b/target/linux/ar71xx/generic/profiles/openmesh.mk
index ddd3f8d..e245e6c 100644
--- a/target/linux/ar71xx/generic/profiles/openmesh.mk
+++ b/target/linux/ar71xx/generic/profiles/openmesh.mk
@@ -61,12 +61,12 @@ endef
 $(eval $(call Profile,MR900))
 
 define Profile/MR1750
-NAME:=OpenMesh MR1750
+NAME:=OpenMesh MR1750/MR1750v2
 PACKAGES:=kmod-ath9k kmod-ath10k ath10k-firmware-qca988x
 endef
 
 define Profile/MR1750/Description
-Package set optimized for the OpenMesh MR1750.
+Package set optimized for the OpenMesh MR1750/MR1750v2.
 endef
 
 $(eval $(call Profile,MR1750))
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 11/13] package/uboot-envtools: add OpenMesh MR1750v2 support

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624546/

 package/boot/uboot-envtools/files/ar71xx | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boot/uboot-envtools/files/ar71xx 
b/package/boot/uboot-envtools/files/ar71xx
index 81c6481..459e73d 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -22,6 +22,7 @@ eap300v2 | \
 hornet-ub | \
 hornet-ub-x2 | \
 mr1750 | \
+mr1750v2 | \
 mr600 | \
 mr600v2 | \
 mr900 | \
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 12/13] ar71xx: extract ath10k wifi board.bin for the OpenMesh MR1750v2 board

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624547/

 target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8fc3ab3..f01c6d3 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -72,6 +72,7 @@ case "$FIRMWARE" in
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
;;
mr1750 | \
+   mr1750v2 | \
om5p-acv2)
ath10kcal_extract "ART" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +16)
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 10/13] package/om-watchdog: add OpenMesh MR1750v2 support

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624545/

 package/kernel/om-watchdog/files/om-watchdog.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/om-watchdog/files/om-watchdog.init 
b/package/kernel/om-watchdog/files/om-watchdog.init
index bf8a124..8a1b66e 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -28,7 +28,7 @@ boot() {
"mr600v2")
service_start /sbin/om-watchdog 15
;;
-   "mr900"|"mr900v2"|"mr1750")
+   "mr900"|"mr900v2"|"mr1750"|"mr1750v2")
service_start /sbin/om-watchdog 16
;;
esac
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 09/13] ar71xx: enable sysupgrade for the OpenMesh MR1750v2

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624544/

 target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 +
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
index 0e8ea27..95d39bf 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
@@ -81,6 +81,7 @@ platform_check_image_openmesh()
;;
MR1750)
[ "$board" = "mr1750" ] && break
+   [ "$board" = "mr1750v2" ] && break
echo "Invalid image board target ($img_board_target) 
for this platform: $board. Use the correct image for this platform"
return 1
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 4fb5b34..bf53169 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -291,6 +291,7 @@ platform_check_image() {
return 0;
;;
mr1750 | \
+   mr1750v2 | \
mr600 | \
mr600v2 | \
mr900 | \
@@ -523,6 +524,7 @@ platform_do_upgrade() {
platform_do_upgrade_dir825b "$ARGV"
;;
mr1750 | \
+   mr1750v2 | \
mr600 | \
mr600v2 | \
mr900 | \
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 08/13] ar71xx: add user-space support for the OpenMesh MR1750v2

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624543/

 target/linux/ar71xx/base-files/etc/diag.sh | 3 ++-
 target/linux/ar71xx/base-files/etc/uci-defaults/01_leds| 3 ++-
 target/linux/ar71xx/base-files/etc/uci-defaults/02_network | 1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   | 3 +++
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 9a6b4cf..c5e39d0 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -143,7 +143,8 @@ get_status_led() {
mr600v2)
status_led="mr600:blue:power"
;;
-   mr1750)
+   mr1750 | \
+   mr1750v2)
status_led="mr1750:blue:power"
;;
mr900 | \
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index d297266..d7dc9a1 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -239,7 +239,8 @@ mr600)
ucidef_set_led_wlan "wlan58" "WLAN58" "mr600:green:wlan58" "phy0tpt"
;;
 
-mr1750)
+mr1750 | \
+mr1750v2)
ucidef_set_led_netdev "lan" "LAN" "mr1750:blue:wan" "eth0"
ucidef_set_led_wlan "wlan58" "WLAN58" "mr1750:blue:wlan58" "phy0tpt"
ucidef_set_led_wlan "wlan24" "WLAN24" "mr1750:blue:wlan24" "phy1tpt"
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 49e491f..b2b182e 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -335,6 +335,7 @@ eap7660d |\
 el-mini |\
 loco-m-xw |\
 mr1750 |\
+mr1750v2 |\
 mr600 |\
 mr600v2 |\
 mr900 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 230df0b..2f4b112 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -521,6 +521,9 @@ ar71xx_board_detect() {
*MR1750)
name="mr1750"
;;
+   *MR1750v2)
+   name="mr1750v2"
+   ;;
*MR600)
name="mr600"
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 07/13] ar71xx: add kernel support for the OpenMesh MR1750v2

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624542/

 target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c|  1 +
 .../patches-3.18/818-MIPS-ath79-add-mr1750v2-support.patch | 10 ++
 2 files changed, 11 insertions(+)
 create mode 100644 
target/linux/ar71xx/patches-3.18/818-MIPS-ath79-add-mr1750v2-support.patch

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
index e3c04e7..18101ce 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
@@ -168,3 +168,4 @@ static void __init mr1750_setup(void)
 }
 
 MIPS_MACHINE(ATH79_MACH_MR1750, "MR1750", "OpenMesh MR1750", mr1750_setup);
+MIPS_MACHINE(ATH79_MACH_MR1750V2, "MR1750v2", "OpenMesh MR1750v2", 
mr1750_setup);
diff --git 
a/target/linux/ar71xx/patches-3.18/818-MIPS-ath79-add-mr1750v2-support.patch 
b/target/linux/ar71xx/patches-3.18/818-MIPS-ath79-add-mr1750v2-support.patch
new file mode 100644
index 000..de732ec
--- /dev/null
+++ b/target/linux/ar71xx/patches-3.18/818-MIPS-ath79-add-mr1750v2-support.patch
@@ -0,0 +1,10 @@
+--- a/arch/mips/ath79/machtypes.h
 b/arch/mips/ath79/machtypes.h
+@@ -76,6 +76,7 @@ enum ath79_mach_type {
+   ATH79_MACH_MR12,/* Cisco Meraki MR12 */
+   ATH79_MACH_MR16,/* Cisco Meraki MR16 */
+   ATH79_MACH_MR1750,  /* OpenMesh MR1750 */
++  ATH79_MACH_MR1750V2,/* OpenMesh MR1750v2 */
+   ATH79_MACH_MR600V2, /* OpenMesh MR600v2 */
+   ATH79_MACH_MR600,   /* OpenMesh MR600 */
+   ATH79_MACH_MR900,   /* OpenMesh MR900 */
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 06/13] ar71xx: add OM2P-HSv3 to the OM2P profile

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624541/

 target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk 
b/target/linux/ar71xx/generic/profiles/openmesh.mk
index c0919ed..ddd3f8d 100644
--- a/target/linux/ar71xx/generic/profiles/openmesh.mk
+++ b/target/linux/ar71xx/generic/profiles/openmesh.mk
@@ -6,12 +6,12 @@
 #
 
 define Profile/OM2P
-   NAME:=OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-LC
+   NAME:=OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-HSv3/OM2P-LC
PACKAGES:=kmod-ath9k om-watchdog
 endef
 
 define Profile/OM2P/Description
-   Package set optimized for the OpenMesh 
OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-LC.
+   Package set optimized for the OpenMesh 
OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-HSv3/OM2P-LC.
 endef
 
 $(eval $(call Profile,OM2P))
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 05/13] package/uboot-envtools: add OpenMesh OM2P-HSv3 support

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624539/

 package/boot/uboot-envtools/files/ar71xx | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boot/uboot-envtools/files/ar71xx 
b/package/boot/uboot-envtools/files/ar71xx
index 9071c11..81c6481 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -41,6 +41,7 @@ om2p | \
 om2pv2 | \
 om2p-hs | \
 om2p-hsv2 | \
+om2p-hsv3 | \
 om2p-lc)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4" "0x4"
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 02/13] ar71xx: add user-space support for the OpenMesh OM2P-HSv3

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624537/

 target/linux/ar71xx/base-files/etc/diag.sh  | 1 +
 target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh| 3 +++
 3 files changed, 5 insertions(+)

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 631459f..9a6b4cf 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -171,6 +171,7 @@ get_status_led() {
om2pv2 | \
om2p-hs | \
om2p-hsv2 | \
+   om2p-hsv3 | \
om2p-lc)
status_led="om2p:blue:power"
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index 9a768cd..d297266 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -293,6 +293,7 @@ om2p | \
 om2pv2 | \
 om2p-hs | \
 om2p-hsv2 | \
+om2p-hsv3 | \
 om2p-lc)
ucidef_set_led_netdev "port1" "port1" "om2p:blue:wan" "eth0"
ucidef_set_led_netdev "port2" "port2" "om2p:blue:lan" "eth1"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 92ee56d..230df0b 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -563,6 +563,9 @@ ar71xx_board_detect() {
*"OM2P HSv2")
name="om2p-hsv2"
;;
+   *"OM2P HSv3")
+   name="om2p-hsv3"
+   ;;
*"OM2P LC")
name="om2p-lc"
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 03/13] ar71xx: enable sysupgrade for the OpenMesh OM2P-HSv3

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624538/

 target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 +
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
index 209cdaa..0e8ea27 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
@@ -63,6 +63,7 @@ platform_check_image_openmesh()
[ "$board" = "om2p-lc" ] && break
[ "$board" = "om2p-hs" ] && break
[ "$board" = "om2p-hsv2" ] && break
+   [ "$board" = "om2p-hsv3" ] && break
echo "Invalid image board target ($img_board_target) 
for this platform: $board. Use the correct image for this platform"
return 1
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index d3e8a79..4fb5b34 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -299,6 +299,7 @@ platform_check_image() {
om2pv2 | \
om2p-hs | \
om2p-hsv2 | \
+   om2p-hsv3 | \
om2p-lc | \
om5p | \
om5p-an | \
@@ -530,6 +531,7 @@ platform_do_upgrade() {
om2pv2 | \
om2p-hs | \
om2p-hsv2 | \
+   om2p-hsv3 | \
om2p-lc | \
om5p | \
om5p-an | \
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 04/13] package/om-watchdog: add OpenMesh OM2P-HSv3 support

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624540/

 package/kernel/om-watchdog/files/om-watchdog.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/om-watchdog/files/om-watchdog.init 
b/package/kernel/om-watchdog/files/om-watchdog.init
index 6b96966..bf8a124 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -13,7 +13,7 @@ boot() {
local board=$(ar71xx_board_name)
 
case "$board" in
-   "om2p"|"om2p-hs"|"om2p-hsv2"|"om5p-acv2")
+   "om2p"|"om2p-hs"|"om2p-hsv2"|"om2p-hsv3"|"om5p-acv2")
service_start /sbin/om-watchdog 12
;;
"om2pv2"|"om2p-lc")
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 01/13] ar71xx: add kernel support for the OpenMesh OM2P-HSv3

2016-06-17 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
Based on following CC backports from 2016-05-19:

 * https://patchwork.ozlabs.org/patch/624172/
 * https://patchwork.ozlabs.org/patch/624173/
 * https://patchwork.ozlabs.org/patch/624174/
 * https://patchwork.ozlabs.org/patch/624175/
 * https://patchwork.ozlabs.org/patch/624176/
 * https://patchwork.ozlabs.org/patch/624177/
 * https://patchwork.ozlabs.org/patch/624178/
 * https://patchwork.ozlabs.org/patch/624179/
 * https://patchwork.ozlabs.org/patch/624180/
 * https://patchwork.ozlabs.org/patch/624181/
 * https://patchwork.ozlabs.org/patch/624182/
 * https://patchwork.ozlabs.org/patch/624183/
 * https://patchwork.ozlabs.org/patch/624184/
 * https://patchwork.ozlabs.org/patch/624185/
 * https://patchwork.ozlabs.org/patch/624186/
 * https://patchwork.ozlabs.org/patch/624187/
 * https://patchwork.ozlabs.org/patch/624188/
 * https://patchwork.ozlabs.org/patch/624189/
 * https://patchwork.ozlabs.org/patch/624190/
 * https://patchwork.ozlabs.org/patch/624191/
 * https://patchwork.ozlabs.org/patch/624192/
 * https://patchwork.ozlabs.org/patch/624193/
 * https://patchwork.ozlabs.org/patch/624194/
 * https://patchwork.ozlabs.org/patch/624195/
 * https://patchwork.ozlabs.org/patch/624196/
 * https://patchwork.ozlabs.org/patch/624197/
 * https://patchwork.ozlabs.org/patch/624198/
 * https://patchwork.ozlabs.org/patch/624199/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624201/
 * https://patchwork.ozlabs.org/patch/624202/
 * https://patchwork.ozlabs.org/patch/624203/
 * https://patchwork.ozlabs.org/patch/624200/
 * https://patchwork.ozlabs.org/patch/624205/

It is a backport of the patch for trunk from 2016-05-20 which waits to be
accepted as well:

 * https://patchwork.ozlabs.org/patch/624536/

 target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c  |  1 +
 .../patches-3.18/817-MIPS-ath79-add-om2phsv3-support.patch | 10 ++
 2 files changed, 11 insertions(+)
 create mode 100644 
target/linux/ar71xx/patches-3.18/817-MIPS-ath79-add-om2phsv3-support.patch

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c
index 6b0bdc3..3b282a3 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c
@@ -223,3 +223,4 @@ static void __init om2p_hs_setup(void)
 
 MIPS_MACHINE(ATH79_MACH_OM2P_HS, "OM2P-HS", "OpenMesh OM2P HS", om2p_hs_setup);
 MIPS_MACHINE(ATH79_MACH_OM2P_HSv2, "OM2P-HSv2", "OpenMesh OM2P HSv2", 
om2p_hs_setup);
+MIPS_MACHINE(ATH79_MACH_OM2P_HSv3, "OM2P-HSv3", "OpenMesh OM2P HSv3", 
om2p_hs_setup);
diff --git 
a/target/linux/ar71xx/patches-3.18/817-MIPS-ath79-add-om2phsv3-support.patch 
b/target/linux/ar71xx/patches-3.18/817-MIPS-ath79-add-om2phsv3-support.patch
new file mode 100644
index 000..7305b2e
--- /dev/null
+++ b/target/linux/ar71xx/patches-3.18/817-MIPS-ath79-add-om2phsv3-support.patch
@@ -0,0 +1,10 @@
+--- a/arch/mips/ath79/machtypes.h
 b/arch/mips/ath79/machtypes.h
+@@ -88,6 +88,7 @@ enum ath79_mach_type {
+   ATH79_MACH_NBG460N, /* Zyxel NBG460N/550N/550NH */
+   ATH79_MACH_NBG6716, /* Zyxel NBG6716 */
+   ATH79_MACH_OM2P_HSv2,   /* OpenMesh OM2P-HSv2 */
++  ATH79_MACH_OM2P_HSv3,   /* OpenMesh OM2P-HSv3 */
+   ATH79_MACH_OM2P_HS, /* OpenMesh OM2P-HS */
+   ATH79_MACH_OM2P_LC, /* OpenMesh OM2P-LC */
+   ATH79_MACH_OM2Pv2,  /* OpenMesh OM2Pv2 */
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 04/13] package/om-watchdog: add OpenMesh OM2P-HSv3 support

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 package/kernel/om-watchdog/files/om-watchdog.init | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/kernel/om-watchdog/files/om-watchdog.init 
b/package/kernel/om-watchdog/files/om-watchdog.init
index 79819ad..4c6ac45 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -19,6 +19,7 @@ get_gpio() {
"om2p" | \
"om2p-hs" | \
"om2p-hsv2" | \
+   "om2p-hsv3" | \
"om5p-acv2")
return 12
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 13/13] ar71xx: add MR1750v2 to the MR1750 profile

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk 
b/target/linux/ar71xx/generic/profiles/openmesh.mk
index eb972ee..15b974a 100644
--- a/target/linux/ar71xx/generic/profiles/openmesh.mk
+++ b/target/linux/ar71xx/generic/profiles/openmesh.mk
@@ -61,12 +61,12 @@ endef
 $(eval $(call Profile,MR900))
 
 define Profile/MR1750
-NAME:=OpenMesh MR1750
+NAME:=OpenMesh MR1750/MR1750v2
 PACKAGES:=kmod-ath9k kmod-ath10k
 endef
 
 define Profile/MR1750/Description
-Package set optimized for the OpenMesh MR1750.
+Package set optimized for the OpenMesh MR1750/MR1750v2.
 endef
 
 $(eval $(call Profile,MR1750))
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 12/13] ar71xx: extract ath10k wifi board.bin for the OpenMesh MR1750v2 board

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8fc3ab3..f01c6d3 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -72,6 +72,7 @@ case "$FIRMWARE" in
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
;;
mr1750 | \
+   mr1750v2 | \
om5p-acv2)
ath10kcal_extract "ART" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +16)
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 11/13] package/uboot-envtools: add OpenMesh MR1750v2 support

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 package/boot/uboot-envtools/files/ar71xx | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boot/uboot-envtools/files/ar71xx 
b/package/boot/uboot-envtools/files/ar71xx
index dc7583f..986fdef 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -25,6 +25,7 @@ eap300v2 | \
 hornet-ub | \
 hornet-ub-x2 | \
 mr1750 | \
+mr1750v2 | \
 mr600 | \
 mr600v2 | \
 mr900 | \
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 10/13] package/om-watchdog: add OpenMesh MR1750v2 support

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 package/kernel/om-watchdog/files/om-watchdog.init | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/kernel/om-watchdog/files/om-watchdog.init 
b/package/kernel/om-watchdog/files/om-watchdog.init
index 4c6ac45..4ed178d 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -39,7 +39,8 @@ get_gpio() {
;;
"mr900" | \
"mr900v2" | \
-   "mr1750")
+   "mr1750" | \
+   "mr1750v2")
return 16
;;
esac
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 09/13] ar71xx: enable sysupgrade for the OpenMesh MR1750v2

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 2e01419..2ce5331 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -313,6 +313,7 @@ platform_check_image() {
return 0;
;;
mr1750 | \
+   mr1750v2 | \
mr600 | \
mr600v2 | \
mr900 | \
@@ -572,6 +573,7 @@ platform_do_upgrade() {
platform_do_upgrade_dir825b "$ARGV"
;;
mr1750 | \
+   mr1750v2 | \
mr600 | \
mr600v2 | \
mr900 | \
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 08/13] ar71xx: add user-space support for the OpenMesh MR1750v2

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds | 3 ++-
 target/linux/ar71xx/base-files/etc/board.d/02_network  | 1 +
 target/linux/ar71xx/base-files/etc/diag.sh | 3 ++-
 target/linux/ar71xx/base-files/lib/ar71xx.sh   | 3 +++
 target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 +
 5 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e003ebaa..66a031f 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -322,7 +322,8 @@ mr600)
ucidef_set_led_wlan "wlan58" "WLAN58" "mr600:green:wlan58" "phy0tpt"
;;
 
-mr1750)
+mr1750 | \
+mr1750v2)
ucidef_set_led_netdev "lan" "LAN" "mr1750:blue:wan" "eth0"
ucidef_set_led_wlan "wlan58" "WLAN58" "mr1750:blue:wlan58" "phy0tpt"
ucidef_set_led_wlan "wlan24" "WLAN24" "mr1750:blue:wlan24" "phy1tpt"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 67adf33..6a4cdaf 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -335,6 +335,7 @@ eap7660d |\
 el-mini |\
 loco-m-xw |\
 mr1750 |\
+mr1750v2 |\
 mr18 |\
 mr600 |\
 mr600v2 |\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index ec89470..e296b56 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -176,7 +176,8 @@ get_status_led() {
mr600v2)
status_led="mr600:blue:power"
;;
-   mr1750)
+   mr1750 | \
+   mr1750v2)
status_led="mr1750:blue:power"
;;
mr900 | \
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index d00ef8e..12bc9e3 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -595,6 +595,9 @@ ar71xx_board_detect() {
*MR1750)
name="mr1750"
;;
+   *MR1750v2)
+   name="mr1750v2"
+   ;;
*MR600)
name="mr600"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
index 270ef40..87b6516 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
@@ -65,6 +65,7 @@ platform_check_image_target_openmesh()
;;
MR1750)
[ "$board" = "mr1750" ] && return 0
+   [ "$board" = "mr1750v2" ] && return 0
echo "Invalid image board target ($img_board_target) 
for this platform: $board. Use the correct image for this platform"
return 1
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 07/13] ar71xx: add kernel support for the OpenMesh MR1750v2

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c | 1 +
 target/linux/ar71xx/files/arch/mips/ath79/machtypes.h   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
index e3c04e7..18101ce 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
@@ -168,3 +168,4 @@ static void __init mr1750_setup(void)
 }
 
 MIPS_MACHINE(ATH79_MACH_MR1750, "MR1750", "OpenMesh MR1750", mr1750_setup);
+MIPS_MACHINE(ATH79_MACH_MR1750V2, "MR1750v2", "OpenMesh MR1750v2", 
mr1750_setup);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h 
b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
index e5341f1..0e88996 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
+++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
@@ -96,6 +96,7 @@ enum ath79_mach_type {
ATH79_MACH_MR16,/* Cisco Meraki MR16 */
ATH79_MACH_MR18,/* Cisco Meraki MR18 */
ATH79_MACH_MR1750,  /* OpenMesh MR1750 */
+   ATH79_MACH_MR1750V2,/* OpenMesh MR1750v2 */
ATH79_MACH_MR600V2, /* OpenMesh MR600v2 */
ATH79_MACH_MR600,   /* OpenMesh MR600 */
ATH79_MACH_MR900,   /* OpenMesh MR900 */
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 06/13] ar71xx: add OM2P-HSv3 to the OM2P profile

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk 
b/target/linux/ar71xx/generic/profiles/openmesh.mk
index 6817c59..eb972ee 100644
--- a/target/linux/ar71xx/generic/profiles/openmesh.mk
+++ b/target/linux/ar71xx/generic/profiles/openmesh.mk
@@ -6,12 +6,12 @@
 #
 
 define Profile/OM2P
-   NAME:=OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-LC
+   NAME:=OpenMesh OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-HSv3/OM2P-LC
PACKAGES:=kmod-ath9k om-watchdog
 endef
 
 define Profile/OM2P/Description
-   Package set optimized for the OpenMesh 
OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-LC.
+   Package set optimized for the OpenMesh 
OM2P/OM2Pv2/OM2P-HS/OM2P-HSv2/OM2P-HSv3/OM2P-LC.
 endef
 
 $(eval $(call Profile,OM2P))
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 05/13] package/uboot-envtools: add OpenMesh OM2P-HSv3 support

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 package/boot/uboot-envtools/files/ar71xx | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boot/uboot-envtools/files/ar71xx 
b/package/boot/uboot-envtools/files/ar71xx
index 32e7269..dc7583f 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -44,6 +44,7 @@ om2p | \
 om2pv2 | \
 om2p-hs | \
 om2p-hsv2 | \
+om2p-hsv3 | \
 om2p-lc)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4" "0x4"
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 03/13] ar71xx: enable sysupgrade for the OpenMesh OM2P-HSv3

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 +
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
index bc362a7..270ef40 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
@@ -47,6 +47,7 @@ platform_check_image_target_openmesh()
[ "$board" = "om2p-lc" ] && return 0
[ "$board" = "om2p-hs" ] && return 0
[ "$board" = "om2p-hsv2" ] && return 0
+   [ "$board" = "om2p-hsv3" ] && return 0
echo "Invalid image board target ($img_board_target) 
for this platform: $board. Use the correct image for this platform"
return 1
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 9f8a14b..2e01419 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -321,6 +321,7 @@ platform_check_image() {
om2pv2 | \
om2p-hs | \
om2p-hsv2 | \
+   om2p-hsv3 | \
om2p-lc | \
om5p | \
om5p-an | \
@@ -579,6 +580,7 @@ platform_do_upgrade() {
om2pv2 | \
om2p-hs | \
om2p-hsv2 | \
+   om2p-hsv3 | \
om2p-lc | \
om5p | \
om5p-an | \
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 02/13] ar71xx: add user-space support for the OpenMesh OM2P-HSv3

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds | 1 +
 target/linux/ar71xx/base-files/etc/diag.sh | 1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 39b21ca..e003ebaa 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ om2p | \
 om2pv2 | \
 om2p-hs | \
 om2p-hsv2 | \
+om2p-hsv3 | \
 om2p-lc)
ucidef_set_led_netdev "port1" "port1" "om2p:blue:wan" "eth0"
ucidef_set_led_netdev "port2" "port2" "om2p:blue:lan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index f95a72d..ec89470 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -207,6 +207,7 @@ get_status_led() {
om2pv2 | \
om2p-hs | \
om2p-hsv2 | \
+   om2p-hsv3 | \
om2p-lc)
status_led="om2p:blue:power"
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index d71b8ba..d00ef8e 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -640,6 +640,9 @@ ar71xx_board_detect() {
*"OM2P HSv2")
name="om2p-hsv2"
;;
+   *"OM2P HSv3")
+   name="om2p-hsv3"
+   ;;
*"OM2P LC")
name="om2p-lc"
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 01/13] ar71xx: add kernel support for the OpenMesh OM2P-HSv3

2016-05-20 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c | 1 +
 target/linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c
index 6b0bdc3..3b282a3 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om2p.c
@@ -223,3 +223,4 @@ static void __init om2p_hs_setup(void)
 
 MIPS_MACHINE(ATH79_MACH_OM2P_HS, "OM2P-HS", "OpenMesh OM2P HS", om2p_hs_setup);
 MIPS_MACHINE(ATH79_MACH_OM2P_HSv2, "OM2P-HSv2", "OpenMesh OM2P HSv2", 
om2p_hs_setup);
+MIPS_MACHINE(ATH79_MACH_OM2P_HSv3, "OM2P-HSv3", "OpenMesh OM2P HSv3", 
om2p_hs_setup);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h 
b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
index 4879255..e5341f1 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
+++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
@@ -109,6 +109,7 @@ enum ath79_mach_type {
ATH79_MACH_NBG6616, /* Zyxel NBG6616 */
ATH79_MACH_NBG6716, /* Zyxel NBG6716 */
ATH79_MACH_OM2P_HSv2,   /* OpenMesh OM2P-HSv2 */
+   ATH79_MACH_OM2P_HSv3,   /* OpenMesh OM2P-HSv3 */
ATH79_MACH_OM2P_HS, /* OpenMesh OM2P-HS */
ATH79_MACH_OM2P_LC, /* OpenMesh OM2P-LC */
ATH79_MACH_OM2Pv2,  /* OpenMesh OM2Pv2 */
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 34/34] ar71xx: add OM5P-ACv2 to the OM5P-AC profile

2016-05-19 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>

Backport of r49155
---
 target/linux/ar71xx/generic/profiles/openmesh.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk 
b/target/linux/ar71xx/generic/profiles/openmesh.mk
index 64aaa24..c0919ed 100644
--- a/target/linux/ar71xx/generic/profiles/openmesh.mk
+++ b/target/linux/ar71xx/generic/profiles/openmesh.mk
@@ -28,12 +28,12 @@ endef
 $(eval $(call Profile,OM5P))
 
 define Profile/OM5PAC
-   NAME:=OpenMesh OM5P-AC
+   NAME:=OpenMesh OM5P-AC/OM5P-ACv2
PACKAGES:=kmod-ath9k kmod-ath10k om-watchdog ath10k-firmware-qca988x
 endef
 
 define Profile/OM5PAC/Description
-   Package set optimized for the OpenMesh OM5P-AC.
+   Package set optimized for the OpenMesh OM5P-AC/OM5P-ACv2.
 endef
 
 $(eval $(call Profile,OM5PAC))
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 33/34] ar71xx: extract ath10k wifi board.bin for the OpenMesh OM5P-ACv2 board

2016-05-19 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>

Backport of r49154
---
 .../linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata   | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 1b6de1e..8fc3ab3 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -71,7 +71,8 @@ case "$FIRMWARE" in
ath10kcal_extract "caldata" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
;;
-   mr1750)
+   mr1750 | \
+   om5p-acv2)
ath10kcal_extract "ART" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +16)
;;
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 30/34] ar71xx: enable sysupgrade for the OpenMesh OM5P-ACv2

2016-05-19 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>

Backport of r49151
---
 target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh | 1 +
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
index 1cfead9..209cdaa 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
@@ -74,6 +74,7 @@ platform_check_image_openmesh()
;;
OM5PAC)
[ "$board" = "om5p-ac" ] && break
+   [ "$board" = "om5p-acv2" ] && break
echo "Invalid image board target ($img_board_target) 
for this platform: $board. Use the correct image for this platform"
return 1
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index eb5c01e..d3e8a79 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -302,7 +302,8 @@ platform_check_image() {
om2p-lc | \
om5p | \
om5p-an | \
-   om5p-ac)
+   om5p-ac | \
+   om5p-acv2)
platform_check_image_openmesh "$magic_long" "$1" && return 0
return 1
;;
@@ -532,7 +533,8 @@ platform_do_upgrade() {
om2p-lc | \
om5p | \
om5p-an | \
-   om5p-ac)
+   om5p-ac | \
+   om5p-acv2)
platform_do_upgrade_openmesh "$ARGV"
;;
unifi-outdoor-plus | \
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH CC 26/34] ar71xx: extract ath10k wifi board.bin for the OpenMesh OM5P-AC board

2016-05-19 Thread Sven Eckelmann 
Signed-off-by: Sven Eckelmann <sven.eckelm...@open-mesh.com>

Backport of r49147
---
 .../linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index e6fcec8..1b6de1e 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -95,6 +95,10 @@ case "$FIRMWARE" in
rb-911g-5hpacd)
ath10kcal_from_file "/sys/firmware/routerboot/ext_wlan_data" 
20480 2116
;;
+   om5p-ac)
+   ath10kcal_extract "ART" 20480 2116
+   ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +16)
+   ;;
esac
;;
 *)
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

  1   2   3   >