'config route' extension for more compact notation
Hi, I'm thinking about something like (taken from my home router): config route option target '103.136.220.0/22' option interface 'wan' option type 'blackhole' config route option target '103.123.116.0/22' option interface 'wan' option type 'blackhole' config route option target '130.44.212.0/22' option interface 'wan' option type 'blackhole' etc. Kudos to you if you spotted these as being ByteDance TikTok servers in China which US subscribers aren't supposed to have their traffic sent to, but (surprise!!!) it still is anyway. A nicer (more compact) notation might be: config route list target '103.123.116.0/22' list target '103.136.220.0/22' list target '130.44.212.0/22' option interface 'wan' option type 'blackhole' So, how about a change to config/route where, if it doesn't find 'option target', then it searches for 'list target' instead, and populates an ipset instead, using that for the match criteria? We could probably do something similar for config/rule in the firewall, for the src_ip, src_port, dst_ip, dst_port, etc. using 'list' instead of 'option', and ipsets to compactly match multiple addresses, ports, etc. But then, firewall would depend on ipset functionality being baked in. On x86_64, this isn't big: -rw-r--r-- 1 philipp philipp 823 May 10 22:15 bin/targets/x86/64/packages/kmod-ipt-ipset_5.4.110-1_x86_64.ipk -rw-r--r-- 1 philipp philipp 2036 Mar 19 16:57 bin/packages/x86_64/base/ipset_7.6-1_x86_64.ipk What do you all think? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH V3 netifd] interface: support "device" attribute and deprecate "ifname"
From: Rafał Miłecki
Interfaces need to be assigned to devices. For that purpose a "device"
option should be more accurate than "ifname" one.
For backward compatibility old option remains supported too.
Config example:
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
config interface 'lan'
option device 'br-lan'
option proto 'static'
Signed-off-by: Rafał Miłecki
---
V2: Add translation in the "add_dynamic" ubus method handler
V3: Just add IFACE_ATTR_DEVICE as *new* option to simplify backward comp
---
interface.c | 25 +++--
interface.h | 2 +-
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/interface.c b/interface.c
index a91246a..1d1a5f8 100644
--- a/interface.c
+++ b/interface.c
@@ -30,7 +30,8 @@ struct vlist_tree interfaces;
static LIST_HEAD(iface_all_users);
enum {
- IFACE_ATTR_IFNAME,
+ IFACE_ATTR_DEVICE,
+ IFACE_ATTR_IFNAME, /* Backward compatibility */
IFACE_ATTR_PROTO,
IFACE_ATTR_AUTO,
IFACE_ATTR_JAIL,
@@ -55,6 +56,7 @@ enum {
};
static const struct blobmsg_policy iface_attrs[IFACE_ATTR_MAX] = {
+ [IFACE_ATTR_DEVICE] = { .name = "device", .type = BLOBMSG_TYPE_STRING },
[IFACE_ATTR_PROTO] = { .name = "proto", .type = BLOBMSG_TYPE_STRING },
[IFACE_ATTR_IFNAME] = { .name = "ifname", .type = BLOBMSG_TYPE_STRING },
[IFACE_ATTR_AUTO] = { .name = "auto", .type = BLOBMSG_TYPE_BOOL },
@@ -641,9 +643,9 @@ interface_claim_device(struct interface *iface)
parent = vlist_find(, iface->parent_ifname, parent,
node);
iface->parent_iface.cb = interface_alias_cb;
interface_add_user(>parent_iface, parent);
- } else if (iface->ifname &&
+ } else if (iface->device &&
!(iface->proto_handler->flags & PROTO_FLAG_NODEV)) {
- dev = device_get(iface->ifname, true);
+ dev = device_get(iface->device, true);
interface_set_device_config(iface, dev);
} else {
dev = iface->ext_dev.dev;
@@ -939,8 +941,11 @@ static bool __interface_add(struct interface *iface,
struct blob_attr *config, b
if (!iface->parent_ifname)
return false;
} else {
- if ((cur = tb[IFACE_ATTR_IFNAME]))
- iface->ifname = blobmsg_data(cur);
+ cur = tb[IFACE_ATTR_DEVICE];
+ if (!cur)
+ cur = tb[IFACE_ATTR_IFNAME];
+ if (cur)
+ iface->device = blobmsg_data(cur);
}
if (iface->dynamic) {
@@ -1216,7 +1221,7 @@ interface_start_jail(const char *jail, const pid_t
netns_pid)
* list, so we can mess with it :)
*/
if (iface->jail_ifname)
- iface->ifname = iface->jail_ifname;
+ iface->device = iface->jail_ifname;
interface_do_reload(iface);
interface_set_up(iface);
@@ -1257,9 +1262,9 @@ interface_stop_jail(const char *jail, const pid_t
netns_pid)
if (!iface->jail || strcmp(iface->jail, jail))
continue;
- orig_ifname = iface->ifname;
+ orig_ifname = iface->device;
if (iface->jail_ifname)
- iface->ifname = iface->jail_ifname;
+ iface->device = iface->jail_ifname;
interface_do_reload(iface);
interface_set_down(iface);
@@ -1352,7 +1357,7 @@ interface_change_config(struct interface *if_old, struct
interface *if_new)
if (!reload && interface_device_config_changed(if_old, if_new))
reload = true;
- if (FIELD_CHANGED_STR(ifname) ||
+ if (FIELD_CHANGED_STR(device) ||
if_old->proto_handler != if_new->proto_handler)
reload = true;
@@ -1391,7 +1396,7 @@ interface_change_config(struct interface *if_old, struct
interface *if_new)
if_old->jail_ifname = if_new->jail_ifname;
- if_old->ifname = if_new->ifname;
+ if_old->device = if_new->device;
if_old->parent_ifname = if_new->parent_ifname;
if_old->dynamic = if_new->dynamic;
if_old->proto_handler = if_new->proto_handler;
diff --git a/interface.h b/interface.h
index 9c136b6..1767bf1 100644
--- a/interface.h
+++ b/interface.h
@@ -107,7 +107,7 @@ struct interface {
enum interface_event hotplug_ev;
const char *name;
- const char *ifname;
+ const char *device;
char *jail;
char *jail_ifname;
int netns_fd;
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] cn913x: add support for iEi Puzzle-M901/Puzzle-M902
Hi. W dniu 25.05.2021 o 10:22, Daniel Golle pisze: > Hi! > > thank you for submitting support for this interesting hardware. > There are some minor style issues which need to be addressed before > the patch can be merged into our tree. > It would also be better to split this into at least two patches: > [1/2] Add driver for Epson RX8130 RTC This RTC seems to be supported for a long time by upstream rtc-ds1307 driver [1]. What does not work with upstream one that works with this one? > [2/2] Add support for Puzzla M90x > > Other than that, please see my comments inline below: > > On Mon, May 24, 2021 at 01:58:00AM +0800, eveans2...@gmail.com wrote: >> From: ianchang >> >> Hardware specification >> -- >> * CN9130 SoC, Quad-core ARMv8 Cortex-72 @ 2200 MHz >> * 4 GB DDR >> * 4 GB eMMC >> * 4 MB (SPI Flash) >> * 6 x 2.5 Gigabit ports (Puzzle-M901) >> - External PHY with 6 ports (AQR112R) >> * 6 x 2.5 Gigabit ports (Puzzle-M902) >> - External PHY with 6 ports (AQR112R) >>3 x 10 Gigabit ports (Puzzle-M902) >> - External PHY with 3 ports (AQR113R) >> >> * 4 x Front panel LED >> * 1 x USB 3.0 >> * Reset button on Rear panel >> * UART (115200 8N1,header on PCB) >> >> Signed-off-by: ianchang > > Please use your full real name seperated by spaces (here in SoB and in > the Form: line above) > >> --- >> .../base-files/etc/board.d/02_network |9 +- >> target/linux/mvebu/cortexa72/config-5.4 | 14 + >> .../boot/dts/marvell/armada-ap807-quad.dtsi | 93 + >> .../arm64/boot/dts/marvell/armada-ap807.dtsi | 30 + >> .../arm64/boot/dts/marvell/armada-ap80x.dtsi | 464 >> .../arm64/boot/dts/marvell/armada-cp115.dtsi | 12 + >> .../arm64/boot/dts/marvell/armada-cp11x.dtsi | 573 + > > The above armada-*.dtsi are all already present in vanilla Linux. > Do not overwrite them here. Please amend them with patches, if needed. > > >> .../dts/marvell/puzzle-armada-common.dtsi | 11 + >> .../boot/dts/marvell/puzzle-armada-cp110.dtsi | 12 + >> .../arm64/boot/dts/marvell/puzzle-cn9130.dtsi | 37 + >> .../dts/marvell/puzzle-m901-cn9130-db.dts | 429 >> .../dts/marvell/puzzle-m901-cn9131-db.dts | 243 +++ >> .../dts/marvell/puzzle-m902-cn9130-db.dts | 430 >> .../dts/marvell/puzzle-m902-cn9131-db.dts | 247 +++ >> .../dts/marvell/puzzle-m902-cn9132-db.dts | 261 +++ >> target/linux/mvebu/files/drivers/rtc/Kconfig | 1943 + >> target/linux/mvebu/files/drivers/rtc/Makefile | 189 ++ >> .../mvebu/files/drivers/rtc/rtc-rx8130.c | 807 +++ >> target/linux/mvebu/image/cortexa72.mk | 20 + >> 19 files changed, 5823 insertions(+), 1 deletion(-) >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-ap807-quad.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-ap807.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-cp115.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-armada-common.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-armada-cp110.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-cn9130.dtsi >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m901-cn9130-db.dts >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m901-cn9131-db.dts >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m902-cn9130-db.dts >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m902-cn9131-db.dts >> create mode 100644 >> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m902-cn9132-db.dts >> create mode 100644 target/linux/mvebu/files/drivers/rtc/Kconfig > > You should not overwrite existing files in the kernel tree > (drivers/rtc/Kconfig does exist already). Use a patch and add that to > target/linux/mvevu/patches-*/ instead to modify files which are present > in the Linux kernel tree. > >> create mode 100644 target/linux/mvebu/files/drivers/rtc/Makefile > > Same here. > > >> create mode 100644 target/linux/mvebu/files/drivers/rtc/rtc-rx8130.c >> >> diff --git a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network >> b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network >> index 9ab3c8174d..9ad043b343 100755 >> --- a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network >> +++ b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network >> @@ -21,8 +21,15 @@ marvell,armada8040-db) >> marvell,armada7040-db) >> ucidef_set_interfaces_lan_wan "eth0
[PATCH] ipq40xx: add uboot-envtools to default packages
When support for Luma WRTQ-329ACN was added, the instructions for flashing this device include using tools from uboot-envtools package. Unfortunately the OpenWrt buildroot system omits packages from DEVICE_PACKAGES when CONFIG_TARGET_MULTI_PROFILE, CONFIG_TARGET_PER_DEVICE_ROOTFS, CONFIG_TARGET_ALL_PROFILES are set. In result the official images are without tools mentioned in the instruction. The workoround for the fashing would be installing uboot-envtools when booted with initramfs image, but not always the access to internet is available. The other method would be to issue the necesary command in U-Boot environment but some serial terminals default configuration don't work well with pasting lines longer than 80 chars. Therefore add uboot-envtools to default packages, which adds really small flash footprint to rootfs, where increased size usually is not an issue. Signed-off-by: Tomasz Maciej Nowak --- Please also backport to 21.02 branch. target/linux/ipq40xx/Makefile | 3 ++- target/linux/ipq40xx/image/generic.mk | 28 --- 2 files changed, 14 insertions(+), 17 deletions(-) diff --git a/target/linux/ipq40xx/Makefile b/target/linux/ipq40xx/Makefile index 43b1fcb0f9f5..400612376cb9 100644 --- a/target/linux/ipq40xx/Makefile +++ b/target/linux/ipq40xx/Makefile @@ -18,6 +18,7 @@ DEFAULT_PACKAGES += \ kmod-usb-dwc3-qcom \ kmod-leds-gpio kmod-gpio-button-hotplug swconfig \ kmod-ath10k-ct wpad-basic-wolfssl \ - kmod-usb3 kmod-usb-dwc3 ath10k-firmware-qca4019-ct + kmod-usb3 kmod-usb-dwc3 ath10k-firmware-qca4019-ct \ + uboot-envtools $(eval $(call BuildTarget)) diff --git a/target/linux/ipq40xx/image/generic.mk b/target/linux/ipq40xx/image/generic.mk index 4e40b8be50ed..358a583f8465 100644 --- a/target/linux/ipq40xx/image/generic.mk +++ b/target/linux/ipq40xx/image/generic.mk @@ -121,8 +121,7 @@ define Device/alfa-network_ap120c-ac DEVICE_VENDOR := ALFA Network DEVICE_MODEL := AP120C-AC SOC := qcom-ipq4018 - DEVICE_PACKAGES := kmod-usb-acm \ - kmod-tpm-i2c-atmel uboot-envtools + DEVICE_PACKAGES := kmod-usb-acm kmod-tpm-i2c-atmel BLOCKSIZE := 128k PAGESIZE := 2048 IMAGE_SIZE := 65536k @@ -141,7 +140,6 @@ endef define Device/aruba_ap-303 $(call Device/aruba_glenmorangie) DEVICE_MODEL := AP-303 - DEVICE_PACKAGES += uboot-envtools endef TARGET_DEVICES += aruba_ap-303 @@ -154,7 +152,7 @@ TARGET_DEVICES += aruba_ap-303h define Device/aruba_ap-365 $(call Device/aruba_glenmorangie) DEVICE_MODEL := AP-365 - DEVICE_PACKAGES += kmod-hwmon-ad7418 uboot-envtools + DEVICE_PACKAGES += kmod-hwmon-ad7418 endef TARGET_DEVICES += aruba_ap-365 @@ -237,7 +235,7 @@ define Device/buffalo_wtr-m2133hp DEVICE_VENDOR := Buffalo DEVICE_MODEL := WTR-M2133HP SOC := qcom-ipq4019 - DEVICE_PACKAGES := uboot-envtools ath10k-firmware-qca9984-ct ipq-wifi-buffalo_wtr-m2133hp + DEVICE_PACKAGES := ath10k-firmware-qca9984-ct ipq-wifi-buffalo_wtr-m2133hp BLOCKSIZE := 128k PAGESIZE := 2048 endef @@ -318,7 +316,7 @@ define Device/devolo_magic-2-wifi-next IMAGE_SIZE := 26624k IMAGES := sysupgrade.bin IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata - DEVICE_PACKAGES := ipq-wifi-devolo_magic-2-wifi-next uboot-envtools + DEVICE_PACKAGES := ipq-wifi-devolo_magic-2-wifi-next endef TARGET_DEVICES += devolo_magic-2-wifi-next @@ -357,7 +355,7 @@ define Device/edgecore_ecw5211 SOC := qcom-ipq4018 BLOCKSIZE := 128k PAGESIZE := 2048 - DEVICE_PACKAGES := kmod-tpm-i2c-atmel kmod-usb-acm uboot-envtools + DEVICE_PACKAGES := kmod-tpm-i2c-atmel kmod-usb-acm endef TARGET_DEVICES += edgecore_ecw5211 @@ -541,7 +539,6 @@ define Device/linksys_ea6350v3 UBINIZE_OPTS := -E 5 IMAGES += factory.bin IMAGE/factory.bin := append-kernel | append-uImage-fakehdr filesystem | pad-to (KERNEL_SIZE) | append-ubi | linksys-image type=EA6350v3 - DEVICE_PACKAGES := uboot-envtools endef TARGET_DEVICES += linksys_ea6350v3 @@ -557,7 +554,7 @@ define Device/linksys_ea8300 UBINIZE_OPTS := -E 5# EOD marks to "hide" factory sig at EOF IMAGES += factory.bin IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi | linksys-image type=EA8300 - DEVICE_PACKAGES := uboot-envtools ath10k-firmware-qca9888-ct ipq-wifi-linksys_ea8300 kmod-usb-ledtrig-usbport + DEVICE_PACKAGES := ath10k-firmware-qca9888-ct ipq-wifi-linksys_ea8300 kmod-usb-ledtrig-usbport endef TARGET_DEVICES += linksys_ea8300 @@ -573,7 +570,7 @@ define Device/linksys_mr8300 UBINIZE_OPTS := -E 5# EOD marks to "hide" factory sig at EOF IMAGES += factory.bin IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) |
[PATCH] mvebu: armada-37xx: remove ethernet alias patch
This patch has been added with initial support for ESPRESSObin board and
mistakenly it affects all boards with this SoC. Drop this patch since
the aliases are now in upstream dts for ESPRESSObin. If any boards are
relying on this, please add the respective alias to that board dts.
Signed-off-by: Tomasz Maciej Nowak
---
...ts-marvell-armada37xx-Add-eth0-alias.patch | 20 ---
...itch-PHY-operation-mode-to-2500base.patch} | 0
...mada-xp-linksys-mamba-resize-kernel.patch} | 0
...16-armada-370-dts-fix-crypto-engine.patch} | 0
4 files changed, 20 deletions(-)
delete mode 100644
target/linux/mvebu/patches-5.10/314-arm64-dts-marvell-armada37xx-Add-eth0-alias.patch
rename
target/linux/mvebu/patches-5.10/{315-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
=> 314-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch} (100%)
rename
target/linux/mvebu/patches-5.10/{316-armada-xp-linksys-mamba-resize-kernel.patch
=> 315-armada-xp-linksys-mamba-resize-kernel.patch} (100%)
rename
target/linux/mvebu/patches-5.10/{317-armada-370-dts-fix-crypto-engine.patch =>
316-armada-370-dts-fix-crypto-engine.patch} (100%)
diff --git
a/target/linux/mvebu/patches-5.10/314-arm64-dts-marvell-armada37xx-Add-eth0-alias.patch
b/target/linux/mvebu/patches-5.10/314-arm64-dts-marvell-armada37xx-Add-eth0-alias.patch
deleted file mode 100644
index e989f59d5cd4..
---
a/target/linux/mvebu/patches-5.10/314-arm64-dts-marvell-armada37xx-Add-eth0-alias.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-From be893f672e340b56ca60f2f6c32fdd713a5852f5 Mon Sep 17 00:00:00 2001
-From: Kevin Mihelich
-Date: Tue, 4 Jul 2017 19:25:28 -0600
-Subject: arm64: dts: marvell: armada37xx: Add eth0 alias
-
-Signed-off-by: Kevin Mihelich
- arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
- 1 file changed, 1 insertion(+)
-
a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
-+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
-@@ -18,6 +18,7 @@
- #size-cells = <2>;
-
- aliases {
-+ ethernet0 =
- serial0 =
- serial1 =
- };
diff --git
a/target/linux/mvebu/patches-5.10/315-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
b/target/linux/mvebu/patches-5.10/314-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
similarity index 100%
rename from
target/linux/mvebu/patches-5.10/315-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
rename to
target/linux/mvebu/patches-5.10/314-arm64-dts-uDPU-switch-PHY-operation-mode-to-2500base.patch
diff --git
a/target/linux/mvebu/patches-5.10/316-armada-xp-linksys-mamba-resize-kernel.patch
b/target/linux/mvebu/patches-5.10/315-armada-xp-linksys-mamba-resize-kernel.patch
similarity index 100%
rename from
target/linux/mvebu/patches-5.10/316-armada-xp-linksys-mamba-resize-kernel.patch
rename to
target/linux/mvebu/patches-5.10/315-armada-xp-linksys-mamba-resize-kernel.patch
diff --git
a/target/linux/mvebu/patches-5.10/317-armada-370-dts-fix-crypto-engine.patch
b/target/linux/mvebu/patches-5.10/316-armada-370-dts-fix-crypto-engine.patch
similarity index 100%
rename from
target/linux/mvebu/patches-5.10/317-armada-370-dts-fix-crypto-engine.patch
rename to
target/linux/mvebu/patches-5.10/316-armada-370-dts-fix-crypto-engine.patch
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uclient crash when trying to abort connection after getting HTTP headers
I'd like to abort uclient connection after getting HTTP error code in a
response header.
Example:
static void foo_header_done_cb(struct uclient *cl)
{
if (cl->status_code != 200) {
uclient_disconnect(cl);
uclient_free(cl);
}
}
The problem is that uclient_http_headers_complete() [1] after calling
"header_done" callback still uses the uclient struct. Freeing it results
in a crash. On the other hand calling uclient_disconnect() without
uclient_free() will result in memory leak.
Any hint, please?
[1] https://lxr.openwrt.org/source/uclient/uclient-http.c#L635
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
Russell Senior [2021-05-25 04:06:30]: Hi, > Looking closer, I realize that the mtd-mac-address line isn't even > needed, since it will inherit it from the included > ar9342_ubnt_xw.dtsi. > > I took a swing at replacing mtd-mac-address with nvmem-cells as in > your example, but I got an incomprehensible cascade of errors from > unrelated ath79 devices dts, like this: > > "Missing #address-cells in interrupt provider" > > which made no sense to me and I gave up. check this out https://github.com/openwrt/openwrt/pull/4041/files#diff-7b814ee8f5f9fde504d466195b8f39172897a3bb9d344a6a0b2eedf0450c11c0R113 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 2:33 AM Russell Senior
wrote:
>
> On Tue, May 25, 2021 at 1:40 AM Rafał Miłecki wrote:
> >
> > On 23.05.2021 13:59, Russell Senior wrote:
> > > + {
> > > + status = "okay";
> > > +
> > > + /* default for ar934x, except for 1000M and 10M */
> > > + pll-data = <0x0200 0x0101 0x1313>;
> > > +
> > > + mtd-mac-address = < 0x0>;
> >
> > I'd love to have new DTS use upstream "nvmem-cells" property for that basic
> > case.
> >
> > Example:
> > arm64: dts: broadcom: bcm4908: add Ethernet MAC addr
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f01f5cdb548352418b34ce77db02a560fe2913b
>
> Not sure this qualifies as a new DTS, it is derived almost entirely
> from other ubiquiti ar9342 hardware's DTS. I think such a conversion
> would make more sense to do wholesale, later on. I'm not particularly
> prepared to take that on at the moment.
Looking closer, I realize that the mtd-mac-address line isn't even
needed, since it will inherit it from the included
ar9342_ubnt_xw.dtsi.
I took a swing at replacing mtd-mac-address with nvmem-cells as in
your example, but I got an incomprehensible cascade of errors from
unrelated ath79 devices dts, like this:
"Missing #address-cells in interrupt provider"
which made no sense to me and I gave up.
>
> $ git grep mtd-mac-address | wc -l
> 1119
>
> $ git grep -l mtd-mac-address | wc -l
> 568
>
> >
> >
> > > +
> > > + phy-mode = "rgmii-id";
> > > + phy-handle = <>;
> > > +
> > > + gmac-config {
> > > + device = <>;
> > > + rxd-delay = <3>;
> > > + rxdv-delay = <3>;
> > > + };
> > > +};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 3:57 AM Russell Senior wrote: > > On Tue, May 25, 2021 at 3:33 AM Vincent Wiemann > wrote: > > > > On 5/25/21 2:23 AM, Russell Senior wrote: > > > On Mon, May 24, 2021 at 2:51 AM Vincent Wiemann > > > wrote: > > >> > > >> Hi Russel, > > >> > > >> On 5/24/21 1:06 AM, Russell Senior wrote: > > >>> On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, > > >>> not "e6 c2". > > >> > > >> That's very interesting... I think the PowerBeam 400 was sold under the > > >> NanoBeam series at the beginning. So there might be an entry missing. > > >> Is your PowerBeam old? > > > > > > It was purchased circa 2015. It is clearly marked PowerBeam M2 on the > > > sticker, along with "M/N: PBE-M2-400", although the FCCID suggests > > > some overlap with NanoBeam (SWX-NBM2HP). > > > > > > > Thank you for that information. We've also purchased a PowerBeam in 2015 > > where on the sticker it says PowerBeam, but the box stated NanoBeam... (sorry for the empty reply ... gmail--) I went and checked my box, it says PowerBeam M2. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 3:33 AM Vincent Wiemann wrote: > > On 5/25/21 2:23 AM, Russell Senior wrote: > > On Mon, May 24, 2021 at 2:51 AM Vincent Wiemann > > wrote: > >> > >> Hi Russel, > >> > >> On 5/24/21 1:06 AM, Russell Senior wrote: > >>> On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, not > >>> "e6 c2". > >> > >> That's very interesting... I think the PowerBeam 400 was sold under the > >> NanoBeam series at the beginning. So there might be an entry missing. > >> Is your PowerBeam old? > > > > It was purchased circa 2015. It is clearly marked PowerBeam M2 on the > > sticker, along with "M/N: PBE-M2-400", although the FCCID suggests > > some overlap with NanoBeam (SWX-NBM2HP). > > > > Thank you for that information. We've also purchased a PowerBeam in 2015 > where on the sticker it says PowerBeam, but the box stated NanoBeam... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 netifd] interface: rename "ifname" attribute to "device"
On 2021-05-24 15:35, Rafał Miłecki wrote: > From: Rafał Miłecki > > Interfaces need to be assigned to devices. For that purpose a "device" > option should be more accurate than "ifname" one. > > For backward compatibility add a temporary config translation. > > Config example: > > config device > option name 'br-lan' > option type 'bridge' > list ports 'lan1' > list ports 'lan2' > > config interface 'lan' > option device 'br-lan' > option proto 'static' > > Signed-off-by: Rafał Miłecki I think the code for backwards compatibility would be a lot simpler if you add both IFACE_ATTR_DEVICE and IFACE_ATTR_IFNAME and initialize tb[IFACE_ATTR_DEVICE] to tb[IFACE_ATTR_IFNAME] if it's NULL. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On 5/25/21 2:23 AM, Russell Senior wrote: On Mon, May 24, 2021 at 2:51 AM Vincent Wiemann wrote: Hi Russel, On 5/24/21 1:06 AM, Russell Senior wrote: On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, not "e6 c2". That's very interesting... I think the PowerBeam 400 was sold under the NanoBeam series at the beginning. So there might be an entry missing. Is your PowerBeam old? It was purchased circa 2015. It is clearly marked PowerBeam M2 on the sticker, along with "M/N: PBE-M2-400", although the FCCID suggests some overlap with NanoBeam (SWX-NBM2HP). Thank you for that information. We've also purchased a PowerBeam in 2015 where on the sticker it says PowerBeam, but the box stated NanoBeam... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 1:40 AM Rafał Miłecki wrote:
>
> On 23.05.2021 13:59, Russell Senior wrote:
> > + {
> > + status = "okay";
> > +
> > + /* default for ar934x, except for 1000M and 10M */
> > + pll-data = <0x0200 0x0101 0x1313>;
> > +
> > + mtd-mac-address = < 0x0>;
>
> I'd love to have new DTS use upstream "nvmem-cells" property for that basic
> case.
>
> Example:
> arm64: dts: broadcom: bcm4908: add Ethernet MAC addr
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f01f5cdb548352418b34ce77db02a560fe2913b
Not sure this qualifies as a new DTS, it is derived almost entirely
from other ubiquiti ar9342 hardware's DTS. I think such a conversion
would make more sense to do wholesale, later on. I'm not particularly
prepared to take that on at the moment.
$ git grep mtd-mac-address | wc -l
1119
$ git grep -l mtd-mac-address | wc -l
568
>
>
> > +
> > + phy-mode = "rgmii-id";
> > + phy-handle = <>;
> > +
> > + gmac-config {
> > + device = <>;
> > + rxd-delay = <3>;
> > + rxdv-delay = <3>;
> > + };
> > +};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On 23.05.2021 13:59, Russell Senior wrote:
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ mtd-mac-address = < 0x0>;
I'd love to have new DTS use upstream "nvmem-cells" property for that basic
case.
Example:
arm64: dts: broadcom: bcm4908: add Ethernet MAC addr
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f01f5cdb548352418b34ce77db02a560fe2913b
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
