- 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
- 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
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/dev/e1000/e1000_82575.c | ||
---|---|---|
1750 | 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 | ||
---|---|---|
1750 | 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 | ||
---|---|---|
1750 | 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 | ||
---|---|---|
1704 | add break here too? |