Re: [PATCH iwl-net 1/2] idpf: keep the mailbox up while tearing down vports on shutdown

On 9/21/2026 2:06 PM, Tantilov, Emil S wrote:

In that case wouldn't just the reset on shutdown be sufficient? The FW
should clear the resources on reset, which should take care of the stale
vports.

Sorry for the slow reply; I wanted data before answering. On these
devices it is not sufficient.

Same arm64 hosts with two idpf PFs, IOMMU translating so every stray
write is blocked and logged as an F_TRANSLATION fault, warm reboot in a
loop, counting boots with idpf faults (always ~19 s in, at the first
queue reconfiguration):

  shutdown as in net-queue (mailbox shut first, no reset):    10 of 10
  same + PF reset after idpf_vc_core_deinit():                 2 of 2
  same + PF reset, then poll PFGEN_RSTAT for completion:       10 of 10
  teardown messages delivered, no reset (IDPF_REMOVE_IN_PROG
  set in idpf_shutdown(), the effect of this patch):           0 of 100

In the third case the serial console shows the reset happening:
PFR_STATE goes from 0x2 to 0x1 within the poll on both functions, and
reading the register mid-reset raises a TLP error on the function, so
the reset is not being lost to the reboot. The device still has the
previous kernel's queues afterwards. The reset the next kernel does at
probe (IDPF_HR_DRV_LOAD) does not clear them either; only the
disable/destroy messages do.

Is a PF reset expected to drop the vport and queue configuration on
your parts? If it is, this looks like a device firmware issue on our
side and I will raise it with the vendor. Either way the driver cannot
rely on it here.

If there is some clean way to shortcut the MBX on shutdown then I guess
it would be acceptable, but I don't know what a "safe" timeout would be.
As you can see the timeouts are already quite long, so you could
potentially still bail out on a working CP that just so happens to be
busy on the replies.

Also, consider the case where a reset on the PF will kill the MBX for
the VFs associated with it, so a shutdown on such a VF will always end
up timing out, since the VF reset is a message to the FW.

Understood. Given the above, some mailbox traffic on shutdown seems
unavoidable if the stale queues are to go away. What I would propose for
v2:

  - keep the vport teardown on shutdown, but give those transactions
    a short shutdown-only timeout, and stop at the first timeout
    instead of waiting on every remaining message, so a dead CP costs
    one timeout rather than several minutes;
  - skip it on a VF, where the PF/CP owns the VF's resources and the
    mailbox may already be gone;
  - drop idpf_is_reset_detected() as you suggested, and drop patch 2.

A busy CP that misses the short timeout leaves us where net-queue is
today, which is no worse than now. Would that be acceptable?

Thanks,
Tian Xun