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