Add tx bias support check before getting tx bias of sff8436 and sff8636#586
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
mihirpat1
left a comment
There was a problem hiding this comment.
In the testing part of the description, can you also mention if you tested flat and/or non-flat memory transceiver for each type of SFP tested?
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| @@ -398,7 +400,7 @@ def get_rx_los_support(self): | |||
| return True | |||
There was a problem hiding this comment.
@prgeor , get_rx_los_support function is only being used in cmis.py and sff8472.py . In sff8436.py and sff8636.py, they are just defined but not used anywhere in the module. I guess we don't have to fix get_rx_los_support for sff8436.py and sff8472.py.
There was a problem hiding this comment.
@prgeor @mihirpat1 , I have added the fix for get_rx_los_support and get_rx_los. I have also tested it and added the result to the PR description.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes the tx bias response for SFF-8436 and SFF-8636 copper interfaces by making them return 'N/A' instead of 0, ensuring consistency with other DOM values for copper interfaces that don't support tx bias monitoring.
Key changes:
- Updated support check methods to return False for copper interfaces
- Added early return logic to DOM methods when support is not available
- Enhanced test coverage for copper interface simulation
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| sonic_platform_base/sonic_xcvr/api/public/sff8636.py | Updated tx_bias_support and rx_los_support methods to return False for copper, added support checks in get_tx_bias and get_rx_los |
| sonic_platform_base/sonic_xcvr/api/public/sff8436.py | Updated tx_bias_support and rx_los_support methods to return False for copper, added support checks in get_tx_bias and get_rx_los |
| tests/sonic_xcvr/test_sff8636.py | Added test assertions for tx_bias and rx_los returning 'N/A' for copper, fixed duplicate rx_power_support assertion |
| tests/sonic_xcvr/test_sff8436.py | Added test assertions for tx_bias and rx_los returning 'N/A' for copper, fixed duplicate rx_power_support assertion |
Description
Fix the tx bias response for sff8436 and sff8636 copper interfaces.
Motivation and Context
Tx bias of sff8436 and sff8636 interfaces would return as 0 even for copper interfaces. As copper interfaces don't support txbias, we change the return to 'N/A' for them. It keeps the behavior consistent with other DOM values.
How Has This Been Tested?
I looked at the output of the following commands on a sonic device:
sudo sfputil show eeprom: The output remained unchanged.show interface transce eeprom: The output remained unchanged.After the change, the tx_bias of sff8436 and sff8636 copper interfaces returned as 'N/A'. The output for other interfaces remained unchanged. It was tested on a testbed with following types of txvrs:
Before the rx_los_support change:
After making the rx_los_support change:
Additional Information (Optional)