Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?
On 11/10/19 12:59, Jo-Philipp Wich wrote: Hi Bjørn, Or: Start discussing the release blockers here and now. Thanks. 1) Blocker: LuCI master needs to be backported to 19.07 Time estimate: 2-3 weeks 2) Blocker: All relevant sub-components for WPA-3 + GUI support, such as hostapd, iwinfo etc. need to be backported to 19.07 Time estimate: 2 weeks 3) Blocker: Some weaknesses in libustream-ssl client certificate handling need to be addressed, which can only be solved by an API redesign. Band-aid fixes available but not merged, nobody worked on API redesign yet Time estimate: 1 week 4) Blocker: Need to assert the state of the Dragonblood WPA3 vulnerabilities in 19.07's hostapd Time estimate: a few days I guess ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Is WPA3 support so critical for 19.07? I'm not aware of many client devices that actually need that (i.e. cannot use WPA2). Imho if it's not ready for a stable as-is, just postpone it and tell people that need bleeding edge to use Master/snapshot -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mpc85xx: correct TP-LINK TL-WDR4900 MAC addresses
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > Behalf Of David Bauer > Sent: Montag, 14. Oktober 2019 00:14 > To: openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] [PATCH] mpc85xx: correct TP-LINK TL-WDR4900 MAC > addresses > > This commit fixes TP-Link TL-WDR4900 v1 MAC address assignment. > Previously, the MAC addrss was read for the ethernet from the "config" > partition. However, the content of this partition is dependent on the > firmware which was previously installed on the device. > > Switch the MAC address source to the U-Boot partition, where the MAC > address is always present at a fixed partition. The partition was > previously already used for the WiFi MAC-addresses. > > Signed-off-by: David Bauer Reviewed-by: Adrian Schmutzler Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: correct ar71xx boardname for UniFi AC Lite
This corrects the additional boardname for the image metadata to the one used in ar71xx. The previously present additional entry was never used on a running system. Signed-off-by: David Bauer --- target/linux/ath79/image/generic-ubnt.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ath79/image/generic-ubnt.mk b/target/linux/ath79/image/generic-ubnt.mk index 984b18ccae..801b0128ac 100644 --- a/target/linux/ath79/image/generic-ubnt.mk +++ b/target/linux/ath79/image/generic-ubnt.mk @@ -221,7 +221,7 @@ endef define Device/ubnt_unifiac-lite $(Device/ubnt_unifiac) DEVICE_MODEL := UniFi AC-Lite - SUPPORTED_DEVICES += ubnt-unifiac-lite + SUPPORTED_DEVICES += unifiac-lite endef TARGET_DEVICES += ubnt_unifiac-lite -- 2.23.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add AR934x NAND Flash Controller driver
Hello Michal On 10/14/19 12:22 AM, Michal Cieslakiewicz wrote: > Hello David, > > Yes, please update my commit. > > Thank you for your feedback, review and tests. Indeed I (wrongly) > assumed minimalistic approach and delegated ar71xx reset procedure to > a simple DT property. I have only WNDR4300 to test the driver - this > router interestingly has no problems whatsoever (I've booted it tens of > times). ar934x-nand is my first DT driver port ever, and I thanks to > your patch now I know more about implementing reset features :-) No Problem (and thanks for taking care of that). I've started work on the NAND driver some months ago, but quickly lost interested as more fun stuff was around. Glad to see this coming true. The ar71xx implementation also triggered resets for the ethernet switch analog. I'm a bit lost here grasping the correlation. I will try to get my hands on GPL source from the Atheros implementation, seeing I can make out the reason for this reset. Best wishes David > > Again, thanks and best regards > Michal > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 1/2] treewide: use a single ath10k MAC patching function with checksum
While all ath10k eeproms have a checksum field, so far two
functions for patching ath10k MAC address have been present (and
been used).
This merges code to provide a single function ath10k_patch_mac
in caldata.sh, having its name in accordance with ath9k functions.
By doing so, correct MAC patching for current and future ath10k
devices should be ensured.
This patch adds checksum adjustments for several targets on
ath79 and lantiq.
Signed-off-by: Adrian Schmutzler
---
v3: Merged ath79 and lantiq patches, rename function to be consistent
---
.../base-files/files/lib/functions/caldata.sh | 8 +---
.../etc/hotplug.d/firmware/11-ath10k-caldata | 44 +--
.../etc/hotplug.d/firmware/11-ath10k-caldata | 24 +-
.../etc/hotplug.d/firmware/11-ath10k-caldata | 28 ++--
.../etc/hotplug.d/firmware/11-ath10k-caldata | 2 +-
5 files changed, 50 insertions(+), 56 deletions(-)
diff --git a/package/base-files/files/lib/functions/caldata.sh
b/package/base-files/files/lib/functions/caldata.sh
index 004bcfa990..1ff69ce1ae 100644
--- a/package/base-files/files/lib/functions/caldata.sh
+++ b/package/base-files/files/lib/functions/caldata.sh
@@ -121,13 +121,7 @@ ath9k_patch_mac_crc() {
caldata_patch_mac "$mac" "$mac_offset" "$chksum_offset"
}
-ath10kcal_patch_mac() {
- local mac=$1
-
- caldata_patch_mac "$mac" 0x6
-}
-
-ath10kcal_patch_mac_crc() {
+ath10k_patch_mac() {
local mac=$1
caldata_patch_mac "$mac" 0x6 0x2
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index ebc1fc24d0..3b7d5b0682 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -22,54 +22,54 @@ case "$FIRMWARE" in
devolo,dvl1750i|\
devolo,dvl1750x)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary art
0x0) -1)
+ ath10k_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0x0) -1)
;;
dlink,dir-859-a1)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(mtd_get_mac_ascii devdata "wlan5mac")
+ ath10k_patch_mac $(mtd_get_mac_ascii devdata "wlan5mac")
;;
elecom,wrc-1750ghbk2-i)
caldata_extract "art" 0x5000 0x844
;;
engenius,ecb1750)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(mtd_get_mac_ascii u-boot-env athaddr)
+ ath10k_patch_mac $(mtd_get_mac_ascii u-boot-env athaddr)
;;
engenius,epg5000|\
iodata,wn-ac1167dgr|\
iodata,wn-ac1600dgr2)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_ascii
u-boot-env ethaddr) +1)
+ ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii u-boot-env
ethaddr) +1)
;;
engenius,ews511ap)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +1)
+ ath10k_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +1)
;;
glinet,gl-ar750|\
glinet,gl-ar750s)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0x0)
+1)
+ ath10k_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0x0) +1)
;;
glinet,gl-x750)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0x0)
+2)
+ ath10k_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0x0) +2)
;;
nec,wg800hp)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac_crc $(mtd_get_mac_text board_data 0x880)
+ ath10k_patch_mac $(mtd_get_mac_text board_data 0x880)
;;
ocedo,koala|\
ocedo,ursus)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(mtd_get_mac_binary art 0xc)
+ ath10k_patch_mac $(mtd_get_mac_binary art 0xc)
;;
openmesh,om5p-ac-v2)
caldata_extract "art" 0x5000 0x844
- ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +16)
+ ath10k_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +16)
;;
qihoo,c301)
caldata_extract "radiocfg" 0x5000 0x844
- ath10kcal_patch_mac_crc $(mtd_get_mac_ascii devdata wlan5mac)
+ ath10k_patch_mac $(mtd_get_mac_ascii devdata wlan5mac)
;;
tplink,archer-a7-v5|\
tplink,archer-c2-v3|\
[OpenWrt-Devel] [PATCH v3 2/2] lantiq: modify ath9k caldata extraction to reuse caldata.sh
In lantiq, ath9k caldata extraction is implemented to work in two
alternate "modes", the standard one and another one with swapped
byte pairs.
This rearranges the functions so "standard" use is based on the
caldata.sh library, while only a single local function is required
for the special case.
Note that while the parameter for switching between normal and swab
is removed, the size of the caldata is added to the function calls
to stay consistent.
Signed-off-by: Adrian Schmutzler
---
v2:
- Added this patch (previously separate [5/5] lantiq: modify ath9k caldata
extraction to reuse caldata.sh)
- Made size in caldata_extract_swap a parameter to match other functions
v3:
- Rebase, no other changes
---
.../etc/hotplug.d/firmware/12-ath9k-eeprom| 62 +--
1 file changed, 15 insertions(+), 47 deletions(-)
diff --git
a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom
b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom
index d0bef23045..5a6e8d360b 100644
--- a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom
+++ b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/12-ath9k-eeprom
@@ -1,55 +1,23 @@
#!/bin/sh
-# Based on ar71xx 10-ath9k-eeprom
[ -e /lib/firmware/$FIRMWARE ] && exit 0
. /lib/functions/caldata.sh
-. /lib/upgrade/nand.sh
-ath9k_eeprom_extract_raw() {
- local source=$1
- local offset=$(($2))
- local swap=$3
- local size=4096
- local bs=1
- local conv=
-
- if [ $swap -gt 0 ]; then
- bs=2
- conv="conv=swab"
- size=$((size / bs))
- offset=$((offset / bs))
- fi
-
- dd if=$source of=/lib/firmware/$FIRMWARE bs=$bs skip=$offset
count=$size $conv 2>/dev/null || \
- caldata_die "failed to extract from $mtd"
-}
-
-ath9k_eeprom_extract() {
+caldata_extract_swap() {
local part=$1
local offset=$2
- local swap=$3
+ local count=$3
local mtd
mtd=$(find_mtd_chardev $part)
- [ -n "$mtd" ] || \
- caldata_die "no mtd device found for partition $part"
-
- ath9k_eeprom_extract_raw $mtd $offset $swap
-}
-
-ath9k_ubi_eeprom_extract() {
- local part=$1
- local offset=$2
- local swap=$3
- local ubidev=$(nand_find_ubi $CI_UBIPART)
- local ubi
+ [ -n "$mtd" ] || caldata_die "no mtd device found for partition $part"
- ubi=$(nand_find_volume $ubidev $part)
- [ -n "$ubi" ] || \
- caldata_die "no UBI volume found for $part"
+ offset=$(($offset / 2))
+ count=$(($count / 2))
- ath9k_eeprom_extract_raw /dev/$ubi $offset $swap
+ dd if=$mtd of=/lib/firmware/$FIRMWARE bs=2 skip=$offset count=$count
conv=swab 2>/dev/null || \
+ caldata_die "failed to extract calibration data from $mtd"
}
case "$FIRMWARE" in
@@ -60,25 +28,25 @@ case "$FIRMWARE" in
case "$board" in
arcadyan,arv7518pw)
- ath9k_eeprom_extract "boardconfig" 0x400 1
+ caldata_extract_swap "boardconfig" 0x400 0x1000
;;
arcadyan,arv8539pw22)
- ath9k_eeprom_extract "art" 0x400 1
+ caldata_extract_swap "art" 0x400 0x1000
;;
bt,homehub-v2b)
- ath9k_eeprom_extract "art" 0x0 1
+ caldata_extract_swap "art" 0x0 0x1000
ath9k_patch_mac_crc "00:00:00:00:00:00" 0x20c
;;
bt,homehub-v3a)
- ath9k_eeprom_extract "art-copy" 0x0 1
+ caldata_extract_swap "art-copy" 0x0 0x1000
ath9k_patch_mac_crc $(macaddr_add
$(mtd_get_mac_ascii uboot_env ethaddr) +2) 0x10c
;;
bt,homehub-v5a)
- ath9k_ubi_eeprom_extract "caldata" 0x1000 0
+ caldata_extract_ubi "caldata" 0x1000 0x1000
ath9k_patch_mac_crc $(macaddr_add
$(mtd_get_mac_binary_ubi caldata 0x110c) +2) 0x10c
;;
netgear,dgn3500|netgear,dgn3500b)
- ath9k_eeprom_extract "calibration" 0xf000 0
+ caldata_extract "calibration" 0xf000 0x1000
ath9k_patch_mac_crc $(macaddr_add
$(mtd_get_mac_ascii uboot-env ethaddr) +2) 0x20c
;;
avm,fritz3370-rev2-hynix|\
@@ -87,13 +55,13 @@ case "$FIRMWARE" in
caldata_extract_reverse "urlader" 0x1541 0x440
;;
[OpenWrt-Devel] [PATCH v2] ath79: fix patching ath9k MAC address for MyNet WiFi Range Extender
The code line patching ath9k MAC address for this device contains
a wrong number of arguments including an unset "$mac", which
looks like a typo or copy/paste mistake.
This has been introduced already in the device support commit
745dee11ac78 ("ath79: add support for WD My Net Wi-Fi Range
Extender").
This patch just removes the "$mac" argument, leaving a formally
valid line. (No on-device test has been performed.)
Cc: Christian Lamparter
Signed-off-by: Adrian Schmutzler
---
v2: Rebased on master (due to caldata patchset)
---
.../ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 3240026aec..69d36383d5 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -108,7 +108,7 @@ case "$FIRMWARE" in
;;
wd,mynet-wifi-rangeextender)
caldata_extract "art" 0x1000 0x1000
- ath9k_patch_mac $(nvram get wl0_hwaddr) "$mac"
+ ath9k_patch_mac $(nvram get wl0_hwaddr)
;;
*)
caldata_die "board $board is not supported yet"
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: correct ar71xx boardname for UniFi AC Lite
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > Behalf Of David Bauer > Sent: Montag, 14. Oktober 2019 12:47 > To: openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] [PATCH] ath79: correct ar71xx boardname for UniFi AC > Lite > > This corrects the additional boardname for the image metadata to the one > used in ar71xx. The previously present additional entry was never used > on a running system. > > Signed-off-by: David Bauer Reviewed-by: Adrian Schmutzler Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
Hi,
the device name is inconsistent in model string and DEVICE_MODEL (hyphens...).
However, as this is only the friendly name, it is not really important.
On their homepage, Ubiquiti never uses hyphens on product names, only for the
abbreviations:
UniFi AC Pro vs. UAP-AC-PRO-5
UniFi AC Lite vs. UAP-AC-LITE
Since we are using a lot of hyphens for other Ubiquiti devices, too, I wouldn't
bother for this commit.
But it might make sense to "correct" the friendly names for all Ubiquiti
devices at some point in the future.
Best
Adrian
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Andreas Ziegler
> Sent: Sonntag, 6. Oktober 2019 19:49
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
>
> The Unifi AC-LR has identical hardware to the Unifi AC-Lite.
> The antenna setup is different according to the vendor,
> which explains the thicker enclosure.
> Therefore, it is helpful to know the exact device variant,
> instead of having "Ubiquiti UniFi-AC-LITE/MESH".
>
> Signed-off-by: Andreas Ziegler
> ---
> target/linux/ath79/base-files/etc/board.d/02_network | 1 +
> .../base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts | 9 +
> target/linux/ath79/image/generic-ubnt.mk | 7 +++
> 4 files changed, 18 insertions(+)
> create mode 100644 target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
>
> diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
> b/target/linux/ath79/base-files/etc/board.d/02_network
> index 0de17adb9d..fe74bddbf1 100755
> --- a/target/linux/ath79/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/base-files/etc/board.d/02_network
> @@ -50,6 +50,7 @@ ath79_setup_interfaces()
> ubnt,nanostation-ac-loco|\
> ubnt,rocket-m|\
> ubnt,unifiac-lite|\
> + ubnt,unifiac-lr|\
> ubnt,unifiac-mesh|\
> ubnt,unifi|\
> wd,mynet-wifi-rangeextender|\
> diff --git
> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ath79/base-
> files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 446b729a2b..ba39cb3981 100644
> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -179,6 +179,7 @@ case "$FIRMWARE" in
> ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary info
> 0x8) +1)
> ;;
> ubnt,unifiac-lite|\
> + ubnt,unifiac-lr|\
> ubnt,unifiac-mesh|\
> ubnt,unifiac-mesh-pro|\
> ubnt,lap-120|\
> diff --git a/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
> b/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
> new file mode 100644
> index 00..a1e542ada6
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "qca9563_ubnt_unifiac-lite.dtsi"
> +
> +/ {
> + compatible = "ubnt,unifiac-lr", "qca,qca9563";
> + model = "Ubiquiti UniFi-AC-LR";
> +};
> diff --git a/target/linux/ath79/image/generic-ubnt.mk
> b/target/linux/ath79/image/generic-ubnt.mk
> index 4b2cee215c..13af092ee3 100644
> --- a/target/linux/ath79/image/generic-ubnt.mk
> +++ b/target/linux/ath79/image/generic-ubnt.mk
> @@ -225,6 +225,13 @@ define Device/ubnt_unifiac-lite
> endef
> TARGET_DEVICES += ubnt_unifiac-lite
>
> +define Device/ubnt_unifiac-lr
> + $(Device/ubnt_unifiac)
> + DEVICE_MODEL := UniFi AC-LR
> + SUPPORTED_DEVICES += unifiac-lite
> +endef
> +TARGET_DEVICES += ubnt_unifiac-lr
> +
> define Device/ubnt_unifiac-mesh
>$(Device/ubnt_unifiac)
>DEVICE_MODEL := UniFi AC-Mesh
> --
> 2.23.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for Sitecom WLR-7100
Hi,
> diff --git a/target/linux/ath79/dts/ar1022_sitecom_wlr-7100.dts
> b/target/linux/ath79/dts/ar1022_sitecom_wlr-7100.dts
> new file mode 100644
> index 00..8a70b597b0
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar1022_sitecom_wlr-7100.dts
You are using ar1022 here, but do not reference it in the compatible or provide
a comment about it in the commit message.
> + uenv: partition@3 {
You are not using the "uenv" label anywhere, so remove it.
> +define Device/sitecom_wlr-7100
> + ATH_SOC := ar1022
> + DEVICE_VENDOR := Sitecom
> + DEVICE_MODEL := WLR-7100
> + DEVICE_VARIANT := v1 002
What's the meaning of the "002"?
If you have a variant "v1", you should include it in the device name, i.e. use
sitecom_wlr-7100-v1 instead of sitecom_wlr-7100 etc.
This will help users and developers when a v2 shows up.
You can account for the alternate (marketing) name here with:
DEVICE_ALT0_VENDOR := Sitecom
DEVICE_ALT0_MODEL := X7 AC1200
> + DEVICE_PACKAGES := ath10k-firmware-qca988x kmod-ath10k kmod-usb2
Since 2018 OpenWrt uses -ct drivers by default. Please test and change to those.
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
Hello Adrian,
On 10/14/19 2:18 PM, Adrian Schmutzler wrote:
> Hi,
>
> the device name is inconsistent in model string and DEVICE_MODEL (hyphens...).
>
> However, as this is only the friendly name, it is not really important.
>
> On their homepage, Ubiquiti never uses hyphens on product names, only for the
> abbreviations:
> UniFi AC Pro vs. UAP-AC-PRO-5
> UniFi AC Lite vs. UAP-AC-LITE
>
> Since we are using a lot of hyphens for other Ubiquiti devices, too, I
> wouldn't bother for this commit.
> But it might make sense to "correct" the friendly names for all Ubiquiti
> devices at some point in the future.
I've looked into the naming Ubiquiti uses for their devices and sadly, they
have for
each of their devices multiple namings on their Website.
> UniFi AC Pro
> UniFi AP AC Pro
> UAP-AC-PRO
And don't get started on their Mesh series, things only get more confusing
there.
If we want to be 100% consistent, we probably have to use the product-ids
(UAP-AC-PRO for example),
however i think having the marketing name is nicer.
Best wishes
David
>
> Best
>
> Adrian
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
>> Behalf Of Andreas Ziegler
>> Sent: Sonntag, 6. Oktober 2019 19:49
>> To: openwrt-devel@lists.openwrt.org
>> Subject: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
>>
>> The Unifi AC-LR has identical hardware to the Unifi AC-Lite.
>> The antenna setup is different according to the vendor,
>> which explains the thicker enclosure.
>> Therefore, it is helpful to know the exact device variant,
>> instead of having "Ubiquiti UniFi-AC-LITE/MESH".
>>
>> Signed-off-by: Andreas Ziegler
>> ---
>> target/linux/ath79/base-files/etc/board.d/02_network | 1 +
>> .../base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
>> target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts | 9 +
>> target/linux/ath79/image/generic-ubnt.mk | 7 +++
>> 4 files changed, 18 insertions(+)
>> create mode 100644 target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
>>
>> diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
>> b/target/linux/ath79/base-files/etc/board.d/02_network
>> index 0de17adb9d..fe74bddbf1 100755
>> --- a/target/linux/ath79/base-files/etc/board.d/02_network
>> +++ b/target/linux/ath79/base-files/etc/board.d/02_network
>> @@ -50,6 +50,7 @@ ath79_setup_interfaces()
>> ubnt,nanostation-ac-loco|\
>> ubnt,rocket-m|\
>> ubnt,unifiac-lite|\
>> +ubnt,unifiac-lr|\
>> ubnt,unifiac-mesh|\
>> ubnt,unifi|\
>> wd,mynet-wifi-rangeextender|\
>> diff --git
>> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
>> b/target/linux/ath79/base-
>> files/etc/hotplug.d/firmware/11-ath10k-caldata
>> index 446b729a2b..ba39cb3981 100644
>> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
>> +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
>> @@ -179,6 +179,7 @@ case "$FIRMWARE" in
>> ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary info
>> 0x8) +1)
>> ;;
>> ubnt,unifiac-lite|\
>> +ubnt,unifiac-lr|\
>> ubnt,unifiac-mesh|\
>> ubnt,unifiac-mesh-pro|\
>> ubnt,lap-120|\
>> diff --git a/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
>> b/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
>> new file mode 100644
>> index 00..a1e542ada6
>> --- /dev/null
>> +++ b/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
>> @@ -0,0 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +/dts-v1/;
>> +
>> +#include "qca9563_ubnt_unifiac-lite.dtsi"
>> +
>> +/ {
>> +compatible = "ubnt,unifiac-lr", "qca,qca9563";
>> +model = "Ubiquiti UniFi-AC-LR";
>> +};
>> diff --git a/target/linux/ath79/image/generic-ubnt.mk
>> b/target/linux/ath79/image/generic-ubnt.mk
>> index 4b2cee215c..13af092ee3 100644
>> --- a/target/linux/ath79/image/generic-ubnt.mk
>> +++ b/target/linux/ath79/image/generic-ubnt.mk
>> @@ -225,6 +225,13 @@ define Device/ubnt_unifiac-lite
>> endef
>> TARGET_DEVICES += ubnt_unifiac-lite
>>
>> +define Device/ubnt_unifiac-lr
>> + $(Device/ubnt_unifiac)
>> + DEVICE_MODEL := UniFi AC-LR
>> + SUPPORTED_DEVICES += unifiac-lite
>> +endef
>> +TARGET_DEVICES += ubnt_unifiac-lr
>> +
>> define Device/ubnt_unifiac-mesh
>>$(Device/ubnt_unifiac)
>>DEVICE_MODEL := UniFi AC-Mesh
>> --
>> 2.23.0
>>
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
Hi David,
> -Original Message-
> From: David Bauer [mailto:m...@david-bauer.net]
> Sent: Montag, 14. Oktober 2019 14:39
> To: Adrian Schmutzler
> Cc: d...@andreas-ziegler.de; openwrt-devel
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
>
> Hello Adrian,
>
> On 10/14/19 2:18 PM, Adrian Schmutzler wrote:
> > Hi,
> >
> > the device name is inconsistent in model string and DEVICE_MODEL
> > (hyphens...).
> >
> > However, as this is only the friendly name, it is not really important.
> >
> > On their homepage, Ubiquiti never uses hyphens on product names, only for
> > the abbreviations:
> > UniFi AC Pro vs. UAP-AC-PRO-5
> > UniFi AC Lite vs. UAP-AC-LITE
> >
> > Since we are using a lot of hyphens for other Ubiquiti devices, too, I
> > wouldn't bother for this commit.
> > But it might make sense to "correct" the friendly names for all Ubiquiti
> > devices at some point in the future.
>
> I've looked into the naming Ubiquiti uses for their devices and sadly, they
> have for
> each of their devices multiple namings on their Website.
>
> > UniFi AC Pro
> > UniFi AP AC Pro
> > UAP-AC-PRO
Since we have the alternate names now, one could actually provide at least two,
e.g.
DEVICE_MODEL := UniFi AC Pro
DEVICE_ALT0_MODEL := UAP-AC-PRO
I was mainly focusing on that we are using the names without hyphens originally
and then add hyphens to them.
Nevertheless, I do not believe this is terribly important or blocks the LR
support patch.
It's more like an objective for a boring, rainy afternoon.
Best
Adrian
>
> And don't get started on their Mesh series, things only get more confusing
> there.
>
> If we want to be 100% consistent, we probably have to use the product-ids
> (UAP-AC-PRO for example),
> however i think having the marketing name is nicer.
>
> Best wishes
> David
>
> >
> > Best
> >
> > Adrian
> >
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> >> Behalf Of Andreas Ziegler
> >> Sent: Sonntag, 6. Oktober 2019 19:49
> >> To: openwrt-devel@lists.openwrt.org
> >> Subject: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
> >>
> >> The Unifi AC-LR has identical hardware to the Unifi AC-Lite.
> >> The antenna setup is different according to the vendor,
> >> which explains the thicker enclosure.
> >> Therefore, it is helpful to know the exact device variant,
> >> instead of having "Ubiquiti UniFi-AC-LITE/MESH".
> >>
> >> Signed-off-by: Andreas Ziegler
> >> ---
> >> target/linux/ath79/base-files/etc/board.d/02_network | 1 +
> >> .../base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> >> target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts | 9 +
> >> target/linux/ath79/image/generic-ubnt.mk | 7 +++
> >> 4 files changed, 18 insertions(+)
> >> create mode 100644 target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
> >>
> >> diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
> >> b/target/linux/ath79/base-files/etc/board.d/02_network
> >> index 0de17adb9d..fe74bddbf1 100755
> >> --- a/target/linux/ath79/base-files/etc/board.d/02_network
> >> +++ b/target/linux/ath79/base-files/etc/board.d/02_network
> >> @@ -50,6 +50,7 @@ ath79_setup_interfaces()
> >>ubnt,nanostation-ac-loco|\
> >>ubnt,rocket-m|\
> >>ubnt,unifiac-lite|\
> >> + ubnt,unifiac-lr|\
> >>ubnt,unifiac-mesh|\
> >>ubnt,unifi|\
> >>wd,mynet-wifi-rangeextender|\
> >> diff --git
> >> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> >> b/target/linux/ath79/base-
> >> files/etc/hotplug.d/firmware/11-ath10k-caldata
> >> index 446b729a2b..ba39cb3981 100644
> >> ---
> >> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> >> +++
> >> b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> >> @@ -179,6 +179,7 @@ case "$FIRMWARE" in
> >>ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary info
> >> 0x8) +1)
> >>;;
> >>ubnt,unifiac-lite|\
> >> + ubnt,unifiac-lr|\
> >>ubnt,unifiac-mesh|\
> >>ubnt,unifiac-mesh-pro|\
> >>ubnt,lap-120|\
> >> diff --git a/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
> >> b/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
> >> new file mode 100644
> >> index 00..a1e542ada6
> >> --- /dev/null
> >> +++ b/target/linux/ath79/dts/qca9563_ubnt_unifiac-lr.dts
> >> @@ -0,0 +1,9 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> >> +/dts-v1/;
> >> +
> >> +#include "qca9563_ubnt_unifiac-lite.dtsi"
> >> +
> >> +/ {
> >> + compatible = "ubnt,unifiac-lr", "qca,qca9563";
> >> + model = "Ubiquiti UniFi-AC-LR";
> >> +};
> >> diff --git a/target/linux/ath79/image/generic-ubnt.mk
> >> b/target/linux/ath79/image/generic-ubnt.mk
> >> index 4b2cee215c..13af092ee3 100644
> >> --- a/target/linux/ath79/image/generic-ubnt.mk
> >> +++ b/target/linux/ath79/image/generic-ubnt.mk
> >> @@ -225,6 +225,13 @@ define Devi
Re: [OpenWrt-Devel] [PATCH] ath79: add AR934x NAND Flash Controller driver
On Mon, 14 Oct 2019 12:57:29 +0200 David Bauer wrote: > Hello Michal > > On 10/14/19 12:22 AM, Michal Cieslakiewicz wrote: > > Hello David, > > > > Yes, please update my commit. > > > > Thank you for your feedback, review and tests. Indeed I (wrongly) > > assumed minimalistic approach and delegated ar71xx reset procedure > > to a simple DT property. I have only WNDR4300 to test the driver - > > this router interestingly has no problems whatsoever (I've booted > > it tens of times). ar934x-nand is my first DT driver port ever, and > > I thanks to your patch now I know more about implementing reset > > features :-) > > No Problem (and thanks for taking care of that). I've started work on > the NAND driver some months ago, but quickly lost interested as more > fun stuff was around. Glad to see this coming true. > > The ar71xx implementation also triggered resets for the ethernet > switch analog. I'm a bit lost here grasping the correlation. I will > try to get my hands on GPL source from the Atheros implementation, > seeing I can make out the reason for this reset. > > Best wishes > David > Hello David, Yes, this 'analog switch reset' puzzles me also, there are no clues how it affects NAND chip in official AR9344 datasheet. Also in Netgear's u-boot sources there is a reset sequence in ath_nand_hw_init() function (board/ar7240/common/ath_nand.c file), but it does not even touch ethernet switch. For now I've found a place for it in WNDR4300 dts file in '&builtin_switch' section where it's added to generic ethernet switch reset. No problems so far on my WNDR4300, neither with NAND nor with network. Best regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: add support for Netgear WNDR4300
Hi Michal, > -Original Message- > From: Michal Cieslakiewicz [mailto:michal.cieslakiew...@wp.pl] > Sent: Freitag, 11. Oktober 2019 19:15 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH 1/2] ath79: add support for Netgear > WNDR4300 > > On Fri, 11 Oct 2019 14:58:03 +0200 > "Adrian Schmutzler" wrote: > > > Hi, > > > > > > Have you checked that there are no usable addresses in 0x1002 and > > > > 0x5006? > > > > > > > Yes, there are wireless addresses inside calibration data at > > > offsets you provided, and they are both equal to LAN MAC. > > > > Okay, so for &wmac that would mean it should correctly read the > > address from calibration data even if you do not specify it. Thus, > > you should be able to remove the mtd-mac-address for wmac and still > > have the correct MAC address. > > > > For 0x5006 this is more interesting, as it implies that the vendor > > puts a "wrong" MAC address into the calibration data. However, since > > you have verified it, it seems appropriate to overwrite the address > > in calibration with mtd-mac-address in this case. > > > > Note that if you remove the mtd-mac-address for wmac, you will need > > to change the label-mac-device alias to ð0 then. > > > > Best > > > > Adrian > > > > Hello Adrian, > > IMHO the valid place for Netgear routers to get MACs from is 0x0-0xc > (beginning of art partition). This is the first Netgear model I came > across that has a real hardware address inside calibration area, > usually there are 0xff's there. I always look into vendor's u-boot > sources to find hints about configuration and all WN[D]Rs I had access > to point at 'the start of the art' :-). > Even though vendor u-boot does not put Wifi into use, it defines where > wmac address is for u-boot commands like 'wmacset' etc. > We should consider leaving it as it is now, as long as we decide to > honour u-boot as the valid option/tool for changing device > configuration. > It looks like Netgear has its own way of handling these things... > Anyway, I'll gladly read what you as a developer think about all this. > > Best regards > Michal I am just reluctant to overwrite a MAC address with itself. However, I understand your point and cannot provide any superior insights to what you've presented here. So, keep your current setup if you prefer it. Still, I would change the ambiguous label-mac-device to eth0, so it's unaffected if someone changes wmac MAC address setup later. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ath79: add support for TP-Link TL-MR6400
Hi,
I had a look into ar71xx mach files. Find some additional comments below.
> diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds
> b/target/linux/ath79/base-files/etc/board.d/01_leds
> index 778316e450..385ac8d9ca 100755
> --- a/target/linux/ath79/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/base-files/etc/board.d/01_leds
> @@ -130,6 +130,11 @@ tplink,archer-c7-v5)
> ucidef_set_led_switch "lan3" "LAN3" "tp-link:green:lan3" "switch0"
> "0x10"
> ucidef_set_led_switch "lan4" "LAN4" "tp-link:green:lan4" "switch0"
> "0x20"
> ;;
> +tplink,tl-mr6400-v1)
> + ucidef_set_led_netdev "lan" "LAN" "tp-link:white:lan" "eth0"
> + ucidef_set_led_netdev "wan" "WAN" "tp-link:white:wan" "eth1"
netdev triggers won't work for LAN and WAN. You will need to change one of them
to ucidef_set_led_switch (have a look at other ath79 devices in 01_leds for
reference).
Unfortunately, I can never recall which of them it is. You will know when the
LED is on although no cable is connected ...
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_tplink_tl-mr6400-v1.dts
> @@ -0,0 +1,172 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "tplink,tl-mr6400-v1", "qca,qca9531";
> + model = "TP-Link TL-MR6400 v1";
> +
> + aliases {
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-running = &led_power;
> + led-upgrade = &led_power;
> + };
> +
> + gpio_leds: leds {
Do you need the gpio_leds label somewhere? If not, remove it.
[...]
> +ð0 {
> + status = "okay";
> + phy-mode = "mii";
Those two lines can be removed. eth0 is not disabled before, and phy-mode is
already set in parent DTSI.
> + phy-handle = <&swphy0>;
> +
> + mtd-mac-address = <&uboot 0x1fc00>;
> + mtd-mac-address-increment = <1>;
> +
> + gmac-config {
> + device = <&gmac>;
> + switch-phy-swap = <1>;
> + switch-phy-addr-swap = <1>;
> + };
Hmm, I do not see a phy-swap in mr6400 mach files. But if all ports are
working, it might still be okay ...
> +};
> +
> +ð1 {
> + status = "okay";
Remove status, it's already set in parent dtsi.
> + mtd-mac-address = <&uboot 0x1fc00>;
> + mtd-mac-address-increment = <(-1)>;
> +};
> +
> +&wmac {
> + status = "okay";
> + mtd-cal-data = <&art 0x1000>;
> + mtd-mac-address = <&uboot 0x1fc00>;
> +};
> +
> +&usb0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_port: port@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
> +};
> +
> +&usb_phy {
> + status = "okay";
> +};
> +
> +&gpio {
> + lte_power {
> + gpio-hog;
> + gpios = <4 GPIO_ACTIVE_HIGH>;
Is GPIO_ACTIVE_HIGH correct here?
ar71xx mach files have:
gpio_request_one(TL_MR6400_GPIO_LTE_POWER,
GPIOF_OUT_INIT_LOW | GPIOF_EXPORT_DIR_FIXED |
GPIOF_ACTIVE_LOW,
"LTE power");
> + output-low;
> + line-name = "tp-link:power:LTE";
> + };
> +};
> diff --git a/target/linux/ath79/image/generic-tp-link.mk
> b/target/linux/ath79/image/generic-tp-link.mk
> index 5519e9c960..78d7810f29 100644
> --- a/target/linux/ath79/image/generic-tp-link.mk
> +++ b/target/linux/ath79/image/generic-tp-link.mk
> @@ -393,6 +393,16 @@ define Device/tplink_tl-wr810n-v1
> endef
> TARGET_DEVICES += tplink_tl-wr810n-v1
>
> +define Device/tplink_tl-mr6400-v1
> + $(Device/tplink-8mlzma)
> + ATH_SOC := qca9531
> + DEVICE_MODEL := TL-MR6400
> + DEVICE_VARIANT := v1
> + TPLINK_HWID := 0x6401
You need to add
SUPPORTED_DEVICES := tl-mr6400
here.
> + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-net
> kmod-usb-net-rndis kmod-usb-serial kmod-usb-serial-option adb
You can remove the following, as those are inherited by the others:
kmod-usb-core kmod-usb-net kmod-usb-serial
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ath79: add support for TP-Link TL-MR6400
Hi, > -Original Message- > From: Enrico Mioso [mailto:mrkiko...@gmail.com] > Sent: Dienstag, 8. Oktober 2019 07:14 > To: Filip Moc > Cc: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org > Subject: Re: [PATCH V2] ath79: add support for TP-Link TL-MR6400 > > Hi Filip, hello all! > > Thank you very very much for your help and sorry for me not ansering to your > previous mail. I tought I would re-check this all when I > went back home to report with precise informations, but in the end I didn't. > Your help is very very much apreciated. > > As you found out, I would need help in exactly that: setting port numbers > correctly in the UI and fixing the fact eth0 doesn't receive > connection status events. What exactly are you referring to when you say "connection status events"? This has two aspects: One is the LED status which needs to be set with switch0 (I commented on that in my previous e-mail reviewing your v2 patch again). The other one is that switch-phy-swap has an effect on which ports can detect link status changes. This setting will affect several things: 1. Which port gets link detection 2. The port numbers will change 3. The order in which gmacs are set up will change: If you change that, eth0 will become eth1 and vice versa (on running system). This will require adjustment of setup in 02_network/01_leds, where ethX then needs to be swapped, too. Note that for several devices eth0/eth1 are swapped compared to ar71xx. So, you really have a lot to play around with and to make wrong ;-) For further reading on the effects of switch-phy-swap, you might have a look at this Pull Request (starting at the comment): https://github.com/openwrt/openwrt/pull/1942#issuecomment-529078064 Note that the situation in the PR is even more complicated as the vendor did a dumbass setup in the first place. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: add support for Netgear WNDR4300
On Mon, 14 Oct 2019 16:50:22 +0200 "Adrian Schmutzler" wrote: Hello Adrian, > > Still, I would change the ambiguous label-mac-device to eth0, so it's > unaffected if someone changes wmac MAC address setup later. > Sure, that's indeed safer and better solution. I will use that one. Thanks! Regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for UniFi AC-LR
Adrian Schmutzler schrieb am 14.10.19 um 14:18: > Since we are using a lot of hyphens for other Ubiquiti devices, too, I > wouldn't bother for this commit. this was my only intention: keeping it consistent with already supported unifi devices. i don't mind anyone changing this before committing it. Kind Regards Andreas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lua: Fix linking under glibc
Compilation of liblua itself works, but when other packages link against it, the linker starts throwing undefined references to a bunch of math functions in libm. First discovered in a failed attempt to transition a package to uClibc++. Signed-off-by: Rosen Penev --- package/utils/lua/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/utils/lua/Makefile b/package/utils/lua/Makefile index e376e8c472..0421abc301 100644 --- a/package/utils/lua/Makefile +++ b/package/utils/lua/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=lua PKG_VERSION:=5.1.5 -PKG_RELEASE:=6 +PKG_RELEASE:=7 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://www.lua.org/ftp/ \ @@ -99,7 +99,7 @@ define Build/Compile RANLIB="$(TARGET_CROSS)ranlib" \ INSTALL_ROOT=/usr \ CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" \ - MYLDFLAGS="$(TARGET_LDFLAGS)" \ + MYLDFLAGS="$(TARGET_LDFLAGS) $(if $(CONFIG_USE_GLIBC),-lm)" \ PKG_VERSION=$(PKG_VERSION) \ linux rm -rf $(PKG_INSTALL_DIR) -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
