aboutsummaryrefslogtreecommitdiff
path: root/sys/dev
diff options
context:
space:
mode:
authorBjoern A. Zeeb <bz@FreeBSD.org>2026-06-01 23:59:01 +0000
committerBjoern A. Zeeb <bz@FreeBSD.org>2026-07-13 14:58:23 +0000
commit66b25ddf9125b2f3707e0f22b01b47bdff463fa7 (patch)
tree26ce9e2b85e92d43e19c9cab3cc0af15d94600ee /sys/dev
parentf9a37065b6948831f62a33fd0c68c96985b01a41 (diff)
LinuxKPI: pci detach: implement a proper detach (release) path
There are two paths in the LinuxKPI PCI code to instantiate a "pdev" (LinuxKPI pci_dev). One is using the FreeBSD bus framework and the pdev will be the softc. This commit starts cleaning up the detach path for just that case to the best possible. So far we did a lot of the work in linux_pci_detach_device(), which is the internal handler of the detach function and little in the (*release) callback (devres cleanup only). The problem with that is, that we tear down resources which later in the devres cleanup are needed. With them not being there anymore we panic, e.g., in lkpi_dma_unmap < lkpi_dmam_free_coherent < lkpi_devres_release_free_list. The solution is to migrate most of the cleanup work into the (*release) callback, which will automatically be called when the device (kobj) reference drops to zero. The only work which should be done immediately is to let the dirver do its cleanup; this has to happen before we try to teardown the resources, but also we do want this to happen when detach is called (the first time). One problem we have with the deferred cleanup of the remaining parts is that we do not know upon calling pci_dev_put() whether this cleared the last reference and triggered the cleanup or not but we cannot return from the detach function with pending resources and dangling pointers, which then may be used. In order to work around this, we clear the (*release) callback function when it is run and check for that in the detach routine. If the (*release) callback was not run, we refuse to detach (force would be needed) as we'd rather keep the device than risk a follow-up panic on leaked resources. Given this should not happen in a well programmed world, I believe it is fine to take that and log it to let the user know. Try to leave a few comments behind to help with understanding in the future. With this we can unload the mt7921 driver (or shutdown the system) without panic. Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: dumbbell Differential Revision: https://reviews.freebsd.org/D57429
Diffstat (limited to 'sys/dev')
0 files changed, 0 insertions, 0 deletions