sonic-net / sonic-platform-common

Python packages which provide a common interface to platform-specific hardware peripherals in SONiC

SONiC: Software for Open Networking in the Cloud

sonic-platform-common

Collection of Python packages which provide a common interface to platform-specific hardware peripherals in SONiC

Contribution guide

All contributors must sign a contribution license agreement (CLA) before contributions can be accepted. This process is now automated via a GitHub bot when submitting new pull request. If the contributor has not yet signed a CLA, the bot will create a comment on the pull request containing a link to electronically sign the CLA.

GitHub Workflow

We're following basic GitHub Flow. If you have no idea what we're talking about, check out GitHub's official guide. Note that merge is only performed by the repository maintainer.

Guide for performing commits:

• Isolate each commit to one component/bugfix/issue/feature
• Use a standard commit message format:

[component/folder touched]: Description intent of your changes

[List of changes]

Signed-off-by: Your Name [email protected]

For example:

swss-common: Stabilize the ConsumerTable

* Fixing autoreconf
* Fixing unit-tests by adding checkers and initialize the DB before start
* Adding the ability to select from multiple channels
* Health-Monitor - The idea of the patch is that if something went wrong with the notification channel, 
  we will have the option to know about it (Query the LLEN table length).
  
  Signed-off-by: John Doe [email protected]

• Each developer should fork this repository and add the team as a Contributor
• Push your changes to your private fork and do "pull-request" to this repository
• Use a pull request to do code review
• Use issues to keep track of what is going on

sonic-platform-common's Issues

SFF-8472 Rx power conversion function incorrect

sonic-platform-common/sonic_platform_base/sonic_sfp/sff8472.py

Lines 831 to 871 in 2606cd5

	# RX_PWR(uW) = RX_PWR_4 * RX_PWR_AD +
	# RX_PWR_3 * RX_PWR_AD +
	# RX_PWR_2 * RX_PWR_AD +
	# RX_PWR_1 * RX_PWR_AD +
	# RX_PWR(0)
	off = self.dom_ext_calibration_constants['RX_PWR_4']['offset']
	rx_pwr_byte3 = int(eeprom_data[off], 16)
	rx_pwr_byte2 = int(eeprom_data[off + 1], 16)
	rx_pwr_byte1 = int(eeprom_data[off + 2], 16)
	rx_pwr_byte0 = int(eeprom_data[off + 3], 16)
	rx_pwr_4 = (rx_pwr_byte3 << 24) | (rx_pwr_byte2 << 16) | (rx_pwr_byte1 << 8) | (rx_pwr_byte0 & 0xff)
	off = self.dom_ext_calibration_constants['RX_PWR_3']['offset']
	rx_pwr_byte3 = int(eeprom_data[off], 16)
	rx_pwr_byte2 = int(eeprom_data[off + 1], 16)
	rx_pwr_byte1 = int(eeprom_data[off + 2], 16)
	rx_pwr_byte0 = int(eeprom_data[off + 3], 16)
	rx_pwr_3 = (rx_pwr_byte3 << 24) | (rx_pwr_byte2 << 16) | (rx_pwr_byte1 << 8) | (rx_pwr_byte0 & 0xff)
	off = self.dom_ext_calibration_constants['RX_PWR_2']['offset']
	rx_pwr_byte3 = int(eeprom_data[off], 16)
	rx_pwr_byte2 = int(eeprom_data[off + 1], 16)
	rx_pwr_byte1 = int(eeprom_data[off + 2], 16)
	rx_pwr_byte0 = int(eeprom_data[off + 3], 16)
	rx_pwr_2 = (rx_pwr_byte3 << 24) | (rx_pwr_byte2 << 16) | (rx_pwr_byte1 << 8) | (rx_pwr_byte0 & 0xff)
	off = self.dom_ext_calibration_constants['RX_PWR_1']['offset']
	rx_pwr_byte3 = int(eeprom_data[off], 16)
	rx_pwr_byte2 = int(eeprom_data[off + 1], 16)
	rx_pwr_byte1 = int(eeprom_data[off + 2], 16)
	rx_pwr_byte0 = int(eeprom_data[off + 3], 16)
	rx_pwr_1 = (rx_pwr_byte3 << 24) | (rx_pwr_byte2 << 16) | (rx_pwr_byte1 << 8) | (rx_pwr_byte0 & 0xff)
	off = self.dom_ext_calibration_constants['RX_PWR_0']['offset']
	rx_pwr_byte3 = int(eeprom_data[off], 16)
	rx_pwr_byte2 = int(eeprom_data[off + 1], 16)
	rx_pwr_byte1 = int(eeprom_data[off + 2], 16)
	rx_pwr_byte0 = int(eeprom_data[off + 3], 16)
	rx_pwr_0 = (rx_pwr_byte3 << 24) | (rx_pwr_byte2 << 16) | (rx_pwr_byte1 << 8) | (rx_pwr_byte0 & 0xff)
	rx_pwr = (rx_pwr_4 * result) + (rx_pwr_3 * result) + (rx_pwr_2 * result) + (rx_pwr_1 * result) + rx_pwr_0

SFF-8472 section 9.3

The specification states, under 5)
Received power, RX_PWR, is given in uW by the following equation:

Rx_PWR (uW) = Rx_PWR(4) * Rx_PWR_ADe4 (16 bit unsigned integer) +
           Rx_PWR(3) * Rx_PWR_ADe3 (16 bit unsigned integer) +
           Rx_PWR(2) * Rx_PWR_ADe2 (16 bit unsigned integer) +
           Rx_PWR(1) * Rx_PWR_AD (16 bit unsigned integer) +
           Rx_PWR(0)

which means Rx_PWR_AD is raised to the power of 4, 3 and 2 respectively in the expression. The comment and code does not reflect that.

Furthermore, the calibration constants are stored in IEEE Std 754 single precision float format in the device. These cannot be treated as integers, as is done in the code.

sfputilbase.py to utilize portconfig.py instead of parsing config files directly

