[PATCH 0/2] arm64: dts: renesas: falcon: Wire-up Ethernet breakout board

[PATCH 0/2] arm64: dts: renesas: falcon: Wire-up Ethernet breakout board

[Niklas Söderlund]

Hi Geert,

This small series wires up the Marvell 88Q2110 PHYs found on the Falcon 
Ethernet breakout board. With this applied all five PHYs are probed 
correctly.

    mv88q2110 e6810000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6810000.ethernet-ffffffff:07, irq=POLL)
    mv88q2110 e6820000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6820000.ethernet-ffffffff:07, irq=POLL)
    mv88q2110 e6830000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6830000.ethernet-ffffffff:07, irq=POLL)
    mv88q2110 e6840000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6840000.ethernet-ffffffff:07, irq=POLL)
    mv88q2110 e6850000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6850000.ethernet-ffffffff:07, irq=POLL)

They can be auto detected with just the compatible 
"ethernet-phy-ieee802.3-c45", but to keep the style currently used I 
have added the specific compatible for the 88Q2110 as done for other 
SoCs.

The primary issue we had with this in the past was due to an incorrect  
PHY address. After studying the schematics (v100) I found the PHYs 
address pins are wired differently on Falcon compared to other Gen4 
boards. On Falcon they are pulled-down, while on other Gen4 boards they 
are left unconnected and subjected to the PHYs internal pull-ups. This 
gives the PHY an address where the lower 3 bits of the address is 
inverted for Falcon.

Patch 1/2 is a simple preparation patch removing properties that should 
not be set in the base SoC include and will produce warnings once the 
mdio node is added. Patch 2/2 wires up the PHYs.

Most likely the change in 1/2 should be applied to AVB0 also, but 
pending our discussion in a different patch about where to place the 
reset-gpio property for mdio nodes that don't strictly need it I left 
AVB0 as is.

Niklas Söderlund (2):
  arm64: dts: renesas: r8a779a0: Remove address- and size-cells from
    AVB[1-5]
  arm64: dts: renesas: falcon: ethernet: Describe PHYs connected on the
    breakout board

 .../dts/renesas/r8a779a0-falcon-ethernet.dtsi | 248 ++++++++++++++++++
 arch/arm64/boot/dts/renesas/r8a779a0.dtsi     |  10 -
 2 files changed, 248 insertions(+), 10 deletions(-)

-- 
2.46.2

[PATCH 1/2] arm64: dts: renesas: r8a779a0: Remove address- and size-cells from AVB[1-5]

[Niklas Söderlund]

When describing the PHYs on the Falcon Ethernet breakout board mdio
nodes will be needed to describe the connections, and each mdio node
will need to contain these two properties instead. This will make the
address-cells and size-cells described in the base SoC include file
redundant and they will produce warnings, remove them.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
 arch/arm64/boot/dts/renesas/r8a779a0.dtsi | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
index 7156b1a542e8..fe6d97859e4a 100644
--- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
@@ -765,8 +765,6 @@ avb1: ethernet@e6810000 {
 			rx-internal-delay-ps = <0>;
 			tx-internal-delay-ps = <0>;
 			iommus = <&ipmmu_ds1 1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
 			status = "disabled";
 		};
 
@@ -814,8 +812,6 @@ avb2: ethernet@e6820000 {
 			rx-internal-delay-ps = <0>;
 			tx-internal-delay-ps = <0>;
 			iommus = <&ipmmu_ds1 2>;
-			#address-cells = <1>;
-			#size-cells = <0>;
 			status = "disabled";
 		};
 
@@ -863,8 +859,6 @@ avb3: ethernet@e6830000 {
 			rx-internal-delay-ps = <0>;
 			tx-internal-delay-ps = <0>;
 			iommus = <&ipmmu_ds1 3>;
-			#address-cells = <1>;
-			#size-cells = <0>;
 			status = "disabled";
 		};
 
@@ -912,8 +906,6 @@ avb4: ethernet@e6840000 {
 			rx-internal-delay-ps = <0>;
 			tx-internal-delay-ps = <0>;
 			iommus = <&ipmmu_ds1 4>;
-			#address-cells = <1>;
-			#size-cells = <0>;
 			status = "disabled";
 		};
 
