[sfp] Add parsing the dom_capability to sff8472 #102
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Read the diagnostic monitoring type register to get dom_capability * Provide basic dom_capability info table as transceiver info * Unify the name of parsing dom_capability function for both QSFP and SFP
|
Hi @jleveque, |
|
@keboliu: Please review. |
keboliu
reviewed
Nov 10, 2020
| for key in qsfp_dom_capability_tup: | ||
| if key in sfp_dom_capability_data['data']: | ||
| dom_capability_dict[key] = "yes" if sfp_dom_capability_data['data'][key]['value'] == 'on' else "no" | ||
| transceiver_info_dict['dom_capability'] = str(dom_capability_dict) |
There was a problem hiding this comment.
Is it necessary to expose this to transceiver_info_dict? My understanding is that this is only some internal flag, if DOM supported, means can get the related meaningful monitor info from the EEPROM.
There was a problem hiding this comment.
This is a verification method for the SFP type transceiver for now.
If user buy a SFP type transceiver with DOM capability, there is no way to check DOM capability of the transceiver in SONIC currently. With this, the user can check if he/she buy a fake one or not at least.
And in the future, we can enhance this part to check more dom info according to its dom_capability.
keboliu
approved these changes
Jan 16, 2021
jleveque
approved these changes
Jan 19, 2021
4 tasks
jleveque
added a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Feb 5, 2021
…rse_dom_capability' (#6695) **- Why I did it** PR sonic-net/sonic-platform-common#102 modified the name of the SFF-8436 (QSFP) method to align the method name between all drivers, renaming it from `parse_qsfp_dom_capability` to `parse_dom_capability`. Once the submodule was updated, the callers using the old nomenclature broke. This PR updates all callers to use the new naming convention. **- How I did it** Update the name of the function globally for all calls into the SFF-8436 driver. Note that the QSFP-DD driver still uses the old nomenclature and should be modified similarly. I will open a PR to handle this separately.
daall
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Feb 5, 2021
…rse_dom_capability' (#6695) **- Why I did it** PR sonic-net/sonic-platform-common#102 modified the name of the SFF-8436 (QSFP) method to align the method name between all drivers, renaming it from `parse_qsfp_dom_capability` to `parse_dom_capability`. Once the submodule was updated, the callers using the old nomenclature broke. This PR updates all callers to use the new naming convention. **- How I did it** Update the name of the function globally for all calls into the SFF-8436 driver. Note that the QSFP-DD driver still uses the old nomenclature and should be modified similarly. I will open a PR to handle this separately.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I did
Following SFF-8472 to read diagnostic monitoring type register.
Use that register to check if diagnostic monitoring function implemented or not.
How I did it
Check the register position from SFF-8472 document.
Read the register value from the EEPROM.
How to verify it
Compare one transceiver which support diagnostic monitoring function to another transceiver which doesn't support it.
Run 'show interfaces transceiver eeprom' command.