[PATCH 1/4] arm: dts: gr-peach: Remove empty line

[PATCH 1/4] arm: dts: gr-peach: Remove empty line

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Remove an empty line in gr-peach device tree source file.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH 2/4] arm: dts: gr-peach: Add SCIF2 pin group

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for SCIF2 serial debug interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add device nodes for user leds on gr-peach board.

Singular? (also in the one-line summary)

> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for ETHER pin group.
> The interface can be configured and probed, but no traffic can be
> transmitted or received.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> ---
> When in u-boot console I can ping a connected host, after the
> system has booted I can configure an ip address on the interface but
> cannot exchange any traffic.
> I have compared the pin configuration procedure with the u-boot
> implemented one and some sketches from mbed operating system libraries,
> the configured pins are correct and registers values seems to match.
> Not sure if this patch should be sent for inclusion but sending it out
> anyway for you to judge this.
>
> Thanks
>    j
> ---
>  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> index bcfa644..5ce558f 100644
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -58,6 +58,28 @@
>                 /* P6_2 as RxD2; P6_3 as TxD2 */
>                 pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
>         };
> +
> +       ether_pins: ether {
> +               /* Ethernet on Ports 1,3,5,10 */
> +               pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
> +                        <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
> +                        <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
> +                        <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
> +                        <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
> +                        <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
> +                        <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
> +                        <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
> +                        <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
> +                        <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
> +                        <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
> +                        <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
> +                        <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
> +                        <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
> +                        <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
> +                        <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
> +                        <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
> +                        <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */

All OK, but do you need P4_2, which is used for ET_nRST?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> Hello Simon,
>    now that RZ/A1 pin controller is merged, it's time to enable some peripheral
> devices on GR-Peach has it has been done for Genmai and RSK boards.
> 
> The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
> be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> be defined in r7s72100.dtsi.
> 
> Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> traffic on that. I can set the ip address and probe the device and double
> checked the pin configuration process against u-boot sources (where the
> interface is working instead). Sending the patch anyway and let you decide what
> to do with that.
> 
> Thanks
>    j
> 
> Jacopo Mondi (4):
>   arm: dts: gr-peach: Remove empty line
>   arm: dts: gr-peach: Add SCIF2 pin group
>   arm: dts: gr-peach: Add ETHER pin group
>   arm: dts: gr-peach: Add user led device nodes

Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
I am leaving the 3rd (ETHER) patch pending resolution of the review
provided by Geert.

[PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 06:53:50AM -0400, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> > Hello Simon,
> >    now that RZ/A1 pin controller is merged, it's time to enable some peripheral
> > devices on GR-Peach has it has been done for Genmai and RSK boards.
> > 
> > The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
> > be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> > be defined in r7s72100.dtsi.
> > 
> > Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> > traffic on that. I can set the ip address and probe the device and double
> > checked the pin configuration process against u-boot sources (where the
> > interface is working instead). Sending the patch anyway and let you decide what
> > to do with that.
> > 
> > Thanks
> >    j
> > 
> > Jacopo Mondi (4):
> >   arm: dts: gr-peach: Remove empty line
> >   arm: dts: gr-peach: Add SCIF2 pin group
> >   arm: dts: gr-peach: Add ETHER pin group
> >   arm: dts: gr-peach: Add user led device nodes
> 
> Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
> I am leaving the 3rd (ETHER) patch pending resolution of the review
> provided by Geert.

BTW, the prefix these patches should start with "ARM:".
I fixed this when applying the patches described above.

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Hi Geert,

On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > Add pin configuration subnode for ETHER pin group.
> > The interface can be configured and probed, but no traffic can be
> > transmitted or received.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > ---
> > When in u-boot console I can ping a connected host, after the
> > system has booted I can configure an ip address on the interface but
> > cannot exchange any traffic.
> > I have compared the pin configuration procedure with the u-boot
> > implemented one and some sketches from mbed operating system libraries,
> > the configured pins are correct and registers values seems to match.
> > Not sure if this patch should be sent for inclusion but sending it out
> > anyway for you to judge this.
> >
> > Thanks
> >    j
> > ---
> >  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > index bcfa644..5ce558f 100644
> > --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > @@ -58,6 +58,28 @@
> >                 /* P6_2 as RxD2; P6_3 as TxD2 */
> >                 pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
> >         };
> > +
> > +       ether_pins: ether {
> > +               /* Ethernet on Ports 1,3,5,10 */
> > +               pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
> > +                        <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
> > +                        <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
> > +                        <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
> > +                        <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
> > +                        <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
> > +                        <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
> > +                        <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
> > +                        <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
> > +                        <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
> > +                        <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
> > +                        <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
> > +                        <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
> > +                        <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
> > +                        <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
> > +                        <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
> > +                        <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
> > +                        <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */
>
> All OK, but do you need P4_2, which is used for ET_nRST?

I tried requesting the GPIO in the "ether" subnode and define it as
"active low", so that it is kept high during regular operations.
I have verified through register writes dump it is cycled just after
the gpio is requested, and this should reset the interface before the
actual sh_eth driver kicks in.

I haven't find any mention in device tree bindings documentation of a
"reset-gpio" property for sh_eth, in the code examples I've seen in
u-boot and mbed, the interface is reset before any actual
configuration is performed. I feel like that should be the place where
that gpio is requested and cycled...

Thanks
   j
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 1:46 PM, jmondi <jacopo@jmondi.org> wrote:
> On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
>> <jacopo+renesas@jmondi.org> wrote:
>> > Add pin configuration subnode for ETHER pin group.
>> > The interface can be configured and probed, but no traffic can be
>> > transmitted or received.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>> >
>> > ---
>> > When in u-boot console I can ping a connected host, after the
>> > system has booted I can configure an ip address on the interface but
>> > cannot exchange any traffic.
>> > I have compared the pin configuration procedure with the u-boot
>> > implemented one and some sketches from mbed operating system libraries,
>> > the configured pins are correct and registers values seems to match.
>> > Not sure if this patch should be sent for inclusion but sending it out
>> > anyway for you to judge this.

>> All OK, but do you need P4_2, which is used for ET_nRST?
>
> I tried requesting the GPIO in the "ether" subnode and define it as
> "active low", so that it is kept high during regular operations.
> I have verified through register writes dump it is cycled just after
> the gpio is requested, and this should reset the interface before the
> actual sh_eth driver kicks in.
>
> I haven't find any mention in device tree bindings documentation of a
> "reset-gpio" property for sh_eth, in the code examples I've seen in
> u-boot and mbed, the interface is reset before any actual
> configuration is performed. I feel like that should be the place where
> that gpio is requested and cycled...

Documentation/devicetree/bindings/net/mdio.txt says

These are generic properties that can apply to any MDIO bus.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Thanks Geert,

On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>

[snip]

> > I haven't find any mention in device tree bindings documentation of a
> > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > u-boot and mbed, the interface is reset before any actual
> > configuration is performed. I feel like that should be the place where
> > that gpio is requested and cycled...
>
> Documentation/devicetree/bindings/net/mdio.txt says
>
> These are generic properties that can apply to any MDIO bus.
>

I have now used mdio defined generic properties

&ether {
	pinctrl-names = "default";
	pinctrl-0 = <&ether_pins>;

	status = "okay";

	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
	reset-delay-us = <5>;

	renesas,no-ether-link;
	phy-handle = <&phy0>;
	phy0: ethernet-phy at 0 {
               reg = <0>;
	};
};

I see the gpio being cycled, but same results as before: device gets
probed, address set, but I cannot ping, device gets probed, address
gets set, but I cannot ping

--- target ---
[    0.000000] libphy: sh_mii: probed
[    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.

# ifconfig eth0 192.168.100.50
[    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)

--- host ---
$ping 192.168.100.50
PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable


Let's leave this out of the DTS series I've just sent for now, ok?

Thanks
   j

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> Thanks Geert,
> 
> On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> 
> [snip]
> 
> > > I haven't find any mention in device tree bindings documentation of a
> > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > u-boot and mbed, the interface is reset before any actual
> > > configuration is performed. I feel like that should be the place where
> > > that gpio is requested and cycled...
> >
> > Documentation/devicetree/bindings/net/mdio.txt says
> >
> > These are generic properties that can apply to any MDIO bus.
> >
> 
> I have now used mdio defined generic properties
> 
> &ether {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&ether_pins>;
> 
> 	status = "okay";
> 
> 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> 	reset-delay-us = <5>;
> 
> 	renesas,no-ether-link;
> 	phy-handle = <&phy0>;
> 	phy0: ethernet-phy at 0 {
>                reg = <0>;
> 	};
> };
> 
> I see the gpio being cycled, but same results as before: device gets
> probed, address set, but I cannot ping, device gets probed, address
> gets set, but I cannot ping
> 
> --- target ---
> [    0.000000] libphy: sh_mii: probed
> [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> 
> # ifconfig eth0 192.168.100.50
> [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> 
> --- host ---
> $ping 192.168.100.50
> PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> 
> 
> Let's leave this out of the DTS series I've just sent for now, ok?

I'm a little confused by this. Am I right in thinking that you don't want
this patch applied at this time and may resubmit it or an updated version
later? With that understanding I have marked it as "Rejected" for now. Feel
free to resubmit when you are ready.

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Hi Simon,

On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > Thanks Geert,
> >
> > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > Hi Jacopo,
> > >
> >
> > [snip]
> >
> > > > I haven't find any mention in device tree bindings documentation of a
> > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > u-boot and mbed, the interface is reset before any actual
> > > > configuration is performed. I feel like that should be the place where
> > > > that gpio is requested and cycled...
> > >
> > > Documentation/devicetree/bindings/net/mdio.txt says
> > >
> > > These are generic properties that can apply to any MDIO bus.
> > >
> >
> > I have now used mdio defined generic properties
> >
> > &ether {
> > 	pinctrl-names = "default";
> > 	pinctrl-0 = <&ether_pins>;
> >
> > 	status = "okay";
> >
> > 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > 	reset-delay-us = <5>;
> >
> > 	renesas,no-ether-link;
> > 	phy-handle = <&phy0>;
> > 	phy0: ethernet-phy at 0 {
> >                reg = <0>;
> > 	};
> > };
> >
> > I see the gpio being cycled, but same results as before: device gets
> > probed, address set, but I cannot ping, device gets probed, address
> > gets set, but I cannot ping
> >
> > --- target ---
> > [    0.000000] libphy: sh_mii: probed
> > [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> >
> > # ifconfig eth0 192.168.100.50
> > [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> >
> > --- host ---
> > $ping 192.168.100.50
> > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >
> >
> > Let's leave this out of the DTS series I've just sent for now, ok?
>
> I'm a little confused by this. Am I right in thinking that you don't want
> this patch applied at this time and may resubmit it or an updated version
> later? With that understanding I have marked it as "Rejected" for now. Feel
> free to resubmit when you are ready.

Yes please, you got me right here.

Even if pix muxing is performed "correctly", and I can set ip address
and probe the interface, not traffic can be exchanged on it.

For this reason, let's not enable it at this time

Is this fine?

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Wed, Aug 30, 2017 at 09:35:28AM +0200, jmondi wrote:
> Hi Simon,
> 
> On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> > On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > > Thanks Geert,
> > >
> > > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > > Hi Jacopo,
> > > >
> > >
> > > [snip]
> > >
> > > > > I haven't find any mention in device tree bindings documentation of a
> > > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > > u-boot and mbed, the interface is reset before any actual
> > > > > configuration is performed. I feel like that should be the place where
> > > > > that gpio is requested and cycled...
> > > >
> > > > Documentation/devicetree/bindings/net/mdio.txt says
> > > >
> > > > These are generic properties that can apply to any MDIO bus.
> > > >
> > >
> > > I have now used mdio defined generic properties
> > >
> > > &ether {
> > > 	pinctrl-names = "default";
> > > 	pinctrl-0 = <&ether_pins>;
> > >
> > > 	status = "okay";
> > >
> > > 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > > 	reset-delay-us = <5>;
> > >
> > > 	renesas,no-ether-link;
> > > 	phy-handle = <&phy0>;
> > > 	phy0: ethernet-phy at 0 {
> > >                reg = <0>;
> > > 	};
> > > };
> > >
> > > I see the gpio being cycled, but same results as before: device gets
> > > probed, address set, but I cannot ping, device gets probed, address
> > > gets set, but I cannot ping
> > >
> > > --- target ---
> > > [    0.000000] libphy: sh_mii: probed
> > > [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> > >
> > > # ifconfig eth0 192.168.100.50
> > > [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> > >
> > > --- host ---
> > > $ping 192.168.100.50
> > > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >
> > >
> > > Let's leave this out of the DTS series I've just sent for now, ok?
> >
> > I'm a little confused by this. Am I right in thinking that you don't want
> > this patch applied at this time and may resubmit it or an updated version
> > later? With that understanding I have marked it as "Rejected" for now. Feel
> > free to resubmit when you are ready.
> 
> Yes please, you got me right here.
> 
> Even if pix muxing is performed "correctly", and I can set ip address
> and probe the interface, not traffic can be exchanged on it.
> 
> For this reason, let's not enable it at this time
> 
> Is this fine?

Yes, that is fine. Lets not enable things that don't work :)