diff options
author | John Harrison <John.C.Harrison@Intel.com> | 2025-09-09 15:41:31 -0700 |
---|---|---|
committer | John Harrison <John.C.Harrison@Intel.com> | 2025-09-16 12:11:08 -0700 |
commit | 3b09b11805bfee32d5a0000f5ede42c07237a6c4 (patch) | |
tree | 816c127dbf6be1d247d401725b211e8b67e81f95 /rust/helpers/build_bug.c | |
parent | 1a869168d91f1a1a2b0db22cea0295c67908e5d8 (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/build_bug.c')
0 files changed, 0 insertions, 0 deletions