Re: [PATCH net v4 1/2] enic: retain admin-channel DMA until queues stop

[Satish Kharat <satishkh@cisco.com>]

Thanks for the review.

I agree that mbox_tx_poisoned does not represent an independent state in
this series. The field came from the follow-on SR-IOV mailbox-recovery
work, where a posted-send timeout must be distinguished while the admin
channel is still LIVE. In this two-patch fixes series, unresolved queue
ownership is already represented by admin_chan_state being QUARANTINED,
while mbox_send_disabled blocks new sends. V5 therefore removes
mbox_tx_poisoned. I will introduce that state with the follow-on recovery
patch that actually needs and consumes it.

I also agree that probe failure should make a final queue check after
ordinary teardown has had an opportunity to stop the queues. V5 runs
generic teardown and CMD_CLOSE before the final direct admin WQ/RQ
check in both probe unwind and removal. It releases the admin graph if
both queues have stopped and otherwise retains it.

I do not plan to treat an all-ones MMIO read or a recoverable PCI
channel-offline state as proof that DMA has stopped. Those observations
show that the queue registers are inaccessible, but do not establish
completion of previously issued DMA. V5 keeps the conservative
retention policy and documents it explicitly.

The failed-reset/reopen followed by a repeated datapath stop is a valid
pre-existing lifecycle issue. It is separate from admin DMA ownership,
so I will address it independently with fault injection at the
enic_open() failure points followed by administrative close and device
removal.

I have made these changes in V5 and will post the revision shortly.

pw-bot: cr