sfputilbase.py should utilize sonic-config-engine/portconfig.py to parse port configuration files, rather than doing it directly.

Eventually, the functionality in portconfig.py should be moved out of sonic-config-engine and into sonic-py-common, which is tracked by #110

Add support for QSAs

Add support for QSFP-to-SFP transceiver adapters

test-xcrvd unit test unstable

21.txt

sffbase.py convert_hex_to_string method is throwing exception on str.strip operation after Python 3 migration

return str.strip(binascii.unhexlify(ret_str)) is causing an exception such that SFP eeprom fields are not being populated properly. This occurs because the str.strip exception is being returned from convert_hex_to_string instead of the properly converted value.

[SFP-Refactor] Modify transceiver dict vendor key name

With earlier SFP refactor, 'hardware_rev' is used in place of 'vendor_rev'.
With new SFP refactor, this issue is fixed. In some platforms, vendor_rev key is not defined in transceiver dictionary.
'hardware_rev' is not mentioned in SFF specs except CMIS.
If sonic-net/sonic-platform-daemons#231 is integrated, xcvrd will crash for the vendors as 'vendor_rev' key is not defined.
All the repository has to change 'hardware_rev' key to 'vendor_rev' key as it'd mislead the EEPROM information.

Question about cdb get_fw_info using cmis 4.0

sonic-platform-common/sonic_platform_base/sonic_xcvr/api/public/cmis.py

Lines 1267 to 1272 in 285a4dd

	if self.cdb.cdb_chkcode(rpl) != rpl_chkcode:
	string = 'Get module FW info: Need to enter password\n'
	logger.info(string)
	# Reset password for module using CMIS 4.0
	self.cdb.module_enter_password(0)
	rpllen, rpl_chkcode, rpl = self.cdb.get_fw_info()

here we info 'Need to enter password', why we reset the password(0x0) instead of using default password(0x00001011)?

issue about SFP_MODULE_THRESHOLD_OFFSET not defined

Aug 14 14:41:35.522412 sonic INFO pmon#supervisord: xcvrd File "/usr/bin/xcvrd", line 831, in main
Aug 14 14:41:35.522904 sonic INFO pmon#supervisord: xcvrd
Aug 14 14:41:35.523230 sonic INFO pmon#supervisord: xcvrd xcvrd.run()
Aug 14 14:41:35.523587 sonic INFO pmon#supervisord: xcvrd File "/usr/bin/xcvrd", line 795, in run
Aug 14 14:41:35.524570 sonic INFO pmon#supervisord: xcvrd self.init()
Aug 14 14:41:35.524715 sonic INFO pmon#supervisord: xcvrd File "/usr/bin/xcvrd", line 779, in init
Aug 14 14:41:35.524810 sonic INFO pmon#supervisord: xcvrd post_port_sfp_dom_info_to_db(is_warm_start, self.stop_event)
Aug 14 14:41:35.524891 sonic INFO pmon#supervisord: xcvrd File "/usr/bin/xcvrd", line 326, in post_port_sfp_dom_info_to_db
Aug 14 14:41:35.524981 sonic INFO pmon#supervisord: xcvrd post_port_dom_threshold_info_to_db(logical_port_name, dom_tbl, stop_even)
Aug 14 14:41:35.525063 sonic INFO pmon#supervisord: xcvrd File "/usr/bin/xcvrd", line 220, in post_port_dom_threshold_info_to_db
Aug 14 14:41:35.525148 sonic INFO pmon#supervisord: xcvrd dom_info_dict = platform_sfputil.get_transceiver_dom_threshold_info_dict)
Aug 14 14:41:35.525233 sonic INFO pmon#supervisord: xcvrd File "/usr/local/lib/python2.7/dist-packages/sonic_sfp/sfputilbase.py", lit
Aug 14 14:41:35.527763 sonic INFO pmon#supervisord: xcvrd (offset + SFP_MODULE_THRESHOLD_OFFSET),
Aug 14 14:41:35.527873 sonic INFO pmon#supervisord: xcvrd NameError: global name 'SFP_MODULE_THRESHOLD_OFFSET' is not defined

[sonic_eeprom] Class methods shouldn't take the EEPROM data as a parameter

EEPROM class should obtain EEPROM data when instantiated and store as a class member, then use that data in methods rather than having to pass the raw data into the methods. It defeats the purpose of object-orientation.

xcvrd crash: Exception occured at CmisManagerTask thread due to TypeError

cmis.py:get_application() did not check 'NoneType' return from xcvr_eeprom.read().

Jun  1 23:32:49.924628 sonic ERR pmon#xcvrd[273]: Exception occured at CmisManagerTask thread due to TypeError("unsupported operand type(s) for >>: 'NoneType' and 'int'")
Jun  1 23:32:49.927284 sonic ERR pmon#xcvrd[273]: Traceback (most recent call last):
Jun  1 23:32:49.927284 sonic ERR pmon#xcvrd[273]:   File "/usr/local/lib/python3.9/dist-packages/xcvrd/xcvrd.py", line 1666, in run
Jun  1 23:32:49.927301 sonic ERR pmon#xcvrd[273]:     self.task_worker()
Jun  1 23:32:49.927339 sonic ERR pmon#xcvrd[273]:   File "/usr/local/lib/python3.9/dist-packages/xcvrd/xcvrd.py", line 1536, in task_worker
Jun  1 23:32:49.927375 sonic ERR pmon#xcvrd[273]:     need_update = self.is_cmis_application_update_required(api, appl, host_lanes_mask)
Jun  1 23:32:49.927394 sonic ERR pmon#xcvrd[273]:   File "/usr/local/lib/python3.9/dist-packages/xcvrd/xcvrd.py", line 1162, in is_cmis_application_update_required
Jun  1 23:32:49.927413 sonic ERR pmon#xcvrd[273]:     elif app_old != api.get_application(lane):
Jun  1 23:32:49.927432 sonic ERR pmon#xcvrd[273]:   File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/api/public/cmis.py", line 2000, in get_application
Jun  1 23:32:49.927447 sonic ERR pmon#xcvrd[273]:     appl = self.xcvr_eeprom.read(name) >> 4
Jun  1 23:32:49.927465 sonic ERR pmon#xcvrd[273]: TypeError: unsupported operand type(s) for >>: 'NoneType' and 'int'
Jun  1 23:32:49.927621 sonic ERR pmon#xcvrd[273]: Xcvrd: exception found at child thread CmisManagerTask due to TypeError("unsupported operand type(s) for >>: 'NoneType' and 'int'")
Jun  1 23:32:49.927621 sonic ERR pmon#xcvrd[273]: Exiting main loop as child thread raised exception!
Jun  1 23:32:49.944454 sonic INFO pmon#supervisord 2023-06-01 23:32:49,944 INFO exited: xcvrd (terminated by SIGKILL; not expected)

