Dell M14MK SFP28 отклоняется на OpenWrt с no common interface modes, а QSFPTEK SFP+ линкуется

Этот дамп всё объясняет. У слоя sfp в ядре ровно один источник данных для определения, какие режимы интерфейса может выдать модуль - это те самые байты соответствия. Когда ни один из них не выставлен, получается пустое множество, оно пересекается с тем, что предлагает MAC, общего не находится ничего, и печатается ровно то сообщение, что вы видите. 10000baseCR/Full в ethtool - это то, что осталось от стороны порта, а не то, что запросил модуль. Стоковая прошивка вендора на это не смотрит, потому что такие образы обычно вообще пропускают байты соответствия и вместо этого сверяют строки vendor и part со встроенным списком - вот почему оптика работала до перепрошивки.

Решение, которое реально держится - это квирк модуля. В drivers/net/phy/sfp.c добавьте запись SFP_QUIRK_S, совпадающую по vendor DELL и part M14MK, и принудительно выставляйте ETHTOOL_LINK_MODE_10000baseSR_Full и PHY_INTERFACE_MODE_10GBASER, затем пересоберите образ. Порт поднимается как обычный 10G линк, отчитываясь 10000baseSR/Full, и строка unsupported-module исчезает из лога.

Два предостережения. Держите патч в виде, который можно отправить в netdev, а не сидеть на нём в отдельной ветке: EEPROM сам себя не починит, и та же деталь Dell есть у других людей. И если вы вообще не хотите поддерживать свою сборку ядра, скучная альтернатива - уже имеющийся у вас QSFPTEK SFP+ - 10G это всё, что этот порт вам в любом случае даст.