@@ -961,8 +953,6 @@ avb5: ethernet@e6850000 {
 			rx-internal-delay-ps = <0>;
 			tx-internal-delay-ps = <0>;
 			iommus = <&ipmmu_ds1 11>;
-			#address-cells = <1>;
-			#size-cells = <0>;
 			status = "disabled";
 		};
 
-- 
2.46.2

[PATCH 2/2] arm64: dts: renesas: falcon: ethernet: Describe PHYs connected on the breakout board

[Niklas Söderlund]

Describe and connect the five Marvell 88Q2110 PHYs present on the Falcon
Ethernet breakout board.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
 .../dts/renesas/r8a779a0-falcon-ethernet.dtsi | 248 ++++++++++++++++++
 1 file changed, 248 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a779a0-falcon-ethernet.dtsi b/arch/arm64/boot/dts/renesas/r8a779a0-falcon-ethernet.dtsi
index e11bf9ace776..69c3c5589da9 100644
--- a/arch/arm64/boot/dts/renesas/r8a779a0-falcon-ethernet.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779a0-falcon-ethernet.dtsi
@@ -5,6 +5,127 @@
  * Copyright (C) 2021 Glider bv
  */
 
+/ {
+	aliases {
+		ethernet1 = &avb1;
+		ethernet2 = &avb2;
+		ethernet3 = &avb3;
+		ethernet4 = &avb4;
+		ethernet5 = &avb5;
+	};
+};
+
+&avb1 {
+	pinctrl-0 = <&avb1_pins>;
+	pinctrl-names = "default";
+	phy-handle = <&avb1_phy>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		reset-gpios = <&gpio5 15 GPIO_ACTIVE_LOW>;
+		reset-post-delay-us = <4000>;
+
+		avb1_phy: ethernet-phy@7 {
+			compatible = "ethernet-phy-id002b.0980",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <7>;
+			interrupts-extended = <&gpio5 16 IRQ_TYPE_LEVEL_LOW>;
+		};
+	};
+};
+
+&avb2 {
+	pinctrl-0 = <&avb2_pins>;
+	pinctrl-names = "default";
+	phy-handle = <&avb2_phy>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
+		reset-post-delay-us = <4000>;
+
+		avb2_phy: ethernet-phy@7 {
+			compatible = "ethernet-phy-id002b.0980",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <7>;
+			interrupts-extended = <&gpio6 16 IRQ_TYPE_LEVEL_LOW>;
+		};
+	};
+};
+
+&avb3 {
+	pinctrl-0 = <&avb3_pins>;
+	pinctrl-names = "default";
+	phy-handle = <&avb3_phy>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		reset-gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
+		reset-post-delay-us = <4000>;
+
+		avb3_phy: ethernet-phy@7 {
+			compatible = "ethernet-phy-id002b.0980",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <7>;
+			interrupts-extended = <&gpio7 16 IRQ_TYPE_LEVEL_LOW>;
+		};
+	};
+};
+
+&avb4 {
+	pinctrl-0 = <&avb4_pins>;
+	pinctrl-names = "default";
+	phy-handle = <&avb4_phy>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		reset-gpios = <&gpio8 15 GPIO_ACTIVE_LOW>;
+		reset-post-delay-us = <4000>;
+
+		avb4_phy: ethernet-phy@7 {
+			compatible = "ethernet-phy-id002b.0980",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <7>;
+			interrupts-extended = <&gpio8 16 IRQ_TYPE_LEVEL_LOW>;
+		};
+	};
+};
+
+&avb5 {
+	pinctrl-0 = <&avb5_pins>;
+	pinctrl-names = "default";
+	phy-handle = <&avb5_phy>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		reset-gpios = <&gpio9 15 GPIO_ACTIVE_LOW>;
+		reset-post-delay-us = <4000>;
+
+		avb5_phy: ethernet-phy@7 {
+			compatible = "ethernet-phy-id002b.0980",
+				     "ethernet-phy-ieee802.3-c45";
+			reg = <7>;
+			interrupts-extended = <&gpio9 16 IRQ_TYPE_LEVEL_LOW>;
+		};
+	};
+};
+
+
 &i2c0 {
 	eeprom@53 {
 		compatible = "rohm,br24g01", "atmel,24c01";
@@ -13,3 +134,130 @@ eeprom@53 {
 		pagesize = <8>;
 	};
 };
+
+&pfc {
+	avb1_pins: avb1 {
+		mux {
+			groups = "avb1_link", "avb1_mdio", "avb1_rgmii",
+				 "avb1_txcrefclk";
+			function = "avb1";
+		};
+
+		link {
+			groups = "avb1_link";
+			bias-disable;
+		};
+
+		mdio {
+			groups = "avb1_mdio";
+			drive-strength = <24>;
+			bias-disable;
+		};
+
+		rgmii {
+			groups = "avb1_rgmii";
+			drive-strength = <24>;
+			bias-disable;
+		};
+	};
+
+	avb2_pins: avb2 {
+		mux {
+			groups = "avb2_link", "avb2_mdio", "avb2_rgmii",
+				 "avb2_txcrefclk";
+			function = "avb2";
+		};
+
+		link {
+			groups = "avb2_link";
+			bias-disable;
+		};
+
+		mdio {
+			groups = "avb2_mdio";
+			drive-strength = <24>;
+			bias-disable;
+		};
+
+		rgmii {
+			groups = "avb2_rgmii";
+			drive-strength = <24>;
+			bias-disable;
+		};
+	};
+
+	avb3_pins: avb3 {
+		mux {
+			groups = "avb3_link", "avb3_mdio", "avb3_rgmii",
+				 "avb3_txcrefclk";
+			function = "avb3";
+		};
+
+		link {
+			groups = "avb3_link";
+			bias-disable;
+		};
+
+		mdio {
+			groups = "avb3_mdio";
+			drive-strength = <24>;
+			bias-disable;
+		};
+
+		rgmii {
+			groups = "avb3_rgmii";
+			drive-strength = <24>;
+			bias-disable;
+		};
+	};
+
+	avb4_pins: avb4 {
+		mux {
+			groups = "avb4_link", "avb4_mdio", "avb4_rgmii",
+				 "avb4_txcrefclk";
+			function = "avb4";
+		};
+
+		link {
+			groups = "avb4_link";
+			bias-disable;
+		};
+
+		mdio {
+			groups = "avb4_mdio";
+			drive-strength = <24>;
+			bias-disable;
+		};
+
+		rgmii {
+			groups = "avb4_rgmii";
+			drive-strength = <24>;
+			bias-disable;
+		};
+	};
+
+	avb5_pins: avb5 {
+		mux {
+			groups = "avb5_link", "avb5_mdio", "avb5_rgmii",
+				 "avb5_txcrefclk";
+			function = "avb5";
+		};
+
+		link {
+			groups = "avb5_link";
+			bias-disable;
+		};
+
+		mdio {
+			groups = "avb5_mdio";
+			drive-strength = <24>;
+			bias-disable;
+		};
+
+		rgmii {
+			groups = "avb5_rgmii";
+			drive-strength = <24>;
+			bias-disable;
+		};
+	};
+};
-- 
2.46.2

Re: [PATCH 0/2] arm64: dts: renesas: falcon: Wire-up Ethernet breakout board

[Geert Uytterhoeven]

Hi Niklas,

Thanks for your series!

On Tue, Oct 22, 2024 at 8:48 PM Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> This small series wires up the Marvell 88Q2110 PHYs found on the Falcon
> Ethernet breakout board. With this applied all five PHYs are probed
> correctly.
>
>     mv88q2110 e6810000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6810000.ethernet-ffffffff:07, irq=POLL)
>     mv88q2110 e6820000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6820000.ethernet-ffffffff:07, irq=POLL)
>     mv88q2110 e6830000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6830000.ethernet-ffffffff:07, irq=POLL)
>     mv88q2110 e6840000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6840000.ethernet-ffffffff:07, irq=POLL)
>     mv88q2110 e6850000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6850000.ethernet-ffffffff:07, irq=POLL)
>
> They can be auto detected with just the compatible
> "ethernet-phy-ieee802.3-c45", but to keep the style currently used I
> have added the specific compatible for the 88Q2110 as done for other
> SoCs.

