Re: Interface names when putting 802.1q VLAN on top of bonding configuration
On 28.05.2021 03:36, Mike Bernardo wrote: I have the below working config, is there a way to get the name to be 'vlan20', instead of 'bonding-lan.20' ? I have tried a bunch of stuff and so far nothing has worked. I don't think you can change Linux interface name. I believe this is how Linux handles VLANs. That "vlan20" visible in your config is a hint for OpenWrt logical interface name. So you should have ubus object: network.interface.vlan20 in your case. You can use (object) name when managing interface, e.g.: ubus call network.interface.vlan20 status That name is also what you'll see in LuCI if you happen to use it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Interface names when putting 802.1q VLAN on top of bonding configuration
Hi, I have the below working config, is there a way to get the name to be 'vlan20', instead of 'bonding-lan.20' ? I have tried a bunch of stuff and so far nothing has worked. Thanks for any help! Mike config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdb9:bf48:0362::/48' config interface 'lan' option proto 'bonding' option auto '1' option ipaddr '172.20.32.250' option netmask '255.255.255.0' option ip6assign '60' option bonding_policy '802.3ad' option link_monitoring 'mii' option slaves 'eth1' option lacp_rate 'fast' option miimon '100' option use_carrier 1 option xmit_hash_policy 'layer3+4' option gateway '172.20.32.1' option force_link '1' config interface 'vlan20' option auto '1' option force_link '1' option ifname 'bonding-lan.20' option proto 'static' option name 'vlan20' option ipaddr '172.20.34.2' option netmask '255.255.255.128' root@OpenWrt:/etc/config# ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether d0:50:99:d4:f7:80 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc mq master bonding-lan state UP group default qlen 1000 link/ether d0:50:99:d4:f7:81 brd ff:ff:ff:ff:ff:ff 4: bond0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 52:d7:61:b2:0c:b3 brd ff:ff:ff:ff:ff:ff 29: bonding-lan: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether d0:50:99:d4:f7:81 brd ff:ff:ff:ff:ff:ff inet 172.20.32.250/24 brd 172.20.32.255 scope global bonding-lan valid_lft forever preferred_lft forever inet6 fdb9:bf48:362::1/60 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::d250:99ff:fed4:f781/64 scope link valid_lft forever preferred_lft forever 30: bonding-lan.20@bonding-lan: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether d0:50:99:d4:f7:81 brd ff:ff:ff:ff:ff:ff inet 172.20.34.2/25 brd 172.20.34.127 scope global bonding-lan.20 valid_lft forever preferred_lft forever inet6 fe80::d250:99ff:fed4:f781/64 scope link valid_lft forever preferred_lft forever ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] ath79: add support for Ubiquiti PowerBeam M (XW)
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
since v1:
* renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
since v2:
* removed redundant mtd-mac-address from dts
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 34 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 44 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
new file mode 100644
index 00..6db058f887
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 1990353394..35ce90aeb4 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4133b9d7d3..6e31cdac69 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -85,6 +85,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m|\
ubnt,unifiac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 733d803d7a..5948e059e8 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m-xw
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m-xw
+
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.31.1
___
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)
I am going to send a v3 patch with the redundant mtd-mac-address
removed in a few minutes, hopefully in-reply-to this thread if I can
manage to do it right.
On Thu, May 27, 2021 at 3:01 PM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Vincent Wiemann
> > Sent: Sonntag, 23. Mai 2021 14:20
> > To: Russell Senior ; openwrt-
> > de...@lists.openwrt.org
> > Subject: Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
> >
> > Just as a side-note:
> > There are 5 different versions of the PowerBeam with different device IDs...
> >
> > Source:
> > https://github.com/freifunk-gluon/gluon/issues/94#issuecomment-
> > 510831878
> > -- PowerBeam M5
> > -- ERP 26 dBm according to datasheet
> > 'e3e5' = { -- PBE-M5-300
> > pa_gain = 4
> > ant_gain = 22
> > },
> > 'e4e5' = { -- PBE-M5-400
> > pa_gain = 4
> > ant_gain = 25
> > },
> > 'e6e5' = { -- PBE-M5-400 ISO!!
> > pa_gain = 4
> > ant_gain = 25
> > },
> > 'e885' = { -- PBE-M5-620
> > pa_gain = 4
> > ant_gain = 29
> > },
> >
> > -- Powerbeam M2 400?
> > -- ERP 28 dBm according to datasheet
> > 'e6c2' = { -- PBE-M2-400
> > pa_gain = 6
> > ant_gain = 18 dBi
> > },
> >
> > While I think there shouldn't be different DTS files for them, there is a
> > script
> > missing that respects the antenna and external PA gain of these devices.
>
> So far, we have not cared about this at device-support level (at all) as far
> as I remember.
> I'm not sure whether we apply antenna gain for ath79 Ubiquiti _at all_ by
> default. (From what I remember we don't).
>
> So, I tend to not care about this for this particular PR.
>
> Best
>
> Adrian
>
> >
> > Best,
> >
> > Vincent
> >
> >
> >
> > On 5/23/21 1:59 PM, Russell Senior wrote:
> > > This patch adds support for the Ubiquiti PowerBeam M (XW), e.g.
> > > PBE-M5-400, a 802.11n wireless with a feed+dish form factor. This
> > > device was previously supported by the ar71xx loco-m-xw firmware.
> > >
> > > Specifications:
> > > - Atheros AR9342 SoC
> > > - 64 MB RAM
> > > - 8 MB SPI flash
> > > - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> > > - Power and LAN green LEDs
> > > - 4x RSSI LEDs (red, orange, green, green)
> > > - UART (115200 8N1)
> > >
> > > Flashing via stock GUI:
> > > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > > device! Read the wiki for more info.
> > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > > - Upload the factory image via AirOS web GUI.
> > >
> > > Flashing via TFTP:
> > > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > > device! Read the wiki for more info.
> > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > > - Use a pointy tool (e.g., unbent paperclip) to keep the
> > > reset button pressed.
> > > - Power on the device (keep reset button pressed).
> > > - Keep pressing until LEDs flash alternatively LED1+LED3 =>
> > > LED2+LED4 => LED1+LED3, etc.
> > > - Release reset button.
> > > - The device starts a TFTP server at 192.168.1.20.
> > > - Set a static IP on the computer (e.g., 192.168.1.21/24).
> > > - Upload via tftp the factory image:
> > > $ tftp 192.168.1.20
> > > tftp> bin
> > > tftp> trace
> > > tftp> put
> > > openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-
> > factory.bin
> > >
> > > WARNING: so far, no non-destructive method has been discovered for
> > > opening the enclosure to reach the serial console. Internal photos are
> > > available here: https://fcc.io/SWX-NBM5HP
> > >
> > > Changes since v1:
> > > * renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
> > >
> > > Signed-off-by: Russell Senior
> > > ---
> > > .../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 36
> > +++
> > > .../generic/base-files/etc/board.d/01_leds| 1 +
> > > .../generic/base-files/etc/board.d/02_network | 1 +
> > > target/linux/ath79/image/generic-ubnt.mk | 8 +
> > > 4 files changed, 46 insertions(+)
> > > create mode 100644
> > > target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > >
> > > diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > > b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > > new file mode 100644
> > > index 00..edcb06acef
> > > --- /dev/null
> > > +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > > @@ -0,0 +1,36 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > > +
> > >
[PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility
MikroTik boards with 512 byte NAND pages require the old YAFFS1 OOB
layout for compatibility with the RouterBoot bootloader. The RB4xx NAND
driver supports such OOB layout, but checks a NAND page size too early
before the flash identification, what effectively preventing the old OOB
layout from being used.
To fix this issue, move the page size check and OOB layout configuration
to the chip attaching hook, which is specially intorduced for ECC and
OOB tweaking.
While at it, copy a comment from the old AR71xx driver to make it clear,
why do we need this OOB layout tweaking.
Run tested with MikroTik RB411U board.
Signed-off-by: Sergey Ryazanov
---
.../files/drivers/mtd/nand/raw/nand_rb4xx.c | 25 ---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
index 50bd69f6a4..00c65d14ae 100644
--- a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
@@ -81,6 +81,23 @@ static const struct mtd_ooblayout_ops
rb4xx_nand_ecclayout_ops = {
.free = rb4xx_ooblayout_free,
};
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+* Now we knows flash parameters and can tweak OOB the layout for old
+* (usually 64MiB) flashes.
+*
+* We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+* bootloader will not be able to find the kernel that we load.
+*/
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip *chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops = {
+ .attach_chip = rb4xx_nand_attach_chip,
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
-
nand->chip.ecc.mode = NAND_ECC_SOFT;
nand->chip.ecc.algo = NAND_ECC_HAMMING;
nand->chip.options = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops = _nand_controller_ops;
ret = nand_scan(>chip, 1);
if (ret)
--
2.26.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)
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Vincent Wiemann
> Sent: Sonntag, 23. Mai 2021 14:20
> To: Russell Senior ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
>
> Just as a side-note:
> There are 5 different versions of the PowerBeam with different device IDs...
>
> Source:
> https://github.com/freifunk-gluon/gluon/issues/94#issuecomment-
> 510831878
> -- PowerBeam M5
> -- ERP 26 dBm according to datasheet
> 'e3e5' = { -- PBE-M5-300
> pa_gain = 4
> ant_gain = 22
> },
> 'e4e5' = { -- PBE-M5-400
> pa_gain = 4
> ant_gain = 25
> },
> 'e6e5' = { -- PBE-M5-400 ISO!!
> pa_gain = 4
> ant_gain = 25
> },
> 'e885' = { -- PBE-M5-620
> pa_gain = 4
> ant_gain = 29
> },
>
> -- Powerbeam M2 400?
> -- ERP 28 dBm according to datasheet
> 'e6c2' = { -- PBE-M2-400
> pa_gain = 6
> ant_gain = 18 dBi
> },
>
> While I think there shouldn't be different DTS files for them, there is a
> script
> missing that respects the antenna and external PA gain of these devices.
So far, we have not cared about this at device-support level (at all) as far as
I remember.
I'm not sure whether we apply antenna gain for ath79 Ubiquiti _at all_ by
default. (From what I remember we don't).
So, I tend to not care about this for this particular PR.
Best
Adrian
>
> Best,
>
> Vincent
>
>
>
> On 5/23/21 1:59 PM, Russell Senior wrote:
> > This patch adds support for the Ubiquiti PowerBeam M (XW), e.g.
> > PBE-M5-400, a 802.11n wireless with a feed+dish form factor. This
> > device was previously supported by the ar71xx loco-m-xw firmware.
> >
> > Specifications:
> > - Atheros AR9342 SoC
> > - 64 MB RAM
> > - 8 MB SPI flash
> > - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> > - Power and LAN green LEDs
> > - 4x RSSI LEDs (red, orange, green, green)
> > - UART (115200 8N1)
> >
> > Flashing via stock GUI:
> > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > device! Read the wiki for more info.
> > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > - Upload the factory image via AirOS web GUI.
> >
> > Flashing via TFTP:
> > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > device! Read the wiki for more info.
> > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > - Use a pointy tool (e.g., unbent paperclip) to keep the
> > reset button pressed.
> > - Power on the device (keep reset button pressed).
> > - Keep pressing until LEDs flash alternatively LED1+LED3 =>
> > LED2+LED4 => LED1+LED3, etc.
> > - Release reset button.
> > - The device starts a TFTP server at 192.168.1.20.
> > - Set a static IP on the computer (e.g., 192.168.1.21/24).
> > - Upload via tftp the factory image:
> > $ tftp 192.168.1.20
> > tftp> bin
> > tftp> trace
> > tftp> put
> > openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-
> factory.bin
> >
> > WARNING: so far, no non-destructive method has been discovered for
> > opening the enclosure to reach the serial console. Internal photos are
> > available here: https://fcc.io/SWX-NBM5HP
> >
> > Changes since v1:
> > * renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
> >
> > Signed-off-by: Russell Senior
> > ---
> > .../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 36
> +++
> > .../generic/base-files/etc/board.d/01_leds| 1 +
> > .../generic/base-files/etc/board.d/02_network | 1 +
> > target/linux/ath79/image/generic-ubnt.mk | 8 +
> > 4 files changed, 46 insertions(+)
> > create mode 100644
> > target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> >
> > diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > new file mode 100644
> > index 00..edcb06acef
> > --- /dev/null
> > +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > @@ -0,0 +1,36 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +
> > +#include "ar9342_ubnt_xw.dtsi"
> > +
> > +/ {
> > + compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
> > + model = "Ubiquiti PowerBeam M (XW)"; };
> > +
> > + {
> > + status = "okay";
> > +
> > + phy-mask = <4>;
> > +
> > + phy4: ethernet-phy@4 {
> > + reg = <4>;
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +
> > + /* default for ar934x, except for 1000M and 10M */
> > + pll-data = <0x0200 0x0101
[PATCH luci] luci-mod-network: allow setting bridge device MTU and MAC
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/tools/network.js | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
b/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
index 12ed08ad17..199cd0f152 100644
--- a/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
+++ b/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
@@ -610,11 +610,13 @@ return baseclass.extend({
o.placeholder = getDeviceValue(dev, 'getMTU');
o.datatype = 'max(9200)';
o.depends('type', '');
+ o.depends('type', 'bridge');
o = this.addOption(s, 'devgeneral', form.Value, 'macaddr',
_('MAC address'));
o.placeholder = getDeviceValue(dev, 'getMAC');
o.datatype = 'macaddr';
o.depends('type', '');
+ o.depends('type', 'bridge');
o.depends('type', 'macvlan');
o.depends('type', 'veth');
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] ath10k-ct: backport upstream fixes for FragAttacks
I am aware, just haven't had time to work on it yet. Thanks, Ben On 5/27/21 4:05 AM, Nick Lowe wrote: Hi Hauke, I wonder if it is worth also opening an issue for this over at https://github.com/greearb/ath10k-ct/issues ? Best, Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
On 23.05.21 11:01, Adrian Schmutzler wrote: ... diff --git a/target/linux/ath79/image/mikrotik.mk b/target/linux/ath79/image/mikrotik.mk index 74f8603b5a..0072ec527d 100644 --- a/target/linux/ath79/image/mikrotik.mk +++ b/target/linux/ath79/image/mikrotik.mk @@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g endef TARGET_DEVICES += mikrotik_routerboard-493g +define Device/mikrotik_routerboard-912g + $(Device/mikrotik_nand) + SOC := ar9342 + DEVICE_MODEL := RouterBOARD 912G + DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper + SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd endef So, both have exactly the same setup as implemented here? Best Adrian yes. I personally use rb-912uag-5hpnd board. The hardware is identical with the exception of the band used. What's your 2 cents to get both supported using a single target? Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] ath10k-ct: backport upstream fixes for FragAttacks
Hi Hauke, I wonder if it is worth also opening an issue for this over at https://github.com/greearb/ath10k-ct/issues ? Best, Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools/isl: bump to 0.24
Tested with Graphite and -floop-nest-optimize, without issues. Signed-off-by: Rui Salvaterra --- tools/isl/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/isl/Makefile b/tools/isl/Makefile index c1000e1e31..be372fe2a8 100644 --- a/tools/isl/Makefile +++ b/tools/isl/Makefile @@ -7,11 +7,11 @@ include $(TOPDIR)/rules.mk PKG_NAME:=isl -PKG_VERSION:=0.20 +PKG_VERSION:=0.24 PKG_SOURCE_URL:=http://isl.gforge.inria.fr PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz -PKG_HASH:=a5596a9fb8a5b365cb612e4b9628735d6e67e9178fae134a816ae195017e77aa +PKG_HASH:=043105cc544f416b48736fff8caf077fb0663a717d06b1113f16e391ac99ebad HOST_BUILD_PARALLEL:=1 -- 2.31.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ugps: start also in case device is absent
Don't bail out from init script in case the GPS device is missing.
Some modems take time to come up, and some people may use things like
'kplex' to feed ugpsd. Hence it is better to always start ugpsd
unconditionally and let procd's respawn take care of retrying.
Signed-off-by: Daniel Golle
---
package/utils/ugps/Makefile| 2 +-
package/utils/ugps/files/ugps.init | 12
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/package/utils/ugps/Makefile b/package/utils/ugps/Makefile
index 4ce64d9631..16cdbc41b9 100644
--- a/package/utils/ugps/Makefile
+++ b/package/utils/ugps/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=ugps
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_URL=$(PROJECT_GIT)/project/ugps.git
PKG_SOURCE_PROTO:=git
diff --git a/package/utils/ugps/files/ugps.init
b/package/utils/ugps/files/ugps.init
index 3cd1ca1b8d..f52b19cc27 100644
--- a/package/utils/ugps/files/ugps.init
+++ b/package/utils/ugps/files/ugps.init
@@ -17,10 +17,14 @@ start_service() {
[ "$disabled" == "0" ] || return
- [ -c "$tty" ] || {
- tty="/dev/$tty"
- [ -c "$tty" ] || return
- }
+ case "$tty" in
+ "/"*)
+ true
+ ;;
+ *)
+ tty="/dev/$tty"
+ ;;
+ esac
procd_open_instance
procd_set_param command "$PROG"
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[Bug] ag71xx: MTU limited to 1516
Hello, I run a batman-adv mesh consisting of several Ubiquiti UniFi AC Mesh Pro. Some of the devices are connected over gigabit ethernet and I want to use the wired connection as a mesh backhaul. This requires setting the ethernet MTU to at least 1528 bytes, since batman-adv prepends its own header to packets entering the mesh. This shouldn't be a problem since both the Qualcomm Atheros QCA956X SoC and the Atheros AR8337 switch support jumbo frames. However, after doing some testing I figured out that I can only set the MTU to a value up to 1516. If I go higher, ifconfig fails with the error message 'SIOCSIFMTU: Invalid argument': # ifconfig eth0 mtu 9000 ifconfig: SIOCSIFMTU: Invalid argument # ifconfig eth0 mtu 4072 ifconfig: SIOCSIFMTU: Invalid argument # ifconfig eth0 mtu 1500 # ifconfig eth0 mtu 1490 # ifconfig eth0 mtu 1520 ifconfig: SIOCSIFMTU: Invalid argument # ifconfig eth0 mtu 1516 # ifconfig eth0 mtu 1517 ifconfig: SIOCSIFMTU: Invalid argument This issue exists both in OpenWrt 19.07.7 and 21.02.0-rc1. I did some research and found older reports suggesting that other devices are also affected by this issue. (https://forum.openwrt.org/t/ag71xx-gigabit-e-g-archer-c7-v5-eth-raising-mtu-problem-regression/44138, https://dev.archive.openwrt.org/ticket/18296) Is anybody around who can help fixing the problem? I think https://forum.openwrt.org/t/ag71xx-gigabit-e-g-archer-c7-v5-eth-raising-mtu-problem-regression/44138 already describes a potential patch. Thanks! Regards, Dominik ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
From: Denis Kalashnikov
This board has been supported in the ar71xx.
Links:
* https://mikrotik.com/product/RB912UAG-2HPnD
* https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd
Hardware:
* SoC: Atheros AR9342,
* RAM: DDR 64MB,
* SPI NOR: 64KB,
* NAND: 128MB,
* Ethernet: x1 10/100/1000 port with passive POE in,
* Wi-Fi: 802.11 b/g/n,
* PCIe,
* USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A
port -- both can be used for LTE modem. But only one can be used.
* LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED,
Ethernet phy LED,
* Button,
* Beeper.
Not working:
* Button: it shares gpio line 15 with NAND ALE and NAND IO7,
and current drivers doesn't easily support this configuration,
* Beeper: it is connected to bit 5 of a serial shift register
(tested with sysfs led trigger timer). But kmod-gpio-beeper
doesn't work -- we left this as is for now.
Flashing:
* Use the RouterBOARD Reset button to enable TFTP netboot,
boot kernel and initramfs and then perform sysupgrade.
* From ar71xx OpenWrt firmware run:
$ sysupgrade -F /tmp/
For more info see: https://openwrt.org/toh/mikrotik/common.
Co-Developed-by: Koen Vandeputte
Signed-off-by: Denis Kalashnikov
---
Changelog:
RFC v1 --> RFC v2
- Delete uneeded comments from DTS,
- Delete ascii-art of board scheme near NAND latch from DTS,
- Rewrite gpio_latch and nand_gpio nodes to be consistent with the
new versions of drivers,
- Fix SPI NOR flash and SPI serial shift register maximum speeds
(thanks to Koen Vandeputte),
- Add UART, PCIe, USB support and gpio exports (thanks to Koen Vandeputte),
- Fix Ethernet node (thanks to Koen Vandeputte),
- Add key and beeper nodes in disabled state just to be documented.
RFC v2 --> v1
- Add led aliases -- now OpenWrt controls power led,
- Remove disabled nodes (reset key and gpio-beeper),
- Fix gpio-export node,
- Fix model name,
- Move gpio_nand and gpio_latch nodes from ahb node to the root node.
---
...9342_mikrotik_routerboard-912uag-2hpnd.dts | 214 ++
target/linux/ath79/image/mikrotik.mk | 9 +
.../base-files/etc/board.d/02_network | 2 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
.../base-files/lib/upgrade/platform.sh| 1 +
5 files changed, 227 insertions(+)
create mode 100644
target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
diff --git
a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
new file mode 100644
index 00..ffca700e0a
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "ar9344.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "mikrotik,routerboard-912uag-2hpnd", "qca,ar9342";
+ model = "MikroTik RouterBOARD 912UAG-2HPnD";
+
+ aliases {
+led-boot = _power;
+led-failsafe = _power;
+led-running = _power;
+led-upgrade = _power;
+};
+
+ gpio_latch: gpio_latch {
+ compatible = "gpio-latch";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpios = < 0 GPIO_ACTIVE_HIGH>,
+ < 1 GPIO_ACTIVE_HIGH>,
+ < 2 GPIO_ACTIVE_HIGH>,
+ < 3 GPIO_ACTIVE_HIGH>,
+ <0>, /* Not connected */
+ < 13 GPIO_ACTIVE_HIGH>,
+ < 14 GPIO_ACTIVE_HIGH>,
+ < 15 GPIO_ACTIVE_HIGH>,
+ < 11 GPIO_ACTIVE_LOW>; /* Latch Enable */
+ };
+
+ nand_gpio {
+ compatible = "mikrotik,rb91x-nand";
+
+ gpios = <_latch 3 GPIO_ACTIVE_HIGH>, /* Read */
+ < 4 GPIO_ACTIVE_HIGH>, /* Ready (RDY) */
+ <_latch 5 GPIO_ACTIVE_LOW>, /* Chip Enable (nCE)
*/
+ <_latch 6 GPIO_ACTIVE_HIGH>, /* Command Latch
Enable (CLE) */
+ <_latch 7 GPIO_ACTIVE_HIGH>, /* Address Latch
Enable (ALE) */
+ < 12 GPIO_ACTIVE_LOW>, /* Read/Write Enable
(nRW) */
+ <_latch 8 GPIO_ACTIVE_LOW>; /* Latch Enable (nLE)
*/
+
+ partitions {
+ compatible = "fixed-partitions";
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "booter";
+ reg = <0x0 0x004>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "kernel";
+ reg = <0x004 0x03c>;
+ };
+
+ partition@40 {
+ label = "ubi";
+
[PATCH 2/3] ath79: add NAND driver for MikroTik RB91xG series
From: Denis Kalashnikov
Main part is copied from ar71xx original driver rb91x_nand
written by Gabor Juhos .
What is done:
* Support of kernel 5.4 and 5.10,
* DTS support,
* New gpio API (gpiod_*) support.
Signed-off-by: Denis Kalashnikov
---
Changelog:
RFC v1 --> RFC v2
- Do not use MFD driver API anymore,
- Change DTS node params,
- Use the new gpio API (gpiod_*),
- Add kernel 5.10 support.
RFC v2 --> v1
- Get partitions info from DTS,
- Change DTS node params: use a gpios array instead of
separate named gpios params,
- Minor cosmetic code fixes.
---
.../files/drivers/mtd/nand/raw/rb91x_nand.c | 375 ++
target/linux/ath79/mikrotik/config-default| 1 +
.../patches-5.10/939-mikrotik-rb91x.patch | 23 ++
.../patches-5.4/939-mikrotik-rb91x.patch | 21 +
4 files changed, 420 insertions(+)
create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
new file mode 100644
index 00..e231944519
--- /dev/null
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
@@ -0,0 +1,375 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * MikroTik RB91x NAND flash driver
+ *
+ * Main part is copied from original driver written by Gabor Juhos.
+ *
+ * Copyright (C) 2013-2014 Gabor Juhos
+ */
+
+/*
+ * WARNING: to speed up NAND reading/writing we are working with SoC GPIO
+ * controller registers directly -- not through standard GPIO API.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Bit masks for NAND data lines in ath79 gpio 32-bit register */
+#define RB91X_NAND_NRW_BIT BIT(12)
+#define RB91X_NAND_DATA_BITS (BIT(0) | BIT(1) | BIT(2) | BIT(3) | BIT(4) \
+ | BIT(13) | BIT(14) | BIT(15))
+#define RB91X_NAND_LOW_DATA_MASK 0x1f
+#define RB91X_NAND_HIGH_DATA_MASK 0xe0
+#define RB91X_NAND_HIGH_DATA_SHIFT 8
+
+enum rb91x_nand_gpios {
+ RB91X_NAND_READ,/* Read */
+ RB91X_NAND_RDY, /* NAND Ready */
+ RB91X_NAND_NCE, /* Chip Enable. Active low */
+ RB91X_NAND_CLE, /* Command Latch Enable */
+ RB91X_NAND_ALE, /* Address Latch Enable */
+ RB91X_NAND_NRW, /* Read/Write. Active low */
+ RB91X_NAND_NLE, /* Latch Enable. Active low */
+
+ RB91X_NAND_GPIOS,
+};
+
+struct rb91x_nand_drvdata {
+ struct nand_chip chip;
+ struct device *dev;
+ struct gpio_desc **gpio;
+ void __iomem *ath79_gpio_base;
+};
+
+static inline void rb91x_nand_latch_lock(struct rb91x_nand_drvdata *drvdata,
+int lock)
+{
+ gpiod_set_value_cansleep(drvdata->gpio[RB91X_NAND_NLE], lock);
+}
+
+static int rb91x_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ switch (section) {
+ case 0:
+ oobregion->offset = 8;
+ oobregion->length = 3;
+ return 0;
+ case 1:
+ oobregion->offset = 13;
+ oobregion->length = 3;
+ return 0;
+ default:
+ return -ERANGE;
+ }
+}
+
+static int rb91x_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ switch (section) {
+ case 0:
+ oobregion->offset = 0;
+ oobregion->length = 4;
+ return 0;
+ case 1:
+ oobregion->offset = 4;
+ oobregion->length = 1;
+ return 0;
+ case 2:
+ oobregion->offset = 6;
+ oobregion->length = 2;
+ return 0;
+ case 3:
+ oobregion->offset = 11;
+ oobregion->length = 2;
+ return 0;
+ default:
+ return -ERANGE;
+ }
+}
+
+static const struct mtd_ooblayout_ops rb91x_nand_ecclayout_ops = {
+ .ecc = rb91x_ooblayout_ecc,
+ .free = rb91x_ooblayout_free,
+};
+
+static void rb91x_nand_write(struct rb91x_nand_drvdata *drvdata,
+const u8 *buf,
+unsigned len)
+{
+ void __iomem *base = drvdata->ath79_gpio_base;
+ u32 oe_reg;
+ u32 out_reg;
+ u32 out;
+ unsigned i;
+
+ rb91x_nand_latch_lock(drvdata, 1);
+
+ oe_reg = __raw_readl(base + AR71XX_GPIO_REG_OE);
+ out_reg = __raw_readl(base + AR71XX_GPIO_REG_OUT);
+
+ /* Set data lines to output mode */
+ __raw_writel(oe_reg & ~(RB91X_NAND_DATA_BITS | RB91X_NAND_NRW_BIT),
+base + AR71XX_GPIO_REG_OE);
+
+ out = out_reg & ~(RB91X_NAND_DATA_BITS | RB91X_NAND_NRW_BIT);
+ for (i = 0; i != len; i++) {
+ u32 data;
+
+ data = (buf[i] & RB91X_NAND_HIGH_DATA_MASK) <<
+
[PATCH 1/3] ath79: add gpio-latch driver for MikroTik RouterBOARDs
From: Denis Kalashnikov
This is a slighty modified version of ar71xx gpio-latch driver
written by Gabor Juhos .
Changes:
* DTS support,
* New gpio API (gpiod_*).
Signed-off-by: Denis Kalashnikov
---
Changelog:
RFC v1 --> RFC v2
- Don't use MFD driver API anymore,
- Use the new gpio API (gpiod_*),
- Add support of kernel 5.10.
RFC v2 --> v1
- Change DTS node params -- remove redundant latch-enable-gpios param,
- Delete unneeded direction input callback (latch is output-only),
- Add support of pin holes (unconnected lines of the latch).
---
.../ath79/files/drivers/gpio/gpio-latch.c | 203 ++
.../patches-5.10/939-mikrotik-rb91x.patch | 26 +++
.../patches-5.4/939-mikrotik-rb91x.patch | 23 ++
3 files changed, 252 insertions(+)
create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c
create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch
create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch
diff --git a/target/linux/ath79/files/drivers/gpio/gpio-latch.c
b/target/linux/ath79/files/drivers/gpio/gpio-latch.c
new file mode 100644
index 00..f3545a663e
--- /dev/null
+++ b/target/linux/ath79/files/drivers/gpio/gpio-latch.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * GPIO latch driver
+ *
+ * Copyright (C) 2014 Gabor Juhos
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GPIO_LATCH_DRIVER_NAME "gpio-latch"
+#define GPIO_LATCH_LINES 9
+
+struct gpio_latch_chip {
+ struct gpio_chip gc;
+ struct mutex mutex;
+ struct mutex latch_mutex;
+ bool latch_enabled;
+ int le_gpio;
+ bool le_active_low;
+ struct gpio_desc *gpios[GPIO_LATCH_LINES];
+};
+
+static inline struct gpio_latch_chip *to_gpio_latch_chip(struct gpio_chip *gc)
+{
+ return container_of(gc, struct gpio_latch_chip, gc);
+}
+
+static void gpio_latch_lock(struct gpio_latch_chip *glc, bool enable)
+{
+ mutex_lock(>mutex);
+
+ if (enable)
+ glc->latch_enabled = true;
+
+ if (glc->latch_enabled)
+ mutex_lock(>latch_mutex);
+}
+
+static void gpio_latch_unlock(struct gpio_latch_chip *glc, bool disable)
+{
+ if (glc->latch_enabled)
+ mutex_unlock(>latch_mutex);
+
+ if (disable)
+ glc->latch_enabled = true;
+
+ mutex_unlock(>mutex);
+}
+
+static int
+gpio_latch_get(struct gpio_chip *gc, unsigned offset)
+{
+ struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
+ int ret;
+
+ gpio_latch_lock(glc, false);
+ ret = gpiod_get_value(glc->gpios[offset]);
+ gpio_latch_unlock(glc, false);
+
+ return ret;
+}
+
+static void
+gpio_latch_set(struct gpio_chip *gc, unsigned offset, int value)
+{
+ struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
+ bool enable_latch = false;
+ bool disable_latch = false;
+
+ if (offset == glc->le_gpio) {
+ enable_latch = value ^ glc->le_active_low;
+ disable_latch = !enable_latch;
+ }
+
+ gpio_latch_lock(glc, enable_latch);
+ gpiod_set_raw_value(glc->gpios[offset], value);
+ gpio_latch_unlock(glc, disable_latch);
+}
+
+static int
+gpio_latch_direction_output(struct gpio_chip *gc, unsigned offset, int value)
+{
+ struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
+ bool enable_latch = false;
+ bool disable_latch = false;
+ int ret;
+
+ if (offset == glc->le_gpio) {
+ enable_latch = value ^ glc->le_active_low;
+ disable_latch = !enable_latch;
+ }
+
+ gpio_latch_lock(glc, enable_latch);
+ ret = gpiod_direction_output_raw(glc->gpios[offset], value);
+ gpio_latch_unlock(glc, disable_latch);
+
+ return ret;
+}
+
+static int gpio_latch_probe(struct platform_device *pdev)
+{
+ struct gpio_latch_chip *glc;
+ struct gpio_chip *gc;
+ struct device *dev = >dev;
+ struct device_node *of_node = dev->of_node;
+ int i, n;
+
+ glc = devm_kzalloc(dev, sizeof(*glc), GFP_KERNEL);
+ if (!glc)
+ return -ENOMEM;
+
+ mutex_init(>mutex);
+ mutex_init(>latch_mutex);
+
+ n = gpiod_count(dev, NULL);
+ if (n <= 0) {
+ dev_err(dev, "failed to get gpios: %d\n", n);
+ return n;
+ } else if (n != GPIO_LATCH_LINES) {
+ dev_err(dev, "expected %d gpios\n", GPIO_LATCH_LINES);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < n; i++) {
+ glc->gpios[i] = devm_gpiod_get_index_optional(dev, NULL, i,
+ GPIOD_OUT_LOW);
+ if (IS_ERR(glc->gpios[i])) {
+ dev_err(dev, "failed to get gpio %d: %d\n", i,
+ PTR_ERR(glc->gpios[i]));
+ return PTR_ERR(glc->gpios[i]);
+ }
+
[PATCH 0/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
From: Denis Kalashnikov RB912 needs two ad hoc drivers: gpio-latch and rb91x_nand. So I've ported them from ar71xx and added DTS. In RFC v1 I added a MFD driver that provided API for manipulating shared gpio lines to gpio-latch and nand drivers. In RFC v2 I just ported gpio-latch and rb91x_nand drivers from ar71xx to ath79 by adding DTS support and usage of a new gpio API (gpiod_*). This way is turned to be more clear and compact. So, I've tried to fix what you guys advised me and here is my patches v1. All seems to be working on my RB912UAG-2HPnD. Except a button and a beeper. The beeper seems is not important thing, but the button is. The button shares gpio 15 with NAND ALE and NAND IO7, but this is not easily supported by the current drivers. May be we need ad hoc driver for button. Or may be there is a more general solution for this problem (like rb91x-gpio driver that arbitrates all gpio lines instead of gpio-latch). This can be fixed in the next patches. Denis Kalashnikov (3): ath79: add gpio-latch driver for MikroTik RouterBOARDs ath79: add NAND driver for MikroTik RB91xG series ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD ...9342_mikrotik_routerboard-912uag-2hpnd.dts | 214 ++ .../ath79/files/drivers/gpio/gpio-latch.c | 203 ++ .../files/drivers/mtd/nand/raw/rb91x_nand.c | 375 ++ target/linux/ath79/image/mikrotik.mk | 9 + .../base-files/etc/board.d/02_network | 2 + .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 + .../base-files/lib/upgrade/platform.sh| 1 + target/linux/ath79/mikrotik/config-default| 1 + .../patches-5.10/939-mikrotik-rb91x.patch | 49 +++ .../patches-5.4/939-mikrotik-rb91x.patch | 44 ++ 10 files changed, 899 insertions(+) create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch -- 2.26.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
John Crispin writes: > that ubnt 6-lr unit boots fine with HEAD and delivers good > performance. It is really hard to get hold of them right now in EU. I > managed to get one as "used" on ebay and after initial testing sent it > off to Daniel s.T. he can give it some loving care in regards to > uboot. hoping to get another one soonish. Thanks. Sounds good. I've noticed the delivery problems. But at least I can order it in a local shop - and wait.. Still wondering about the multigig port. I guess it's an excuse to get a multigig PoE switch so I can test :-) > the only caveate with that unit is that on 2G it uses the built in > wmac which is only HT. Not a big problem for me. 2G is too crowded to be useful for anything at all. Could probably do just fine without a 2G radio. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
