Broadcom Starfighter 2 Ethernet switch driver

Broadcom’s Starfighter 2 Ethernet switch hardware block is commonly found anddeployed in the following products:

  • xDSL gateways such as BCM63138
  • streaming/multimedia Set Top Box such as BCM7445
  • Cable Modem/residential gateways such as BCM7145/BCM3390

The switch is typically deployed in a configuration involving between 5 to 13ports, offering a range of built-in and customizable interfaces:

  • single integrated Gigabit PHY
  • quad integrated Gigabit PHY
  • quad external Gigabit PHY w/ MDIO multiplexer
  • integrated MoCA PHY
  • several external MII/RevMII/GMII/RGMII interfaces

The switch also supports specific congestion control features which allow MoCAfail-over not to lose packets during a MoCA role re-election, as well as out ofband back-pressure to the host CPU network interface when downstream interfacesare connected at a lower speed.

The switch hardware block is typically interfaced using MMIO accesses andcontains a bunch of sub-blocks/registers:

  • SWITCH_CORE: common switch registers
  • SWITCH_REG: external interfaces switch register
  • SWITCH_MDIO: external MDIO bus controller (there is another one in SWITCH_CORE,which is used for indirect PHY accesses)
  • SWITCH_INDIR_RW: 64-bits wide register helper block
  • SWITCH_INTRL2_0/1: Level-2 interrupt controllers
  • SWITCH_ACB: Admission control block
  • SWITCH_FCB: Fail-over control block

Implementation details

The driver is located indrivers/net/dsa/bcm_sf2.c and is implemented as a DSAdriver; seeDocumentation/networking/dsa/dsa.rst for details on the subsystemand what it provides.

The SF2 switch is configured to enable a Broadcom specific 4-bytes switch tagwhich gets inserted by the switch for every packet forwarded to the CPUinterface, conversely, the CPU network interface should insert a similar tag forpackets entering the CPU port. The tag format is described innet/dsa/tag_brcm.c.

Overall, the SF2 driver is a fairly regular DSA driver; there are a fewspecifics covered below.

Device Tree probing

The DSA platform device driver is probed using a specific compatible stringprovided innet/dsa/dsa.c. The reason for that is because the DSA subsystem getsregistered as a platform device driver currently. DSA will provide the neededdevice_node pointers which are then accessible by the switch driver setupfunction to setup resources such as register ranges and interrupts. Thiscurrently works very well because none of the of_* functions utilized by thedriver require a struct device to be bound to a struct device_node, but thingsmay change in the future.

MDIO indirect accesses

Due to a limitation in how Broadcom switches have been designed, externalBroadcom switches connected to a SF2 require the use of the DSA slave MDIO busin order to properly configure them. By default, the SF2 pseudo-PHY address, andan external switch pseudo-PHY address will both be snooping for incoming MDIOtransactions, since they are at the same address (30), resulting in some kind of“double” programming. Using DSA, and settingds->phys_mii_mask accordingly, weselectively divert reads and writes towards external Broadcom switchespseudo-PHY addresses. Newer revisions of the SF2 hardware have introduced aconfigurable pseudo-PHY address which circumvents the initial design limitation.

Multimedia over CoAxial (MoCA) interfaces

MoCA interfaces are fairly specific and require the use of a firmware blob whichgets loaded onto the MoCA processor(s) for packet processing. The switchhardware contains logic which will assert/de-assert link states accordingly forthe MoCA interface whenever the MoCA coaxial cable gets disconnected or thefirmware gets reloaded. The SF2 driver relies on such events to properly set itsMoCA interface carrier state and properly report this to the networking stack.

The MoCA interfaces are supported using the PHY library’s fixed PHY/emulated PHYdevice and the switch driver registers afixed_link_update callback for suchPHYs which reflects the link state obtained from the interrupt handler.

Power Management

Whenever possible, the SF2 driver tries to minimize the overall switch powerconsumption by applying a combination of:

  • turning off internal buffers/memories
  • disabling packet processing logic
  • putting integrated PHYs in IDDQ/low-power
  • reducing the switch core clock based on the active port count
  • enabling and advertising EEE
  • turning off RGMII data processing logic when the link goes down

Wake-on-LAN

Wake-on-LAN is currently implemented by utilizing the host processor EthernetMAC controller wake-on logic. Whenever Wake-on-LAN is requested, an intersectionbetween the user request and the supported host Ethernet interface WoLcapabilities is done and the intersection result gets configured. Duringsystem-wide suspend/resume, only ports not participating in Wake-on-LAN aredisabled.