bcm_sf2.rst 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115
  1. =============================================
  2. Broadcom Starfighter 2 Ethernet switch driver
  3. =============================================
  4. Broadcom's Starfighter 2 Ethernet switch hardware block is commonly found and
  5. deployed in the following products:
  6. - xDSL gateways such as BCM63138
  7. - streaming/multimedia Set Top Box such as BCM7445
  8. - Cable Modem/residential gateways such as BCM7145/BCM3390
  9. The switch is typically deployed in a configuration involving between 5 to 13
  10. ports, offering a range of built-in and customizable interfaces:
  11. - single integrated Gigabit PHY
  12. - quad integrated Gigabit PHY
  13. - quad external Gigabit PHY w/ MDIO multiplexer
  14. - integrated MoCA PHY
  15. - several external MII/RevMII/GMII/RGMII interfaces
  16. The switch also supports specific congestion control features which allow MoCA
  17. fail-over not to lose packets during a MoCA role re-election, as well as out of
  18. band back-pressure to the host CPU network interface when downstream interfaces
  19. are connected at a lower speed.
  20. The switch hardware block is typically interfaced using MMIO accesses and
  21. contains a bunch of sub-blocks/registers:
  22. - ``SWITCH_CORE``: common switch registers
  23. - ``SWITCH_REG``: external interfaces switch register
  24. - ``SWITCH_MDIO``: external MDIO bus controller (there is another one in SWITCH_CORE,
  25. which is used for indirect PHY accesses)
  26. - ``SWITCH_INDIR_RW``: 64-bits wide register helper block
  27. - ``SWITCH_INTRL2_0/1``: Level-2 interrupt controllers
  28. - ``SWITCH_ACB``: Admission control block
  29. - ``SWITCH_FCB``: Fail-over control block
  30. Implementation details
  31. ======================
  32. The driver is located in ``drivers/net/dsa/bcm_sf2.c`` and is implemented as a DSA
  33. driver; see ``Documentation/networking/dsa/dsa.rst`` for details on the subsystem
  34. and what it provides.
  35. The SF2 switch is configured to enable a Broadcom specific 4-bytes switch tag
  36. which gets inserted by the switch for every packet forwarded to the CPU
  37. interface, conversely, the CPU network interface should insert a similar tag for
  38. packets entering the CPU port. The tag format is described in
  39. ``net/dsa/tag_brcm.c``.
  40. Overall, the SF2 driver is a fairly regular DSA driver; there are a few
  41. specifics covered below.
  42. Device Tree probing
  43. -------------------
  44. The DSA platform device driver is probed using a specific compatible string
  45. provided in ``net/dsa/dsa.c``. The reason for that is because the DSA subsystem gets
  46. registered as a platform device driver currently. DSA will provide the needed
  47. device_node pointers which are then accessible by the switch driver setup
  48. function to setup resources such as register ranges and interrupts. This
  49. currently works very well because none of the of_* functions utilized by the
  50. driver require a struct device to be bound to a struct device_node, but things
  51. may change in the future.
  52. MDIO indirect accesses
  53. ----------------------
  54. Due to a limitation in how Broadcom switches have been designed, external
  55. Broadcom switches connected to a SF2 require the use of the DSA slave MDIO bus
  56. in order to properly configure them. By default, the SF2 pseudo-PHY address, and
  57. an external switch pseudo-PHY address will both be snooping for incoming MDIO
  58. transactions, since they are at the same address (30), resulting in some kind of
  59. "double" programming. Using DSA, and setting ``ds->phys_mii_mask`` accordingly, we
  60. selectively divert reads and writes towards external Broadcom switches
  61. pseudo-PHY addresses. Newer revisions of the SF2 hardware have introduced a
  62. configurable pseudo-PHY address which circumvents the initial design limitation.
  63. Multimedia over CoAxial (MoCA) interfaces
  64. -----------------------------------------
  65. MoCA interfaces are fairly specific and require the use of a firmware blob which
  66. gets loaded onto the MoCA processor(s) for packet processing. The switch
  67. hardware contains logic which will assert/de-assert link states accordingly for
  68. the MoCA interface whenever the MoCA coaxial cable gets disconnected or the
  69. firmware gets reloaded. The SF2 driver relies on such events to properly set its
  70. MoCA interface carrier state and properly report this to the networking stack.
  71. The MoCA interfaces are supported using the PHY library's fixed PHY/emulated PHY
  72. device and the switch driver registers a ``fixed_link_update`` callback for such
  73. PHYs which reflects the link state obtained from the interrupt handler.
  74. Power Management
  75. ----------------
  76. Whenever possible, the SF2 driver tries to minimize the overall switch power
  77. consumption by applying a combination of:
  78. - turning off internal buffers/memories
  79. - disabling packet processing logic
  80. - putting integrated PHYs in IDDQ/low-power
  81. - reducing the switch core clock based on the active port count
  82. - enabling and advertising EEE
  83. - turning off RGMII data processing logic when the link goes down
  84. Wake-on-LAN
  85. -----------
  86. Wake-on-LAN is currently implemented by utilizing the host processor Ethernet
  87. MAC controller wake-on logic. Whenever Wake-on-LAN is requested, an intersection
  88. between the user request and the supported host Ethernet interface WoL
  89. capabilities is done and the intersection result gets configured. During
  90. system-wide suspend/resume, only ports not participating in Wake-on-LAN are
  91. disabled.