On 10/24/2025 12:21 AM, Jijie Shao wrote:
> 
> on 2025/10/24 9:05, Jacob Keller wrote:
>>
>> On 10/21/2025 7:00 AM, Jijie Shao wrote:
>>> current, driver will call netif_device_detach() in
>>> pci_error_handlers.error_detected() and do reset in
>>> pci_error_handlers.slot_reset().
>>> However, if pci_error_handlers.slot_reset() is not called
>>> after pci_error_handlers.error_detected(),
>>> driver will be detached and unable to recover.
>>>
>>> drivers/pci/pcie/err.c/report_error_detected() says:
>>>    If any device in the subtree does not have an error_detected
>>>    callback, PCI_ERS_RESULT_NO_AER_DRIVER prevents subsequent
>>>    error callbacks of any device in the subtree, and will
>>>    exit in the disconnected error state.
>>>
>>> Therefore, when the hibmcge device and other devices that do not
>>> support the error_detected callback are under the same subtree,
>>> hibmcge will be unable to do slot_reset.
>>>
>> Hmm.
>>
>> In the example case, the slot_reset never happens, but the PCI device is
>> still in an error state, which means that the device is not functional..
>>
>> In that case detaching the netdev and remaining detached seems like an
>> expected outcome?
>>
>> I guess I don't fully understand the setup in this scenario.
> 
> We have encountered some non-fatal errors, such as the SMMU event 0x10,
> which triggered the PCIe RAS and caused the network port to become unusable.
> 

Right. I forgot the same function is called even for non-fatal errors.