Similar issue fixed recently: #371

[sonic_sfp] The key for connector dict should be lowercase for class sff8472InterfaceId

The following is the dict connector defined in sff8472.py .
connector = {'00': 'Unknown',
'01': 'SC',
'02': 'Fibre Channel Style 1 copper connector',
'03': 'Fibre Channel Style 2 copper connector',
'04': 'BNC/TNC',
'05': 'Fibre Channel coaxial headers',
'06': 'FibreJack',
'07': 'LC',
'08': 'MT-RJ',
'09': 'MU',
'0a': 'SG',
'0b': 'Optical pigtail',
'0C': 'MPO Parallel Optic',
'20': 'HSSDCII',
'21': 'CopperPigtail',
'22': 'RJ45',
'23': 'No separable connector'}

For connector dict, the key for 'MPO Parallel Optic' should use '0c', not '0C' .

xcvrd crashes in SFP refactored code.

In the latest master image, xcvrd crashes while trying to get transceiver info for 400G DAC.
root@sonic:~# show ver

SONiC Software Version: SONiC.master.60307-dirty-20211220.184919
Distribution: Debian 11.2
Kernel: 5.10.0-8-2-amd64
Build commit: 0d327ab
Build date: Mon Dec 20 18:56:46 UTC 2021
Built by: AzDevOps@sonic-build-workers-00101A

Platform: x86_64-dellemc_z9332f_d1508-r0
HwSKU: DellEMC-Z9332f-O32
ASIC: broadcom
ASIC Count: 1
Serial Number: 1QHXCW2
Model Number: 04CN21
Hardware Revision: A00
Uptime: 09:35:14 up 24 min, 1 user, load average: 0.68, 0.63, 0.54

root@sonic:~# python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.

