All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mallesh Koujalagi" <mallesh.koujalagi@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v13 2/4] drm/doc: Document DRM_WEDGE_RECOVERY_COLD_RESET recovery method
Date: Wed, 05 Aug 2026 07:20:50 +0000	[thread overview]
Message-ID: <20260805072050.779E21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805071152.1225416-8-mallesh.koujalagi@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The example `cold-reset.sh` script fails to find native PCIe hotplug (pciehp) slots for directly attached devices because it initializes its topology traversal with the parent directory of the device, skipping the device's own PCI address which is what actually matches the hotplug slot's `address` attribute.
--

--- Patch [2]: [PATCH v13 2/4] drm/doc: Document DRM_WEDGE_RECOVERY_COLD_RESET recovery method ---
commit ae4802bfe15243552790a2e115f55653f35d380a
Author: Mallesh Koujalagi <mallesh.koujalagi@intel.com>

drm/doc: Document DRM_WEDGE_RECOVERY_COLD_RESET recovery method

This commit adds documentation for the WEDGED=cold-reset recovery method
in the DRM subsystem. It explains the consumer expectations and provides
an example udev rule alongside a recovery script for cycling PCIe slot power.

> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 93df92c4ac8cf..52255247a6db9 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
[ ... ]
> +Example - cold-reset
> +--------------------
> +
> +Udev rule::
> +
> +    SUBSYSTEM=="drm", ENV{WEDGED}=="cold-reset", DEVPATH=="*/drm/card[0-9]", \
> +    RUN+="/path/to/cold-reset.sh $env{DEVPATH}"
> +
> +Recovery script::
[ ... ]
> +    dev=$(basename "$syspath")
> +    [ -e "$PCI_DEVS/$dev" ] || die "not a PCI device: $dev"
> +    echo "device : $dev"
> +
> +    slot=""
> +    walk=$(dirname "$(readlink -f "$PCI_DEVS/$dev")")

[Severity: Medium]
Does this topology traversal intentionally skip the device's own PCI address?

By initializing walk with the parent directory via dirname, it appears the
script will miss the device itself when checking for matching hotplug slot
addresses in the loop below. This seems like it could cause the script to fail
to find native PCIe hotplug slots for directly attached devices, leading to a
"no hotplug slot with power control found" error when users try to run it.

> +
> +    while true; do
> +        ancestor=$(basename "$walk")
> +        case "$ancestor" in pci*) break ;; esac  # reached the virtual bus root
> +
> +        ancestor_nofn=${ancestor%.*}  # strip function: 0000:03:01.0 -> 0000:03:01
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805071152.1225416-6-mallesh.koujalagi@intel.com?part=2

  reply	other threads:[~2026-08-05  7:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  7:11 [PATCH v13 0/4] Introduce cold reset recovery method Mallesh Koujalagi
2026-08-05  7:11 ` [PATCH v13 1/4] drm: Add DRM_WEDGE_RECOVERY_COLD_RESET " Mallesh Koujalagi
2026-08-05  7:19   ` sashiko-bot
2026-08-05  7:11 ` [PATCH v13 2/4] drm/doc: Document " Mallesh Koujalagi
2026-08-05  7:20   ` sashiko-bot [this message]
2026-08-05  7:11 ` [PATCH v13 3/4] drm/xe: Handle PUNIT errors by requesting cold-reset recovery Mallesh Koujalagi
2026-08-05  7:30   ` sashiko-bot
2026-08-05  7:11 ` [PATCH v13 4/4] drm/xe/ras: Use fault-inject to trigger cold-reset wedge Mallesh Koujalagi
2026-08-05  7:24   ` sashiko-bot
2026-08-05  9:13   ` Raag Jadav
2026-08-05 10:01     ` Mallesh, Koujalagi
2026-08-05 11:50 ` ✓ CI.KUnit: success for Introduce cold reset recovery method (rev13) Patchwork
2026-08-05 12:31 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-05 22:59 ` ✗ Xe.CI.FULL: " Patchwork
2026-08-06 16:41 ` ✓ CI.KUnit: success for Introduce cold reset recovery method (rev14) Patchwork
2026-08-06 17:22 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-07  5:53 ` ✗ Xe.CI.FULL: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260805072050.779E21F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mallesh.koujalagi@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.