Claude review: PCI: add driver flag to opt into disabling SR-IOV on remove()

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

This is the linchpin of the series. The design is well thought out.

**`pci_iov_disable()` logic** is correct: short-circuit evaluation in `if (!dev->is_physfn || !iov->num_VFs || !drv->managed_sriov)` protects against dereferencing `iov` when `dev->sriov` is actually the `physfn` union member on VF devices.

**Ordering change in `pci_device_remove()`** is necessary and correct:

```c
+	pci_iov_disable(pci_dev);
 	if (drv->remove) {
 		...
 	}
 	pcibios_free_irq(pci_dev);
-	pci_dev->driver = NULL;
 	pci_iov_remove(pci_dev);
+	pci_dev->driver = NULL;
```

`pci_iov_remove()` now needs `dev->driver` to check `managed_sriov`, so the `driver = NULL` assignment must move after it. This is safe since the driver pointer was already valid during the preceding `drv->remove()` call.

**`pci_iov_remove()` behavior change**: For non-`managed_sriov` drivers, behavior is preserved (warn and return). For `managed_sriov` drivers, the `WARN_ON(iov->num_VFs)` + `sriov_disable()` at the end catches broken drivers that re-enable SR-IOV during `remove()`. Good defensive coding.

**Minor**: The `WARN_ON(!drv)` checks added to both functions are a good defensive addition, though if `drv` were ever NULL at this point there would be larger problems.

---
Generated by Claude Code Patch Reviewer