summaryrefslogtreecommitdiff
path: root/include/linux/timerqueue.h
diff options
context:
space:
mode:
authorGustavo Sousa <gustavo.sousa@intel.com>2026-05-22 05:45:18 -0300
committerGustavo Sousa <gustavo.sousa@intel.com>2026-05-22 10:52:29 -0300
commitf6d460e33e537b576d74c67bb9b6352511f5bb96 (patch)
tree3a91404e17015ca96a89f8208baa41b6b21f2136 /include/linux/timerqueue.h
parentff7746336b2325087aa7958d40f327bcc50185f8 (diff)
drm/xe/rtp: Don't short-circuit to false in or-yes case
While RTP processing evaluates true on the "yes-or" case (i.e. a conjunction of rules that evaluate to true followed by an "OR" without the right hand operand), it does not on the "or-yes" one. Both cases are considered malformed and could be a result of someone dropping checks deemed not necessary anymore and forgetting to drop the superfluous "OR". Nevertheless, we should aim for consistency, and having the "or-yes" case also evaluating to true while also causing a warning seems reasonable. So let's do that. The "or-yes" pattern being evaluated to false comes from the fact that that we unconditionally short-circuit upon finding XE_RTP_MATCH_OR on the outer loop. We should only do that if the preceding conjunction of rules evaluated to true (meaning that rcount must be non-zero) and continue the evaluation otherwise. Do that and also add extra test cases to validate the short-circuiting behavior. Notice that some of the new test cases have a "FIXME" comment, which comes from the fact that we are unable to detect syntax errors after the short-circuit point. That is going to be fixed in a follow-up change. Link: https://lore.kernel.org/intel-xe/871pfw4lo9.fsf@intel.com/ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-3-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Diffstat (limited to 'include/linux/timerqueue.h')
0 files changed, 0 insertions, 0 deletions