2
0

adm6996.txt 5.2 KB

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