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

[Tian Xun Ng <luckilystar08@gmail.com>]

On 9/18/2026, Tantilov, Emil S wrote:
> Actually we can't wait on shutdown. If the MBX is defunct, like CP is
> down or unresponsive, the shutdown will hang for a very long time. This
> is the reason why we wanted to avoid communication on shutdown. Have you
> tested the shutdown after stopping the control plane?

No, I have not, and I cannot on this platform: the control plane sits
behind the device and I have no way to stop it from the host. So I have
to take your point as given, and as written the patch is not acceptable:
each teardown transaction uses IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC (60 s),
and the teardown per vport is disable_vport, disable_queues (which also
waits for the SW marker) and destroy_vport. With a dead CP and two vports
that is minutes of hang on every reboot, to remove a fault that only
shows up on warm reboots. That trade is wrong.

What I would like to propose for v2 is to keep the teardown but bound it:
a shutdown-specific timeout, on the order of a second or two, used for
those three transactions when the driver is shutting down. If the CP
answers, the device is told to stop its queues and the stray writes go
away; if it does not, shutdown loses a bounded couple of seconds instead
of minutes. Does that direction look acceptable to you, and is there a
timeout value you would consider safe? If you would rather not have any
mailbox traffic on shutdown at all, then I think the fix has to come from
the device side instead, and I would rather know that before sending v2.

> This logic already exists in the reset handling, there should be no need
> to replicate it here. Do you have a trace and/or exact scenario that
> leads to remove being called while in a reset, but MBX is still alive?

No, I do not have such a trace. I added idpf_is_reset_detected() defensively
rather than from an observed case, and I will drop it in v2.

For the record, what we do see without any of this, on arm64 with two idpf
functions: after a warm reboot the device still has its queues enabled with
the previous kernel's ring addresses, and the first queue reconfiguration in
the next boot makes it write SW_MARKER completions into memory that kernel
has already reused. 20 of 20 warm reboots on an unpatched control node, none
in 151 with the teardown messages delivered.

Thanks for the review.