| 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. |
| 111 | |
