Für Bring-up und Feldausfälle (siehe Inbetriebnahme-Post dieser Serie) sind Diagnose-APIs entscheidend. Der Fact-Check gegen die reale SWS bringt hier eine Überraschung zutage, die die ursprüngliche Planung ("wird auf Switch-Ebene statt PHY-Ebene geschaltet") korrigiert.

Die meisten der hier vorgestellten EthSwt-Diagnose-APIs sind laut SWS reine Weiterleitungen an die entsprechende EthTrcv_*-Funktion der referenzierten Transceiver-Instanz — keine eigenständige Switch-Implementierung. Das ist inhaltlich sinnvoll: Kabeldiagnose, Loopback und Signalqualität sind PHY-Layer-Konzepte, die EthSwt nur adressierbar macht, aber nicht selbst neu implementiert.

Die Weiterleitungs-APIs im Überblick

EthSwt-APILeitet weiter an

EthSwt_RunPortCableDiagnostic

EthTrcv_RunCableDiagnostic (asynchron, reentrant je Switch/Port-Kombination)

EthSwt_GetPortCableDiagnosticsResult

EthTrcv_GetCableDiagnosticsResult

EthSwt_SetPortTestMode

EthTrcv_SetPhyTestMode

EthSwt_SetPortLoopbackMode

EthTrcv_SetPhyLoopbackMode

EthSwt_SetPortTxMode

EthTrcv_SetPhyTxMode

EthSwt_GetPortSignalQuality

EthTrcv_GetPhySignalQuality

Jede dieser Funktionen nutzt die EthIf-Treiberabstraktion, um den Aufruf an die über EthSwtPortTrcvRef (siehe Teil 3 dieser Serie) referenzierte EthTrcv-Instanz weiterzureichen.

Praktische Konsequenz: Referenziert ein EthSwtPort keinen EthTrcv (z. B. weil der PHY komplett switch-intern ist, siehe Hardware-Architektur-Post), liefern diese APIs entsprechend E_NOT_OK oder — im Fall von EthSwt_GetPortSignalQuality — den Sentinel-Wert 0xFFFFFFFF.

EthSwt_GetPortIdentifier: ein cleveres Detail

Diese Funktion liefert die OUI (Organizationally Unique Identifier, 24 Bit) des Ports — mit einer bemerkenswerten Kodierungs-Regel:

  • Kann die OUI vom referenzierten EthTrcv über EthTrcv_GetPhyIdentifier ermittelt werden, setzt EthSwt_GetPortIdentifier die 8 höchstwertigen Bits auf 0x00xxxxxx

  • Kann sie nicht ermittelt werden bzw. kommt sie direkt vom Switch-Port selbst, werden die 8 höchstwertigen Bits auf 0xFFxxxxxx gesetzt

Diese Kodierung erlaubt es, allein am Rückgabewert zu erkennen, woher die OUI stammt — ein nützliches Diagnosemerkmal, um zu unterscheiden, ob man Informationen über einen echten externen PHY-Chip oder über den Switch-Port selbst erhalten hat.

Switch-eigene Diagnose: GetSwitchIdentifier

Im Gegensatz zu den reinen Weiterleitungs-APIs identifiziert EthSwt_GetSwitchIdentifier tatsächlich den Switch-Chip selbst — relevant für Multi-Switch-Systeme, in denen mehrere gleichartige Chips unterschieden werden müssen. EthSwt_GetPortIdentifier dagegen ist ein Hybrid: Es bevorzugt die OUI vom referenzierten EthTrcv, fällt aber auf eine switch-eigene Kennung zurück, wenn kein Transceiver referenziert ist oder dieser keine OUI liefern kann (siehe Kodierungsregel oben).

Fallstudie: ein Port zeigt sporadische Fehler

  1. Signalqualität prüfen — EthSwt_GetPortSignalQuality; liefert der Aufruf 0xFFFFFFFF, fehlt entweder die Trcv-Referenz oder der PHY unterstützt keine Signalqualitätsmessung

  2. Kabeldiagnose anstoßen — EthSwt_RunPortCableDiagnostic (asynchron) und das Ergebnis über EthSwt_GetPortCableDiagnosticsResult abholen

  3. Loopback-Test — EthSwt_SetPortLoopbackMode, um den Fehler auf PHY-/Leitungsebene einzugrenzen, unabhängig vom Switch-Fabric

  4. Port-Identität verifizieren — EthSwt_GetPortIdentifier, um sicherzustellen, dass tatsächlich der erwartete Port bzw. PHY-Chip angesprochen wird

Zusammenfassung

AspektKernaussage

Weiterleitungs-APIs

Cable-Diagnose, Test-/Loopback-/Tx-Modus und Signalqualität sind reine Wrapper um die entsprechende EthTrcv_*-Funktion

Ohne Trcv-Referenz

Diese APIs liefern E_NOT_OK bzw. Sentinel-Werte wie 0xFFFFFFFF

OUI-Kodierung

0x00xxxxxx = von EthTrcv ermittelt, 0xFFxxxxxx = anderer Ursprung

Switch-eigene Diagnose

GetPortIdentifier/GetSwitchIdentifier identifizieren den Switch selbst, nicht den PHY