Re: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

[Andrew Lunn]

> > I also have a simple utility to communicate with that registers file to 
> > read/write
> > register individually.  Is there a standard Linux utility for that
> > function?
> 
> I don't think standard utility exists. Binary file which can be
> written by userspace shoudl be enough.

mii-tool will allow you to read PHY registers. The kernel API it uses
allows you to read any register on the MDIO bus.

>spi@0 {
> compatible = "microchip,ksz8895";
>   ...
>   ports {
>   port@4 {
>   reg = <4>;
>   label = "cpu";
>   ethernet = <>;
>   fixed-link {
>   speed = <100>;
>   full-duplex;
>   };
>   };
> };
>  };
> 
> On one side, and
> 
>  mac0: ethernet@800f {
>phy-mode = "rmii";
>status = "okay";
>fixed-link {
> speed = <100>;
> full-duplex;
>};
>  };

Are the MAC connected back-to-back, or do you have PHYs in the middle?

mac0 you have phy-mode = "rmii";. You can put the same in the port@4,
but i don't know if the driver looks for it, and configures the MAC as
needed.

Andrew

Re: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

[Pavel Machek]

Hi!

Thanks for the support.

> > root@miro:~# mii-tool lan3
> > lan3: negotiated 1000baseT-HD flow-control, link ok
> > 
> > But IIRC the switch is 100mbit? And dmesg does get it right. Its just
> > mii-tool that is confused.
> > 
> > Link detection seems to work
> > 
> > root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> > lan1: negotiated 1000baseT-HD flow-control, link ok
> > root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> > lan1: no link
> > 
> > (But that really should be 100baseT, not 1000baseT).
> 
> ethtool lan3 should also report the correct setting.

Yes, after port is configured, ethtool produces right results:

 Speed: 100Mb/s
 Duplex: Full

Before that, it looks rather confusing:

root@miro:~# ethtool lan2
root@miro:~# ethtool lan2
Settings for lan2:
...
Speed: Unknown!
Duplex: Unknown! (255)

> > Is there register dump available somewhere? I was using
> > /sys/bus/spi/devices/spi32766.0/registers but this does not seem to be
> > available.
> 
> There is a patch to add that functionality.  It is very simple and I will 
> send it
> to you later.  Without that it is hard to debug the DSA driver if there is
> something wrong.

That would be nice :-).

> I also have a simple utility to communicate with that registers file to 
> read/write
> register individually.  Is there a standard Linux utility for that
> function?

I don't think standard utility exists. Binary file which can be
written by userspace shoudl be enough.

> >  p04_rx: 660
> >  p04_rx_hi: 0
> >  p04_rx_undersize: 0
> >  p04_rx_fragments: 20
> 
> This indicates a problem with the MAC.  Are you using a MII or RMII version?

I do have:
mac0: ethernet@800f {
   phy-mode = "rmii";
   pinctrl-names = "default";
   ...
   }

> >  p04_tx_hi: 0
> >  p04_tx_late_col: 0
> >  p04_tx_pause: 0
> >  p04_tx_bcast: 0
> >  p04_tx_mcast: 3
> 

> This indicates the host port tried to send frames to the MAC.
> >  tx_total_col: 0
> >  tx_exc_col: 0
> >  tx_single_col: 0
> >  tx_mult_col: 0
> >  rx_discards: 0
> >  tx_discards: 0
> 
> They just reported frames are received from the port.  Because of problem with
> the host port there is no transmission coming from the host port.

I disabled second ethernet port in the dts so it could not interfere
with testing, butno change.

Is there any way to debug the host port problems? I do have

   spi@0 {
compatible = "microchip,ksz8895";
...
ports {
port@4 {
reg = <4>;
label = "cpu";
ethernet = <>;
fixed-link {
speed = <100>;
full-duplex;
};
};
};
 };

On one side, and

 mac0: ethernet@800f {
   phy-mode = "rmii";
   status = "okay";
   fixed-link {
  speed = <100>;
  full-duplex;
   };
 };

on the other...

