Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Julia Filipchuk <julia.filipchuk@intel.com>,
	<intel-xe@lists.freedesktop.org>
Cc: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com>
Subject: Re: [PATCH 2/3] drm/xe/pxp: Remove incorrect handling of impossible state during suspend
Date: Mon, 23 Feb 2026 14:48:16 -0800	[thread overview]
Message-ID: <5f2408f2-55dd-4c9b-a86a-73af08c81fdf@intel.com> (raw)
In-Reply-To: <9a612289-7c41-4d19-8095-59348ed107c5@intel.com>



On 2/23/2026 2:42 PM, Julia Filipchuk wrote:
> On 2/18/2026 4:26 PM, Daniele Ceraolo Spurio wrote:
>> The default case of the PXP suspend switch is incorrectly exiting
>> without releasing the lock. However, this case is impossible to hit
>> because we're switching on an enum and all the valid enum values have
>> their own cases. Therefore, we can just get rid of the default case
>> and rely on the compiler to warn us if a new enum value is added and
>> we forget to add it to the switch.
> I understand the reasoning but prefer just adding a 'mutex_unlock(&pxp->mutex);'
> to keep the check. The case for XE_PXP_START_IN_PROGRESS does this before goto.

Which check are you referring to? it's impossible for that code to ever 
be executed, so keeping it doesn't actually change anything at runtime.

>
> There is a similar pattern in pxp_start that correctly releases the mutex on
> cleanup. Any reason to remove it too?

Yeah we can remove that one as well, but it should be done separately 
since it's not a fix.

>
>


  reply	other threads:[~2026-02-23 22:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-19  0:26 [PATCH 0/3] drm/xe: PXP fixes Daniele Ceraolo Spurio
2026-02-19  0:26 ` [PATCH 1/3] drm/xe/pxp: Clean up termination status on failure Daniele Ceraolo Spurio
2026-02-23 22:14   ` Julia Filipchuk
2026-02-23 22:29     ` Daniele Ceraolo Spurio
2026-02-23 23:51       ` Julia Filipchuk
2026-02-19  0:26 ` [PATCH 2/3] drm/xe/pxp: Remove incorrect handling of impossible state during suspend Daniele Ceraolo Spurio
2026-02-23 22:42   ` Julia Filipchuk
2026-02-23 22:48     ` Daniele Ceraolo Spurio [this message]
2026-02-23 23:54       ` Julia Filipchuk
2026-02-19  0:26 ` [PATCH 3/3] drm/xe/pxp: Do a PXP termination before suspend entry Daniele Ceraolo Spurio
2026-02-23 23:50   ` Julia Filipchuk
2026-02-25 22:42   ` Daniele Ceraolo Spurio
2026-02-19  1:22 ` ✓ CI.KUnit: success for drm/xe: PXP fixes Patchwork
2026-02-19  1:57 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-19  2:56 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-02-19 11:46 ` 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=5f2408f2-55dd-4c9b-a86a-73af08c81fdf@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=alan.previn.teres.alexis@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=julia.filipchuk@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox