summaryrefslogtreecommitdiff
path: root/lib/bust_spinlocks.c
diff options
context:
space:
mode:
authorDavid Herrmann <dh.herrmann@googlemail.com>2012-01-07 18:47:14 +0400
committerJohan Hedberg <johan.hedberg@intel.com>2012-02-13 19:01:23 +0400
commitbf18c7118cf83ad4b9aa476354b4a06bcb9d0c4f (patch)
treec9a0de3c8bf6c6288fee5a0178dfde4c19a16c1e /lib/bust_spinlocks.c
parentaed014a02e809bd228a8ce7e7cc432ded9b72ef6 (diff)
downloadlinux-bf18c7118cf83ad4b9aa476354b4a06bcb9d0c4f.tar.xz
Bluetooth: vhci: Free driver_data on file release
This removes the hci-destruct callback and instead frees the private driver data in the vhci_release file release function. There is no reason to keep private driver data available if the driver has already shut down. After vhci_release is called our module can be unloaded. The only reason it is kept alive is the hci-core having a module-ref on us because of our destruct callback. However, this callback only frees hdev->driver_data. That is, we wait for the hdev-device to get destroyed to free our internal driver-data. In fact, the hci-core does never touch hdev->driver_data so it doesn't care if it is NULL. Therefore, we simply free it when unloading the driver. Another important fact is that the hdev core does not call any callbacks other than the destruct-cb after hci_unregister_dev() has been called. So there is no function of our module that will be called nor does the hci-core touch hdev->driver_data. Hence, no other code can touch hdev->driver_data after our cleanup so the destruct callback is definitely unnecessary here. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Diffstat (limited to 'lib/bust_spinlocks.c')
0 files changed, 0 insertions, 0 deletions