diff options
author | David Herrmann <dh.herrmann@googlemail.com> | 2012-01-07 15:47:14 +0100 |
---|---|---|
committer | Johan Hedberg <johan.hedberg@intel.com> | 2012-02-13 16:01:23 +0100 |
commit | bf18c7118cf83ad4b9aa476354b4a06bcb9d0c4f (patch) | |
tree | c9a0de3c8bf6c6288fee5a0178dfde4c19a16c1e /drivers/regulator/tps6105x-regulator.c | |
parent | Bluetooth: dtl1-cs: Remove empty destruct cb (diff) | |
download | linux-bf18c7118cf83ad4b9aa476354b4a06bcb9d0c4f.tar.xz linux-bf18c7118cf83ad4b9aa476354b4a06bcb9d0c4f.zip |
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 'drivers/regulator/tps6105x-regulator.c')
0 files changed, 0 insertions, 0 deletions