summaryrefslogtreecommitdiff
path: root/rust/helpers/bitmap.c
diff options
context:
space:
mode:
authorJohn Harrison <John.C.Harrison@Intel.com>2025-09-09 15:41:31 -0700
committerJohn Harrison <John.C.Harrison@Intel.com>2025-09-16 12:11:08 -0700
commit3b09b11805bfee32d5a0000f5ede42c07237a6c4 (patch)
tree816c127dbf6be1d247d401725b211e8b67e81f95 /rust/helpers/bitmap.c
parent1a869168d91f1a1a2b0db22cea0295c67908e5d8 (diff)
drm/xe/guc: Return an error code if the GuC load fails
Due to multiple explosion issues in the early days of the Xe driver, the GuC load was hacked to never return a failure. That prevented kernel panics and such initially, but now all it achieves is creating more confusing errors when the driver tries to submit commands to a GuC it already knows is not there. So fix that up. As a stop-gap and to help with debug of load failures due to invalid GuC init params, a wedge call had been added to the inner GuC load function. The reason being that it leaves the GuC log accessible via debugfs. However, for an end user, simply aborting the module load is much cleaner than wedging and trying to continue. The wedge blocks user submissions but it seems that various bits of the driver itself still try to submit to a dead GuC and lots of subsequent errors occur. And with regards to developers debugging why their particular code change is being rejected by the GuC, it is trivial to either add the wedge back in and hack the return code to zero again or to just do a GuC log dump to dmesg. v2: Add support for error injection testing and drop the now redundant wedge call. CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://lore.kernel.org/r/20250909224132.536320-1-John.C.Harrison@Intel.com
Diffstat (limited to 'rust/helpers/bitmap.c')
0 files changed, 0 insertions, 0 deletions