- 13 Feb, 2012 40 commits
-
-
Johan Hedberg authored
This allows for other uses such as checking for an embedded class of device value in order to decide whether to append the class or not. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This patch add a two byte eir_len parameter mgmt_ev_device_found. Since it's unlikely that the data will in the short term be much bigger than conventional EIR lengths just use a small stack based buffer for now to avoid dynamic memory allocation & freeing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
User space uses device_(dis)connected instead of just (dis)connected so rename the defines and functions to match this. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
There are several other dev_flags besided HCI_MGMT that should not be cleared upon reset. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Andre Guedes authored
Devices found during LE scan should be reported to userspace through mgmt_device_found events. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Andre Guedes authored
This patch adds a new parameter to mgmt_device_found() to inform the length of 'eir' pointer. EIR data from LE advertising report event doesn't have a fixed length as EIR data from extended inquiry result event does. We needed to change mgmt_device_found() so it copies 'eir_len' bytes instead of HCI_MAX_EIR_LENGTH. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Andrei Emeltchenko authored
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Andrei Emeltchenko authored
Remove unneeded conversion from sk to chan. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Szymon Janc authored
Reference counter was incremented when starting ack timer but decremented only when clearing timer, not when timer fired. Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Szymon Janc authored
There is no need to send RNR immediately when entring local busy. Also upper layer might clear local busy condition before ack timer expires saving few cycles for sending RNR. This also prevents sending two RNRs in some cases where sending one would be enough i.e received N I-frame can trigger local busy (sending RNR acking up to N-1 I-frame) and later sending ack (RNR acking up to N I-frame). This was affecting TC_ERM_BV_07_C and TC_ERM_BV_22_C with some non default channel parameters (tx window and receiving buffer sizes). Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Szymon Janc authored
ack_timer should be cleared when sending ACK to avoid acking I-frames twice. This commit introduces helper function (only send ack, not clearing timer) which is used by l2cap_send_ack and l2cap_ack_timeout. This is to avoid clearing ack timer in timer function. Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Szymon Janc authored
SREJ frame with P-bit set acknowledges I-frames numbered up to (ReqSeq - 1). With this patch P-bit in SREJ is set only when there are some I-frames to ack. This fixes ambiguous situation when lost of I-frame with TxSeq=0 would result in sending SREJ acking all previous I-frames. Consider following scenario: TxWindow=3 HostA: sent I-frame TxSeq=0 HostA: sent I-frame TxSeq=1 HostA: sent I-frame TxSeq=2 HostB: missed I-frame TxSeq=0 HostB: received I-frame TxSeq=1 HostB: sent SREJ ReqSeq=0 Pbit=1 HostA: received SREJ ReqSeq=0 Pbit=1 <- All I-frames acked or not? ... Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Szymon Janc authored
This is usefull when need to make action after timer was cleared depending on if it was running or not. Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Fabio Estevam authored
Fix the following build warning: CC [M] net/bluetooth/hci_core.o net/bluetooth/hci_core.c: In function ‘__check_enable_hs’: net/bluetooth/hci_core.c:2587: warning: return from incompatible pointer type module_param in hci_core.c passes 'enable_hs' as bool format, so fix this variable definition type. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Johan Hedberg authored
This patch makes sure that devices with stronger signal (RSSI closer to 0) are sorted first in the resolve list and will therefore get their names resolved first during device discovery. Since it's more likely that the device the user is trying to discover has a strong signal due to its proximity this ensures that the user gets the "device found" event for it more quickly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The HCI_MGMT flag should not be cleared when resetting a HCI device. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
There's no point in exposing these to user-space (which is what happens to everything in hdev->flags) so move them to dev_flags instead. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
As reported by Dan Carpenter this function causes a Sparse warning and shouldn't be declared inline: include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a definition" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
David Herrmann authored
Since we remove the owner field of hci_dev hci_dev_put and __hci_dev_put do the same so we can merge them into one function. Same for hci_dev_hold and __hci_dev_hold. 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>
-
David Herrmann authored
The hci_dev->dev device structure has an internal refcount. This refcount is used to protect the whole hci_dev object. However, we currently do not use it. Therefore, if someone calls hci_free_dev() we currently immediately destroy the hci_dev object because we never took the device refcount. This even happens if the hci_dev->refcnt is not 0. In fact, the hci_dev->refcnt is totally useless in its current state. Therefore, we simply remove hci_dev->refcnt and instead use hci_dev->dev refcnt. This fixes all the symptoms and also correctly integrates the device structure into our bluetooth bus system. 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>
-
David Herrmann authored
After unregistering an hci_dev object a bluetooth driver does not have any callbacks in the hci_dev structure left over. Therefore, there is no need to keep a reference to the module. Previously, we needed this to protect the hci-destruct callback. However, this callback is no longer available so we do not need this owner field, anymore. Drivers now call hci_unregister_dev() and they are done with the object. 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>
-
David Herrmann authored
We provide a device-object to other subsystems and we provide our own release-function. Therefore, the device-object must own a reference to our module, otherwise the release-function may get deleted before the device-object does. 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>
-
David Herrmann authored
The hci-destruct callback is not used by any driver so we can remove it. There is no reason to keep it alive, anymore. Drivers can free their internal data on driver-release and we do not need to provide a public destruct callback. Internally, we still use a destruct callback inside of hci_sysfs.c. This one is used to correctly free our hci_dev data structure if no more users have a reference to it. 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>
-
David Herrmann authored
We currently leak the hci_uart object if HCI_UART_PROTO_SET is never set because the hci-destruct callback will then never be called. This fix removes the hci-destruct callback and frees the driver internal private hci_uart object directly on tty-close. We call hci_unregister_dev() here so the hci-core will never call our callbacks again (except destruct). Therefore, we can safely free the driver internal data right away and set the destruct callback to NULL. 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>
-
David Herrmann authored
Instead of waiting for the hdev object to get freed we now free the private driver-internal data on SDIO shutdown. This allows us to remove the obsolete hci-destruct callback and free our data object right away after calling hci_unregister_dev(). The HCI-core does not call any callbacks after this so we are never called again and can safely exit the module. 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>
-
David Herrmann authored
Instead of waiting for the hci-device to be destroyed we now free the private driver data on driver shutdown right away. We call hci_unregister_dev() on driver shutdown, that means, the hci-core will never ever call our callbacks again except the destruct callback. It also does not access hdev->driver_data so there is no reason to keep that alive. We simply set the destruct cb to NULL to avoid getting called again. 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>
-
David Herrmann authored
Instead of using the hci-destruct callback we free our private driver data on USB shutdown. We already called hci_unregister_dev() here so the hci core will never ever call our callbacks again except the destruct callback. However, there is no reason to keep our *private* driver data alive if we get never called again and the hci-core does never touch it the data. So we simply free it right away and set the destruct callback to NULL. 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>
-
David Herrmann authored
This frees the private driver data on USB shutdown instead of using the hci-destruct callback. We already call usb_set_intfdata(intf, NULL) but we do not do the same with the hci object. This would be totally safe, though. After calling hci_unregister_dev()/hci_free_dev() the hdev object will never call any callback of us again except the destruct callback. Therefore, we can safely set the destruct callback to NULL and free the driver data right away. This allows to unload the module without waiting for the hdev device to be released. 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>
-
David Herrmann authored
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>
-
David Herrmann authored
The destruct cb is optional so we can safely remove our dummy cb. 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>
-
David Herrmann authored
The destruct cb is optional so remove our empty dummy cb. 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>
-
David Herrmann authored
The destruct callback is optional and we provide an empty callback so remove it. 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>
-
David Herrmann authored
The callback is optional and we provide an empty callback so remove it entirely. 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>
-
David Herrmann authored
The callback is optional and we provide an empty callback so remove it. 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>
-
David Herrmann authored
The destruct callback is optional and we provide an empty callback so remove it entirely to avoid unnecessary code. 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>
-
David Herrmann authored
Several drivers already provide an empty callback so we can actually make this optional and then remove all those empty callbacks in the drivers. This callback isn't needed at all by most drivers as they can remove their allocated structures on device disconnect and not on hci destruction. 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>
-
David Herrmann authored
We currently leak the driver info structure if dtl1_config fails. If we add a kfree() to dtl1_release to fix this, then dtl1_release and dtl1_detach are identical so this merges both functions. 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>
-
David Herrmann authored
The uart_proto open() callback is not called in atomic context so we can safely sleep here. The caller hci_uart_set_proto() in hci_ldisc.c is an ioctl-handler and therefore can sleep. 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>
-
David Herrmann authored
The uart_proto open() callback is not called in atomic context so we can safely sleep here. The caller hci_uart_set_proto() in hci_ldisc.c is an ioctl-handler and therefore can sleep. 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>
-
David Herrmann authored
The uart_proto open() callback is not called in atomic context so we can safely sleep here. The caller hci_uart_set_proto() in hci_ldisc.c is an ioctl-handler and therefore can sleep. 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>
-