If the specific compatible values are not needed, I prefer not to add
them, as DT should describe only what cannot be auto-detected[1].
Have you tried kexec and/or unbinding/rebinding the AVB driver
(the latter is probably easiest)?

> The primary issue we had with this in the past was due to an incorrect
> PHY address. After studying the schematics (v100) I found the PHYs
> address pins are wired differently on Falcon compared to other Gen4
> boards. On Falcon they are pulled-down, while on other Gen4 boards they
> are left unconnected and subjected to the PHYs internal pull-ups. This
> gives the PHY an address where the lower 3 bits of the address is
> inverted for Falcon.

This was changed in v102 of the schematics (REV0043c vs. REV0043b of
the schematics for the Ethernet sub board): See "Changed Strap pin
settings ==> PHYAD=[0,0,0], pull-down removed" on page 1, and the
various PHY configuration notes...
Moreover, this might be different in other board revisions, as the
BSP uses PHY address 1 for RAVB1, address 2 for RAVB2, and so on...

As I only had remote access to Falcon, I never knew the actual board
revision I was using.

How to handle this (yet another DTS file)?
Are non-v100 variants widespread?

[1] In theory, we could drop all SoC- and family-specific compatible
    values, and just look at the Product Register. I do not suggest
    going that way ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/2] arm64: dts: renesas: falcon: Wire-up Ethernet breakout board

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 109 bytes --]


