ExternalVendorCode/openwrt
1
0
Fork 0
mirror of https://github.com/openwrt/openwrt.git synced 2024-12-27 17:18:59 +00:00
Code Issues Actions 9 Packages Projects Releases Wiki Activity
21b3fff01c
openwrt/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dts

28 lines
419 B
Plaintext
Raw Normal View History

ramips: mt7621: tidy up names for Ubiquiti devices The "proper" vendor prefix for Ubiquiti is "ubnt", this is used in all targets except ramips and also recommended by the kernel. This patch adjusts the various board/image/device name variables accordingly. Since we touch it anyway, this also adds the space in "EdgeRouter X" as a hyphen to those variables to really make them consistent with the model name. While at it, create a real shared definition for the devices in image/mt7621.mk instead of deriving one device from another. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-04-07 08:47:18 +00:00
#include "mt7621_ubnt_edgerouter-x.dtsi"
/ {
model = "Ubiquiti EdgeRouter X";
compatible = "ubnt,edgerouter-x", "mediatek,mt7621-soc";
};
ramips: mt7621-dts: mux phy0/4 to gmac1 Mux the MT7530 switch's phy0/4 to the SoC's gmac1 on devices where RGMII2 pins are available. This achieves 2 Gbps total bandwidth to the CPU using the second RGMII. The ports called "wan" are muxed where possible. On a minority of devices, this is not possible. Those cases: mt7621_ampedwireless_ally-r1900k.dts: lan3 mt7621_ubnt_edgerouter-x.dts: eth0 mt7621_gnubee_gb-pc1.dts: ethblue mt7621_linksys_re6500.dts: lan1 mt7621_netgear_wac104.dts: lan4 mt7621_tplink_eap235-wall-v1.dts: lan0 mt7621_tplink_eap615-wall-v1.dts: lan0 mt7621_ubnt_usw-flex.dts: lan1 The "wan" port is just what the vendor designated on the board/plastic chasis of the device. On a technical level, there is no difference between a lan and wan port on MT7621AT, MT7621DAT and MT7621ST SoCs. Prefer connecting to WAN via the port described above for these devices to benefit the feature brought with this patch. mt7621_d-team_newifi-d2.dts cannot benefit this feature, although it looks like it should, because the rgmii2 pins are wired to unused components. Tested on a range of devices documented on the GitHub PR. Link: https://github.com/openwrt/openwrt/pull/10238 Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2022-07-05 22:20:32 +00:00
&gmac1 {
status = "okay";
ramips: mt7621: support openwrt,netdev-name for renaming interfaces Edgerouter X currently has its eth1 port on the switch missing since there is a naming conflict currently. So, as the root cause is mixing kernel support for DSA interfaces having predictable names set via "label" property vs others having it assigned dynamically lets avoid the conflict by using our own custom property as suggested upstream [1]. So, add support via "openwrt,netdev-name" property and use it on ERX. Fixes: 2a25c6ace8d8 ("ramips: get rid of downstream network device label patch") Fixes: #15643 Link: https://github.com/openwrt/openwrt/pull/17062 Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-11-24 20:15:08 +00:00
openwrt,netdev-name = "eth0";
ramips: mt7621-dts: mux phy0/4 to gmac1 Mux the MT7530 switch's phy0/4 to the SoC's gmac1 on devices where RGMII2 pins are available. This achieves 2 Gbps total bandwidth to the CPU using the second RGMII. The ports called "wan" are muxed where possible. On a minority of devices, this is not possible. Those cases: mt7621_ampedwireless_ally-r1900k.dts: lan3 mt7621_ubnt_edgerouter-x.dts: eth0 mt7621_gnubee_gb-pc1.dts: ethblue mt7621_linksys_re6500.dts: lan1 mt7621_netgear_wac104.dts: lan4 mt7621_tplink_eap235-wall-v1.dts: lan0 mt7621_tplink_eap615-wall-v1.dts: lan0 mt7621_ubnt_usw-flex.dts: lan1 The "wan" port is just what the vendor designated on the board/plastic chasis of the device. On a technical level, there is no difference between a lan and wan port on MT7621AT, MT7621DAT and MT7621ST SoCs. Prefer connecting to WAN via the port described above for these devices to benefit the feature brought with this patch. mt7621_d-team_newifi-d2.dts cannot benefit this feature, although it looks like it should, because the rgmii2 pins are wired to unused components. Tested on a range of devices documented on the GitHub PR. Link: https://github.com/openwrt/openwrt/pull/10238 Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2022-07-05 22:20:32 +00:00
phy-handle = <&ethphy0>;
ramips: fix Ubiquiti EdgeRouter X's MAC address for gmac1 This fixes: [ 0.586649] OF: /ethernet@1e100000/mac@1: #nvmem-cell-cells = 1 found 0 Fixes: 28b6224104cc ("ramips: use fixed layout cell "mac-base" for Ubiquiti EdgeRouter X") Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2023-07-18 09:26:37 +00:00
nvmem-cells = <&macaddr_factory_22 0>;
ramips: mt7621-dts: mux phy0/4 to gmac1 Mux the MT7530 switch's phy0/4 to the SoC's gmac1 on devices where RGMII2 pins are available. This achieves 2 Gbps total bandwidth to the CPU using the second RGMII. The ports called "wan" are muxed where possible. On a minority of devices, this is not possible. Those cases: mt7621_ampedwireless_ally-r1900k.dts: lan3 mt7621_ubnt_edgerouter-x.dts: eth0 mt7621_gnubee_gb-pc1.dts: ethblue mt7621_linksys_re6500.dts: lan1 mt7621_netgear_wac104.dts: lan4 mt7621_tplink_eap235-wall-v1.dts: lan0 mt7621_tplink_eap615-wall-v1.dts: lan0 mt7621_ubnt_usw-flex.dts: lan1 The "wan" port is just what the vendor designated on the board/plastic chasis of the device. On a technical level, there is no difference between a lan and wan port on MT7621AT, MT7621DAT and MT7621ST SoCs. Prefer connecting to WAN via the port described above for these devices to benefit the feature brought with this patch. mt7621_d-team_newifi-d2.dts cannot benefit this feature, although it looks like it should, because the rgmii2 pins are wired to unused components. Tested on a range of devices documented on the GitHub PR. Link: https://github.com/openwrt/openwrt/pull/10238 Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2022-07-05 22:20:32 +00:00
nvmem-cell-names = "mac-address";
};
ramips: mt7621-dts: describe switch PHYs and adjust PHY muxing Currently, the MT7530 DSA subdriver configures the MT7530 switch to provide direct access to switch PHYs, meaning, the switch PHYs listen on the MDIO bus the switch listens on. The PHY muxing feature makes use of this. This is problematic as the PHY may be attached before the switch is initialised, in which case, the PHY will fail to be attached. Since commit 91374ba537bd ("net: dsa: mt7530: support OF-based registration of switch MDIO bus") on mainline Linux, we can describe the switch PHYs on the MDIO bus of the switch on the device tree. When the PHY is described this way, the switch will be initialised first, then the switch MDIO bus will be registered. Only after these steps, the PHY will be attached. Describe the switch PHYs on mt7621.dtsi and remove defining the switch PHY on the SoC's mdio bus node. When the PHY muxing is in use, the interrupts for the muxed PHY won't work, therefore delete the "interrupts" property on the devices where the PHY muxing feature is in use. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2024-04-28 19:52:51 +00:00
&ethphy0 {
/delete-property/ interrupts;
ramips: mt7621-dts: mux phy0/4 to gmac1 Mux the MT7530 switch's phy0/4 to the SoC's gmac1 on devices where RGMII2 pins are available. This achieves 2 Gbps total bandwidth to the CPU using the second RGMII. The ports called "wan" are muxed where possible. On a minority of devices, this is not possible. Those cases: mt7621_ampedwireless_ally-r1900k.dts: lan3 mt7621_ubnt_edgerouter-x.dts: eth0 mt7621_gnubee_gb-pc1.dts: ethblue mt7621_linksys_re6500.dts: lan1 mt7621_netgear_wac104.dts: lan4 mt7621_tplink_eap235-wall-v1.dts: lan0 mt7621_tplink_eap615-wall-v1.dts: lan0 mt7621_ubnt_usw-flex.dts: lan1 The "wan" port is just what the vendor designated on the board/plastic chasis of the device. On a technical level, there is no difference between a lan and wan port on MT7621AT, MT7621DAT and MT7621ST SoCs. Prefer connecting to WAN via the port described above for these devices to benefit the feature brought with this patch. mt7621_d-team_newifi-d2.dts cannot benefit this feature, although it looks like it should, because the rgmii2 pins are wired to unused components. Tested on a range of devices documented on the GitHub PR. Link: https://github.com/openwrt/openwrt/pull/10238 Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2022-07-05 22:20:32 +00:00
};
&switch0 {
ports {
port@0 {
status = "disabled";
};
};
};
Reference in New Issue Copy Permalink