Re: [PATCH v3 23/23] drm/xe/pci: Report 'cannot re-enable' error using SIGID

["Mallesh, Koujalagi" <mallesh.koujalagi@intel.com>]

On 12-08-2026 02:53 pm, Michal Wajdeczko wrote:
>
> On 8/12/2026 8:58 AM, Mallesh, Koujalagi wrote:
>> On 30-07-2026 08:51 pm, Michal Wajdeczko wrote:
>>> Report 'cannot re-enable PCI device' error using xe_log() helper.
>>>
>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> Cc: Riana Tauro <riana.tauro@intel.com>
>>> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
>>> Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>>> ---
>>>    drivers/gpu/drm/xe/xe_pci_error.c | 7 +++++--
>>>    1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_pci_error.c b/drivers/gpu/drm/xe/xe_pci_error.c
>>> index e41af2ac7f23..fb965f52be5e 100644
>>> --- a/drivers/gpu/drm/xe/xe_pci_error.c
>>> +++ b/drivers/gpu/drm/xe/xe_pci_error.c
>>> @@ -7,6 +7,7 @@
>>>      #include "xe_device.h"
>>>    #include "xe_gt.h"
>>> +#include "xe_log.h"
>>>    #include "xe_pci.h"
>>>    #include "xe_pm.h"
>>>    #include "xe_printk.h"
>>> @@ -90,13 +91,15 @@ static pci_ers_result_t xe_pci_error_slot_reset(struct pci_dev *pdev)
>>>    {
>>>        const struct pci_device_id *ent = pci_match_id(pdev->driver->id_table, pdev);
>>>        struct xe_device *xe = pdev_to_xe_device(pdev);
>>> +    int err;
>>>          xe_info(xe, "PCI error: slot reset\n");
>> Please use xe_log_info.
> but do we care now?
Since it's showing PCI error message so up to you!
> it's info only and I guess we should prioritize to convert
> real errors into SIGID logs first
Agreed!
>>>          pci_restore_state(pdev);
>>>    -    if (pci_enable_device(pdev)) {
>>> -        xe_err(xe, "Cannot re-enable PCI device after reset\n");
>>> +    err = pci_enable_device(pdev);
>>> +    if (err) {
>>> +        xe_log_err_fatal(xe, PCI, err, "Cannot re-enable PCI device after reset\n");
>> PCI component used XE_SIGID_SW looks semantic mismatch, we can add DRIVER_HARDWARE with PCI
> but introduced in patch 3/23 component PCI represents the component
> that is beyond our Xe driver (part of the SYSTEM) as we don't manage
> that directly
>
> and since our SIGID choices are limited, the generic SIGID_SW is
> the most applicable IMO

hmm, I know, we've limited SIGID choice, PCI with SW sigid is broader 
scope however in this case PCI is initiating slot reset

if it's making sense we can use it right?
> if you disagree, please comment patch 3/23 as it is already
> reviewed
That was just my suggestion up to you!!
>> and make
>>
>> a PCIe link failure that required active recovery right?
> this code is already part of the HW error handling
> maybe we should (or there is) declare wedged
>
> but I don't want to make here any changes beyond simple
> conversion from xe_err() to xe_log_err()

hmm, ok

Thanks,

-/Mallesh

>> Thanks,
>>
>> -/Mallesh
>>
>>>            return PCI_ERS_RESULT_DISCONNECT;
>>>        }
>>>