from sonic_platform.chassis import Chassis
c=Chassis()
c.get_sfp(1).get_transceiver_info()
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/sfp_optoe_base.py", line 24, in get_transceiver_info
return api.get_transceiver_info() if api is not None else None
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/api/public/cmis.py", line 121, in get_transceiver_info
admin_info = self.xcvr_eeprom.read(consts.ADMIN_INFO_FIELD)
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/xcvr_eeprom.py", line 30, in read
return field.decode(raw_data, **decoded_deps)
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/fields/xcvr_field.py", line 252, in decode
result[field.name] = field.decode(raw_data[offset - start: offset + field.get_size() - start],
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/fields/xcvr_field.py", line 273, in decode
date = super(DateField, self).decode(raw_data, **decoded_deps)
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/fields/xcvr_field.py", line 191, in decode
return struct.unpack(self.format, raw_data)[0].decode(self.encoding)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 6: ordinal not in range(128)

Add LICENSE and documentation

Hi, would it be possible to add a LICENSE to this repo?

The order of the `SfpUtilHelper.logical` ports list is broken

be04b80 mutilasic platform support breaks the order

sonic-platform-common/sonic_platform_base/sonic_sfp/sfputilhelper.py

Line 93 in 2efe97e

self.logical = list(set(self.logical))

Use the function set(...) would break the original order of list

And this issue would also cause the sfputil show eeprom failed due to the order of the presence are miss matched with the port.

[sonic_eeprom] Refactor State DB-related functionality

• Use swsscommon rather than direct Redis library access
• All tabular printing functions should use the tabulate module
• Should the library have functionality to read from DB, or only write? Or should even writing be offloaded elsewhere?

SFP-Refactor: Could not able to fetch get_transceiver_info()

While trying to dump transceiver information for CMIS device, it crashes with following trace.
python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.

from sonic_platform.chassis import Chassis
c=Chassis()
c.get_sfp(1).get_transceiver_info()
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/sfp_optoe_base.py", line 24, in get_transceiver_info
return api.get_transceiver_info() if api is not None else None
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/api/public/cmis.py", line 23, in get_transceiver_info
admin_info = self.xcvr_eeprom.read(consts.ADMIN_INFO_FIELD)
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/xcvr_eeprom.py", line 28, in read
return field.decode(raw_data, **decoded_deps)
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/fields/xcvr_field.py", line 235, in decode
result[field.name] = field.decode(raw_data[offset - start: offset + field.get_size() - start],
File "/usr/local/lib/python3.9/dist-packages/sonic_platform_base/sonic_xcvr/fields/public/cmis.py", line 12, in decode
mult = 10 ** (len_mult - 1)
TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'

Unable to parse `Extended Specification Compliance` and `10/40G Ethernet Compliance Code` for `QSFP+ or later with SFF-8636 or SFF-8436` whose ID is 0x0D and `revision compliance` is greater than 2

Description

Unable to parse Extended Specification Compliance and 10/40G Ethernet Compliance Code for QSFP+ or later with SFF-8636 or SFF-8436 whose ID is 0x0D and revision compliance is greater than 2.
According to SFF8024, Identifier value 0x0d stands for QSFP+ or later with SFF-8636 or SFF-8436 management interface (SFF-8436, FF-8635, SFF-8665, SFF-8685 et al.)
In this case, revision compliance (page 00h byte 1) should also be read in order to determine whether it is 8434 or 8436.

value	Memory Map version
0	Revision not specified. Do not use for SFF-8636 rev 2.5 or higher.
1	SFF-8436 Rev 4.8 or earlier
2	Includes functionality described in revision 4.8 or earlier of SFF-8436, except that this byte and Bytes 186-189 are as defined in this document
3	SFF-8636 Rev 1.3 or earlier
4	SFF-8636 Rev 1.4
5	SFF-8636 Rev 1.5
6	SFF-8636 Rev 2.0
7	SFF-8636 Rev 2.5, 2.6, or 2.7
other value	reserved

If the revision compliance is greater than 2, it should be parsed using 8636 memory map. Otherwise the Extended Specification Compliance (byte 192) won't be parsed.

The parsing logic of 10/40G/100G Ethernet Compliance Codes in Specification Compliance (page 00H byte 131) in SFF8636 is also problematic.
Bit 7 should be reserved as 0 in 8436 but can be 1 in 8636. However, in the code, it parses the field using enumeration which assumes only 1 bit can be 1. If 2 or more bits are zero, it fails to parse it.
A bit mask of bit 0~6 should be introduced for this field.

value	meaning
7	Extended: See section 6.3.23. The Extended Specification Compliance Codes are maintained in the Transceiver Management section of SFF-8024.
6	10GBASE-LRM
5	10GBASE-LR
4	10GBASE-SR
3	40GBASE-CR4
2	40GBASE-SR4
1	40GBASE-LR4
0	40G Active Cable (XLPPI)

Steps to reproduce the issue:

Describe the results you received:

all specification compliances are unknown.

show int transceiver eeprom Ethernet48
Ethernet48: SFP EEPROM detected
        Application Advertisement: N/A
        Connector: No separable connector
        Encoding: Unspecified
        Extended Identifier: Power Class 1 Module (1.5W max. Power consumption), No CLEI code present in Page 02h, No CDR in TX, No CDR in RX
        Extended RateSelect Compliance: QSFP+ Rate Select Version 1
        Identifier: QSFP+ or later with SFF-8636 or SFF-8436
        Length Cable Assembly(m): 1.0
        Nominal Bit Rate(100Mbs): 255
        Specification compliance:
                10/40G Ethernet Compliance Code: Unknown
                Fibre Channel Link Length: Unknown
                Fibre Channel Speed: Unknown
                Fibre Channel Transmission Media: Unknown
                Fibre Channel Transmitter Technology: Unknown
                Gigabit Ethernet Compliant Codes: Unknown
                SAS/SATA Compliance Codes: Unknown
                SONET Compliance Codes: Unknown
        Vendor Date Code(YYYY-MM-DD Lot): 2016-08-03   
        Vendor Name: Mellanox        
        Vendor OUI: 00-02-c9
        Vendor PN: MCP1600-E001    
        Vendor Rev: A2
        Vendor SN: MT1630VS06791   

it doesn't alive with the output of ethtool (40G, 100G, 25G are identified)

ethtool -m sfp13
        Identifier                                : 0x0d (QSFP+)
        Extended identifier                       : 0x00
        Extended identifier description           : 1.5W max. Power consumption
        Extended identifier description           : No CDR in TX, No CDR in RX
        Extended identifier description           : High Power Class (> 3.5 W) not enabled
        Connector                                 : 0x23 (No separable connector)
        Transceiver codes                         : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : 40G Ethernet: 40G Base-CR4
        Transceiver type                          : 100G Ethernet: 100G Base-CR4 or 25G Base-CR CA-L
        Encoding                                  : 0x00 (unspecified)
        BR, Nominal                               : 25500Mbps
        Rate identifier                           : 0x00
        Length (SMF,km)                           : 0km
        Length (OM3 50um)                         : 0m
        Length (OM2 50um)                         : 0m
        Length (OM1 62.5um)                       : 0m
        Length (Copper or Active cable)           : 1m
        Transmitter technology                    : 0xa0 (Copper cable unequalized)
        Attenuation at 2.5GHz                     : 3db
        Attenuation at 5.0GHz                     : 4db
        Attenuation at 7.0GHz                     : 5db
        Attenuation at 12.9GHz                    : 9db
        Vendor name                               : Mellanox
        Vendor OUI                                : 00:02:c9
        Vendor PN                                 : MCP1600-E001
        Vendor rev                                : A2
        Vendor SN                                 : MT1630VS06791
        Date code                                 : 160803
        Revision Compliance                       : SFF-8636 Rev 1.5
        Module temperature                        : 0.00 degrees C / 32.00 degrees F
        Module voltage                            : 0.0000 V

Describe the results you expected:

Output of show version:

master, 202305

(paste your output here)

Output of show techsupport:

(paste your output here or download and attach the file here )

Additional information you deem important (e.g. issue happens only occasionally):

SfpUtilBase: not all EEPROM data are parsed

To complete the below get/set function, it is found those information are not parsed from EEPROM though there are parser handlers found.

We are on 202012 branch.

    #    get_rx_los
    #    get_tx_fault
    #    get_tx_disable
    #    get_tx_disable_channel
    #    get_lpmode
    #    get_power_override
    #    tx_disable
    #    tx_disable_channel
    #    set_lpmode
    #    set_power_override

Not found in the DB too - which I think is brought into by the sfputil base class only via xcvrd right ? Are these going to be available ?

  "TRANSCEIVER_DOM_SENSOR|Ethernet2": {
    "expireat": 1550333773.959492,
    "ttl": -0.001,
    "type": "hash",
    "value": {
      "rx1power": "0.4112",
      "rx2power": "0.5173",
      "rx3power": "0.4817",
      "rx4power": "0.5907",
      "rxpowerhighalarm": "5.4000",
      "rxpowerhighwarning": "2.4000",
      "rxpowerlowalarm": "-15.0031",
      "rxpowerlowwarning": "-11.0018",
      "temperature": "20.7305",
      "temphighalarm": "75.0000",
      "temphighwarning": "70.0000",
      "templowalarm": "-5.0000",
      "templowwarning": "0.0000",
      "tx1bias": "7.4940",
      "tx1power": "N/A",
      "tx2bias": "7.4940",
      "tx2power": "N/A",
      "tx3bias": "7.4940",
      "tx3power": "N/A",
      "tx4bias": "7.4940",
      "tx4power": "N/A",
      "txbiashighalarm": "10.0000",
      "txbiashighwarning": "8.5000",
      "txbiaslowalarm": "2.0000",
      "txbiaslowwarning": "3.0000",
      "txpowerhighalarm": "N/A",
      "txpowerhighwarning": "N/A",
      "txpowerlowalarm": "N/A",
      "txpowerlowwarning": "N/A",
      "vcchighalarm": "3.6300",
      "vcchighwarning": "3.4650",
      "vcclowalarm": "2.9700",
      "vcclowwarning": "3.1350",
      "voltage": "3.2939"
    }
  },

  "TRANSCEIVER_INFO|Ethernet2": {
    "expireat": 1550333773.954,
    "ttl": -0.001,
    "type": "hash",
    "value": {
      "application_advertisement": "N/A",
      "cable_length": "50",
      "cable_type": "Length Cable Assembly(m)",
      "connector": "MPOx12",
      "encoding": "64B66B",
      "ext_identifier": "Power Class 4(3.5W max), CLEI present, CDR present in Rx Tx",
      "ext_rateselect_compliance": "QSFP+ Rate Select Version 1",
      "hardware_rev": "05",
      "is_replaceable": "False",
      "manufacturer": "CISCO-AVAGO",
      "model": "AFBR-89CDDZ-CS3",
      "nominal_bit_rate": "255",
      "serial": "AVF2219S0T9",
      "specification_compliance": "{}",
      "type": "QSFP28 or later",
      "vendor_date": "2018-05-11 ",
      "vendor_oui": "00-17-6a"
    }
  },

  "TRANSCEIVER_STATUS|Ethernet2": {
    "expireat": 1550333773.9559891,
    "ttl": -0.001,
    "type": "hash",
    "value": {
      "status": "1"
    }
  },

[sonic_ssd] Nokia-7215: "show platform ssdhealth" not showing health percent

The command is not showing the correct value for ssd health.

admin@sonic:~$ show platform ssdhealth 
Device Model : M.2 (S42) 3IE4
Health       : N/A
Temperature  : 25C

[sonic_xcvr]create_xcvr_api don't support port_id=0x0c

We try to call get_power_set() as below and found it get None.
api = self.get_xcvr_api()
power_set = api.get_power_set()

So check xcvr_api_factory.py and found below code,
def create_xcvr_api(self):
...................................

QSFP28

    elif id == 0x11:
        codes = Sff8636Codes
        mem_map = Sff8636MemMap(codes)
        xcvr_eeprom = XcvrEeprom(self.reader, self.writer, mem_map)
        api = Sff8636Api(xcvr_eeprom)
    # QSFP+
    elif id == 0x0D:
        codes = Sff8436Codes
        mem_map = Sff8436MemMap(codes)
        xcvr_eeprom = XcvrEeprom(self.reader, self.writer, mem_map)
        api = Sff8436Api(xcvr_eeprom)

As I know QSFP(port_id=0xC) should follow SFF8436.
But it seems create_xcvr_api() lack of id==0x0C.
Could someone help check it?

xcvrd crashes while parsing QSFP-DD fields

Issue:
xcvrd crashes while parsing QSFP-DD connector type.

Crash trace:
Jul 7 19:18:00.577779 str-DellEmc-z9332f-032 INFO pmon#syseepromd[45]: Starting up...
Jul 7 19:18:00.910456 str-DellEmc-z9332f-032 INFO pmon#/supervisord: message repeated 3 times: [ pcied Platform PCIe Configuration file doesn't exist!]
Jul 7 19:18:00.910586 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd Traceback (most recent call last):
Jul 7 19:18:00.910656 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/bin/xcvrd", line 8, in
Jul 7 19:18:00.910722 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd sys.exit(main())
Jul 7 19:18:00.910789 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/xcvrd/xcvrd.py", line 1416, in main
Jul 7 19:18:00.910858 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd xcvrd.run()
Jul 7 19:18:00.910920 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/xcvrd/xcvrd.py", line 1364, in run
Jul 7 19:18:00.910989 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd self.init()
Jul 7 19:18:00.911059 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/xcvrd/xcvrd.py", line 1327, in init
Jul 7 19:18:00.911125 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd post_port_sfp_dom_info_to_db(is_warm_start, self.stop_event)
Jul 7 19:18:00.911193 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/xcvrd/xcvrd.py", line 500, in post_port_sfp_dom_info_to_db
Jul 7 19:18:00.911258 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd post_port_sfp_info_to_db(logical_port_name, int_tbl[asic_index], transceiver_dict, stop_event)
Jul 7 19:18:00.911326 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/xcvrd/xcvrd.py", line 292, in post_port_sfp_info_to_db
Jul 7 19:18:00.911394 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd port_info_dict = _wrapper_get_transceiver_info(physical_port)
Jul 7 19:18:00.911461 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/xcvrd/xcvrd.py", line 163, in _wrapper_get_transceiver_info
Jul 7 19:18:00.911531 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd return platform_chassis.get_sfp(physical_port).get_transceiver_info()
Jul 7 19:18:00.911598 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/sonic_platform/sfp.py", line 542, in get_transceiver_info
Jul 7 19:18:00.911665 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd connector = self._get_eeprom_data('connector')
Jul 7 19:18:00.911733 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/sonic_platform/sfp.py", line 392, in _get_eeprom_data
Jul 7 19:18:00.911801 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd eeprom_data_raw, 0)
Jul 7 19:18:00.911867 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_sfp/qsfp_dd.py", line 221, in parse_connector
Jul 7 19:18:00.911933 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd return sffbase.parse(self, self.connector, connector_data, start_pos)
Jul 7 19:18:00.911998 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_sfp/sffbase.py", line 186, in parse
Jul 7 19:18:00.912065 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd outdict = self.parse_sff(eeprom_map, eeprom_data, start_pos)
Jul 7 19:18:00.912143 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_sfp/sffbase.py", line 158, in parse_sff
Jul 7 19:18:00.912233 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd meta_data, start_pos)
Jul 7 19:18:00.912324 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_sfp/sffbase.py", line 127, in parse_sff_element
Jul 7 19:18:00.912395 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd offset, size)
Jul 7 19:18:00.912465 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_sfp/qsfp_dd.py", line 49, in decode_connector
Jul 7 19:18:00.912533 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd return connector_dict[connector_id]
Jul 7 19:18:00.912603 str-DellEmc-z9332f-032 INFO pmon#/supervisord: xcvrd KeyError: 'ff'
Jul 7 19:18:00.939018 str-DellEmc-z9332f-032 INFO pmon#supervisord 2021-07-07 19:18:00,938 INFO exited: xcvrd (exit status 1; not expected)
Jul 7 19:18:01.651780 str-DellEmc-z9332f-032 NOTICE pmon#psud[44]: PSU absence warning cleared: PSU 1 is inserted back.