Thanks,
Pavel
 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

RE: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

[Tristram.Ha]

> Ok, let me retry:
> 
> > One thing to debug this problem is to dump the MIB counters.  Use the
> ethtool
> > utility to show MIB counters of both ports:
> >
> > ethtool -S lan3
> > ethtool -S eth0
> >
> > Assuming eth0 is the MAC controller that drives the switch, the receive
> counters of
> > the host port of the switch should match the transmit counters of
> > lan3, and vice versa.
> 
> Hmm. I'm getting some "interesting" results from mii-tool:
> 
> root@miro:~# mii-tool lan3
> lan3: negotiated 1000baseT-HD flow-control, link ok
> 
> But IIRC the switch is 100mbit? And dmesg does get it right. Its just
> mii-tool that is confused.
> 
> Link detection seems to work
> 
> root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> lan1: negotiated 1000baseT-HD flow-control, link ok
> root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> lan1: no link
> 
> (But that really should be 100baseT, not 1000baseT).

ethtool lan3 should also report the correct setting.

> Is there register dump available somewhere? I was using
> /sys/bus/spi/devices/spi32766.0/registers but this does not seem to be
> available.

There is a patch to add that functionality.  It is very simple and I will send 
it
to you later.  Without that it is hard to debug the DSA driver if there is
something wrong.

I also have a simple utility to communicate with that registers file to 
read/write
register individually.  Is there a standard Linux utility for that function?

> I tried that ethtool -S, and counters do not seem to match:
> root@miro:~# ethtool -S eth0
> NIC statistics:
>  tx_dropped: 0
>  tx_packets: 55
>  tx_broadcast: 35
>  tx_multicast: 20
>  tx_crc_errors: 0
>  tx_undersize: 0
>  tx_oversize: 0
>  tx_fragment: 0
>  tx_jabber: 0
>  tx_collision: 0
>  tx_64byte: 0
>  tx_65to127byte: 35
>  tx_128to255byte: 0
>  tx_256to511byte: 20
>  tx_512to1023byte: 0
>  tx_1024to2047byte: 0
>  tx_GTE2048byte: 0
>  tx_octets: 9576
>  IEEE_tx_drop: 0
>  IEEE_tx_frame_ok: 55
>  IEEE_tx_1col: 0
>  IEEE_tx_mcol: 0
>  IEEE_tx_def: 0
>  IEEE_tx_lcol: 0
>  IEEE_tx_excol: 0
>  IEEE_tx_macerr: 0
>  IEEE_tx_cserr: 0
>  IEEE_tx_sqe: 0
>  IEEE_tx_fdxfc: 0
>  IEEE_tx_octets_ok: 9576
>  rx_packets: 0
>  rx_broadcast: 0
>  rx_multicast: 0
>  rx_crc_errors: 0
>  rx_undersize: 0
>  rx_oversize: 0
>  rx_fragment: 0
>  rx_jabber: 0
>  rx_64byte: 0
>  rx_65to127byte: 0
>  rx_128to255byte: 0
>  rx_256to511byte: 0
>  rx_512to1023byte: 0
>  rx_1024to2047byte: 0
>  rx_GTE2048byte: 0
>  rx_octets: 0
>  IEEE_rx_drop: 0
>  IEEE_rx_frame_ok: 0
>  IEEE_rx_crc: 0
>  IEEE_rx_align: 0
>  IEEE_rx_macerr: 0
>  IEEE_rx_fdxfc: 0
>  IEEE_rx_octets_ok: 0

These are the MIB counters from the switch host port:

>  p04_rx: 660
>  p04_rx_hi: 0
>  p04_rx_undersize: 0
>  p04_rx_fragments: 20

This indicates a problem with the MAC.  Are you using a MII or RMII version?

