On 02/06/2024 00.48, Daniel Golle wrote:
On 1 June 2024 20:23:20 UTC, "Arınç ÜNAL" wrote:
I've been working on porting MP-DCCP to Teltonika SDK 7.6.10. The SDK is
based off of OpenWrt, close to 22.03.6. After spending hours on figuring
out why my MP-DCCP port works on the vanill
I've been working on porting MP-DCCP to Teltonika SDK 7.6.10. The SDK is
based off of OpenWrt, close to 22.03.6. After spending hours on figuring
out why my MP-DCCP port works on the vanilla 5.10.201 but not OpenWrt's
5.10.201, I've started looking for OpenWrt's out-of-tree kernel patches. I
was
Hello.
This patch series brings support for ASUS RT-AC3200 and ASUS RT-AC5300 on
OpenWrt.
Note to Rafał, please apply this after backporting the device tree patches
for these devices.
Signed-off-by: Arınç ÜNAL
---
Arınç ÜNAL (2):
bcm53xx: add support for ASUS RT-AC3200 and ASUS RT-AC5300
From: Arınç ÜNAL
Add ASUS RT-AC3200 and ASUS RT-AC5300 to the set wireless LED behaviour
quirk. ASUS RT-AC3200's wireless chip is different than ASUS RT-AC5300's,
the environment variables for it are 0:ledbh10 and 1:ledbh10.
Signed-off-by: Arınç ÜNAL
---
package/utils/nvram/Makefile
From: Arınç ÜNAL
ASUS RT-AC3200 and ASUS RT-AC5300 are AC3200 and AC5300 routers,
respectively, featuring 5 Ethernet ports over the integrated Broadcom
switch.
ASUS RT-AC3200 hardware info:
* Processor: Broadcom BCM4709A0 dual-core @ 1.0 GHz
* Switch: BCM53012 in BCM4709A0
* DDR3 RAM: 256 MB
Hello everyone!
We're doing an OpenWrt summit this year. We're inviting all OpenWrt
enthusiasts to join us at the event. We will auction off one or two OpenWrt
One. And we will have a big cake for OpenWrt's 20 year anniversary. It's
going to be a relaxed event full of social activities with
On 5.02.2024 22:10, Rafał Miłecki wrote:
On 5.02.2024 15:15, Robert Marko wrote:
On Mon, 5 Feb 2024 at 14:23, Rafał Miłecki wrote:
From: Rafał Miłecki
Aquantia AQR113C is PHY that needs loading a firmware. Some devices may
have it stored on flash and some need filesystem to provide it.
John hello.
I like this project quite a lot. I'm very excited to see it happen and
would love to be involved! The company I work with, Xeront, has some PCB
designs of their own. I can happily connect you with folks for any
discussions about the electronic engineering and manufacturing aspects of
Hello everyone!
Thanks to all who voted on the polls, we have decided the dates for the
Battlemesh v16 and OpenWrt Summit joint event.
Date: 15-19 May 2024, 5 days
Location: Kyrenia/Girne/Κερύνεια
The OpenWrt Summit will be held on 18-19 May 2024.
This is a small announcement for people that
Hey everyone.
For the joint Battlemesh and OpenWrt summit event in May 2024, I, as the
head organiser, have requested from the United Nations Peacekeeping Force
in Cyprus (UNFICYP) to have a tour of the old Nicosia International
Airport on the date of the event. For those of you who are not
an OpenWrt
track on the last 2 days of Battlemesh in parallel.
Who would like to join?
Hauke
On 11/25/23 12:59, Arınç ÜNAL wrote:
Hello!
I am the head organiser of the next Battlemesh. I will also be involved
the most on organising the OpenWrt summit. Let me know if you've got any
questions.
Hello!
I am the head organiser of the next Battlemesh. I will also be involved
the most on organising the OpenWrt summit. Let me know if you've got any
questions. My website from my email address includes the channels other
than email to reach me more easily.
Arınç
On 23 November 2023 23:54:16
On 4.09.2023 23:58, Linus Walleij wrote:
On Mon, Sep 4, 2023 at 12:03 PM Rafał Miłecki wrote:
I don't see anything incorrect with Linus's original patch. Maybe we
just have some dependency handling issue in u-boot generic .mk code?
I have transient problem with the dependencies at times,
On 19.06.2023 09:36, Linus Walleij wrote:
The DIR-890L is very similar to DIR-885L, but has both USB2
and USB3. The signature for the wrgac36 board was copied from
DD-Wrt.
The DIR-890L bootstrap will only load the first 2 MB after
the SEAMA header in the NAND flash, uncompress it with LZMA
and
On 20.08.2023 23:54, Rafał Miłecki wrote:
niedz., 20 sie 2023 o 20:50 Arınç ÜNAL napisał(a):
On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" wrote:
sob., 19 sie 2023 o 17:12 Arınç ÜNAL napisał(a):
The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND.
On 20 August 2023 17:15:51 GMT+03:00, "Rafał Miłecki" wrote:
>sob., 19 sie 2023 o 17:12 Arınç ÜNAL napisał(a):
>> The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It
>> causes the devices with NVRAM in NAND to bootloop. Create a subtarget for
&g
NVMEM_BRCM_NVRAM enabled.
Signed-off-by: Arınç ÜNAL
---
target/linux/bcm53xx/Makefile| 8 +-
target/linux/bcm53xx/generic/target.mk | 4 +
target/linux/bcm53xx/image/Makefile | 338 +--
target/linux/bcm53xx/image/generic.mk| 43 +++
target/linux/bcm53xx/image
Backport the patch that adds the DT for ASUS RT-AC3100.
Signed-off-by: Arınç ÜNAL
---
...s-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch | 431 ++
...RM-BCM5301X-Add-DT-for-Netgear-R7900.patch | 2 +-
...s-BCM5301X-Add-DT-for-Asus-RT-AC3100.patch | 431 ++
...RM
will be supported by having brcmfmac use
the firmware file for the wireless chip it detects.
Signed-off-by: Arınç ÜNAL
---
target/linux/bcm53xx/image/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/target/linux/bcm53xx/image/Makefile
b/target/linux/bcm53xx/image/Makefile
Add ASUS RT-AC3100 to the set wireless LED behaviour quirk.
Signed-off-by: Arınç ÜNAL
---
package/utils/nvram/Makefile | 2 +-
package/utils/nvram/files/nvram-bcm53xx.init | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/utils/nvram/Makefile b/package
Hi.
The bgmac_bcma driver will hang trying to retrieve the MAC address if
NVMEM is enabled without NVMEM_BRCM_NVRAM enabled.
The device bootloops if NVMEM_BRCM_NVRAM is enabled so I can't tell
whether the bgmac_bcma driver would still hang if NVMEM_BRCM_NVRAM was
enabled and didn't cause
On 1.08.2023 15:28, Arınç ÜNAL wrote:
On 1.08.2023 15:16, Rafał Miłecki wrote:
On 2023-08-01 12:42, Arınç ÜNAL wrote:
The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It
causes the devices with NVRAM in NAND, such as ASUS RT-AC88U, to
bootloop.
Until the driver is fixed
On 1.08.2023 15:16, Rafał Miłecki wrote:
On 2023-08-01 12:42, Arınç ÜNAL wrote:
The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It
causes the devices with NVRAM in NAND, such as ASUS RT-AC88U, to
bootloop.
Until the driver is fixed, disable it.
Driver works and it useful
I've attached the kernel log with NVMEM enabled and disabled for reference.
Arınç
On 1.08.2023 13:42, Arınç ÜNAL wrote:
The NVMEM_BRCM_NVRAM driver won't work properly with NVRAM in NAND. It
causes the devices with NVRAM in NAND, such as ASUS RT-AC88U, to bootloop.
Until the driver is fixed
enabled.
Link:
https://forum.openwrt.org/t/asus-rt-ac88u-hw-a6-broken-in-22-03-3/147882/40
Signed-off-by: Arınç ÜNAL
---
target/linux/bcm53xx/config-5.15 | 3 ---
target/linux/bcm53xx/config-6.1 | 3 ---
2 files changed, 6 deletions(-)
diff --git a/target/linux/bcm53xx/config-5.15 b/target
Hi Rafał.
I am late to this so I just wanted to say thanks for doing this. We're
one step closer to mainlining the DTs of the MT7621 SoC devices.
Arınç
On 14.07.2023 16:11, Rafał Miłecki wrote:
From: Rafał Miłecki
With upstream accepted "mac-base" binding there is no need for a
downstream
rs/net/dsa/realtek/rtl8365mb.c
just edit rtl8365mb_chip_infos[] to include the magic for RTL8363SB
and see if it magically works. You probably need a jam table magic
sequence from the vendor driver if you have that.
The upstream device tree for ASUS RT AC88U has the
8365MB courtesy of Arınç ÜNAL :
https://git.kern
Hi.
I see a lot of development on the network drivers like DSA, PHY, etc.
Are there any plans to put all these drivers on the realtek target on
mainline Linux? To fully support these SoCs on mainline Linux?
Arınç
___
openwrt-devel mailing list
On 15.04.2023 20:02, Sam Kuper wrote:
On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
These are the ideas I've been thinking about for the future of OpenWrt
for a while. It looks complete enough to share it with all of you.
[...]
https://arinc9.notion.site/OpenWrt-next-gen-ideas
On 31.03.2023 20:15, Felix Fietkau wrote:
On 31.03.23 18:55, Arınç ÜNAL wrote:
On 31.03.2023 19:45, Felix Fietkau wrote:
On 31.03.23 18:40, Arınç ÜNAL wrote:
I just thought of this. Why don't we just, for example, 'make
mt7621_defconfig && make mod2noconfig', then compile
On 31.03.2023 14:33, Daniel Golle wrote:
Hi!
On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
Hi all,
These are the ideas I've been thinking about for the future of OpenWrt for a
while. It looks complete enough to share it with all of you.
I'm willing to put a great deal of effort
On 31.03.2023 19:45, Felix Fietkau wrote:
On 31.03.23 18:40, Arınç ÜNAL wrote:
I just thought of this. Why don't we just, for example, 'make
mt7621_defconfig && make mod2noconfig', then compile normally with
kernel module packages. This way, OpenWrt compiles a kernel with the
leas
On 31.03.2023 19:35, Felix Fietkau wrote:
On 31.03.23 18:22, Arınç ÜNAL wrote:
On 31.03.2023 19:04, Felix Fietkau wrote:
On 31.03.23 14:52, Arınç ÜNAL wrote:
On 31.03.2023 14:33, Daniel Golle wrote:
Hi!
On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
Hi all
On 31.03.2023 19:04, Felix Fietkau wrote:
On 31.03.23 14:52, Arınç ÜNAL wrote:
On 31.03.2023 14:33, Daniel Golle wrote:
Hi!
On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
Hi all,
These are the ideas I've been thinking about for the future of
OpenWrt for a
while. It looks
On 31.03.2023 18:36, Daniel Golle wrote:
On Fri, Mar 31, 2023 at 05:35:22PM +0300, Arınç ÜNAL wrote:
On 31.03.2023 16:47, Daniel Golle wrote:
On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote:
On 31.03.2023 14:33, Daniel Golle wrote:
Hi!
On Fri, Mar 31, 2023 at 12:44:12PM +0300
On 31.03.2023 16:47, Daniel Golle wrote:
On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote:
On 31.03.2023 14:33, Daniel Golle wrote:
Hi!
On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
Hi all,
These are the ideas I've been thinking about for the future of OpenWrt
On 31.03.2023 14:33, Daniel Golle wrote:
Hi!
On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
Hi all,
These are the ideas I've been thinking about for the future of OpenWrt for a
while. It looks complete enough to share it with all of you.
I'm willing to put a great deal of effort
Hi all,
These are the ideas I've been thinking about for the future of OpenWrt
for a while. It looks complete enough to share it with all of you.
I'm willing to put a great deal of effort to get as much out-of-tree
patches on mainline Linux as possible.
You can make a comment on Notion or
Kudos on the master to main change.
Arınç
On 29.03.2023 23:43, Paul Spooren wrote:
Hi,
Another month, another developer meeting - short and sweet:
https://openwrt.org/meetings/20230328
Best,
Paul
___
openwrt-devel mailing list
On 8.03.2023 02:25, Hauke Mehrtens wrote:
Hi,
Wireless Battlemesh v15 is coming up in May 8-14.
https://battlemesh.org/BattleMeshV15
Battlemesh will take place this year in Calafou, Vallbona d'Anoia,
Barcelona.
We were thinking to do a OpenWrt meeting in parallel or before/after
Battlemesh.
On 4.03.2023 00:48, Jan Hoffmann wrote:
This series fixes multiple issues related to the L2 table and multicast
table. That includes an issue that causes corruption of the port mask
for unknown multicast forwarding, which can occur even when multicast
snooping is disabled.
With these patches,
On 3.02.2023 16:03, Hauke Mehrtens wrote:
On 1/27/23 14:57, arinc9.u...@gmail.com wrote:
From: Arınç ÜNAL
The Huasifei WS1208V2 is an AC1200 router featuring 5 Ethernet ports
with a
Quectel RM520N-GL cellular modem which supports QMI and MBIM modes.
Specifications:
- MT7621AT, 256 MiB RAM
On 26.01.2023 22:31, Enrico Mioso wrote:
On Thu, 26 Jan 2023, arinc9.u...@gmail.com wrote:
Date: Thu, 26 Jan 2023 19:35:27
From: arinc9.u...@gmail.com
To: openwrt-devel@lists.openwrt.org
Cc: Arınç ÜNAL
Subject: [PATCH] ramips: add support for Huasifei WS1208V2
From: Arınç ÜNAL
On 22.01.2023 20:44, Daniel Santos wrote:
On 1/22/23 00:23, Arınç ÜNAL wrote:
On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos
wrote:
On 1/21/23 15:19, Arınç ÜNAL wrote:
On 21.01.2023 21:32, Daniel Santos wrote:
... You can use this to see what the valid values are for each
group
On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos
wrote:
>On 1/21/23 15:19, Arınç ÜNAL wrote:
>> On 21.01.2023 21:32, Daniel Santos wrote:
>>> ... You can use this to see what the valid values are for each group,
>>> because until this all goes yaml, there's no
By the way, I just got an "undelivered mail returned to sender" for
John's mail address. I don't think they'll be replying here any time
soon. ;)
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
ÜNAL wrote:
On 21.01.2023 10:56, Sergio Paracuellos wrote:
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL
wrote:
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
GPIO by default. Requesting a gpio by either from devicetree or `echo
203 > /sys/class/gpio/export` wo
On 21.01.2023 10:56, Sergio Paracuellos wrote:
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
GPIO by default. Requesting a gpio by either from devicetree or `echo
203 > /sys/class/gpio/export` won't cha
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
GPIO by default. Requesting a gpio by either from devicetree or `echo
203 > /sys/class/gpio/export` won't change anything. You have to claim
the pin group as gpio on the devicetree.
Quoting my response from [0]:
On 15.01.2023 23:13, Linus Walleij wrote:
On Sun, Jan 15, 2023 at 9:02 PM Arınç ÜNAL wrote:
On 15.01.2023 17:54, Linus Walleij wrote:
On Fri, Jan 13, 2023 at 11:11 PM Arınç ÜNAL wrote:
Side question, did you risk writing your test builds to the flash or
have you already got the flash
On 15.01.2023 17:54, Linus Walleij wrote:
On Fri, Jan 13, 2023 at 11:11 PM Arınç ÜNAL wrote:
Side question, did you risk writing your test builds to the flash or
have you already got the flash in an easily reprogrammable set up?
This device has the boot prom in NOR so firmware is only
On 12.01.2023 23:51, Linus Walleij wrote:
On Sun, Jan 8, 2023 at 12:33 AM Linus Walleij wrote:
I guess trying to figure out what lzma-loader does and implement
the same for ARM is the way to go, or at some point I felt like
implementing U-Boot for the BCM53xx and implement SEAMA
loading from
On 11.01.2023 01:19, Linus Walleij wrote:
On Sun, Jan 8, 2023 at 5:38 PM Arınç ÜNAL wrote:
Is it possible to create a root filesystem archive? Is there a directory
where the final filesystem is extracted before turned to a squashfs image?
It's right there in the Kconfig menu:
Target Images
Quoting me and Luiz's message.
On 9.01.2023 05:17, Luiz Angelo Daros de Luca wrote:
Hi Arınç,
Is it possible to create a root filesystem archive?
CONFIG_TARGET_ROOTFS_TARGZ ?
Ah, of course. Thanks.
OpenWrt filesystem hasn’t got /init. I get this error when I link the
filesystem with
Is it possible to create a root filesystem archive? Is there a directory
where the final filesystem is extracted before turned to a squashfs image?
I know there's buildroot for this but I want to use LuCI, buildroot
seems to only have uci.
Arınç
-by: Arınç ÜNAL
Hold on to this next time.
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Funny Linus thought to mention me since I've been working on booting
stuff on arm and mips boards very recently.
On 8.01.2023 06:18, Chuanhong Guo wrote:
Hi!
On Sun, Jan 8, 2023 at 7:38 AM Linus Walleij wrote:
I guess trying to figure out what lzma-loader does and implement
the same for ARM
-by: Arınç ÜNAL
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 2.01.2023 18:34, Harm Berntsen wrote:
On Mon, 2023-01-02 at 18:18 +0300, Arınç ÜNAL wrote:
On 2.01.2023 18:03, Harm Berntsen wrote:
On Wed, 2022-12-28 at 23:11 +0300, Arınç ÜNAL wrote:
The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band
access
point distributed as Experia WiFi
On 2.01.2023 18:03, Harm Berntsen wrote:
On Wed, 2022-12-28 at 23:11 +0300, Arınç ÜNAL wrote:
The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access
point distributed as Experia WiFi by KPN in the Netherlands. It
features
two ethernet ports and 2 internal antennas.
Specifications
This gives each port an individual link to the CPU, like in f1c9afd801
(ramips: mt7621-dts: mux phy0/4 to gmac1, 2022-07-06).
The advantage of this is that it can now route packets faster between
the ports (before the CPU only had a single 1Gb link to the switch that
has to be shared between
The Arcadyan WE420223-99 is a WiFi AC simultaneous dual-band access
point distributed as Experia WiFi by KPN in the Netherlands. It features
two ethernet ports and 2 internal antennas.
Specifications
--
SOC : Mediatek MT7621AT
ETH : Two 1 gigabit ports, built into the SOC
WIFI :
There's this reply under one of David's patches. Give this a try. Let me
know if you need help with git.
https://github.com/openwrt/openwrt/commit/15167671b0d7cf0c95568dd6f9620db082df5d96#commitcomment-51920086
Arınç
On 1.12.2022 15:07, Arınç ÜNAL wrote:
David Bauer also did some work
David Bauer also did some work on it. CC'ing.
On 1.12.2022 15:01, Arınç ÜNAL wrote:
René van Dorst worked on this here:
https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/710-at803x.patch
Their mail doesn't seem to work anymore.
Arınç
On 30.11.2022 14:49, David
René van Dorst worked on this here:
https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/710-at803x.patch
Their mail doesn't seem to work anymore.
Arınç
On 30.11.2022 14:49, David Collett wrote:
Hi All,
I am using an SFP module in a MikroTik RouterBOARD 760iGS.
as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
Acked-by: Arınç ÜNAL
Keep this if you send a new version.
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc115d8d6f73dd260de1609182f3645844d6907
Signed-off-by: Arınç ÜNAL
---
Here's how I did it, for the interested (or suggestions):
Find
On 30.11.2022 19:50, Jonas Gorski wrote:
On Wed, 30 Nov 2022 at 15:43, Arınç ÜNAL wrote:
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc115d8d6f73dd260de1609182f3645844d6907
as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
I assume everything works fine now?
Acked-by: Arınç ÜNAL
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc115d8d6f73dd260de1609182f3645844d6907
Signed-off-by: Arınç ÜNAL
---
These devicetrees do not define the ethernet property for CPU
On 30.11.2022 12:53, Jan-Niklas Burfeind wrote:
On 11/30/22 10:41, Arınç ÜNAL wrote:
On 30.11.2022 12:33, Jan-Niklas Burfeind wrote:
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD
as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
Acked-by: Arınç ÜNAL
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
There's no nvmem implementation on 21.02. Revert to mtd-mac-address.
Fixes: d604032c2a50 ("ramips: fix GB-PC1 and GB-PC2 device support")
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --gi
On 30.11.2022 01:12, Jan-Niklas Burfeind wrote:
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None -
On 29.11.2022 14:35, Bjørn Mork wrote:
Arınç ÜNAL writes:
Change the labels of the DSA ports to generic naming for switch ports.
Probably stupid question, but why?
Not stupid at all.
The labels aren't required. Just drop them if no one depends on the
current default.
I wouldn't
Change the labels of the DSA ports to generic naming for switch ports.
Signed-off-by: Arınç ÜNAL
---
I've made sure every devicetree which includes mt7621.dtsi has got its own
label property. This won't break anything.
Arınç
---
target/linux/ramips/dts/mt7621.dtsi | 10 +-
1 file
Also, please cherry-pick to 22.03.
Thanks a bunch Hauke!
Arınç
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
The phy-mode property must be defined on the MAC instead of the PHY. Define
phy-mode under gmac1 which the external phy is connected to.
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 16.11.2022 11:35, Turritopsis Dohrnii Teo En Ming wrote:
On Wed, 16 Nov 2022 at 20:31, Arınç ÜNAL wrote:
On 15.11.2022 17:16, Turritopsis Dohrnii Teo En Ming wrote:
Subject: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router?
Good day from Singapore,
Can I install
On 15.11.2022 17:16, Turritopsis Dohrnii Teo En Ming wrote:
Subject: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router?
Good day from Singapore,
Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router?
I have searched the Table of Hardware but my device is not
no bridge offloading between the "wan"
and "lan" interfaces.
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_linksys_e7350.dts | 37 ---
.../ramips/dts/mt7621_netgear_wax202.dts | 18 -
.../ramips/dts/mt7621_zbtlink_zbt-wg1608.dtsi | 37 -
will be supported by having brcmfmac use
the firmware file for the wireless chip it detects.
Signed-off-by: Arınç ÜNAL
---
Hauke, please cherry-pick this to 22.03.
Arınç
---
target/linux/bcm53xx/image/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux
to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
v2: Correct misinformation in the patch log.
---
.../linux/ramips/dts
s PHY driver for IP1001 which GB-PC2 has got.
Update interface name and change netdev function.
Enable lzma compression to make up for the increased size of the kernel.
Make spi flash bindings on par with mainline Linux to fix read errors.
Tested on GB-PC2 by Petr.
Tested-by: Petr Louda
Signed-off-by
to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
v2: Correct misinformation in the patch log.
---
.../linux/ramips/dts
Change phy-mode of gmac1 to rgmii on mt7621.dtsi. Same code path is
followed for delayed rgmii and rgmii phy-mode on mtk_eth_soc.c.
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts
to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
v2: Correct misinformation in the patch log.
---
.../linux/ramips/dts
s PHY driver for IP1001 which GB-PC2 has got.
Update interface name and change netdev function.
Enable lzma compression to make up for the increased size of the kernel.
Make spi flash bindings on par with mainline Linux to fix read errors.
Tested on GB-PC2 by Petr.
Tested-by: Petr Louda
Signed-off-by
ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10
ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10
Change phy-mode of gmac1 to rgmii on mt7621.dtsi. Same code path is
followed for delayed rgmii and rgmii phy-mode on mtk_eth_soc.c.
Signed-off-by: Arınç ÜNAL
---
target/linux/ramips/dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts
ethyellow-orange to display link state and activity of the ethyellow
interface for GB-PC2.
Link:
https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf
Tested-by: Petr Louda
Signed-off-by: Arınç ÜNAL
---
.../linux/ramips/dts/mt7621_gnubee_gb-pc1.dts | 10
On 13.09.2022 22:56, Jo-Philipp Wich wrote:
Hi,
IMHO changing, in /etc/config/network:
"config interface" -> "config network"
"config device" -> "config interface"
would eliminate this semantic inconsistency and bring the naming
convention more in line with what Rich referred to in his
ively get better as we work on it.
Rich
PS I edited the DSA Mini-tutorial to strike through the entire Terminology
section pending the outcome of this discussion. Thanks again.
That part should be corrected with my comments and put on the "Network &
Network Interfaces" page. I'
separately.
- One with bridge VLAN filtering
- All interfaces on the bridge, VLAN-aware forwarding.
My "Converting to DSA" page already follows the second configuration.
Arınç
Rich
On Sep 10, 2022, at 9:47 AM, Arınç ÜNAL wrote:
On 10.09.2022 14:59, Rich Brown wrote:
I got the
On 10.09.2022 14:59, Rich Brown wrote:
I got the following definitions from Arınç, I am taking the liberty of opening
this to the entire list, so we can refine these definitions together. I include
some questions in-line to clarify the definitions.
As a start, certain terms have cropped up
On 10.09.2022 14:52, David Lang wrote:
On Sat, 10 Sep 2022, Arınç ÜNAL wrote:
As a start, certain terms have cropped up multiple times in this
discussion. Could I ask for definitions for the following terms?
Here's my understanding.
There is a difference between a physical device
On 10.09.2022 03:04, Rich Brown wrote:
Thanks for all this discussion. I have read everyone's notes carefully, but I
feel as if I am falling farther and farther behind.
I don't understand the distinctions between the terms that everyone is using. (The networking field
is replete with synonyms
Hey Luiz,
On 8.09.2022 06:28, Luiz Angelo Daros de Luca wrote:
- Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10"
- VLAN filtering disabled
Bridging virtual 802.1q interfaces might fail in some scenarios, like
when you use vlan1 or mix tagged with untagged traffic
On 8.09.2022 02:54, Florian Fainelli wrote:
On 9/7/2022 3:00 PM, Sebastian Moeller wrote:
Hi Jo,
I was under the impression* that bridge-vlan filtering is something
that can be relegated to the switch hardware, while creating a bridge
between VLAN interfaces happens in software. Is that
1 - 100 of 194 matches
Mail list logo
