mirror of
git://git.openwrt.org/openwrt/openwrt.git
synced 2025-11-03 14:34:27 -05:00
60c125b8e6
This patch adds 802.1Q VLAN support for the ADM6996M chip. The driver is loaded for both the FC and M model. It will detect which of the two chips is connected. The FC model is initialised, but no further functionality is offered. The PHY driver will always report "100 Mbit/s, link up", for both the M and FC models. This reflects the fact that the link between switch chip and Ethernet MAC is always on[1]. Further documentation can be found in the kernel's Documentation/networking/adm6996.txt Signed-of-By: Peter Lebbing <peter@digitalbrains.com> SVN-Revision: 26865
111 lines
5.2 KiB
Plaintext
111 lines
5.2 KiB
Plaintext
-------
|
|
|
|
ADM6996FC / ADM6996M switch chip driver
|
|
|
|
|
|
1. General information
|
|
|
|
This driver supports the FC and M models only. The ADM6996F and L are
|
|
completely different chips.
|
|
|
|
Support for the FC model is extremely limited at the moment. There is no VLAN
|
|
support as of yet. The driver will not offer an swconfig interface for the FC
|
|
chip.
|
|
|
|
1.1 VLAN IDs
|
|
|
|
It is possible to define 16 different VLANs. Every VLAN has an identifier, its
|
|
VLAN ID. It is easiest if you use at most VLAN IDs 0-15. In that case, the
|
|
swconfig based configuration is very straightforward. To define two VLANs with
|
|
IDs 4 and 5, you can invoke, for example:
|
|
|
|
# swconfig dev ethX vlan 4 set ports '0 1t 2 5t'
|
|
# swconfig dev ethX vlan 5 set ports '0t 1t 5t'
|
|
|
|
The swconfig framework will automatically invoke 'port Y set pvid Z' for every
|
|
port that is an untagged member of VLAN Y, setting its Primary VLAN ID. In
|
|
this example, ports 0 and 2 would get "pvid 4". The Primary VLAN ID of a port
|
|
is the VLAN ID associated with untagged packets coming in on that port.
|
|
|
|
But if you wish to use VLAN IDs outside the range 0-15, this automatic
|
|
behaviour of the swconfig framework becomes a problem. The 16 VLANs that
|
|
swconfig can configure on the ADM6996 also have a "vid" setting. By default,
|
|
this is the same as the number of the VLAN entry, to make the simple behaviour
|
|
above possible. To still support a VLAN with a VLAN ID higher than 15
|
|
(presumably because you are in a network where such VLAN IDs are already in
|
|
use), you can change the "vid" setting of the VLAN to anything in the range
|
|
0-1023. But suppose you did the following:
|
|
|
|
# swconfig dev ethX vlan 0 set vid 998
|
|
# swconfig dev ethX vlan 0 set ports '0 2 5t'
|
|
|
|
Now the swconfig framework will issue 'port 0 set pvid 0' and 'port 2 set pvid
|
|
0'. But the "pvid" should be set to 998, so you are responsible for manually
|
|
fixing this!
|
|
|
|
1.2 VLAN filtering
|
|
|
|
The switch is configured to apply source port filtering. This means that
|
|
packets are only accepted when the port the packets came in on is a member of
|
|
the VLAN the packet should go to.
|
|
|
|
Only membership of a VLAN is tested, it does not matter whether it is a tagged
|
|
or untagged membership.
|
|
|
|
For untagged packets, the destination VLAN is the Primary VLAN ID of the
|
|
incoming port. So if the PVID of a port is 0, but that port is not a member of
|
|
the VLAN with ID 0, this means that untagged packets on that port are dropped.
|
|
This can be used as a roundabout way of dropping untagged packets from a port,
|
|
a mode often referred to as "Admit only tagged packets".
|
|
|
|
1.3 Reset
|
|
|
|
The two supported chip models do not have a sofware-initiated reset. When the
|
|
driver is initialised, as well as when the 'reset' swconfig option is invoked,
|
|
the driver will set those registers it knows about and supports to the correct
|
|
default value. But there are a lot of registers in the chip that the driver
|
|
does not support. If something changed those registers, invoking 'reset' or
|
|
performing a warm reboot might still leave the chip in a "broken" state. Only
|
|
a hardware reset will bring it back in the default state.
|
|
|
|
2. Technical details on PHYs and the ADM6996
|
|
|
|
From the viewpoint of the Linux kernel, it is common that an Ethernet adapter
|
|
can be seen as a separate MAC entity and a separate PHY entity. The PHY entity
|
|
can be queried and set through registers accessible via an MDIO bus. A PHY
|
|
normally has a single address on that bus, in the range 0 through 31.
|
|
|
|
The ADM6996 has special-purpose registers in the range of PHYs 0 through 10.
|
|
Even though all these registers control a single ADM6996 chip, the Linux
|
|
kernel treats this as 11 separate PHYs. The driver will bind to these
|
|
addresses to prevent a different PHY driver from binding and corrupting these
|
|
registers.
|
|
|
|
What Linux sees as the PHY on address 0 is meant for the Ethernet MAC
|
|
connected to the CPU port of the ADM6996 switch chip (port 5). This is the
|
|
Ethernet MAC you will use to send and receive data through the switch.
|
|
|
|
The PHYs at addresses 16 through 20 map to the PHYs on ports 0 through 4 of
|
|
the switch chip. These can be accessed with the Generic PHY driver, as the
|
|
registers have the common layout.
|
|
|
|
If a second Ethernet MAC on your board is wired to the port 4 PHY, that MAC
|
|
needs to bind to PHY address 20 for the port to work correctly.
|
|
|
|
The ADM6996 switch driver will reset the ports 0 through 3 on startup and when
|
|
'reset' is invoked. This could clash with a different PHY driver if the kernel
|
|
binds a PHY driver to address 16 through 19.
|
|
|
|
If Linux binds a PHY on addresses 1 through 10 to an Ethernet MAC, the ADM6996
|
|
driver will simply always report a connected 100 Mbit/s full-duplex link for
|
|
that PHY, and provide no other functionality. This is most likely not what you
|
|
want. So if you see a message in your log
|
|
|
|
ethX: PHY overlaps ADM6996, providing fixed PHY yy.
|
|
|
|
This is most likely an indication that ethX will not work properly, and your
|
|
kernel needs to be configured to attach a different PHY to that Ethernet MAC.
|
|
|
|
Controlling the mapping between MACs and PHYs is usually done in platform- or
|
|
board-specific fixup code. The ADM6996 driver has no influence over this.
|