Page MenuHomeFreeBSD

bxe: Add 2500baseX SFF underpinning
Needs ReviewPublic

Authored by adam.jaremko_freebsd_gmail.com on May 31 2023, 6:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 10 2024, 9:39 PM
Unknown Object (File)
Feb 3 2024, 8:18 AM
Unknown Object (File)
Dec 22 2023, 10:46 PM
Unknown Object (File)
Dec 12 2023, 9:08 AM
Unknown Object (File)
Nov 1 2023, 6:07 PM
Unknown Object (File)
Sep 20 2023, 9:51 PM
Unknown Object (File)
Sep 20 2023, 8:41 PM
Unknown Object (File)
Sep 10 2023, 11:45 AM

Details

Reviewers
None
Group Reviewers
Contributor Reviews (src)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 51812
Build 48703: arc lint + arc unit

Event Timeline

luca.piccirillo_gmail.com added inline comments.
sys/dev/bxe/bxe.c
13873

On dslreports I see many times this same patch with this condition added to the above ELINK_ETH_PHY_XFP_FIBER case instead. Which one is correct?

sys/dev/bxe/bxe.c
13873

On dslreports I see many times this same patch with this condition added to the above ELINK_ETH_PHY_XFP_FIBER case instead. Which one is correct?

This is the correct condition because 2.5G enablement is dependent on 1G advertisement and the media type should be set to ELINK_ETH_PHY_SFP_1G_FIBER (As seen in the changes below in elink_get_edc_mode). The problem lies in how the transceivers eeprom was programmed and if its compliance code is correctly set to begin with. As you can guess, this is rarely the case, hence the dslreports diff. For obvious reasons there isn't code to handle these manufacturer issues.

I settled on correctness vs hacks.

sys/dev/bxe/bxe.c
13873

On second thought, it's probably best to remove this altogether as there is no way to determine if the transceiver actually supports 2.5 from SFF-8472.