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-next>] [day] [month] [year] [list]
Date:   Mon, 28 May 2018 19:47:48 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, openwrt-devel@...ts.openwrt.org,
        LEDE Development List <lede-dev@...ts.infradead.org>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver

This is a second RFC version of the DSA driver for Realtek
RTL8366x especially RTL8366RB.

I've been beating my head against this one and I'm not really
clear on why my ethernet frames are not coming through to the
CPU port on the chip.

It appears when using ethtool -S on the ports that packets
are passing fine into the router fabric and through to the
CPU port but the ethernet driver where the fixed link is
connected refuse to accept the packages.

Of course packages needs VLAN tagging/untagging, this is not
the problem as it seems. The OpenWRT userspace even kicks
the interface in promiscuous mode so all packages should be
accepted, I also tried tcpdump on the interface to no avail:
the ethernet frames are so broken that they do not even make
it through the fixed link.

The do cause error statistics on the ethernet port on the
system side.

It might very well be that the problem is on the ethernet
driver side, and this driver "just works" with other
routers, so reposting it along with the DTS example so others
can try it while I keep banging my head against it. Maybe
I should just try to obtain another router with this chip
so as to establish that it is not the DSA router driver that
is wrong.

I did try this hardware with the present OpenWRT driver
(not DSA) and that failed too.

Anyways check out the new DT bindings etc.

Linus Walleij (4):
  net: phy: realtek: Support RTL8366RB variant
  net: dsa: Add bindings for Realtek SMI DSAs
  net: dsa: realtek-smi: Add Realtek SMI driver
  ARM: dts: Add ethernet and switch to D-Link DIR-685

 .../bindings/net/dsa/realtek-smi.txt          |  153 ++
 arch/arm/boot/dts/gemini-dlink-dir-685.dts    |  153 +-
 drivers/net/dsa/Kconfig                       |   12 +
 drivers/net/dsa/Makefile                      |    2 +
 drivers/net/dsa/realtek-smi.c                 |  488 ++++++
 drivers/net/dsa/realtek-smi.h                 |  146 ++
 drivers/net/dsa/rtl8366.c                     |  524 ++++++
 drivers/net/dsa/rtl8366rb.c                   | 1411 +++++++++++++++++
 drivers/net/phy/realtek.c                     |   33 +
 9 files changed, 2921 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
 create mode 100644 drivers/net/dsa/realtek-smi.c
 create mode 100644 drivers/net/dsa/realtek-smi.h
 create mode 100644 drivers/net/dsa/rtl8366.c
 create mode 100644 drivers/net/dsa/rtl8366rb.c

-- 
2.17.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