J'ai un dilemme,le code est ouvert on devrait pouvoir le modifier sans les foudres de Intel,mais comme je n'ai pas de certitudes, je n'ai pas envie de suivre une pente savonneuse pour Vivien.
Sinon,c'est la bonne piste, le code ne s'applique pas aux SFP juste aux SFP+
Alors non seulement le driver est en GPL-2, mais en plus il est mergé dans Linux (driver 4.4.0 dans le kernel 4.8 que je tourne). Donc pas de soucis pour le modifier.
J'ai fini de faire le tour des contrôles d'optiques, et le driver load avec des modules non supportés mais qui marchent au forceps dans une X520-DA2. Par contre le lien ne monte pas, il semblerait qu'il n'arrive pas du tout à causer aux optiques ou que j'ai oublié de shooter un des goto d'erreur.
Je pense que je vais en rester là pour aujourd'hui et m'y remettre plus tard en repartant depuis les sources officielles du 5.0.4, je l'ai déjà un peu trop charcuté pour comprendre où ça coince :/
Une chose est certaine cependant : vu la quantité de contrôles redondants et arbitraires, et vu le nombre d'endroits où se trouvent les messages et renvois d'erreurs, c'est très clairement une anti-feature digne d'un vendeur d'imprimantes. Donc je plaide l'exception d'interopérabilité pour le reverse-engineering, au besoin.
Au passage j'en apprends un peu plus sur le protocole de validation et de contrôle des optiques, et j'ai bien l'impression qu'il manque peu de chose pour utiliser une telle carte pour les reprogrammer…