Platform Support for CPO#682
Open
bgallagher-nexthop wants to merge 11 commits into
Open
Conversation
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
bgallagher-nexthop
force-pushed
the
cpo-separate-eeprom-access
branch
from
e21b2ec to
025551a
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
prgeor
reviewed
May 29, 2026
prgeor
reviewed
May 29, 2026
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
bgallagher-nexthop
force-pushed
the
cpo-separate-eeprom-access
branch
from
7436ad6 to
76b9602
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
prgeor
reviewed
Jun 1, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR extends sonic_platform_base’s transceiver abstractions to support CPO (Co-Packaged Optics) by factoring common EEPROM read/write behavior into reusable mixins, refactoring existing SFP base classes to use them, and introducing new CPO base classes plus a factory for selecting the correct CPO API implementation.
Changes:
- Introduces shared EEPROM helper utilities (
eeprom_rw.py) and an Optoe-specific EEPROM R/W mixin (optoe_eeprom_rw.py), and reuses them fromXcvrApiFactoryandSfpOptoeBase. - Adds initial CPO base abstractions (
OeBase,ElsfpBase,CpoBase, plus Optoe variants) and aCpoApiFactoryscaffold. - Adds/updates unit tests around the Optoe helpers and the new CPO base/factory scaffolding.
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/sonic_xcvr/test_sfp_optoe_base.py | Updates Optoe constant imports and adds tests for newly-factored Optoe EEPROM helper behavior. |
| tests/sonic_xcvr/test_cpo_base.py | Adds tests for basic caching/initialization behavior of new CPO base classes. |
| tests/sonic_xcvr/test_cpo_api_factory.py | Adds tests asserting current factory behavior (raising ValueError for unsupported/unimplemented selection). |
| sonic_platform_base/sonic_xcvr/xcvr_api_factory.py | Refactors vendor/id EEPROM parsing to use new shared helper functions. |
| sonic_platform_base/sonic_xcvr/sfp_optoe_base.py | Refactors SfpOptoeBase to use the new Optoe EEPROM R/W mixin instead of local implementations. |
| sonic_platform_base/sonic_xcvr/optoe_eeprom_rw.py | Adds Optoe-specific EEPROM R/W mixin and related sysfs helper methods. |
| sonic_platform_base/sonic_xcvr/eeprom_rw.py | Adds shared EEPROM helper functions and an EEPROM R/W mixin interface. |
| sonic_platform_base/sonic_xcvr/cpo_optoe_base.py | Adds Optoe-based OE/ELSFP base classes combining CPO bases with Optoe EEPROM mixin. |
| sonic_platform_base/sonic_xcvr/cpo_base.py | Adds initial CPO base classes (OeBase, ElsfpBase, CpoBase) with API caching hooks. |
| sonic_platform_base/sonic_xcvr/cpo_api_factory.py | Adds CPO API factory scaffolding and hardware-id types for selecting implementations. |
| sonic_platform_base/sfp_base.py | Refactors SfpBase to inherit the new EEPROM R/W mixin interface. |
prgeor
reviewed
Jun 1, 2026
prgeor
reviewed
Jun 1, 2026
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Natgerbi
reviewed
Jun 2, 2026
Comment on lines
+32
to
+34
| def create_oe_api(self): | ||
| # if self._oe.hardware_id.oe_id == OeId.EXAMPLE: | ||
| # self._create_api(...) |
There was a problem hiding this comment.
What is the benefit of having _create_api take the full list of vendors? We already know the oe vendor from the platform.
For ELS, I can understand it, since it may be used across different platforms.
Contributor
Author
There was a problem hiding this comment.
This is primarily to keep the same consistent approach for instantiating an API between the OE and the ELSFP. It also keeps the logic for API instantiation in common, public code as opposed to hidden in vendor platform code.
The vendor will pass in the CpoHardwareId from their code, then sonic-platform-common code knows how to handle the rest.
cc @prgeor as the original suggester of this ID-based approach, in case you have any additional motivation for this approach you'd like to mention
…s sharing more logic Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
…FP functionality are in oe.py and elsfp.py Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Signed-off-by: Brian Gallagher <bgallagher@nexthop.ai>
Collaborator
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This file contains hidden or 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
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.
Description
This PR makes the following changes:
Motivation and Context
This change is required to implement a platform data model for CPO hardware that SONiC daemons can use.
How Has This Been Tested?
Unit-tests have been added. Later on, when vendors extend the CPO API factory code with changes for their own platforms, the unit-tests will be extended to be more useful.