root@str-DellEmc-z9332f-032:~$ show ver

SONiC Software Version: SONiC.20201231.06
Distribution: Debian 10.10
Kernel: 4.19.0-12-2-amd64
Build commit: 959975cede
Build date: Sat Jun 26 15:08:56 UTC 2021
Built by: sonicbld@new-worker-20

Platform: x86_64-dellemc_z9332f_d1508-r0
HwSKU: DellEMC-Z9332f-C32
ASIC: broadcom
ASIC Count: 1
Serial Number: TH04CN21CET0004K0098
Uptime: 21:53:48 up 1:51, 3 users, load average: 0.30, 0.27, 0.27

ChassisBase and ModuleBase classes each have two methods for retrieving serial number

ChassisBase and ModuleBase classes have a get_serial_number() method. However, they both also inherit the get_serial() method from DeviceBase class.

The get_serial_number() method should be removed from these classes, and the inherited get_serial() method should be used, as it is common to all device subclasses.

[syseeprom] Vendor extension TLV content is not displayed

The contents of the vendor extension TLV is not displayed by the 'show platform syseeprom' command. Here's an example of what that looks like.

admin@sonic:~$ show platform syseeprom

TlvInfo Header:
   Id String:    TlvInfo
   Version:      1
   Total Length: 177