>  p04_rx_oversize: 0
>  p04_rx_jabbers: 0
>  p04_rx_symbol_err: 0
>  p04_rx_crc_err: 0
>  p04_rx_align_err: 0
>  p04_rx_mac_ctrl: 0
>  p04_rx_pause: 0
>  p04_rx_bcast: 0
>  p04_rx_mcast: 0
>  p04_rx_ucast: 0
>  p04_rx_64_or_less: 0
>  p04_rx_65_127: 0
>  p04_rx_128_255: 0
>  p04_rx_256_511: 0
>  p04_rx_512_1023: 0
>  p04_rx_1024_1522: 0
>  p04_tx: 388
>  p04_tx_hi: 0
>  p04_tx_late_col: 0
>  p04_tx_pause: 0
>  p04_tx_bcast: 0
>  p04_tx_mcast: 3

This indicates the host port tried to send frames to the MAC.

>  p04_tx_ucast: 0
>  p04_tx_deferred: 0
>  p04_tx_total_col: 0
>  p04_tx_exc_col: 0
>  p04_tx_single_col: 0
>  p04_tx_mult_col: 0
>  p04_rx_discards: 0
>  p04_tx_discards: 0
> root@miro:~# ethtool -S lan3
> NIC statistics:
>  tx_packets: 24
>  tx_bytes: 1356
>  rx_packets: 0
>  rx_bytes: 0

The previous counters are from DSA.  The rest are MIB counters of the port.

>  rx: 566
>  rx_hi: 0
>  rx_undersize: 0
>  rx_fragments: 0
>  rx_oversize: 0
>  rx_jabbers: 0
>  rx_symbol_err: 0
>  rx_crc_err: 0
>  rx_align_err: 0
>  rx_mac_ctrl: 0
>  rx_pause: 0
>  rx_bcast: 0
>  rx_mcast: 4
>  rx_ucast: 0
>  rx_64_or_less: 0
>  rx_65_127: 1
>  rx_128_255: 3
>  rx_256_511: 0
>  rx_512_1023: 0
>  rx_1024_1522: 0
>  tx: 0
>  tx_hi: 0
>  tx_late_col: 0
>  tx_pause: 0
>  tx_bcast: 0
>  tx_mcast: 0
>  tx_ucast: 0
>  tx_deferred: 0
>  tx_total_col: 0
>  tx_exc_col: 0
>  tx_single_col: 0
>  tx_mult_col: 0
>  rx_discards: 0
>  tx_discards: 0

They just reported frames are received from the port.  Because of problem with
the host port there is no transmission coming from the host port.

Re: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

[Pavel Machek]

Hi!

> > I went back to my version of dsa patches, and test above works as
> > expected.
> 
> Sorry to be this late for the reply.  I finally got hold of a KSZ8895 board 
> that
> works with my SoC board to confirm the network communication.
> 
> As expected the KSZ8895 board works correctly as the chip uses the same
> tail tagging feature in KSZ8795, and I did verify that board is
 > working.

Ok, let me retry:

> One thing to debug this problem is to dump the MIB counters.  Use the ethtool
> utility to show MIB counters of both ports:
> 
> ethtool -S lan3
> ethtool -S eth0
> 
> Assuming eth0 is the MAC controller that drives the switch, the receive 
> counters of
> the host port of the switch should match the transmit counters of
> lan3, and vice versa.

Hmm. I'm getting some "interesting" results from mii-tool:

root@miro:~# mii-tool lan3
lan3: negotiated 1000baseT-HD flow-control, link ok

But IIRC the switch is 100mbit? And dmesg does get it right. Its just
mii-tool that is confused.

Link detection seems to work

root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
lan1: negotiated 1000baseT-HD flow-control, link ok
root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
lan1: no link

(But that really should be 100baseT, not 1000baseT).

Is there register dump available somewhere? I was using
/sys/bus/spi/devices/spi32766.0/registers but this does not seem to be
available.

I tried that ethtool -S, and counters do not seem to match:

Help welcome.

Best regards,
Pavel

root@miro:~# ifconfig eth0 up
root@miro:~# ifconfig lan3 192.168.20.103 netmask 255.255.0.0 up
[  180.903675] IPv6: ADDRCONF(NETDEV_UP): lan3: link is not ready
root@miro:~# [  181.913284] ksz8895-switch spi2.0 lan3: Link is Up - 
100Mbps/Full - flow control rx/tx
[  181.921358] IPv6: ADDRCONF(NETDEV_CHANGE): lan3: link becomes ready

