- Adds support for SFPs that are not correctly coded as an SFP transceiver. i.e. Coherent-Finisar FCLF8522P2BTL.
- Configures multi-rate SFPs i.e. Coherent-Finisar FCLF8522P2BTL as SGMII so they can do 10/100/1000 auto-negotiation.
- Adds support for 100BaseLX SGMII transceivers.
- Some code cleanup and additional debugging.
Details
Details
- Reviewers
markj emaste - Group Reviewers
Intel Networking Restricted Owners Package (Owns No Changed Paths) - Commits
- rGcf6a8711e437: e1000: Improve igb(4) SFP support
rGc66d2795bdb5: e1000: Improve igb(4) SFP support
rG15853a5fc954: e1000: Improve igb(4) SFP support
Tested on various managed and unmanaged access switches and back to back.
Customer testing ongoing.
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
| sys/dev/e1000/e1000_82575.c | ||
|---|---|---|
| 1749 | This comment is a bit puzzling - we've already read the SFP's EEPROM, right? So we can assume there is a SFP module plugged in. I was originally wondering if the "else" case could arise from a card with an empty SFP cage, but I think it can only be a module is present but is not SFP/SFF? How does a SFP DAC cable show up? | |
| sys/dev/e1000/e1000_82575.c | ||
|---|---|---|
| 1749 | Oh, presumably this is the point in the summary -- "SFPs that are not correctly coded as an SFP transceiver." What is the impact of not setting module_plugged then? | |
| sys/dev/e1000/e1000_82575.c | ||
|---|---|---|
| 1749 | It's covered by Table 5.1 in the SFP MSA -- for whatever reason in this case we get back 0 "Unknown" and that is causing the customer issue. Because the module type (Table 5.3) is read without regard to the transceiver type before and after my changes I would tend to agree we basically know we have an SFP or SFF at this point but the general error case of landing on e1000_media_type_unknown should be the same with my changes if we didn't get a transceiver type back. A DAC should show up as an SFP, they contain an EEPROM as well. module_plugged is a write only variable here and in Linux and DPDK. Maybe it was intended to optimize the PHY layer, there is a little bit of chicken and egg going on here where the MAC comes up first and makes assumptions about the PHY including powering it up. | |
| sys/dev/e1000/e1000_82575.c | ||
|---|---|---|
| 1701 | add break here too? | |