Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Mellanox]Fix the issue when an SFP module is plugged into a QSFP port via QSA #3846

Merged
merged 1 commit into from
Dec 7, 2019

Conversation

stephenxs
Copy link
Collaborator

@stephenxs stephenxs commented Dec 5, 2019

- What I did
Fix the issue when an SFP module is plugged into a QSFP port via an adapter.

- How I did it
Originally the type of an SFP module is determined according to the SKU dictionary. However, it's possible that as SFP module is plugged into a QSFP port via an adapter. In this case, the EEPROM content will be parsed in the wrong format.
To address that we fetch the identifier value of an xSFP module and then get the type by parsing it.

- How to verify it
Fetch and parse the content of SFP modules and check them.
sfp-type-detect-test.txt

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

read the identifier value first and parsed it.
if it isn't recognized it will be parsed as the default type according to SKU dictionary
@lguohan lguohan merged commit 90ddad4 into sonic-net:master Dec 7, 2019
@stephenxs stephenxs deleted the fix-qsfp-adapter branch December 7, 2019 23:18
@stephenxs
Copy link
Collaborator Author

To be cherry-picked to bmtor, it requires the following PR cherry-picked first:
[Mellanox] support get_transceiver_threshold_info (#3777) commit hash 0c9040d

@nazariig
Copy link
Collaborator

@yxieca just a kindly reminder: please take it to bmtor.

@jleveque
Copy link
Contributor

jleveque commented Jan 2, 2020

@stephenxs, @nazariig: Should this PR (and #3777) also be cherry-picked into the 201911 branch? Are there any other dependencies or any reasons not to?

@stephenxs
Copy link
Collaborator Author

hi @jleveque, I suggest doing so. no dependency on 201911.

@jleveque
Copy link
Contributor

jleveque commented Jan 3, 2020

@stephenxs: Thanks. Just to clarify, #3777 is a required dependency, but there are no others, correct?

abdosi pushed a commit that referenced this pull request Jan 3, 2020
Fix the issue when an SFP module is plugged into a QSFP port via an adapter.

- How I did it
Originally the type of an SFP module is determined according to the SKU dictionary. However, it's possible that as SFP module is plugged into a QSFP port via an adapter. In this case, the EEPROM content will be parsed in the wrong format.
To address that we fetch the identifier value of an xSFP module and then get the type by parsing it.
@stephenxs
Copy link
Collaborator Author

@stephenxs: Thanks. Just to clarify, #3777 is a required dependency, but there are no others, correct?

Hi @jleveque ,
Yes.
On bmtor, it depends on #3777 and doesn't have any other dependencies.
On 201911, it doesn't require any dependency.

@jleveque
Copy link
Contributor

jleveque commented Jan 3, 2020

@stephenxs: So we should or should not also cherry-pick #3777 into the 201911 branch?

@stephenxs
Copy link
Collaborator Author

3777 is already merged into 201911.
probably I failed to express it clear.
for both branch when I said it didn't require other dependencies what I meant is other dependencies have already been merged into the branch. :)

@jleveque
Copy link
Contributor

jleveque commented Jan 3, 2020

Ah, I've got it now. Thanks! #3777 didn't have any "Request for 201911" or "Included in 201911" labels, so I wasn't aware that it had already had been cherry-picked. I will add the "Included in 201911" label to it now.

lguohan pushed a commit that referenced this pull request Jan 6, 2020
Fix the issue when an SFP module is plugged into a QSFP port via an adapter.

- How I did it
Originally the type of an SFP module is determined according to the SKU dictionary. However, it's possible that as SFP module is plugged into a QSFP port via an adapter. In this case, the EEPROM content will be parsed in the wrong format.
To address that we fetch the identifier value of an xSFP module and then get the type by parsing it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants