Hi Kim, >> Actually, our static code analyzer did not see this one. > > ok, so the patch technically isn't fixing anything broken, then. Are you saying the code isn't broken _because_ a static tool analyser did not see anything wrong here? > the new code just added a new condition, which doesn't invalidate > the comment. And simply removing the comment as opposed to amending > it is a bit overkill. You are partially right, but will the staggering lack of comments in the caam driver be fixed by duplicating a cascade of three ifs into english? >> It is indeed simpler but does it consider also the missing error codes >> at index 1 and 5? Just checking for an upper bound is not enough. > > no, the existing code already handles that. Note that newer > documentation fills the 1 and 5 slots, too. If you have the new error codes please send them to me for an update. >> On the other hand, if the error field is only three bits wide instead of >> four as stated by the documentation, a better fix means using a three >> bit mask instead of reporting an invalid error code. > > true, but then we'd introduce a direct discrepancy with the > documentation, and thus h/w. You basically ask me to agree that if there are no _documented_ error codes between 0x8 and 0xf then I should trust that they will never come up on a 4 bit field. Do you want me to drop the patch and pretend there is nothing to see? Cristian S. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
