From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: PCI: add driver flag to opt into disabling SR-IOV on remove() Date: Wed, 04 Mar 2026 08:40:15 +1000 Message-ID: In-Reply-To: <20260303-rust-pci-sriov-v3-1-4443c35f0c88@redhat.com> References: <20260303-rust-pci-sriov-v3-0-4443c35f0c88@redhat.com> <20260303-rust-pci-sriov-v3-1-4443c35f0c88@redhat.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 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