[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

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
>