From: Raag Jadav <raag.jadav@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
rodrigo.vivi@intel.com, intel-xe@lists.freedesktop.org,
riana.tauro@intel.com, matthew.brost@intel.com,
michal.wajdeczko@intel.com, badal.nilawar@intel.com
Subject: Re: [PATCH v2] drm/xe/pcode: Convert unsupported commands to debug level
Date: Wed, 12 Nov 2025 15:45:14 +0100 [thread overview]
Message-ID: <aRSdenIjmrfTaw8U@black.igk.intel.com> (raw)
In-Reply-To: <aQ3xItyGMVnKdzoi@intel.com>
On Fri, Nov 07, 2025 at 03:16:18PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 07, 2025 at 06:03:28AM -0600, Lucas De Marchi wrote:
> > On Fri, Nov 07, 2025 at 11:26:11AM +0530, Raag Jadav wrote:
> > > If the device is running older pcode firmware, it is possible that newer
> > > mailbox commands are not supported by it. The respective functionality
> > > isn't useful in that case but neither is error logging, since it doesn't
> > > particularly signify anything wrong with pcode firmware or device as a
> > > whole. This is useful in cases where we want to make a decision on driver
> > > functionality based on pcode return codes and a bit simpler design choice
> > > compared to other solutions like checking pcode firmware version, which
> > > comes with additional complexity of binding every single command to a
> > > specific version and deems pcode commands useless in case driver fails to
> > > obtain it for reasons unrelated to pcode.
> >
> > yeah.. I don't think we should regress the support in new kernel
> > versions and require users to update their IFWI. However dropping the
> > error message here also makes it harder to find cases in which we are
> > indeed using a wrong command.
> >
> > I'd say to decide on err vs dbg based on CONFIG_DRM_XE_DEBUG so
> > developers can still see the error and take the right action.
>
> I think the caller should decide this. If it's explicitly probing
> for something that may or may not exist then use dbg(), otherwise
> use err().
I like the idea. What I'm afraid is that once we open that door it'll
probably start getting abused.
So rather we can check if we're really *in* probe()? Wait for a v3.
Raag
next prev parent reply other threads:[~2025-11-12 14:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 5:56 [PATCH v2] drm/xe/pcode: Convert unsupported commands to debug level Raag Jadav
2025-11-07 6:05 ` ✓ CI.KUnit: success for " Patchwork
2025-11-07 6:42 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-07 11:43 ` [PATCH v2] " Lucas De Marchi
2025-11-07 11:56 ` Lucas De Marchi
2025-11-07 12:03 ` Lucas De Marchi
2025-11-07 13:16 ` Ville Syrjälä
2025-11-12 14:45 ` Raag Jadav [this message]
2025-11-14 5:25 ` Raag Jadav
2025-11-17 14:26 ` Gupta, Anshuman
2025-11-17 22:03 ` Rodrigo Vivi
2025-11-08 22:14 ` ✓ Xe.CI.Full: success for " 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=aRSdenIjmrfTaw8U@black.igk.intel.com \
--to=raag.jadav@intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=ville.syrjala@linux.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 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.