root@miro:~# route add default gw 192.168.1.1
root@miro:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
^C
--- 192.168.1.1 ping statistics ---
17 packets transmitted, 0 packets received, 100% packet loss
root@miro:~# ethtool -S eth0
NIC statistics:
 tx_dropped: 0
 tx_packets: 55
 tx_broadcast: 35
 tx_multicast: 20
 tx_crc_errors: 0
 tx_undersize: 0
 tx_oversize: 0
 tx_fragment: 0
 tx_jabber: 0
 tx_collision: 0
 tx_64byte: 0
 tx_65to127byte: 35
 tx_128to255byte: 0
 tx_256to511byte: 20
 tx_512to1023byte: 0
 tx_1024to2047byte: 0
 tx_GTE2048byte: 0
 tx_octets: 9576
 IEEE_tx_drop: 0
 IEEE_tx_frame_ok: 55
 IEEE_tx_1col: 0
 IEEE_tx_mcol: 0
 IEEE_tx_def: 0
 IEEE_tx_lcol: 0
 IEEE_tx_excol: 0
 IEEE_tx_macerr: 0
 IEEE_tx_cserr: 0
 IEEE_tx_sqe: 0
 IEEE_tx_fdxfc: 0
 IEEE_tx_octets_ok: 9576
 rx_packets: 0
 rx_broadcast: 0
 rx_multicast: 0
 rx_crc_errors: 0
 rx_undersize: 0
 rx_oversize: 0
 rx_fragment: 0
 rx_jabber: 0
 rx_64byte: 0
 rx_65to127byte: 0
 rx_128to255byte: 0
 rx_256to511byte: 0
 rx_512to1023byte: 0
 rx_1024to2047byte: 0
 rx_GTE2048byte: 0
 rx_octets: 0
 IEEE_rx_drop: 0
 IEEE_rx_frame_ok: 0
 IEEE_rx_crc: 0
 IEEE_rx_align: 0
 IEEE_rx_macerr: 0
 IEEE_rx_fdxfc: 0
 IEEE_rx_octets_ok: 0
 p04_rx: 660
 p04_rx_hi: 0
 p04_rx_undersize: 0
 p04_rx_fragments: 20
 p04_rx_oversize: 0
 p04_rx_jabbers: 0
 p04_rx_symbol_err: 0
 p04_rx_crc_err: 0
 p04_rx_align_err: 0
 p04_rx_mac_ctrl: 0
 p04_rx_pause: 0
 p04_rx_bcast: 0
 p04_rx_mcast: 0
 p04_rx_ucast: 0
 p04_rx_64_or_less: 0
 p04_rx_65_127: 0
 p04_rx_128_255: 0
 p04_rx_256_511: 0
 p04_rx_512_1023: 0
 p04_rx_1024_1522: 0
 p04_tx: 388
 p04_tx_hi: 0
 p04_tx_late_col: 0
 p04_tx_pause: 0
 p04_tx_bcast: 0
 p04_tx_mcast: 3
 p04_tx_ucast: 0
 p04_tx_deferred: 0
 p04_tx_total_col: 0
 p04_tx_exc_col: 0
 p04_tx_single_col: 0
 p04_tx_mult_col: 0
 p04_rx_discards: 0
 p04_tx_discards: 0
