- 18 Mar, 2013 22 commits
-
-
Johan Hedberg authored
When the connectable setting is disabled the fast connectable setting must also be disabled. This is so that we're consistent with the pre-requisites for enabling fast connectable, one of which is that the connectable setting is enabled. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Johan Hedberg authored
This patch refactors the fast connectable HCI commands into their own HCI function. This is necessary so that the same function can be reused fo the fast connectable change required by disabling the connectable setting. Signed-off-by:
-
Johan Hedberg authored
In order to be able to represent fast connectable mode in the mgmt settings we need to have a HCI dev flag for it. This patch adds the flag and makes sure its value is changed whenever a mgmt_set_fast_connectable command completes. Signed-off-by:
-
Johan Hedberg authored
If there's another pending mgmt_set_fast_connectable command we should return a "busy" error response. Signed-off-by:
-
Johan Hedberg authored
The HCI commands that are necessary for fast connectable mode are only available from HCI specification version 1.2 onwards. This should be reflected in the supported settings as well as error response for the set_fast_connectable command when dealing with a < 1.2 capable controller. Signed-off-by:
-
Johan Hedberg authored
The mgmt_set_fast_connectable response should be sent only when all related HCI commands have completed. This patch fixes the issue by using an async request and sending the response to user space throught the complete callback of the request. The patch also fixes in the same go the return parameters of the command which should be the current settings. Signed-off-by:
-
Johan Hedberg authored
This patch changes the mgmt_set_connectable handler to use an async request for sending the required HCI command. This is necessary preparation for handling the fast connectable change that needs to be associated with disabling the connectable setting. Signed-off-by:
-
Johan Hedberg authored
If user space attempts to set the local name to the same value that's already set we should simply return a direct command complete for this mgmt command. Signed-off-by:
-
Johan Hedberg authored
This patch fixes the mgmt_set_local_name command to send the appropriate HCI commands based on BR/EDR support and LE support. Local name and EIR data should only be sent for BR/EDR capable controllers whereas an update to the AD should only happen for LE capable controllers. Signed-off-by:
-
Johan Hedberg authored
For proper control of the AD update and the related HCI commands it's best to run the AD update through an async request instead of a standalone HCI command. This patch changes the hci_update_ad() function to take a request pointer and updates its users appropriately. E.g. the function is no longer called after the init sequence but during stage 3 of the init sequence. The TX power is read during the init sequence, so we don't need an explicit update whenever it is read and the AD update based on the local name should be done through the local name mgmt handler. The only other user is the update based on enabling advertising. This part is still kept as there is no mgmt API to enable it. Signed-off-by:
-
Johan Hedberg authored
We shouldn't respond to the mgmt_set_local_name command until all related HCI commands have completed. This patch fixes the issue by running the local name HCI command and the EIR update in the same asynchronous request, and returning the mgmt command complete through the complete callback of the request. The downside of this is that we must set hdev->dev_name before the local name HCI command has completed since otherwise the generated EIR command doesn't contain the new name. This means that we can no-longer reliably detect when the name has really changed and when not. Luckily this only affects scenarios where the mgmt interface is *not* used (e.g. hciconfig) so redundant mgmt_ev_local_name_changed events in these cases are an acceptable drawback. Signed-off-by:
-
Johan Hedberg authored
When powering off the device the hdev->flags and hdev->dev_flags need to be cleared before calling mgmt_powered(). If this is not done the resulting events sent to user space may contain incorrect values. Note that the HCI_AUTO_OFF flag accessed right after this is part of the persistent flags, so it's unchanged by the hdev->dev_flags reset. Signed-off-by:
-
Johan Hedberg authored
When hci_dev_do_close() is called we should make sure to clear all non-persistent flags in hci->dev_flags. Signed-off-by:
-
Johan Hedberg authored
We'll need to use this mask also when powering off the HCI device so it's better to have this in a single and visible place. Signed-off-by:
-
Johan Hedberg authored
Now that class related operations are tracked through asynchronous HCI requests this flag is no longer needed. Signed-off-by:
-
Johan Hedberg authored
We should only return a mgmt command complete once all HCI commands to a mgmt_set_dev_class or mgmt_add/remove_uuid command have completed. This patch fixes the issue by having a proper async request complete callback for these actions and responding to user space in the callback. Signed-off-by:
-
Johan Hedberg authored
The add/remove_uuid and set_dev_class mgmt commands can trigger both EIR and class HCI commands, so testing just for a pending class command is enough. The simplest way to monitor conflicts that should trigger "busy" error returns is to check for any pending mgmt command that can trigger these HCI commands. This patch adds a helper function for this (pending_eir_or_class) and uses it instead of the old HCI_PENDING_CLASS flag to test for busy conditions. Signed-off-by:
-
Johan Hedberg authored
We should only notify user space that the adapter has been powered on after all HCI commands related to the action have completed. This patch fixes the issue by instating an async request complete callback for these HCI commands and only notifies user space in the callback. Signed-off-by:
-
Johan Hedberg authored
This patch updates sending of HCI commands related to mgmt_set_powered (e.g. class, name and EIR data) to be sent using asynchronous requests. This is necessary since it's the only (well, at least the cleanest) way to keep the power on procedure synchronized and let user space know it has completed only when all HCI commands are completed (this actual fix is coming in a subsequent patch). Signed-off-by:
-
Johan Hedberg authored
These commands will in a subsequent patch be performed in their own asynchronous request, so it's more readable (not just from a resulting code perspective but also the way the patches look like) to have them performed in their own function. Signed-off-by:
-
Alexandru Gheorghiu authored
Replaced calls to kzalloc followed by memcpy with a single call to kmemdup. Signed-off-by:
Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by:
-
Alexandru Gheorghiu authored
Used PTR_RET function instead of IS_ERR and PTR_ERR. Patch found using coccinelle. Signed-off-by:
-
- 15 Mar, 2013 1 commit
-
-
Lubomir Rintel authored
The firmware images are shared with libertas_sdio WiFi chip and used to be in libertas/ subtree in linux-firmware. As btmrvl_sdio used to look into the linux-firmware root, it ended up being unsuccessful. Since the firmware files are not specific to the libertas hardware, they're being moved into mrvl/ now. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Acked-by:
-
- 09 Mar, 2013 7 commits
-
-
Johan Hedberg authored
The opcode in cmd_complete and cmd_status events is 16 bits, so we should only be comparing it after having converted it to the host endianness. There's already an opcode variable in both functions which is in host endiannes so the right fix is to just start using it instead of ev->opcode. Signed-off-by:
-
Andre Guedes authored
If req->err is set, there is no point in queueing the HCI command in HCI request command queue since it won't be sent anyway. Signed-off-by:
Andre Guedes <andre.guedes@openbossa.org> Acked-by:
-
Andre Guedes authored
Since no one checks the returning value of hci_req_add and HCI request errors are now handled in hci_req_run, we can make hci_ req_add returning void. Signed-off-by:
-
Andre Guedes authored
When we are building a HCI request with more than one HCI command and one of the hci_req_add calls fail, we should have some cleanup routine so the HCI commands already queued on HCI request can be deleted. Otherwise, we will face some memory leaks issues. This patch implements the HCI request error handling which is the following: If a hci_req_add fails, we save the error code in hci_ request. Once hci_req_run is called, we verify the error field. If it is different from zero, we delete all HCI commands already queued and return the error code. Signed-off-by:
-
Andre Guedes authored
Since hci_req_run will be returning more than one error code, we should check its returning value in __hci_req_sync. Signed-off-by:
-
Andre Guedes authored
In case the HCI request queue is empty, hci_req_run should return ENODATA instead of EINVAL. This way, hci_req_run returns a more meaningful error value. Signed-off-by:
-
Andre Guedes authored
If hci_req_run returns error, we erroneously leave the current process in TASK_INTERRUPTABLE state. If we leave the process in TASK_INTERRUPTABLE and it is preempted, this process will never be scheduled again. This patch fixes this issue by moving the preparation for scheduling (add to waitqueue and set process state) to just after the hci_req_run call. Signed-off-by:
-
- 08 Mar, 2013 10 commits
-
-
Johan Hedberg authored
With the removal of hci_req_complete() several HCI event handlers have essentially become empty and can be removed. The only potential benefit of these could have been logging, but the hci_event, hci_cmd_complete and hci_cmd_status already provide a log for events which they do not have an explicit handler for. Signed-off-by:
-
Johan Hedberg authored
This variable is no longer needed (due to async HCI request support and the conversion of hci_req_sync to use it), so it can be safely removed. Signed-off-by:
-
Johan Hedberg authored
This patch converts the hci_req_sync() procedure to internaly use the asynchronous HCI requests. The hci_req_sync mechanism relies on hci_req_complete() calls from hci_event.c into hci_core.c whenever a HCI command completes. This is very similar to what asynchronous requests do and makes the conversion fairly straight forward by converting hci_req_complete into a request complete callback. By this change hci_req_complete (renamed to hci_req_sync_complete) becomes private to hci_core.c and all calls to it can be removed from hci_event.c. The commands in each hci_req_sync procedure are collected into their own request by passing the hci_request pointer to the request callback (instead of the hci_dev pointer). The one slight exception is the HCI init request which has the special handling of HCI driver specific initialization commands. These commands are run in their own request prior to the "main" init request. One other extra change that this patch must contain is the handling of spontaneous HCI reset complete events that some controllers exhibit. These were previously handled in the hci_req_complete function but the right place for them now becomes the hci_req_cmd_complete function. Signed-off-by:
-
Johan Hedberg authored
This patch introduces functions to process the HCI request state when receiving HCI Command Status or Command Complete events. Some HCI commands, like Inquiry do not result in a Command complete event so special handling is needed for them. Inquiry is a particularly important one since it is the only forseeable "non-cmd_complete" command that will make good use of the request functionality, and its completion is either indicated by an Inquiry Complete event of a successful Command Complete for HCI_Inquiry_Cancel. Signed-off-by:
-
Johan Hedberg authored
To have a consistent content for hdev->cmd_q all entries need to follow the semantics of asynchronous HCI requests. This means that even single commands need to be dressed as requests by having a request start indicator. This patch adds these indicators to the two places needing it (hci_send_cmd and hci_sock_sendmsg). Signed-off-by:
-
Johan Hedberg authored
This function is analogous to hci_send_cmd() but instead of directly queuing the command to hdev->cmd_q it adds it to the local queue of the asynchronous HCI request being build (inside struct hci_request). This is the main function used for building asynchronous requests and there should be one or more calls to it between calls to hci_req_init and hci_req_run. Signed-off-by:
-
Johan Hedberg authored
This patch moves out the skb creation from hci_send_cmd() into its own prepare_cmd() function. This is essential so the same prepare_cmd() function can be easily reused for skb creation for asynchronous HCI requests. Signed-off-by:
-
Johan Hedberg authored
This patch adds the initial definitions and functions for asynchronous HCI requests. Asynchronous requests are essentially a group of HCI commands together with an optional completion callback. The request is tracked through the already existing command queue by having the necessary context information as part of the control buffer of each skb. The only information needed in the skb control buffer is a flag for indicating that the skb is the start of a request as well as the optional complete callback that should be used when the request is complete (this will be found in the last skb of the request). Signed-off-by:
-
Johan Hedberg authored
Having conditional command sending during a request has always been problematic and caused hacks like the hdev->init_last_cmd variable. This patch removes these conditionals and instead splits the init sequence into three stages, each with its own __hci_req_sync() call. This also paves the way to the upcoming asynchronous request support swhich will also benefit by having a simpler implementation if it doesn't need to cater for requests that change on the fly. Signed-off-by:
-
Johan Hedberg authored
If a request callback doesn't send any commands __hci_req_sync() should fail imediately instead of waiting for the inevitable timeout to occur. This is particularly important once we start creating requests with conditional command sending which can potentially result in no commands being sent at all. Signed-off-by:
-
