Re: [PATCH v2] drm/xe/pcode: Convert unsupported commands to debug level

[Raag Jadav <raag.jadav@intel.com>]

On Wed, Nov 12, 2025 at 03:45:19PM +0100, Raag Jadav wrote:
> 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.

Forgot to add here before floating v3. This is no different from current
situation because we don't have a way to make sure that the changes are
tested on all possible versions of IFWI and since we like to force everyone
to upgrade (atleast internally), it is still possible that we hit some
corner case in the field.

Raag

> > 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.