ARM: dts: add support for Turris Omnia

arch/arm/boot/dts/armada-385-turris-omnia.dts line 200

Quoted 10 lines

+&mdio {

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +9 -0

+	pinctrl-names = "default";
+	pinctrl-0 = <&mdio_pins>;
+	status = "okay";
+
+	phy1: phy at 1 {
+		status = "okay";
+		compatible = "marvell,88E1514", "marvell,88E1510", "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};

phy.txt says:

- compatible: Compatible list, may contain "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45 specifications. If neither of these are specified, the default is to assume clause 22.

If the phy's identifier is known then the list may contain an entry of the form: "ethernet-phy-idAAAA.BBBB" where
AAAA - The value of the 16 bit Phy Identifier 1 register as
4 hex digits. This is the chip vendor OUI bits 3:18
BBBB - The value of the 16 bit Phy Identifier 2 register as
4 hex digits. This is the chip vendor OUI bits 19:24, followed by 10 bits of a vendor specific ID.

The compatible list should not contain other values than those listed here.

Please don't list the "marvell,*" names.

Will do for v2. arch/arm/boot/dts/keystone-* needs fixing in this regard, too.

Still missing is support for the switch.

SFP is untested as is UART1.

Do I need to "register" turris in vendor-prefixes.txt for that?

Quoted 1 line

Still missing is support for the switch.

Is it a Marvell Switch? armada-370-rd.dts would be a good start for the old binding? vf610-zii-dev-rev-b.dts uses the new binding.

Quoted 1 line

SFP is untested as is UART1.

UART would be unusual. They are normally i2c.

Quoted 1 line

Do I need to "register" turris in vendor-prefixes.txt for that?

Yes please.

Hello Andrew,

Quoted 4 lines · Andrew Lunn

Quoted 1 line

Still missing is support for the switch.

Is it a Marvell Switch? armada-370-rd.dts would be a good start for the old binding? vf610-zii-dev-rev-b.dts uses the new binding.

Yeah, a 88E6176. I already try to understand vf610-zii-dev-rev-b.dts. Do you know if this driver works for the 88E6176?

Quoted 10 lines · Andrew Lunn

Quoted 8 lines · Uwe Kleine-K?nig

Review

Quoted 2 lines

(quoted diff) +2 -0

+     switch at 0 {
+             compatible = "marvell,mv88e6176", "marvell,mv88e6085";

All currently supported switches are compatible with the mv88e6085, in terms of probing. During the probe it can read an ID register to find out what specific switch it is, so you don't need additional details here. So please drop the marvell,mv88e6176, it will never be used.

Quoted 7 lines

That's what I know from several imx devices, for example look at

$ git grep imx25 arch/arm/boot/dts/imx25.dtsi

There are several instances of imx25-something, imx$earliersoc-something. Given there is a good reason for this, I wonder why it's different here.

Possibly because you cannot easily tell the variants apart using ID registers in the devices register space? For the switch it is very easy, port register 3 is the ID. It only becomes an issue when probe cannot find this register. There is a new generation mv88e6390 which i'm currently adding support for which has moved the port registers. So i need to add a new compatible string so probe knows where to look.

Quoted 6 lines

Quoted 2 lines

From what you say here, the switch is in mulit-chip mode, at address 0x10. So set the reg property to <0x10>.

When using 0x10 I get

	mv88e6085 f1072004.mdio-mi:10: switch 0x176 probed: Marvell 88E6176, revision 1

Great.

Quoted 1 line

Quoted 1 line

so now I have to find out how to use this.

Just use them as normal interfaces. ip addr add 10.42.42.42/24 dev lan4, brctrl addif br0 lan2, ethtool -S lan1 etc.

The whole idea is that they are just normal Linux network interfaces.

Quoted 3 lines

Quoted 3 lines

Do I need to "register" turris in vendor-prefixes.txt for that?

Yes please.

OK, will wait for Martin to comment what we want there. cznic or turris.

This machine is an open hardware router by cz.nic driven by a Marvell Armada 385.

Signed-off-by Uwe Kleine-K?nig <[email protected]>

---

Hello,

the following components are working:

- WAN port
- eMMC

- UART0
- USB

Still missing is support for the switch. Wireless fails to probe, didn't
debug this up to now. SFP is untested as is UART1.

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +0 -0

new file mode 100644
index 000000000000..d3cd8a4d713d
@@ -0,0 +1,246 @@

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +19 -0

+			usb at 58000 {
+				status = "okay";
+			};
+
+
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+&eth1 {
+	pinctrl-names = "default";

Actually SFP is connected to SGMII interface of eth1, which is routed through SERDES 5.

We have our proprietary support hacked onto mvneta driver for disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS altogether and let's wait till "phylink based SFP module support" or something alike hits upstream, so we can base the SFP support on solid code;

Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch. The problem is that from what I have read so far the switch can not operate in DSA mode with two CPU ports.

Quoted 2 lines

Actually SFP is connected to SGMII interface of eth1, which is routed through SERDES 5.

You say eth1 here. Yet lower down you say got eth0 and eth1 are connected to the switch?

Quoted 7 lines

We have our proprietary support hacked onto mvneta driver for disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS altogether and let's wait till "phylink based SFP module support" or something alike hits upstream, so we can base the SFP support on solid code;

It would be great if you could work on getting the phylink patches into mainline. It is something i have wanted to do for a long time, but it is too low down on my priority list to get to. The code is high quality, so i don't think there will be too many issues. It probably just needs splitting up into smaller batches, submitting, and working on any comments.

Quoted 5 lines

Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch. The problem is that from what I have read so far the switch can not operate in DSA mode with two CPU ports.

Again, this is something i wanted to do, and i did have a prototype at one point. But again, not enough time. If you have resources to work on this, i can find my code, explain my ideas, and let you complete it.

Quoted 2 lines

Actually SFP is connected to SGMII interface of eth1, which is routed through SERDES 5.

You say eth1 here. Yet lower down you say got eth0 and eth1 are connected to the switch?

Quoted 7 lines

We have our proprietary support hacked onto mvneta driver for disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS altogether and let's wait till "phylink based SFP module support" or something alike hits upstream, so we can base the SFP support on solid code;

It would be great if you could work on getting the phylink patches into mainline. It is something i have wanted to do for a long time, but it is too low down on my priority list to get to. The code is high quality, so i don't think there will be too many issues. It probably just needs splitting up into smaller batches, submitting, and working on any comments.

Quoted 5 lines

Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch. The problem is that from what I have read so far the switch can not operate in DSA mode with two CPU ports.

Again, this is something i wanted to do, and i did have a prototype at one point. But again, not enough time. If you have resources to work on this, i can find my code, explain my ideas, and let you complete it.

Quoted 10 lines · Uwe Kleine-K?nig

This machine is an open hardware router by cz.nic driven by a Marvell Armada 385.

Signed-off-by Uwe Kleine-K?nig <[email protected]>

---

Hello,

the following components are working:

Quoted 2 lines

- WAN port
- eMMC

But I not not sure about DDR50 mode. At least with kernel 4.4, that we use in production, we had to limit to SDR50 to overcome I/O errors and communication instability, if I can remember it correctly. So it might need more testing with the current kernel.

Quoted 2 lines

Still missing is support for the switch. Wireless fails to probe, didn't debug this up to now. SFP is untested as is UART1.

Actually SFP is connected to SGMII interface of eth1, which is routed through SERDES 5. The SGMII line is shared between the SFP and metallic PHY 88E1514. There is a autonomous high-speed switch connected to the SFPDET signal from SFP cage. It disconnects the metallic SFP and connects SGMII to SFP once the module is connected.

The SFP is also connected to the I2C mux port 4 and to GPIO expander for reading/driving SFPDET, LOS, TXFLT, TXDIS signals:

&i2c0 {
       pinctrl-names = "default";
       pinctrl-0 = <&i2c0_pins>;
       status = "okay";
       clock-frequency = <100000>;

       i2cmux at 70 {
               compatible = "nxp,pca9547";
               #address-cells = <1>;
               #size-cells = <0>;
               reg = <0x70>;
               status = "okay";

...

               i2c at 7 {
                       /* SFP+ GPIO expander */
                       #address-cells = <1>;
                       #size-cells = <0>;
                       reg = <7>;

                       sfpgpio: gpio at 71 {
                               compatible = "nxp,pca9538";
                               reg = <0x71>;
                               interrupt-parent = <&gpio1>;
                               interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
                               gpio-controller;
                               #gpio-cells = <2>;
                       };

               };
	};
};

We have our proprietary support hacked onto mvneta driver for disconnecting PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS altogether and let's wait till "phylink based SFP module support" or something alike hits upstream, so we can base the SFP support on solid code; unless somebody has a better idea, of course.

Quoted 9 lines

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +0 -0

new file mode 100644
index 000000000000..d3cd8a4d713d
@@ -0,0 +1,246 @@

...

arch/arm/boot/dts/armada-385-turris-omnia.dts

Quoted 2 lines

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +2 -0

+
+			/* USB part of the eSATA/USB 2.0 port */

This comment is perhaps some error inherited from my development DTS. We do not have any eSATA, perhaps PCIe/USB 2.0 slot.

Quoted 20 lines

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +19 -0

+			usb at 58000 {
+				status = "okay";
+			};
+
+
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+&eth1 {
+	pinctrl-names = "default";

arch/arm/boot/dts/armada-385-turris-omnia.dts line 137

Quoted 10 lines

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +10 -0

+	pinctrl-0 = <&ge1_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+

Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch. The problem is that from what I have read so far the switch can not operate in DSA mode with two CPU ports. We currently operate the switch in "normal mode" with the eth0 and eth1 set to fixed-link 1000/full and with proprietary driver (derived from OpenWRT switch drivers). I would say that these records for eth0 and eth1 are therefore redundant, because it does nothing without the switch support and it would most likely change once we have DSA driver (using only eth0).

(quoted diff) +22 -0

+               i2c at 7 {
+                       #address-cells = <1>;
+                       #size-cells = <0>;
+                       reg = <7>;
+
+                       pcawan: gpio at 71 {
+                               compatible = "nxp,pca9538";
+                               reg = <0x71>;
+
+                               pinctrl-names = "default";
+                               pinctrl-0 = <&pcawan_pins>;
+
+                               interrupt-parent = <&gpio1>;
+                               interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+                               gpio-controller;
+                               #gpio-cells = <2>;
+
+                               interrupt-controller;
+                               #interrupt-cells = <2>;
+                       };
+               };

The interrupt-controller part doesn't seem to work though, at least

(quoted diff) +2 -0

+               interrupt-parent = <&pcawan>;
+               interrupts = <7 IRQ_TYPE_LEVEL_LOW>;

in the phy node gives an error.

Quoted 27 lines

+ i2c at 7 {

 +                       #address-cells = <1>;
 +                       #size-cells = <0>;
 +                       reg = <7>;

+
+ pcawan: gpio at 71 {
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14
IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };

The interrupt-controller part doesn't seem to work though, at least

Quoted 4 lines

+ interrupt-parent = <&pcawan>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;

in the phy node gives an error.

Interrupts don't seem to work very well with the nxp,pca9538. Which is probably why it is disabled by default.

Quoted 2 lines · Andrew Lunn

Interrupts don't seem to work very well with the nxp,pca9538. Which is probably why it is disabled by default.

I was thinking about this issue and I can remember that there was an earlier prototype that had a shared interrupt line from PHY (88E1514) and from the PCA9538. In this case we needed to specifically disable the interrupt of the PHY to release the interrupt line (which needed a hack into PHY driver code). The IRQ from PHY is connected as an ordinary input to PCA9538 in later board prototype. And the same holds for the production version.

Do you have CZ11NIC13 or older board revision?

Hello Tomas,

Quoted 5 lines · tomas.hlavacek at nic.cz

Quoted 1 line · Andrew Lunn

Interrupts don't seem to work very well with the nxp,pca9538.

Which

Quoted 1 line

is probably why it is disabled by default.

Quoted 12 lines

I was thinking about this issue and I can remember that there was
an earlier
prototype that had a shared interrupt line from PHY (88E1514) and
from the
PCA9538. In this case we needed to specifically disable the
interrupt of the
PHY to release the interrupt line (which needed a hack into PHY
driver
code). The IRQ from PHY is connected as an ordinary input to
PCA9538 in
later board prototype. And the same holds for the production
version.

That would explain why I see an "irq but nobody cared" message when booting the original system.

This isn't the problem I meant though. When adding interrupt-parent = <&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get an
error saying that there is no irq domain associated with this device.

Quoted 1 line

Do you have CZ11NIC13 or older board revision?

CZ11NIC12 is indicated on my board.

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +18 -0

+			sdhci at d8000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&sdhci_pins>;
+				status = "okay";
+
+				bus-width = <8>;
+				no-1-8-v;
+				non-removable;
+			};
 
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+
+	i2cmux at 70 {
+		compatible = "nxp,pca9547";
+		#address-cells = <1>;
+		#size-cells = <0>;

arch/arm/boot/dts/armada-385-turris-omnia.dts line 3

Quoted 5 lines

+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +3 -0

@@ -0,0 +1,279 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf

Cool that there is a link to the schematics. But please could you put it lower down. It is more likely to be seen if it comes after the copyright and license section.

No leds? No buttons via gpio-keys?

@Tomas: I think it doesn't make sense when we alternate sending patches without prior arrangement. Do you already work on a v5? If not I can do that to fix the last few comments. Not sure when a submission is too late to enter v4.10, but I think the window isn't that big any more.

Quoted 2 lines

No leds? No buttons via gpio-keys?

The leds are controlled by a Cortex-M0 and without intervention blink according to a hardware function (network, power, pci). IMHO that's ok for an initial setup.

Quoted 6 lines

@Tomas: I think it doesn't make sense when we alternate sending
patches
without prior arrangement. Do you already work on a v5? If not I
can do
that to fix the last few comments. Not sure when a submission is too late to enter v4.10, but I think the window isn't that big any more.

It is getting a bit late. But maybe Linus will add in another -rc week.

Quoted 8 lines

Quoted 2 lines

No leds? No buttons via gpio-keys?

The leds are controlled by a Cortex-M0 and without intervention
blink
according to a hardware function (network, power, pci). IMHO that's
ok
for an initial setup.

Yes. That is fine. It is just unusual. Most boards have gpio-led and gpio-keys, which are easy to add. That is why i asked. Adding an LED driver which talks to this M0 can be added later.

Quoted 7 lines · Andrew Lunn

Quoted 4 lines

@Tomas: I think it doesn't make sense when we alternate sending patches without prior arrangement. Do you already work on a v5? If not I can do that to fix the last few comments. Not sure when a submission is too late to enter v4.10, but I think the window isn't that big any more.

It is getting a bit late. But maybe Linus will add in another -rc week.

Quoted 9 lines

Quoted 5 lines

Quoted 1 line

No leds? No buttons via gpio-keys?

The leds are controlled by a Cortex-M0 and without intervention blink according to a hardware function (network, power, pci). IMHO that's ok for an initial setup.

Yes. That is fine. It is just unusual. Most boards have gpio-led and gpio-keys, which are easy to add. That is why i asked. Adding an LED driver which talks to this M0 can be added later.

Actually the WiP driver for MCU LED interface, that we use in our kernel is here:
https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb

It definitely needs some cleanup and it adds non-standard features (main PWM for all LEDs, autonomous blink mode, colors) via custom /sys files, which I suspect that is not going to be acceptable for upstream. Let's keep it for the next iteration.

Quoted 3 lines

Yes. That is fine. It is just unusual. Most boards have gpio-led and gpio-keys, which are easy to add. That is why i asked. Adding an LED driver which talks to this M0 can be added later.

Actually the WiP driver for MCU LED interface, that we use in our
kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb

It definitely needs some cleanup and it adds non-standard features (main PWM for all LEDs, autonomous blink mode, colors) via custom /sys files, which I suspect that is not going to be acceptable for upstream. Let's keep it for the next iteration.

Turris Omnia board by CZ.NIC:

* Marvell Armada 385 SoC
* 1 or 2 GB DDR3
* eMMC
* 8 MB SPI flash (U-Boot and rescue Linux image)
* 88E1514 PHY
* 88E6176 Ethernet switch (not supported)

Supported board revision: CZ11NIC13 (production board).

Signed-off-by Tomas Hlavacek <[email protected]>

---
Changes since Uwe's version:

- add MBUS regions (needed for Marvell CESA)
- remove rtc disable (WFM with CZ11NIC13 = production board)

- cleanup comments

Unsupported peripherals:
- MV88E7176 switch
- SFP
- LEDs

---
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
 2 files changed, 280 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts

arch/arm/boot/dts/Makefile +1 -0

index befcd26..f1d3b9ff 100644
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
 	armada-385-db-ap.dtb \
 	armada-385-linksys-caiman.dtb \
 	armada-385-linksys-cobra.dtb \
+	armada-385-turris-omnia.dtb \
 	armada-388-clearfog.dtb \
 	armada-388-db.dtb \
 	armada-388-gp.dtb \

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +40 -0

new file mode 100644
index 0000000..5ef3d62
@@ -0,0 +1,279 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <[email protected]>
+ * Copyright (C) 2016 Tomas Hlavacek <[email protected]>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is licensed under the terms of the GNU General Public
+ *     License version 2.  This program is licensed "as is" without
+ *     any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +111 -0

+
+	chosen {
+		stdout-path = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>; /* 1024 MB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+		internal-regs {
+
+			/* USB part of the PCIe2/USB 2.0 port */
+			usb at 58000 {
+				status = "okay";
+			};
+
+			sata at a8000 {
+				status = "okay";
+			};
+
+			sdhci at d8000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&sdhci_pins>;
+				status = "okay";
+
+				bus-width = <8>;
+				no-1-8-v;
+				non-removable;
+			};
+
+			usb3 at f0000 {
+				status = "okay";
+			};
+
+			usb3 at f8000 {
+				status = "okay";
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+
+			pcie at 3,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+		};
+	};
+};
+
+/* Connected to 88E6176 switch, port 6 */
+&eth0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge0_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* Connected to 88E6176 switch, port 5 */
+&eth1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ge1_rgmii_pins>;
+	status = "okay";
+	phy-mode = "rgmii-id";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+/* WAN port */
+&eth2 {
+	status = "okay";
+	phy-mode = "sgmii";
+	phy = <&phy1>;
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins>;
+	status = "okay";
+
+	i2cmux at 70 {
+		compatible = "nxp,pca9547";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		status = "okay";

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +17 -0

+		i2c at 7 {
+			/* GPIO expander for SFP+ signals */
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+
+			wangpio: gpio at 71 {
+				compatible = "nxp,pca9538";
+				reg = <0x71>;
+				interrupt-parent = <&gpio1>;
+				interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+		};
+	};
+};

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +4 -0

+		reg = <1>;
+		/* IRQ is connected to PCA9538 pin 7. Currently it
+		 * can not be utilized.
+		 */

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +11 -0

+	status = "okay";
+
+	spi-nor at 0 {
+		compatible = "spansion,s25fl164k", "jedec,spi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0>;
+		spi-max-frequency = <40000000>;
+
+		partition at 0 {
+			reg = <0x0 0x00100000>;

arch/arm/boot/dts/armada-385-turris-omnia.dts new file +6 -0

+};
+
+&uart0 {
+	/* Pin header CN10. */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins>;

Anyway I took your patch and tried few things:
- add pca9538 interrupt-controller
- add IRQ for 88E1514 PHY - and there is a problem:

Hi Uwe!

Quoted 3 lines · tomas.hlavacek at nic.cz

Anyway I took your patch and tried few things:
- add pca9538 interrupt-controller
- add IRQ for 88E1514 PHY - and there is a problem:

...

I thought it over and if I am not mistaken this is not going to work anyway, because pca9538 driver causes the GPIO driver to set IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander pins as IRQ source for 88E1514, because request_irq() on it will fail ultimately.

Quoted 1 line

CZ11NIC12 is indicated on my board.

:-( Well, this board version has wrongly matched length of some differential pairs, IRQ from 88E1514 is connected differently, there are slight differences in power supplies and (if I am not mistaken) something changed in RTC support circuitry. It looks like a huge mistake on our side.

It seems that libphy is probed before pca9538 and we end up with:

[    4.217550] libphy: orion_mdio_bus: probed
[    4.221777] irq: no irq domain found for

/soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !

Any clue where to look in order to defer probing libphy or at least orion_mdio_bus?

Quoted 7 lines

Quoted 1 line

CZ11NIC12 is indicated on my board.

:-( Well, this board version has wrongly matched length of some differential pairs, IRQ from 88E1514 is connected differently, there are slight differences in power supplies and (if I am not mistaken) something changed in RTC support circuitry. It looks like a huge mistake on our side.

Hi Tomas

Would these problems also explain why the Ethernet links to the switch don't work? Maybe the differential pairs?

Quoted 7 lines

Quoted 1 line

CZ11NIC12 is indicated on my board.

:-( Well, this board version has wrongly matched length of some differential pairs, IRQ from 88E1514 is connected differently, there are slight differences in power supplies and (if I am not mistaken) something changed in RTC support circuitry. It looks like a huge mistake on our side.

Hi Tomas

Would these problems also explain why the Ethernet links to the switch don't work? Maybe the differential pairs?

Quoted 7 lines

It seems that libphy is probed before pca9538 and we end up with:

 [    4.217550] libphy: orion_mdio_bus: probed
 [    4.221777] irq: no irq domain found for
 /soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !

Quoted 2 lines

Any clue where to look in order to defer probing libphy or at least orion_mdio_bus?

I think there is a known phylib problem here. Somewhere in the call chain there is a void function, so the EPROBE_DEFFER gets discarded. But i could be remembering this wrongly.