Sync code to the same with tk4 pub/lts/0017-kabi, except deleted rue
and wujing. Partners can submit pull requests to this branch, and we
can pick the commits to tk4 pub/lts/0017-kabi easly.
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
Gitee limit the repo's size to 3GB, to reduce the size of the code,
sync codes to ock 5.4.119-20.0009.21 in one commit.
Signed-off-by: Jianping Liu <frankjpliu@tencent.com>
of_node_put needs to be called when the device node which is got
from of_get_child_by_name finished using.
irq_domain_add_linear() also calls of_node_get() to increase refcount,
so irq_domain will not be affected when it is released.
Fixes: d8652956cf ("net: dsa: realtek-smi: Add Realtek SMI driver")
Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
No current DSA driver makes use of the phydev parameter passed to the
disable_port call. Remove it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The totally undocumented IO mode needs to be set to enumerator
0 to enable port 4 also known as WAN in most configurations,
for ordinary traffic. The 3 bits in the register come up as
010 after reset, but need to be set to 000.
The Realtek source code contains a name for these bits, but
no explanation of what the 8 different IO modes may be.
Set it to zero for the time being and drop a comment so
people know what is going on if they run into trouble. This
"mode zero" works fine with the D-Link DIR-685 with
RTL8366RB.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
Jianping Liu