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