OpenWrt – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | ------- |
2 | |||
3 | ADM6996FC / ADM6996M switch chip driver |
||
4 | |||
5 | |||
6 | 1. General information |
||
7 | |||
8 | This driver supports the FC and M models only. The ADM6996F and L are |
||
9 | completely different chips. |
||
10 | |||
11 | Support for the FC model is extremely limited at the moment. There is no VLAN |
||
12 | support as of yet. The driver will not offer an swconfig interface for the FC |
||
13 | chip. |
||
14 | |||
15 | 1.1 VLAN IDs |
||
16 | |||
17 | It is possible to define 16 different VLANs. Every VLAN has an identifier, its |
||
18 | VLAN ID. It is easiest if you use at most VLAN IDs 0-15. In that case, the |
||
19 | swconfig based configuration is very straightforward. To define two VLANs with |
||
20 | IDs 4 and 5, you can invoke, for example: |
||
21 | |||
22 | # swconfig dev ethX vlan 4 set ports '0 1t 2 5t' |
||
23 | # swconfig dev ethX vlan 5 set ports '0t 1t 5t' |
||
24 | |||
25 | The swconfig framework will automatically invoke 'port Y set pvid Z' for every |
||
26 | port that is an untagged member of VLAN Y, setting its Primary VLAN ID. In |
||
27 | this example, ports 0 and 2 would get "pvid 4". The Primary VLAN ID of a port |
||
28 | is the VLAN ID associated with untagged packets coming in on that port. |
||
29 | |||
30 | But if you wish to use VLAN IDs outside the range 0-15, this automatic |
||
31 | behaviour of the swconfig framework becomes a problem. The 16 VLANs that |
||
32 | swconfig can configure on the ADM6996 also have a "vid" setting. By default, |
||
33 | this is the same as the number of the VLAN entry, to make the simple behaviour |
||
34 | above possible. To still support a VLAN with a VLAN ID higher than 15 |
||
35 | (presumably because you are in a network where such VLAN IDs are already in |
||
36 | use), you can change the "vid" setting of the VLAN to anything in the range |
||
37 | 0-1023. But suppose you did the following: |
||
38 | |||
39 | # swconfig dev ethX vlan 0 set vid 998 |
||
40 | # swconfig dev ethX vlan 0 set ports '0 2 5t' |
||
41 | |||
42 | Now the swconfig framework will issue 'port 0 set pvid 0' and 'port 2 set pvid |
||
43 | 0'. But the "pvid" should be set to 998, so you are responsible for manually |
||
44 | fixing this! |
||
45 | |||
46 | 1.2 VLAN filtering |
||
47 | |||
48 | The switch is configured to apply source port filtering. This means that |
||
49 | packets are only accepted when the port the packets came in on is a member of |
||
50 | the VLAN the packet should go to. |
||
51 | |||
52 | Only membership of a VLAN is tested, it does not matter whether it is a tagged |
||
53 | or untagged membership. |
||
54 | |||
55 | For untagged packets, the destination VLAN is the Primary VLAN ID of the |
||
56 | incoming port. So if the PVID of a port is 0, but that port is not a member of |
||
57 | the VLAN with ID 0, this means that untagged packets on that port are dropped. |
||
58 | This can be used as a roundabout way of dropping untagged packets from a port, |
||
59 | a mode often referred to as "Admit only tagged packets". |
||
60 | |||
61 | 1.3 Reset |
||
62 | |||
63 | The two supported chip models do not have a sofware-initiated reset. When the |
||
64 | driver is initialised, as well as when the 'reset' swconfig option is invoked, |
||
65 | the driver will set those registers it knows about and supports to the correct |
||
66 | default value. But there are a lot of registers in the chip that the driver |
||
67 | does not support. If something changed those registers, invoking 'reset' or |
||
68 | performing a warm reboot might still leave the chip in a "broken" state. Only |
||
69 | a hardware reset will bring it back in the default state. |
||
70 | |||
71 | 2. Technical details on PHYs and the ADM6996 |
||
72 | |||
73 | From the viewpoint of the Linux kernel, it is common that an Ethernet adapter |
||
74 | can be seen as a separate MAC entity and a separate PHY entity. The PHY entity |
||
75 | can be queried and set through registers accessible via an MDIO bus. A PHY |
||
76 | normally has a single address on that bus, in the range 0 through 31. |
||
77 | |||
78 | The ADM6996 has special-purpose registers in the range of PHYs 0 through 10. |
||
79 | Even though all these registers control a single ADM6996 chip, the Linux |
||
80 | kernel treats this as 11 separate PHYs. The driver will bind to these |
||
81 | addresses to prevent a different PHY driver from binding and corrupting these |
||
82 | registers. |
||
83 | |||
84 | What Linux sees as the PHY on address 0 is meant for the Ethernet MAC |
||
85 | connected to the CPU port of the ADM6996 switch chip (port 5). This is the |
||
86 | Ethernet MAC you will use to send and receive data through the switch. |
||
87 | |||
88 | The PHYs at addresses 16 through 20 map to the PHYs on ports 0 through 4 of |
||
89 | the switch chip. These can be accessed with the Generic PHY driver, as the |
||
90 | registers have the common layout. |
||
91 | |||
92 | If a second Ethernet MAC on your board is wired to the port 4 PHY, that MAC |
||
93 | needs to bind to PHY address 20 for the port to work correctly. |
||
94 | |||
95 | The ADM6996 switch driver will reset the ports 0 through 3 on startup and when |
||
96 | 'reset' is invoked. This could clash with a different PHY driver if the kernel |
||
97 | binds a PHY driver to address 16 through 19. |
||
98 | |||
99 | If Linux binds a PHY on addresses 1 through 10 to an Ethernet MAC, the ADM6996 |
||
100 | driver will simply always report a connected 100 Mbit/s full-duplex link for |
||
101 | that PHY, and provide no other functionality. This is most likely not what you |
||
102 | want. So if you see a message in your log |
||
103 | |||
104 | ethX: PHY overlaps ADM6996, providing fixed PHY yy. |
||
105 | |||
106 | This is most likely an indication that ethX will not work properly, and your |
||
107 | kernel needs to be configured to attach a different PHY to that Ethernet MAC. |
||
108 | |||
109 | Controlling the mapping between MACs and PHYs is usually done in platform- or |
||
110 | board-specific fixup code. The ADM6996 driver has no influence over this. |