Re: [PATCH net v6 0/2] enic: retain admin DMA resources and identify V2 VFs

[Satish Kharat <satishkh@cisco.com>]

Thanks for the review.

For patch 1, I am keeping the conservative surprise-removal behavior.
An all-ones MMIO read or PCI disconnect state establishes that the queue
register is no longer readable, but it does not provide the queue-stop
proof used by this patch for previously issued DMA. The driver therefore
releases the admin graph only after directly observing RUNNING == 0. If
surprise removal makes that observation impossible, the graph and PCI
reservation can remain retained until reboot. V7 will state this
limitation more clearly; the code is unchanged.

The reset-worker source comments in V6 already describe both outcomes:
resources are released only after both queues report stopped; otherwise
the channel is quarantined and the reset is abandoned.

The failed internal 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 in a separate datapath lifecycle fix
rather than add a partial fix here.

For patch 2, the code implements the deployed identity contract, but the
V6 wording incorrectly described it. Firmware vf_index and mailbox
src_vnic_id use 0xffff for the PF and zero-based values for VFs. Hardware
CQ sender metadata uses 0 for the PF and vf_index + 1 for a VF; receive
handling converts that value to the corresponding mailbox source ID. V7
will correct the cover letter and commit message.

The 0xffff PF mailbox source is intentional and matches the deployed
protocol; V7 will document the change from the previous zero-filled
field. V7 will also document that READ_ONCE() and dma_rmb() order the
common DEVCMD2 result path before device-written result fields are read.

V7 changes public text only. Its code and stable patch IDs are identical
to V6. I will post V7 shortly.

pw-bot: cr