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

["Tantilov, Emil S" <emil.s.tantilov@intel.com>]

On 9/20/2026 8:27 PM, Tian Xun Ng wrote:
> 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.

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.

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

OK, that makes more sense. I was curious if you are actually seeing an 
issue in your testing.

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

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.

> 
> Thanks for the review.
> 

Thanks,
Emil