TLV Name             Code Len Value
-------------------- ---- --- -----
Product Name         0x21  11 7215 IXS-T1
Part Number          0x22  14 3HE16794AARB01
Serial Number        0x23  11 NK214810028
Base MAC Address     0x24   6 AC:8F:F8:50:AC:3D
Manufacture Date     0x25  19 11/30/2021 16:53:36
Platform Name        0x28  26 armhf-nokia_ixs7215_52x-r0
ONIE Version         0x29  45 2019.11-onie_version-nokia_ixs7215_52x-v1.5.1
MAC Addresses        0x2A   2 64
Service Tag          0x2F  10 CSM9W00FRA
Vendor Extension     0xFD   7 
CRC-32               0xFE   4 0x21DE1669

The Vendor Extension TLV Code and Len are displayed but not the contents.
Please see PR# 270 for a possible fix.

Incorrect vdm freeze and unfreeze is followed on collecting PM stats

Currently PM stats is collected after VDM freeze and unfreeze request, where the data in stats register get rested once the unfreeze request is raised.

Inorder to collect the PM statistics without losing the data, following order of stats freezing and unfreezing to be done.

1. Raise VDM freeze
2. Collect PM stats from stats registers
3. Raise VDM unfreeze /cease freeze request

QSFP-DD FW upgrade doesn't work

For the optics/AOC's supporting LPL, EEPROM FW upgrade is failing.

root@sonic:~# sfputil firmware download Ethernet0 /var/tmp/Dell_CDB_TRIAL_FW_Major_01_Minor_02_BuildNo_03.bin

CDB: Starting firmware download

CDB: firmware download failed! - status 112

root@sonic:~#

status 112 indicates that the payload length is wrong.

Enhance pcieutil to check actual presence of pcie device

pcieutil checks the sysfs entry to conclude if a pcie device is present or not. The sysfs entry won't be updated for non-hotplug pcie device if say, a downstream port of a pcie switch (to which a pcie device is connected) receives a "hot-reset". In this case the pcie device will be disconnected from the bus, but sysfs entry doesn't reflect the missing device.

[SFP-refactor] xcvrd crashes while trying to read CMIS passive cables

Trace Logs:

c.get_sfp(1).get_transceiver_info()
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_xcvr/sfp_optoe_base.py", line 24, in get_transceiver_info
return api.get_transceiver_info() if api is not None else None
File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_xcvr/api/public/cmis.py", line 106, in get_transceiver_info
admin_info = self.xcvr_eeprom.read(consts.ADMIN_INFO_FIELD)
File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_xcvr/xcvr_eeprom.py", line 30, in read
return field.decode(raw_data, **decoded_deps)
File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_xcvr/fields/xcvr_field.py", line 237, in decode
**decoded_deps)
File "/usr/local/lib/python3.7/dist-packages/sonic_platform_base/sonic_xcvr/fields/xcvr_field.py", line 150, in decode
decoded = struct.unpack(self.format, raw_data)[0]
struct.error: unpack requires a buffer of 1 bytes

Issue was not seen for 400G AOC cables.
Note:
The same module was read without any issues when SFP refactor is not included.

Pytest: test_crm failed on loganalyzer error

On running the test_crm.py we see the following loganalyzer failure

The loganalyzer failure is due to:

Test script was looking for start marker string like "start-LogAnalyzer-crm_test.2021-07-01-23:27:43" , but syslog only had "start-LogAnalyzer-crm_test.2021-07-01-23: 27:43" (which has an extra space after the first ":").

What test script was looking for:

E "msg": "Error: (<type 'exceptions.Exception'>, Exception('start-LogAnalyzer-crm_test.2021-07-01-23:27:43 was not found in /var/log',), <traceback object at 0x7f3e53ebb9e0>)"
E }

What syslog had:

syslog.4:Jul 1 23:27:45.430043 mathilda-01 INFO syncd#start-LogAnalyzer-crm_test.2021-07-01-23: 27:43
Basically, test script uses unix socket to write start marker string to syslog. So we manually tried to write "start-LogAnalyzer-crm_test.2021-07-01-23:27:43" to syslog socket ('/dev/log') using the same python snippet test script invokes. The output in syslog would always automatically add an extra space after the first ":"

Workaround tried:
sonic-mgmt/tests/common/plugins/loganalyzer/loganalyzer.py

what we changed in the test script is replacing ':' with '-' in start_marker string:

def _setup_marker(self):
    """
    Adds the marker to the syslog
    """
    start_marker = ".".join((self.marker_prefix, time.strftime("%Y-%m-%d-%H:%M:%S", time.gmtime()))) 
    cmd = "python {run_dir}/loganalyzer.py --action init --run_id {start_marker}".format(run_dir=self.dut_run_dir, start_marker=start_marker)

    logging.debug("Adding start marker '{}'".format(start_marker))
    self.ansible_host.command(

start_marker = ".".join((self.marker_prefix, time.strftime("%Y-%m-%d-%H:%M:%S", time.gmtime()))) --> start_marker = ".".join((self.marker_prefix, time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime())))

