Dell M14MK SFP28 auf OpenWrt abgelehnt mit no common interface modes, während ein QSFPTEK SFP+ linkt

Dieser Dump erklärt die ganze Sache. Der sfp-Layer des Kernels hat genau eine Eingabe, wenn er herausfindet, welche Interface-Modi ein Modul beherrscht, und das sind diese Compliance-Bytes. Sind keine davon gesetzt, landet er bei einer leeren Menge, schneidet die mit dem, was der MAC anbietet, findet nichts gemeinsam und druckt genau die Meldung, die du siehst. Das 10000baseCR/Full in ethtool ist das, was von der Port-Seite übrig bleibt, nicht etwas, das das Modul angefragt hat. Die Stock-Herstellerfirmware kümmert sich nicht darum, weil diese Images die Compliance-Bytes generell komplett überspringen und stattdessen Vendor- und Part-Strings gegen eine fest codierte Liste abgleichen - deshalb hat die Optik funktioniert, bevor du geflasht hast.

Die Lösung, die tatsächlich hält, ist ein Modul-Quirk. In drivers/net/phy/sfp.c einen SFP_QUIRK_S-Eintrag hinzufügen, der auf Vendor DELL mit Part M14MK passt und zwangsweise ETHTOOL_LINK_MODE_10000baseSR_Full sowie PHY_INTERFACE_MODE_10GBASER setzt, dann das Image neu bauen. Der Port kommt als gewöhnlicher 10G-Link hoch, meldet 10000baseSR/Full, und die Unsupported-Module-Zeile verschwindet aus dem Log.

Zwei Einschränkungen. Halt den Patch in einer Form, die du an netdev schicken kannst, statt ihn nur nachgelagert bei dir liegen zu lassen: Das EEPROM repariert sich nicht von selbst, und andere Leute besitzen dasselbe Dell-Teil. Und falls du lieber gar keinen eigenen Kernel-Build pflegen willst, ist die langweilige Alternative das QSFPTEK SFP+, das du schon hast - 10G ist ohnehin alles, was dieser Port hergibt.