[i2c,rtl] Reduce NACK count size #22107
Merged
Conversation
This file contains 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
Originally this NACK count was 32 bits which is not really necessary. With 8 bits the software can see up to the depth of the ACQ FIFO worth of NACKs, beyond that they lose their meaning. The counter should saturate so that when it reads 0xFF that the software knows it has exceeded the counter. Signed-off-by: Marno van der Maas <[email protected]>
After reducing the counter from 32 bits to 8 bits, saturation is now more likely. This commit saturates the NACK counter at the maximum value of 0xFF. Signed-off-by: Marno van der Maas <[email protected]>
marnovandermaas
force-pushed
the
i2c_reduce_nack_count_size
branch
from
7edf6d5
to
5d8cc45
Compare
Closed
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.
Based on the comment by @andreaskurth: #21857 (comment)
The 32 bits for this counter is a bit overkill. 8 bits should probably be enough since that means the software has missed a whole ACQ FIFO full of contents. Beyond this the value loses most of its meaning. This PR also saturates the counter.