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 10/6/2026 3:56 AM, Tian Xun Ng wrote:
> 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.

No worries, thanks for following up.

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

I think this change is warranted - setting IDPF_REMOVE_IN_PROG in 
idpf_shutdown(). We just need to figure out a way to bail early on 
unresponsive FW. For the moment I think it will be OK if we prioritize 
the working case and make sure a shutdown is handled properly.

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

In general yes, a reset is expected to provide a clean slate for the 
driver. This is why the driver issues a reset on load. Even if we make 
the shutdown logic flawless there is no guarantee that it will actually 
run. In some cases like a system hang, we'd still end up being reliant 
on the reset clearing the state.

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

Agreed, this seems like a decent approach.

Thanks,
Emil
> 
> Thanks,
> Tian Xun