I don't know from where the notion that device driver should or

even could call VOP_REVOKE() on vnodes associated with its dev_t's
has originated, but it stops right here.

If there are things people belive destroy_dev() needs to learn how to
do, please tell me about it, preferably with a reproducible test case.

Include <sys/uio.h> in bluetooth code rather than rely on <sys/vnode.h>
to do so.

The fact that some of the USB code needs to include <sys/vnode.h>
still disturbs me greatly, but I do not have time to chase that.

1 files changed, 0 insertions, 5 deletions

diff --git a/sys/dev/usb/ums.c b/sys/dev/usb/ums.c
index 72240bf6b575..d3acf92e514a 100644
--- a/sys/dev/usb/ums.c
+++ b/sys/dev/usb/ums.c
@@ -367,7 +367,6 @@ Static int
 ums_detach(device_t self)
 {
 	struct ums_softc *sc = device_get_softc(self);
-	struct vnode *vp;
 
 	if (sc->sc_enabled)
 		ums_disable(sc);
@@ -377,10 +376,6 @@ ums_detach(device_t self)
 	free(sc->sc_loc_btn, M_USB);
 	free(sc->sc_ibuf, M_USB);
 
-	vp = SLIST_FIRST(&sc->dev->si_hlist);
-	if (vp)
-		VOP_REVOKE(vp, REVOKEALL);
-
 	/* someone waiting for data */
 	/*
 	 * XXX If we wakeup the process here, the device will be gone by