> Are non-v100 variants widespread?

I'd say nothing related to the Falcon could be called "widespread"...


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] arm64: dts: renesas: falcon: Wire-up Ethernet breakout board

[Geert Uytterhoeven]

Hi Wolfram,

On Wed, Oct 23, 2024 at 9:35 AM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > Are non-v100 variants widespread?
>
> I'd say nothing related to the Falcon could be called "widespread"...

I agree (but I didn't want to be the one to spell it out ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/2] arm64: dts: renesas: falcon: Wire-up Ethernet breakout board

[Niklas Söderlund]

Hi Geert,

On 2024-10-23 09:13:11 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> Thanks for your series!
> 
> On Tue, Oct 22, 2024 at 8:48 PM Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se> wrote:
> > This small series wires up the Marvell 88Q2110 PHYs found on the Falcon
> > Ethernet breakout board. With this applied all five PHYs are probed
> > correctly.
> >
> >     mv88q2110 e6810000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6810000.ethernet-ffffffff:07, irq=POLL)
> >     mv88q2110 e6820000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6820000.ethernet-ffffffff:07, irq=POLL)
> >     mv88q2110 e6830000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6830000.ethernet-ffffffff:07, irq=POLL)
> >     mv88q2110 e6840000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6840000.ethernet-ffffffff:07, irq=POLL)
> >     mv88q2110 e6850000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6850000.ethernet-ffffffff:07, irq=POLL)
> >
> > They can be auto detected with just the compatible
> > "ethernet-phy-ieee802.3-c45", but to keep the style currently used I
> > have added the specific compatible for the 88Q2110 as done for other
> > SoCs.
> 
> If the specific compatible values are not needed, I prefer not to add
> them, as DT should describe only what cannot be auto-detected[1].

Ok, I will post a v2 without the specific compatible value.

> Have you tried kexec and/or unbinding/rebinding the AVB driver
> (the latter is probably easiest)?

I have tested unbinding/rebinding the driver both with and without a 
specific compatible value, both scenarios work.

> 
> > The primary issue we had with this in the past was due to an incorrect
> > PHY address. After studying the schematics (v100) I found the PHYs
> > address pins are wired differently on Falcon compared to other Gen4
> > boards. On Falcon they are pulled-down, while on other Gen4 boards they
> > are left unconnected and subjected to the PHYs internal pull-ups. This
> > gives the PHY an address where the lower 3 bits of the address is
> > inverted for Falcon.
> 
> This was changed in v102 of the schematics (REV0043c vs. REV0043b of
> the schematics for the Ethernet sub board): See "Changed Strap pin
> settings ==> PHYAD=[0,0,0], pull-down removed" on page 1, and the
> various PHY configuration notes...
> Moreover, this might be different in other board revisions, as the
> BSP uses PHY address 1 for RAVB1, address 2 for RAVB2, and so on...
> 
> As I only had remote access to Falcon, I never knew the actual board
> revision I was using.