root@miro:~# ethtool -S lan3
NIC statistics:
 tx_packets: 24
 tx_bytes: 1356
 rx_packets: 0
 rx_bytes: 0
 rx: 566
 rx_hi: 0
 rx_undersize: 0
 rx_fragments: 0
 rx_oversize: 0
 rx_jabbers: 0
 rx_symbol_err: 0
 rx_crc_err: 0
 rx_align_err: 0
 rx_mac_ctrl: 0
 rx_pause: 0
 rx_bcast: 0
 rx_mcast: 4
 rx_ucast: 0
 rx_64_or_less: 0
 rx_65_127: 1
 rx_128_255: 3
 rx_256_511: 0
 rx_512_1023: 0
 rx_1024_1522: 0
 tx: 0
 tx_hi: 0
 tx_late_col: 0
 tx_pause: 0
 tx_bcast: 0
 tx_mcast: 0
 tx_ucast: 0
 tx_deferred: 0
 tx_total_col: 0
 tx_exc_col: 0
 tx_single_col: 0
 tx_mult_col: 0
 rx_discards: 0
 tx_discards: 0
root@miro:~# 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

[Tristram.Ha]

> > Sorry to be this late for the reply.  I finally got hold of a KSZ8895 board 
> > that
> > works with my SoC board to confirm the network communication.
> >
> > As expected the KSZ8895 board works correctly as the chip uses the same
> > tail tagging feature in KSZ8795, and I did verify that board is working.
> >
> > One thing to debug this problem is to dump the MIB counters.  Use the
> ethtool
> > utility to show MIB counters of both ports:
> >
> > ethtool -S lan3
> > ethtool -S eth0
> >
> > Assuming eth0 is the MAC controller that drives the switch, the receive
> counters of
> > the host port of the switch should match the transmit counters of
> > lan3, and vice versa.
> 
> Thanks for reply. I'll get to the tests shortly. Could I get .dts
> snippet that works for you and commands you are using for testing?
> 

You said your previous patch works, so I do not think there is anything wrong
with the device tree, unless you are using a completely different one.

The tricky part of network communication is the RMII/MII interface where the
host port connects to the MAC controller.  But again your patch works so there 
is
nothing wrong with the hardware.

I also use a simple setup to test the network:

ifconfig eth0 up
ifconfig lan1 192.168.0.1
ping -c 2 192.168.0.100

If I want a complete test I setup a bridge:

ifconfig eth0 up
ifconfig lan1 up
ifconfig lan2 up
ifconfig lan3 up
ifconfig lan4 up
brctl addbr br0
brctl addif br0 lan1
brctl addif br0 lan2
brctl addif br0 lan3
brctl addif br0 lan4
ifconfig br0 192.168.0.1
ping -c 2 192.168.0.100

RE: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

[Tristram.Ha]

> Thanks for patches. I installed whole series on top of net-next.
> 
> Hardware is:
> 
> root@miro:~# cat /proc/cpuinfo
> model name   : ARM926EJ-S rev 5 (v5l)
> Hardware: Freescale MXS (Device Tree)
> 
> I added devicetree chunks, and enabled DSA in the config. It seems
> switch is detected:
> 
> [4.775934] Micrel KSZ8051 dsa-0.0:00: attached PHY driver [Micrel
> KSZ8051] (mii_bus:phy_addr=dsa-0.0:00, irq=POLL)
> [4.885952] Micrel KSZ8051 dsa-0.0:01: attached PHY driver [Micrel
> KSZ8051] (mii_bus:phy_addr=dsa-0.0:01, irq=POLL)
> [4.995934] Micrel KSZ8051 dsa-0.0:02: attached PHY driver [Micrel
> KSZ8051] (mii_bus:phy_addr=dsa-0.0:02, irq=POLL)
> [5.011484] DSA: tree 0 setup
> 
> root@miro:~# ifconfig lan3 192.168.20.103 netmask 255.255.0.0 up
> [  131.196667] IPv6: ADDRCONF(NETDEV_UP): lan3: link is not ready
> root@miro:~# [  132.225863] ksz8895-switch spi2.0 lan3: Link is Up -
> 100Mbps/Full - flow control rx/tx
> [  132.233939] IPv6: ADDRCONF(NETDEV_CHANGE): lan3: link becomes ready
> 
> root@miro:~# ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ^C
> --- 192.168.1.1 ping statistics ---
> 7 packets transmitted, 0 packets received, 100% packet loss
> root@miro:~# ifconfig [  149.904234] random: crng init done
> 
> But packets do not go through, and there is nothing helpful in
> dmesg. Dts part is:
> 
> spi@0 {
>   compatible = "microchip,ksz8895";
> spi-max-frequency = <2500>;
> reg = <0>;
>   // reset-gpios = < 8 0>;
> status = "okay";
> 
> spi-cpha;
>   spi-cpol;
>ports {
>  #address-cells = <1>;
>  #size-cells = <0>;
>  port@0 {
> reg = <0>;
> label = "lan1";
>  };
>  port@1 {
> reg = <1>;
> label = "lan2";
>  };
>  port@2 {
> reg = <2>;
> label = "lan3";
>  };
>  port@4 {
> reg = <4>;
> label = "cpu";
> ethernet = <>;
> fixed-link {
>speed = <100>;
>full-duplex;
> };
>  };
>};
>   };
> 
> I went back to my version of dsa patches, and test above works as
> expected.

