sfp-refactor 400zr integration#216
Conversation
|
This pull request introduces 3 alerts when merging bbabcc4 into a09f5a3 - view on LGTM.com new alerts:
|
prgeor
left a comment
There was a problem hiding this comment.
The CMIS API would stay for long time, would you please add brief description for each API, about the params and the return value/data. Please also add test cases for QSFP-DD modules. Please address my other comments.
…cmis.py file for ZR application only; 3. separate two dictionaries - sff8024 and cmis_code;
…s from c_cmis.py to cmis.py
|
@qinchuanares could you fix LGTM warnings and also resolve the merge conflict? |
|
This pull request introduces 27 alerts when merging e3cc76a into 2ebd786 - view on LGTM.com new alerts:
|
…. 3. add function module_firmware_switch to switch between A/B image
prgeor
left a comment
There was a problem hiding this comment.
@qinchuanares could you address review comments.
| @@ -22,7 +23,7 @@ def _get_id(self): | |||
|
|
|||
| def create_xcvr_api(self): | |||
| # TODO: load correct classes from id_mapping file | |||
There was a problem hiding this comment.
can you rebase your code with latest master?
| return bytearray(struct.pack(self.format, int(val * self.scale))) | ||
| return bytearray(struct.pack(self.format, int(val))) | ||
|
|
||
| class ListRegField(RegField): |
There was a problem hiding this comment.
I do see this field used in CMIS memmap for TRANS_CDB, CDB_LPL, CDB_CMD, CDB_WRITE_MSG, but I don't see you are using it for decode/encode. I see for CDB, you are using write_flexible(). If not using remove this?
There was a problem hiding this comment.
@qinchuanares still not resolved. if resolved point me to where ListRegField is used. if not used delete ListRegField
@qinchuanares could you update the above sections of your PR? Also please add link to your HLD in the PR description. |
| rx_power_high_warn = self.xcvr_eeprom.read(consts.RX_POWER_HIGH_WARN) | ||
| rx_power_low_warn = self.xcvr_eeprom.read(consts.RX_POWER_LOW_WARN) | ||
| rx_power_dict = {'monitor value lane1': rx_power, | ||
| 'high alarm': rx_power_high_alarm, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined(get_rx_power() ) in sff8436?.
| voltage_low_alarm = self.xcvr_eeprom.read(consts.VOLTAGE_LOW_ALARM) | ||
| voltage_high_warn = self.xcvr_eeprom.read(consts.VOLTAGE_HIGH_WARN) | ||
| voltage_low_warn = self.xcvr_eeprom.read(consts.VOLTAGE_LOW_WARN) | ||
| voltage_dict = {'monitor value': voltage, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined in sff8436?.
| tx_power_low_alarm = self.xcvr_eeprom.read(consts.TX_POWER_LOW_ALARM) | ||
| tx_power_high_warn = self.xcvr_eeprom.read(consts.TX_POWER_HIGH_WARN) | ||
| tx_power_low_warn = self.xcvr_eeprom.read(consts.TX_POWER_LOW_WARN) | ||
| tx_power_dict = {'monitor value lane1': tx_power, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined in sff8436?.
| tx_power_low_alarm = self.xcvr_eeprom.read(consts.TX_POWER_LOW_ALARM) | ||
| tx_power_high_warn = self.xcvr_eeprom.read(consts.TX_POWER_HIGH_WARN) | ||
| tx_power_low_warn = self.xcvr_eeprom.read(consts.TX_POWER_LOW_WARN) | ||
| tx_power_dict = {'monitor value lane1': tx_power, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined in sff8436?.
| tx_bias_current_low_alarm = self.xcvr_eeprom.read(consts.TX_BIAS_CURR_LOW_ALARM) | ||
| tx_bias_current_high_warn = self.xcvr_eeprom.read(consts.TX_BIAS_CURR_HIGH_WARN) | ||
| tx_bias_current_low_warn = self.xcvr_eeprom.read(consts.TX_BIAS_CURR_LOW_WARN) | ||
| tx_bias_current_dict = {'monitor value lane1': tx_bias_current, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined in sff8436?.
| case_temp_low_alarm = self.xcvr_eeprom.read(consts.CASE_TEMP_LOW_ALARM) | ||
| case_temp_high_warn = self.xcvr_eeprom.read(consts.CASE_TEMP_HIGH_WARN) | ||
| case_temp_low_warn = self.xcvr_eeprom.read(consts.CASE_TEMP_LOW_WARN) | ||
| case_temp_dict = {'monitor value': case_temp, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined in sff8436?.
| tx_power_high_warn_dict['TX_lane%d' %(bitpos+1)] = bool((tx_power_high_warn >> bitpos) & 0x1) | ||
| tx_power_low_warn_dict['TX_lane%d' %(bitpos+1)] = bool((tx_power_low_warn >> bitpos) & 0x1) | ||
|
|
||
| tx_power_flag_dict = {'tx_power_high_alarm': tx_power_high_alarm_dict, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined in sff8436?.
| rx_power_high_warn_dict['RX_lane%d' %(bitpos+1)] = bool((rx_power_high_warn >> bitpos) & 0x1) | ||
| rx_power_low_warn_dict['RX_lane%d' %(bitpos+1)] = bool((rx_power_low_warn >> bitpos) & 0x1) | ||
|
|
||
| rx_power_flag_dict = {'rx_power_high_alarm': rx_power_high_alarm_dict, |
There was a problem hiding this comment.
can you rename the dict keys similar to the ones defined in sff8436?.
There was a problem hiding this comment.
please check whether the dict keys defined are similar to existing sff8436/sff8636?
Resolved. |
…m cmis; 3. split cmis and ccmis api when creating xcvr_api in xcvr_api_factory; 4. remove print and add logger to collect info for syslog
prgeor
left a comment
There was a problem hiding this comment.
can you please address review comments? please mark the comment as 'resolved' if done so.
| return bytearray(struct.pack(self.format, int(val * self.scale))) | ||
| return bytearray(struct.pack(self.format, int(val))) | ||
|
|
||
| class ListRegField(RegField): |
There was a problem hiding this comment.
@qinchuanares still not resolved. if resolved point me to where ListRegField is used. if not used delete ListRegField
…only relevant functions. 2. resolved other comments
|
@qinchuanares closing this PR since all changes moved to PR228 |
…; fix the get_firmware_version API to sync with download_firmware (sonic-net#216) Signed-off-by: vaibhav-dahiya [email protected] Description This PR refactors the listening of port probes from linkmgr to xcvrd as so that xcvrd does not see timeout messages like these below Sep 27 22:24:37.490921 SONIC WARNING mux#linkmgrd: link_manager/LinkManagerStateMachine.cpp:815 handleMuxWaitTimeout: Ethernet120: xcvrd timed out responding to linkmgrd, current state: (P: Unknown, M: Wait, L: Down) Refactoring to a separate listener thread mode as well as removing the lock(safe because read/write transaction via eeprom for port probe) seems to handle this, and does not have the logs like this one above. as the read write eeprom also has a mutex lock in the platform api call, optoe implementation. https://github.com/Azure/sonic-linux-kernel/blob/889d76e36b3f012d3782a1c5e1587c32e4d1ed11/patch/driver-support-optoe.patch#L717 Motivation and Context refactor xcvrd for listening to port probes, disable calling the get_firmware_api() while a download is in progress. Signed-off-by: vaibhav-dahiya <[email protected]>
This is a sfp-refactor follow-up work: to add 400ZR driver and high level functions into sfp-refactor. To query the keys in state_DB and write keys in config_DB into the module.
Description
The PR aims to provide 400ZR + SONiC support.
Motivation and Context
To be updated
How Has This Been Tested?
To be updated
Additional Information (Optional)