mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
115 lines
5.1 KiB
115 lines
5.1 KiB
============================================= |
|
Broadcom Starfighter 2 Ethernet switch driver |
|
============================================= |
|
|
|
Broadcom's Starfighter 2 Ethernet switch hardware block is commonly found and |
|
deployed 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 13 |
|
ports, 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 MoCA |
|
fail-over not to lose packets during a MoCA role re-election, as well as out of |
|
band back-pressure to the host CPU network interface when downstream interfaces |
|
are connected at a lower speed. |
|
|
|
The switch hardware block is typically interfaced using MMIO accesses and |
|
contains 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 in ``drivers/net/dsa/bcm_sf2.c`` and is implemented as a DSA |
|
driver; see ``Documentation/networking/dsa/dsa.rst`` for details on the subsystem |
|
and what it provides. |
|
|
|
The SF2 switch is configured to enable a Broadcom specific 4-bytes switch tag |
|
which gets inserted by the switch for every packet forwarded to the CPU |
|
interface, conversely, the CPU network interface should insert a similar tag for |
|
packets entering the CPU port. The tag format is described in |
|
``net/dsa/tag_brcm.c``. |
|
|
|
Overall, the SF2 driver is a fairly regular DSA driver; there are a few |
|
specifics covered below. |
|
|
|
Device Tree probing |
|
------------------- |
|
|
|
The DSA platform device driver is probed using a specific compatible string |
|
provided in ``net/dsa/dsa.c``. The reason for that is because the DSA subsystem gets |
|
registered as a platform device driver currently. DSA will provide the needed |
|
device_node pointers which are then accessible by the switch driver setup |
|
function to setup resources such as register ranges and interrupts. This |
|
currently works very well because none of the of_* functions utilized by the |
|
driver require a struct device to be bound to a struct device_node, but things |
|
may change in the future. |
|
|
|
MDIO indirect accesses |
|
---------------------- |
|
|
|
Due to a limitation in how Broadcom switches have been designed, external |
|
Broadcom switches connected to a SF2 require the use of the DSA slave MDIO bus |
|
in order to properly configure them. By default, the SF2 pseudo-PHY address, and |
|
an external switch pseudo-PHY address will both be snooping for incoming MDIO |
|
transactions, since they are at the same address (30), resulting in some kind of |
|
"double" programming. Using DSA, and setting ``ds->phys_mii_mask`` accordingly, we |
|
selectively divert reads and writes towards external Broadcom switches |
|
pseudo-PHY addresses. Newer revisions of the SF2 hardware have introduced a |
|
configurable 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 which |
|
gets loaded onto the MoCA processor(s) for packet processing. The switch |
|
hardware contains logic which will assert/de-assert link states accordingly for |
|
the MoCA interface whenever the MoCA coaxial cable gets disconnected or the |
|
firmware gets reloaded. The SF2 driver relies on such events to properly set its |
|
MoCA interface carrier state and properly report this to the networking stack. |
|
|
|
The MoCA interfaces are supported using the PHY library's fixed PHY/emulated PHY |
|
device and the switch driver registers a ``fixed_link_update`` callback for such |
|
PHYs which reflects the link state obtained from the interrupt handler. |
|
|
|
|
|
Power Management |
|
---------------- |
|
|
|
Whenever possible, the SF2 driver tries to minimize the overall switch power |
|
consumption 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 Ethernet |
|
MAC controller wake-on logic. Whenever Wake-on-LAN is requested, an intersection |
|
between the user request and the supported host Ethernet interface WoL |
|
capabilities is done and the intersection result gets configured. During |
|
system-wide suspend/resume, only ports not participating in Wake-on-LAN are |
|
disabled.
|
|
|