Runlog:
self = <tests.common.plugins.loganalyzer.loganalyzer.LogAnalyzer instance at 0x7f2950bd6c80>
result = {'expect_messages': {'/tmp/syslog.2021-04-30-12:08:38': []}, 'match_files': {'/tmp/syslog.2021-04-30-12:08:38': {'expe... {'/tmp/syslog.2021-04-30-12:08:38': []}, 'total': {'expected_match': 0, 'expected_missing_match': 1, 'match': 0}, ...}

def _verify_log(self, result):
"""
Verify that total match and expected missing match equals to zero or raise exception otherwise.
Verify that expected_match is not equal to zero when there is configured expected regexp in self.expect_regex list
"""
if not result:
raise LogAnalyzerError("Log analyzer failed - no result.")
if result["total"]["match"] != 0 or result["total"]["expected_missing_match"] != 0:
raise LogAnalyzerError(result)
E LogAnalyzerError: {'match_messages': {'/tmp/syslog.2021-04-30-12:08:38': []}, 'total': {'expected_match': 0, 'expected_missing_match': 1, 'match': 0}, 'match_files': {'/tmp/syslog.2021-04-30-12:08:38': {'expected_match': 0, 'match': 0}}, 'expect_messages': {'/tmp/syslog.2021-04-30-12:08:38': []}, 'unused_expected_regexp': ['.* THRESHOLD_EXCEEDED .*']}

result = {'expect_messages': {'/tmp/syslog.2021-04-30-12:08:38': []}, 'match_files': {'/tmp/syslog.2021-04-30-12:08:38': {'expe... {'/tmp/syslog.2021-04-30-12:08:38': []}, 'total': {'expected_match': 0, 'expected_missing_match': 1, 'match': 0}, ...}
self = <tests.common.plugins.loganalyzer.loganalyzer.LogAnalyzer instance at 0x7f2950bd6c80>

sfputilbase.py read_porttab_mappings() /4 hardcoding

Line 407 & 412 on master branch. The logic is to take Ethernet# and hardcode divide by 4 to get front panel port #. This works for 100G ports but when moving to 400G, folks are using base8 instead of base4 to reflect the # of serdes for port breakout.

Current workaround is to use "index" column for this function.

But we see this (/4) hardcoding several places in SONiC. Request to place either base8 or base4 as a user configurable variable (maybe in JSON) and remove all this /4 hardcoding in SONiC codebase.

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

[Mellanox] When 40G optic is in PLUGGED-ERR state, no amber LED is activated

Setup:

admin@sonic:~$ show version | head
SONiC Software Version: SONiC.HEAD.763-a7701fe
Distribution: Debian 9.5
Kernel: 4.9.0-7-amd64
Build commit: a7701fe
Build date: Mon Oct 15 12:47:09 UTC 2018
Built by: johnar@jenkins-worker-3

Docker images:
REPOSITORY                 TAG                 IMAGE ID            SIZE
docker-orchagent-mlnx      HEAD.763-a7701fe    73031690b2e6        259.7 MB
admin@sonic:~$ show platform summary
Platform: x86_64-mlnx_msn2100-r0
HwSKU: ACS-MSN2100
ASIC: mellanox

Issue:

I observed that once I put 100G optic in the switch which is unsupported it starts blinking with an amber LED to indicate that.
However, with exactly the same situation with 40G optics, the LED is not activated at all.
I think the latter case should start an orange LED as well.

admin@sonic:~$ docker exec -it syncd sx_api_ports_dump.py
=================================================================================================================
|  log_port|local_port|label_port|       mtu| admin_s|  oper_s|       module_s|  pvid|     oper_speed|  fec_mode|
=================================================================================================================
|   0x10100|         1|         7|      9122|      UP|    DOWN|    PLUGGED-ERR|     1|            N/A|      None|
|   0x10500|         5|         8|      9122|      UP|    DOWN|      UNPLUGGED|     1|            N/A|      None|
|   0x10900|         9|         5|      9122|      UP|      UP|        PLUGGED|     1|      100GB_CR4|        RS|
|   0x10d00|        13|         6|      9122|      UP|    DOWN|      UNPLUGGED|     1|            N/A|      None|
|   0x11100|        17|         3|      9122|      UP|    DOWN|        PLUGGED|     1|            N/A|      None|
|   0x11500|        21|         4|      9122|      UP|    DOWN|      UNPLUGGED|     1|            N/A|      None|
|   0x11900|        25|         1|      9122|      UP|    DOWN|        PLUGGED|     1|            N/A|      None|
|   0x11d00|        29|         2|      9122|      UP|    DOWN|      UNPLUGGED|     1|            N/A|      None|
|   0x12100|        33|        10|      9122|      UP|    DOWN|      UNPLUGGED|     1|            N/A|      None|
|   0x12500|        37|         9|      9122|      UP|    DOWN|    PLUGGED-ERR|     1|            N/A|      None|
|   0x12900|        41|        12|      9122|      UP|    DOWN|      UNPLUGGED|     1|            N/A|      None|
|   0x12d00|        45|        11|      9122|      UP|    DOWN|    PLUGGED-ERR|     1|            N/A|      None|
|   0x13100|        49|        14|      9122|      UP|      UP|        PLUGGED|     1|       40GB_CR4|      None|
|   0x13500|        53|        13|      9122|      UP|    DOWN|    PLUGGED-ERR|     1|            N/A|      None|
|   0x13900|        57|        16|      9122|      UP|    DOWN|        PLUGGED|     1|            N/A|      None|
|   0x13d00|        61|        15|      9122|      UP|    DOWN|      UNPLUGGED|     1|            N/A|      None|
=================================================================================================================

Reproduce steps:

Put a non-mellanox optic in the switch. Compare LED behaviour for 100G and 40G types.

[ API 2.0 ] xcvrd issue in media settings supported platforms

Hi,

We notice the following issue in Dell Z9100 where xcvrd exits in API 2.0 with the following trace.
This issue may occur for other platforms also.

root@sonic:/# xcvrd
Traceback (most recent call last):
File "/usr/bin/xcvrd", line 1077, in
main()
File "/usr/bin/xcvrd", line 1074, in main
xcvrd.run()
File "/usr/bin/xcvrd", line 1038, in run
self.init()
File "/usr/bin/xcvrd", line 1022, in init
post_port_sfp_dom_info_to_db(is_warm_start, self.stop_event)
File "/usr/bin/xcvrd", line 391, in post_port_sfp_dom_info_to_db
notify_media_setting(logical_port_name, transceiver_dict, app_port_tbl)
File "/usr/bin/xcvrd", line 613, in notify_media_setting
key = get_media_settings_key(physical_port, transceiver_dict)
File "/usr/bin/xcvrd", line 520, in get_media_settings_key
media_compliance_dict = ast.literal_eval(media_compliance_dict_str)
File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python2.7/ast.py", line 79, in _convert
raise ValueError('malformed string')
ValueError: malformed string
root@sonic:/#

This is due to the fact where one of the EEPROM is not readable(optic issue).
If EEPROM is not readable, currently we return dictionary that has ‘N/A’ fields in sfp.py.
XCVRD doesn’t handle ‘N/A’ and because of this, xcvrd exits.

As per definition added in sfp_base.py, it says that we need to return dictionary.

def get_transceiver_info(self):
"""
Retrieves transceiver info of this SFP

    Returns:
        A dict which contains following keys/values :

--Fix:
Returning “None” for unreadable EEPROM, fixes this issue as None type is handled in xcvrd.

def get_transceiver_info(self):
"""
Retrieves transceiver info of this SFP
"""
transceiver_info_dict = {}
compliance_code_dict = {}
transceiver_info_dict = dict.fromkeys(info_dict_keys, 'N/A')

    # BaseInformation
    iface_data = self._get_eeprom_data('type')
    if (iface_data is not None):
        connector = iface_data['data']['Connector']['value']
        encoding = iface_data['data']['EncodingCodes']['value']
        ext_id = iface_data['data']['Extended Identifier']['value']
        rate_identifier = iface_data['data']['RateIdentifier']['value']
        identifier = iface_data['data']['type']['value']
        bit_rate = str(
            iface_data['data']['Nominal Bit Rate(100Mbs)']['value'])
        type_abbrv_name=iface_data['data']['type_abbrv_name']['value']

        for key in compliance_code_tup:
            if key in iface_data['data']['Specification compliance']['value']:
                compliance_code_dict[key] = iface_data['data']['Specification compliance']['value'][key]['value']
        for key in cable_length_tup:
            if key in iface_data['data']:
                cable_type = key
                cable_length = str(iface_data['data'][key]['value'])
    else:
        return transceiver_info_dict    ====>changing return type to “None” fixes the issue

Query:

1. Incase if we’re returning the dictionary itself, can community handle xcvrd on the dictionary part that has ‘N/A’ value or we need to return “None” in sfp.py?.
2. We need to get clear definition from your side on the return type (documentation needs to be corrected in sfp_base.py on the return type).
3. ‘type_abbrv_name’ key also needs to be documented in sfp_base.py

sfp module dom eeprom related issues

sonic-platform-common/sonic_sfp/sfputilbase.py

sfp module dom eeprom related issues（qsfp module works fine）:
There are two situations in the DOM information location in the sfp module, we need a unified way to handle both cases.
Case A. i2c addr: 0x50 device node, offset 256-511
Case B. i2c addr: 0x51 device node, offset 0-255

1. def get_eeprom_dom_raw(self, port_num). This function now actually gets i2c addr: 0x50, offset 0-255, which doesn't seem to work. (The following situation will only use 0x50)

    if port_num in self.port_to_eeprom_mapping.keys():
        sysfs_sfp_i2c_client_eeprom_path = self.port_to_eeprom_mapping[port_num]
   

2. def get_transceiver_dom_info_dict(self, port_num). This function now actually gets i2c addr: 0x50, offset 256-511, which does not work properly in case B.

3. line 1020，def get_transceiver_dom_info_dict(self, port_num): sfpd_obj = sff8472Dom() not working, calibration_type is not properly initialized.

Remove dependency on sonic-config-engine

Remove dependency on sonic-config-engine (i.e., move portconfig-related functions to sonic-py-common, including those in sonic-config-engine/portconfig.py)

Depends on sonic-net/sonic-buildimage#4999

Support for QSFP28 adapters