[PATCH] drm/xe/log: fix documentation title levels

[PATCH] drm/xe/log: fix documentation title levels

[Guillaume Tucker]

Fix an htmldocs build error in the gpu/xe section by moving all the
titles one level higher in the Xe SIGID page to keep a consistent
hierarchy.  This is the error message:

    Documentation/gpu/xe/xe_sigid.rst:10: (SEVERE/4) Title level inconsistent:

All the other pages in the xe section use <h2> titles so follow the
same convention here as well.

Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
---
 drivers/gpu/drm/xe/abi/xe_sigid_abi.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/xe/abi/xe_sigid_abi.h b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
index 2f3440505f69..277b15fce9cc 100644
--- a/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
+++ b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
@@ -10,14 +10,14 @@
  * DOC: Xe Error Signatures (SIGID)
  *
  * What SIGID stands for
- * ---------------------
+ * =====================
  *
  * SIGID is short for *Signature Identifier*. It is a small, stable integer
  * that names one of the *recognised fault sites* -- nothing more. It is the
  * primary handle used for triage and maps directly to a specific report site.
  *
  * Numbering
- * ---------
+ * =========
  *
  * SIGIDs are a single flat list numbered sequentially within the assigned range,
  * in the order the fault sites were introduced. Values are stable: once assigned
@@ -25,7 +25,7 @@
  * SIGID value is deprecated in place, never re-purposed.
  *
  * Why this exists
- * ---------------
+ * ===============
  *
  * Today the driver reports faults with ad-hoc ``xe_err()`` / ``xe_gt_err()``
  * strings that have no stable shape. That is fine for a human reading dmesg,
@@ -37,7 +37,7 @@
  * firmware versions, and (eventually) across other Intel devices in a node.
  *
  * What a SIGID is not
- * -------------------
+ * ===================
  *
  * SIGID deliberately does not encode the detailed reason or the outcome. Those
  * are carried alongside it::
@@ -51,7 +51,7 @@
  * different severities depending on the instance and the recovery taken.
  *
  * When to use SIGID logging
- * -------------------------
+ * =========================
  *
  * The xe_log_*() helpers are for these recognised fault sites only --
  * important, operator-relevant faults and events. The driver's only job is to
@@ -63,7 +63,7 @@
  * those that correspond to a published fault site.
  *
  * SIGID log output (dmesg vs. the machine record)
- * -----------------------------------------------
+ * ===============================================
  *
  * The dmesg line stays close to a normal xe error message so it remains
  * readable for admins; the only stable, machine-matchable token on it is
@@ -74,7 +74,7 @@
  * carrying the same SIGID (generation is a planned follow-up).
  *
  * How to pick a SIGID (the uniqueness rule)
- * -----------------------------------------
+ * =========================================
  *
  * Pick per *report site*, not per incident. Each site emits the single most
  * specific recognised SIGID *for that site* -- so the question is never
@@ -95,7 +95,7 @@
  * after making significant changes to the site that emits this SIGID.
  *
  * Scope: software vs hardware emitted signatures
- * ----------------------------------------------
+ * ==============================================
  *
  * Some SIGID represents fault sites that the *driver itself* detects and
  * reports from the software POV: probe abort, wedged, survivability, driver-
-- 
2.47.3

✗ LGCI.VerificationFailed: failure for drm/xe/log: fix documentation title levels

[Patchwork]

== Series Details ==

Series: drm/xe/log: fix documentation title levels
URL   : https://patchwork.freedesktop.org/series/175961/
State : failure

== Summary ==

Series author address 'gtucker@gtucker.io' is not on the allowlist, which prevents CI from being automatically triggered.
If you want CI to run for this series, ask Patchwork project owners to click 'retest' on the series in Patchwork.
Exception occurred during validation, bailing out!
Build URL: http://intel-gfx-ci-public.igk.intel.com:8080/job/xe_pw_trigger/1310213/ (on master)

Re: [PATCH] drm/xe/log: fix documentation title levels

[Rodrigo Vivi]

On Sun, Oct 11, 2026 at 07:46:53PM +0200, Guillaume Tucker wrote:
> Fix an htmldocs build error in the gpu/xe section by moving all the
> titles one level higher in the Xe SIGID page to keep a consistent
> hierarchy.  This is the error message:
> 
>     Documentation/gpu/xe/xe_sigid.rst:10: (SEVERE/4) Title level inconsistent:
> 
> All the other pages in the xe section use <h2> titles so follow the
> same convention here as well.

it looks like we have more stuff to fix in the xe_migrate.c still...

thanks for this patch.
pushed to drm-xe-next

> 
> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
> ---
>  drivers/gpu/drm/xe/abi/xe_sigid_abi.h | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/abi/xe_sigid_abi.h b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> index 2f3440505f69..277b15fce9cc 100644
> --- a/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> +++ b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> @@ -10,14 +10,14 @@
>   * DOC: Xe Error Signatures (SIGID)
>   *
>   * What SIGID stands for
> - * ---------------------
> + * =====================
>   *
>   * SIGID is short for *Signature Identifier*. It is a small, stable integer
>   * that names one of the *recognised fault sites* -- nothing more. It is the
>   * primary handle used for triage and maps directly to a specific report site.
>   *
>   * Numbering
> - * ---------
> + * =========
>   *
>   * SIGIDs are a single flat list numbered sequentially within the assigned range,
>   * in the order the fault sites were introduced. Values are stable: once assigned
> @@ -25,7 +25,7 @@
>   * SIGID value is deprecated in place, never re-purposed.
>   *
>   * Why this exists
> - * ---------------
> + * ===============
>   *
>   * Today the driver reports faults with ad-hoc ``xe_err()`` / ``xe_gt_err()``
>   * strings that have no stable shape. That is fine for a human reading dmesg,
> @@ -37,7 +37,7 @@
>   * firmware versions, and (eventually) across other Intel devices in a node.
>   *
>   * What a SIGID is not
> - * -------------------
> + * ===================
>   *
>   * SIGID deliberately does not encode the detailed reason or the outcome. Those
>   * are carried alongside it::
> @@ -51,7 +51,7 @@
>   * different severities depending on the instance and the recovery taken.
>   *
>   * When to use SIGID logging
> - * -------------------------
> + * =========================
>   *
>   * The xe_log_*() helpers are for these recognised fault sites only --
>   * important, operator-relevant faults and events. The driver's only job is to
> @@ -63,7 +63,7 @@
>   * those that correspond to a published fault site.
>   *
>   * SIGID log output (dmesg vs. the machine record)
> - * -----------------------------------------------
> + * ===============================================
>   *
>   * The dmesg line stays close to a normal xe error message so it remains
>   * readable for admins; the only stable, machine-matchable token on it is
> @@ -74,7 +74,7 @@
>   * carrying the same SIGID (generation is a planned follow-up).
>   *
>   * How to pick a SIGID (the uniqueness rule)
> - * -----------------------------------------
> + * =========================================
>   *
>   * Pick per *report site*, not per incident. Each site emits the single most
>   * specific recognised SIGID *for that site* -- so the question is never
> @@ -95,7 +95,7 @@
>   * after making significant changes to the site that emits this SIGID.
>   *
>   * Scope: software vs hardware emitted signatures
> - * ----------------------------------------------
> + * ==============================================
>   *
>   * Some SIGID represents fault sites that the *driver itself* detects and
>   * reports from the software POV: probe abort, wedged, survivability, driver-
> -- 
> 2.47.3
>