lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 5 Dec 2017 23:29:58 +0000
From:   <Tristram.Ha@...rochip.com>
To:     <pavel@....cz>
CC:     <andrew@...n.ch>, <f.fainelli@...il.com>, <muvarov@...il.com>,
        <nathan.leigh.conrad@...il.com>,
        <vivien.didelot@...oirfairelinux.com>,
        <UNGLinuxDriver@...rochip.com>, <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895
 DSA driver

> > 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