I could not find any revision markings on the board. But to the best of 
my ability (the markings are not super clear) I have identified that the 
pull-down resistors are indeed present on the board I have.

> 
> How to handle this (yet another DTS file)?
> Are non-v100 variants widespread?

As Wolfram points out, I don't think it's widespread. I think it's OK to 
move forward with this as all the V3U boards we have seen have this 
configuration. If one pops-up later we can solve it then right? As 
solving this properly would need ether a separate DTS source or at least 
an overlay anyhow.

Is this acceptable for you? If so I will post a v2 with the change 
proposed above.
> 
> [1] In theory, we could drop all SoC- and family-specific compatible
>     values, and just look at the Product Register. I do not suggest
>     going that way ;-)
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

-- 
Kind Regards,
Niklas Söderlund

Re: [PATCH 0/2] arm64: dts: renesas: falcon: Wire-up Ethernet breakout board

[Geert Uytterhoeven]

Hi Niklas,

On Wed, Oct 23, 2024 at 2:41 PM Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> On 2024-10-23 09:13:11 +0200, Geert Uytterhoeven wrote:
> > On Tue, Oct 22, 2024 at 8:48 PM Niklas Söderlund
> > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > This small series wires up the Marvell 88Q2110 PHYs found on the Falcon
> > > Ethernet breakout board. With this applied all five PHYs are probed
> > > correctly.
> > >
> > >     mv88q2110 e6810000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6810000.ethernet-ffffffff:07, irq=POLL)
> > >     mv88q2110 e6820000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6820000.ethernet-ffffffff:07, irq=POLL)
> > >     mv88q2110 e6830000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6830000.ethernet-ffffffff:07, irq=POLL)
> > >     mv88q2110 e6840000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6840000.ethernet-ffffffff:07, irq=POLL)
> > >     mv88q2110 e6850000.ethernet-ffffffff:07: attached PHY driver (mii_bus:phy_addr=e6850000.ethernet-ffffffff:07, irq=POLL)
> > >
> > > They can be auto detected with just the compatible
> > > "ethernet-phy-ieee802.3-c45", but to keep the style currently used I
> > > have added the specific compatible for the 88Q2110 as done for other
> > > SoCs.
> >
> > If the specific compatible values are not needed, I prefer not to add
> > them, as DT should describe only what cannot be auto-detected[1].
>
> Ok, I will post a v2 without the specific compatible value.
>
> > Have you tried kexec and/or unbinding/rebinding the AVB driver
> > (the latter is probably easiest)?
>
> I have tested unbinding/rebinding the driver both with and without a
> specific compatible value, both scenarios work.

Great!

> > > The primary issue we had with this in the past was due to an incorrect
> > > PHY address. After studying the schematics (v100) I found the PHYs
> > > address pins are wired differently on Falcon compared to other Gen4
> > > boards. On Falcon they are pulled-down, while on other Gen4 boards they
> > > are left unconnected and subjected to the PHYs internal pull-ups. This
> > > gives the PHY an address where the lower 3 bits of the address is
> > > inverted for Falcon.
> >
> > This was changed in v102 of the schematics (REV0043c vs. REV0043b of
> > the schematics for the Ethernet sub board): See "Changed Strap pin
> > settings ==> PHYAD=[0,0,0], pull-down removed" on page 1, and the
> > various PHY configuration notes...
> > Moreover, this might be different in other board revisions, as the
> > BSP uses PHY address 1 for RAVB1, address 2 for RAVB2, and so on...
> >
> > As I only had remote access to Falcon, I never knew the actual board
> > revision I was using.
>
> I could not find any revision markings on the board. But to the best of
> my ability (the markings are not super clear) I have identified that the
> pull-down resistors are indeed present on the board I have.
>
> > How to handle this (yet another DTS file)?
> > Are non-v100 variants widespread?
>
> As Wolfram points out, I don't think it's widespread. I think it's OK to
> move forward with this as all the V3U boards we have seen have this
> configuration. If one pops-up later we can solve it then right? As
> solving this properly would need ether a separate DTS source or at least
> an overlay anyhow.
>
> Is this acceptable for you? If so I will post a v2 with the change
> proposed above.

Yes, sounds good to me.
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds