diff options
| author | Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> | 2026-09-11 10:58:29 +0200 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-09-16 19:07:13 -0700 |
| commit | 90e4b849dfa6fc8e6c050bcfe1b331b69c015d28 (patch) | |
| tree | 025cabcbcf5c45d659cceeeb60db45cf0a8d7307 /tools/perf/scripts/python | |
| parent | c7ead9704249d57d4693a04697e3bbd285138fa9 (diff) | |
| download | linux-next-90e4b849dfa6fc8e6c050bcfe1b331b69c015d28.tar.gz linux-next-90e4b849dfa6fc8e6c050bcfe1b331b69c015d28.zip | |
net: stmmac: propagate FPE preemption-class mapping errors
stmmac_fpe_map_preemption_class() dispatches through the
stmmac_do_void_callback() helper, which forces the callback's return
value to 0 whenever the op pointer is populated. As a result the
-EINVAL returned by dwmac5_fpe_map_preemption_class() (e.g. when a
preemptible TC owns more than one TXQ under SP scheduling) is silently
swallowed by every caller.
Switch the dispatch macro to stmmac_do_callback() so the callback's real
result is propagated, and honour it in the taprio and mqprio qdisc
offload.
Note that the taprio "if (ret)" check in tc_taprio_configure() used to
be dead code and now becomes live: a preemptible TC spanning more than
one TXQ under SP scheduling cannot be programmed in hardware, so a
taprio or mqprio configuration that previously returned success while
leaving the preemption-class register unprogrammed now fails with
-EINVAL. For taprio, the failure also runs the disable path, tearing
down the schedule that was just installed; this is the intended
behaviour.
Fixes: 195e4f409a40 ("net: stmmac: support fp parameter of tc-mqprio")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Link: https://patch.msgid.link/20260911-stmmac-tc_setup_dwmac510_mqprio-error-path-v3-1-a76b1e2547c1@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
