i3c: support expected NACK from target device on data xfer - #117367
Open
dcpleung wants to merge 1 commit into
Open
i3c: support expected NACK from target device on data xfer#117367dcpleung wants to merge 1 commit into
dcpleung wants to merge 1 commit into
Conversation
There are some situations where a NACK is expected from the target after sending the address. One example would be MCTP, where the target would NACK if there is no data to return during polling. This use case is not entirely conforming to traditional I2C/I3C transfer mechanism where a NACK after the address byte means there is no target with this address or the target is not responding to the transfer request. In order to support MCTP, we will need to handle this type of transfer gracefully, by adding a new transfer message flag to indicate this type of transfer. A new return value is also being introduced to i3c_transfer() to signal the expected NACK is received. Since most of the wire interactions are handled by the hardware, each individual driver will need to purposely handle this use case. For now, this commit only introduces the building block needed for the drivers to implement the bits to support this use case. Relates to zephyrproject-rtos#114312 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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
3 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.
There are some situations where a NACK is expected from the target after sending the address. One example would be MCTP, where the target would NACK if there is no data to return during polling. This use case is not entirely conforming to traditional I2C/I3C transfer mechanism where a NACK after the address byte means there is no target with this address or the target is not responding to the transfer request. In order to support MCTP, we will need to handle this type of transfer gracefully, by adding a new transfer message flag to indicate this type of transfer. A new return value is also being introduced to i3c_transfer() to signal the expected NACK is received. Since most of the wire interactions are handled by the hardware, each individual driver will need to purposely handle this use case. For now, this commit only introduces the building block needed for the drivers to implement the bits to support this use case.
Relates to #114312