[PDDF] multifpgapci driver support for multiple protocols #24070
Conversation
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
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
raghav-nexthop
force-pushed
the
multifpgapci-driver
branch
from
a778a86 to
fb1dd0b
Compare
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
@geans-pin |
- Accept upstream change for pddf-device.json (now auto-generated) - Add multifpgapci protocol modules to pddf-device.json.j2 template: - pddf_multifpgapci_i2c_module - pddf_multifpgapci_gpio_module - pddf_multifpgapci_spi_module
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
lotus-nexthop
pushed a commit
to nexthop-ai/sonic-buildimage
that referenced
this pull request
Oct 27, 2025
lotus-nexthop
pushed a commit
to nexthop-ai/sonic-buildimage
that referenced
this pull request
Oct 27, 2025
lotus-nexthop
added a commit
to nexthop-ai/sonic-buildimage
that referenced
this pull request
Oct 27, 2025
9 tasks
This reverts commit d457bf7.
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
I pulled out the MDIO change into #24348 |
Contributor
|
HLD: sonic-net/SONiC#2090 |
geans-pin
reviewed
Oct 27, 2025
Contributor
geans-pin
left a comment
geans-pin
left a comment
There was a problem hiding this comment.
Please provide UT verification log based on the PR changes
Contributor
Thanks @geans-pin , I have attachd the dmesg logs which show the pddf kernel module initialization. It is running the image built from this PR itself. |
Collaborator
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
geans-pin
approved these changes
Oct 29, 2025
Praveen-Brcm
approved these changes
Oct 31, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.
[PDDF] Structure and API for protocol modules to register their ops with the driver
[PDDF] Make multifpgapci i2c protocol handler a standalone kernel module
[PDDF] Make multifpgapci gpio protocol handler a standalone kernel module
[PDDF] Cleanup driver private data from having protocol info
Why I did it
Addition of new protocols requires changes to the multifpgapci driver including changes to the internal structure to be able to maintain protocol specific information. This affects speed and ease of development of features, long term maintainability and most importantly the code quality.
Work item tracking
How I did it
Defined a set of operations in the driver that a protocol module should implement. These operations are registered by protocol modules with the driver using an API. As part of this change, all the protocol specific handling is moved to the modules -in this case i2c code is refactored out of the driver and into a separate module. Similarly, the gpio protocol code is converted into an independent loadable module.
How to verify it
Used the latest passing build to verify the loading of modules and detection of i2c devices:
i2c module logs:
gpio module logs
gpio devices
i2c devices
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)