Sorry to be this late for the reply.  I finally got hold of a KSZ8895 board that
works with my SoC board to confirm the network communication.

As expected the KSZ8895 board works correctly as the chip uses the same
tail tagging feature in KSZ8795, and I did verify that board is working.

One thing to debug this problem is to dump the MIB counters.  Use the ethtool
utility to show MIB counters of both ports:

ethtool -S lan3
ethtool -S eth0

Assuming eth0 is the MAC controller that drives the switch, the receive 
counters of
the host port of the switch should match the transmit counters of lan3, and 
vice versa.

Re: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

[Pavel Machek]

Hi!

> From: Tristram Ha 
> 
> Add Microchip KSZ8895 DSA driver.
> 
> Signed-off-by: Tristram Ha 
> Reviewed-by: Woojung Huh 

Thanks for patches. I installed whole series on top of net-next.

Hardware is:

root@miro:~# cat /proc/cpuinfo
model name   : ARM926EJ-S rev 5 (v5l)
Hardware  : Freescale MXS (Device Tree)

I added devicetree chunks, and enabled DSA in the config. It seems
switch is detected:

[4.775934] Micrel KSZ8051 dsa-0.0:00: attached PHY driver [Micrel
KSZ8051] (mii_bus:phy_addr=dsa-0.0:00, irq=POLL)
[4.885952] Micrel KSZ8051 dsa-0.0:01: attached PHY driver [Micrel
KSZ8051] (mii_bus:phy_addr=dsa-0.0:01, irq=POLL)
[4.995934] Micrel KSZ8051 dsa-0.0:02: attached PHY driver [Micrel
KSZ8051] (mii_bus:phy_addr=dsa-0.0:02, irq=POLL)
[5.011484] DSA: tree 0 setup

root@miro:~# ifconfig lan3 192.168.20.103 netmask 255.255.0.0 up
[  131.196667] IPv6: ADDRCONF(NETDEV_UP): lan3: link is not ready
root@miro:~# [  132.225863] ksz8895-switch spi2.0 lan3: Link is Up -
100Mbps/Full - flow control rx/tx
[  132.233939] IPv6: ADDRCONF(NETDEV_CHANGE): lan3: link becomes ready

root@miro:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
^C
--- 192.168.1.1 ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
root@miro:~# ifconfig [  149.904234] random: crng init done

But packets do not go through, and there is nothing helpful in
dmesg. Dts part is:

spi@0 {
compatible = "microchip,ksz8895";
spi-max-frequency = <2500>;
reg = <0>;
// reset-gpios = < 8 0>;
status = "okay";

spi-cpha;
spi-cpol;
   ports {
 #address-cells = <1>;
 #size-cells = <0>;
 port@0 {
reg = <0>;
label = "lan1";
 };
 port@1 {
reg = <1>;
label = "lan2";
 };
 port@2 {
reg = <2>;
label = "lan3";
 };
 port@4 {
reg = <4>;
label = "cpu";
ethernet = <>;
fixed-link {
   speed = <100>;
   full-duplex;
};
 };
   };
};

I went back to my version of dsa patches, and test above works as
expected.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature