aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/dsa/rtl8366.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-06-15net: dsa: rtl8366: Fix up VLAN filteringLinus Walleij1-3/+4
We get this regression when using RTL8366RB as part of a bridge with OpenWrt: WARNING: CPU: 0 PID: 1347 at net/switchdev/switchdev.c:291 switchdev_port_attr_set_now+0x80/0xa4 lan0: Commit of attribute (id=7) failed. (...) realtek-smi switch lan0: failed to initialize vlan filtering on this port This is because it is trying to disable VLAN filtering on VLAN0, as we have forgot to add 1 to the port number to get the right VLAN in rtl8366_vlan_filtering(): when we initialize the VLAN we associate VLAN1 with port 0, VLAN2 with port 1 etc, so we need to add 1 to the port offset. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-14net: dsa: fix warning same module namesAnders Roxell1-1/+1
When building with CONFIG_NET_DSA_REALTEK_SMI and CONFIG_REALTEK_PHY enabled as loadable modules, we see the following warning: warning: same module names found: drivers/net/phy/realtek.ko drivers/net/dsa/realtek.ko Rework so the driver name is realtek-smi instead of realtek. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-18dsa: rtl8366: Remove unused variable.David S. Miller1-1/+0
drivers/net/dsa/rtl8366.c: In function ‘rtl8366_reset_vlan’: drivers/net/dsa/rtl8366.c:234:25: warning: unused variable ‘vlan4k’ [-Wunused-variable] Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-18net: dsa: realtek-smi: Add Realtek SMI driverLinus Walleij1-0/+516
This adds a driver core for the Realtek SMI chips and a subdriver for the RTL8366RB. I just added this chip simply because it is all I can test. The code is a massaged variant of the code that has been sitting out-of-tree in OpenWRT for years in the absence of a proper switch subsystem. This creates a DSA driver for it. I have tried to credit the original authors wherever possible. The main changes I've done from the OpenWRT code: - Added an IRQ chip inside the RTL8366RB switch to demux and handle the line state IRQs. - Distributed the phy handling out to the PHY driver. - Added some RTL8366RB code that was missing in the driver at the time, such as setting up "green ethernet" with a funny jam table and forcing MAC5 (the CPU port) into 1 GBit. - Select jam table and add the default jam table from the vendor driver, also for ASIC "version 0" if need be. - Do not store jam tables in the device tree, store them in the driver. - Pick in the "initvals" jam tables from OpenWRT's driver and make those get selected per compatible for the whole system. It's apparently about electrical settings for this system and whatnot, not really configuration from device tree. - Implemented LED control: beware of bugs because there are no LEDs on the device I am using! We do not implement custom DSA tags. This is explained in a comment in the driver as well: this "tagging protocol" is not simply a few extra bytes tagged on to the ethernet frame as DSA is used to. Instead, enabling the CPU tags will make the switch start talking Realtek RRCP internally. For example a simple ping will make this kind of packets appear inside the switch: 0000 ff ff ff ff ff ff bc ae c5 6b a8 3d 88 99 a2 00 0010 08 06 00 01 08 00 06 04 00 01 bc ae c5 6b a8 3d 0020 a9 fe 01 01 00 00 00 00 00 00 a9 fe 01 02 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 As you can see a custom "8899" tagged packet using the protocol 0xa2. Norm RRCP appears to always have this protocol set to 0x01 according to OpenRRCP. You can also see that this is not a ping packet at all, instead the switch is starting to talk network management issues with the CPU port. So for now custom "tagging" is disabled. This was tested on the D-Link DIR-685 with initramfs and OpenWRT userspaces and works fine on all the LAN ports (lan0 .. lan3). The WAN port is yet not working. Cc: Antti Seppälä <a.seppala@gmail.com> Cc: Roman Yeryomin <roman@advem.lv> Cc: Colin Leitner <colin.leitner@googlemail.com> Cc: Gabor Juhos <juhosg@openwrt.org> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>