- 17 Apr, 2013 1 commit
-
-
David Herrmann authored
hci_conn_hold/put_device() is used to control when hci_conn->dev is no longer needed and can be deleted from the system. Lets first look how they are currently used throughout the code (excluding HIDP!). All code that uses hci_conn_hold_device() looks like this: ... hci_conn_hold_device(); hci_conn_add_sysfs(); ... On the other side, hci_conn_put_device() is exclusively used in hci_conn_del(). So, considering that hci_conn_del() must not be called twice (which would fail horribly), we know that hci_conn_put_device() is only called _once_ (which is in hci_conn_del()). On the other hand, hci_conn_add_sysfs() must not be called twice, either (it would call device_add twice, which breaks the device, see drivers/base/core.c). So we know that hci_conn_hold_device() is also called only once (it's only called directly before hci_conn_add_sysfs()). So hold and put are known to be called only once. That means we can safely remove them and directly call hci_conn_del_sysfs() in hci_conn_del(). But there is one issue left: HIDP also uses hci_conn_hold/put_device(). However, this case can be ignored and simply removed as it is totally broken. The issue is, the only thing HIDP delays with hci_conn_hold_device() is the removal of the hci_conn->dev from sysfs. But, the hci_conn device has no mechanism to get notified when its own parent (hci_dev) gets removed from sysfs. hci_dev_hold/put() does _not_ control when it is removed but only when the device object is created and destroyed. And hci_dev calls hci_conn_flush_*() when it removes itself from sysfs, which itself causes hci_conn_del() to be called, but it does _not_ cause hci_conn_del_sysfs() to be called, which is wrong. Hence, we fix it to call hci_conn_del_sysfs() in hci_conn_del(). This guarantees that a hci_conn object is removed from sysfs _before_ its parent hci_dev is removed. The changes to HIDP look scary, wrong and broken. However, if you look at the HIDP session management, you will notice they're already broken in the exact _same_ way (ever tried "unplugging" HIDP devices? Breaks _all_ the time). So this patch only makes HIDP look _scary_ and _obviously broken_. It does not break HIDP itself, it already is! See later patches in this series which fix HIDP to use proper session-management. Signed-off-by:David Herrmann <dh.herrmann@gmail.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 11 Apr, 2013 7 commits
-
-
Claudio Takahasi authored
This patch sends Reject Synchronous Connection Request Command when hci_conn_timeout is triggered, and the SCO connection is in BT_CONNECT2 state. It prevents inconsistency if the remote host doesn't implement properly the timeout for the connection request, and it removes the connection reference left when the socket is closed for incoming SCO connections. [ 2650.129080] sco_sock_release: sock ffff8801ca417400, sk ffff88020c408800 [ 2650.129092] sco_sock_clear_timer: sock ffff88020c408800 state 6 [ 2650.129101] __sco_sock_close: sk ffff88020c408800 state 6 socket ffff8801ca417400 [ 2650.129108] sco_chan_del: sk ffff88020c408800, conn ffff8801c650ea20, err 104 [ 2650.129114] hci_conn_put: hcon ffff88020c40a800 orig refcnt 1 [ 2650.129128] sco_sock_kill: sk ffff88020c408800 state 9 [ 2650.129135] sco_sock_destruct: sk ffff88020c408800 [ 2650.138468] hci_conn_timeout: hcon ffff88020c40a800 state BT_CONNECT2 Signed-off-by:
Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by:
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by:
-
Claudio Takahasi authored
This patch removes the status parameter of the l2cap_conn_add function. The parameter 'status' is always 0. Signed-off-by:
-
Claudio Takahasi authored
This patch removes unneeded initialization and empty line. Signed-off-by:
-
Claudio Takahasi authored
This patch changes the memory allocation flags in the sco_conn_add function, replacing the type to GFP_KERNEL. This function is executed in process context and it is not called inside an atomic section. Signed-off-by:
-
Claudio Takahasi authored
This patch fixes decrementing SCO connection reference right after stablishing the SCO connection with defer setup enabled. The dump below shows a disconnection command with handle 0, the connection is still in BT_CONNECT2 state and there isn't a handle associated with it. < HCI Command: Accept Synchronous Connection (0x01|0x0029) plen 21 bdaddr 78:47:1D:B3:72:6C > HCI Event: Command Status (0x0f) plen 4 Accept Synchronous Connection (0x01|0x0029) status 0x00 ncmd 1 < HCI Command: Disconnect (0x01|0x0006) plen 3 handle 0 reason 0x13 Reason: Remote User Terminated Connection > HCI Event: Command Status (0x0f) plen 4 Disconnect (0x01|0x0006) status 0x00 ncmd 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x00 handle 46 bdaddr 78:47:1D:B3:72:6C type eSCO Air mode: CVSD < SCO data: handle 46 flags 0x00 dlen 48 Signed-off-by:
-
David Herrmann authored
We use _get() and _put() for device ref-counting in the kernel. However, hci_conn_put() is _not_ used for ref-counting, hence, rename it to hci_conn_drop() so we can later fix ref-counting and introduce hci_conn_put(). hci_conn_hold() and hci_conn_put() are currently used to manage how long a connection should be held alive. When the last user drops the connection, we spawn a delayed work that performs the disconnect. Obviously, this has nothing to do with ref-counting for the _object_ but rather for the keep-alive of the connection. But we really _need_ proper ref-counting for the _object_ to allow connection-users like rfcomm-tty, HIDP or others. Signed-off-by:
-
Marcel Holtmann authored
Trying to squeeze every single vendor setup routine into the same function and have it assigned all the time is actually a bad idea. Especially since the core can handle the absence of a setup routine perfectly fine. To make this a lot simpler for future additions of vendor setup code, split the BCM92035 setup into its own function and only assign it when this specific device has been detected. Doing it like this has the nice side benefit that we do not have to keep a copy of the driver_info around. Signed-off-by:
-
- 06 Apr, 2013 2 commits
-
-
David Herrmann authored
We need to verify that the given sockets actually are l2cap sockets. If they aren't, we are not supposed to access bt_sk(sock) and we shouldn't start the session if the offsets turn out to be valid local BT addresses. That is, if someone passes a TCP socket to HIDCONNADD, then we access some random offset in the TCP socket (which isn't even guaranteed to be valid). Fix this by checking that the socket is an l2cap socket. Signed-off-by:
-
David Herrmann authored
We print this error twice in the first error-path so remove it. One error message is enough. Signed-off-by:
-
- 04 Apr, 2013 14 commits
-
-
Marcel Holtmann authored
The driver init queue is no longer needed. This can be all handled inside the drivers now. So remove it. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
With the early init stage during setup, this quirk can be simplified and kept fully inside the driver. Signed-off-by:
-
Marcel Holtmann authored
Some drivers require a special stage for their early init. This is always specific to the driver or transport. So call back into driver to allow bringing up the device. The advantage with this stage is that the Bluetooth core is actually handling the HCI layer now. This means that command and event processing is available. Signed-off-by:
-
Johan Hedberg authored
This patch adds a __hci_cmd_sync_ev function, analogous to __hci_cmd_sync except that it also takes an event parameter to indicate that the command completes with a special event instead of command complete. Internally this new function takes advantage of the hci_req_add_ev function introduced in the previous patch. The primary expected user of this new function are the setup routines of HCI drivers which may want to send custom commands and return only when they have completed. Signed-off-by:
-
Johan Hedberg authored
This patch adds support for having commands within HCI requests that do not result in a command complete but some other event. This is at least needed for some vendor specific commands to be issued in the hdev->setup() procecure, but might also be useful for other commands. The way that the support is implemented is by extending the skb control buffer to have a field to indicate that the command is expected to terminate with a special event. After sending the command each received event can then be compared against this field through hdev->sent_cmd. Signed-off-by:
-
Johan Hedberg authored
This patch adds a helper function for sending a single HCI command waiting for its completion and then returning back the parameters in the resulting command complete event (if there was one). The implementation is very similar to that of hci_req_sync() except that instead of invocing a callback for sending HCI commands the function constructs and sends one itself and after being woken up picks the last received event from hdev->recv_evt (if it matches the right criteria) and returns it. Signed-off-by:
-
Johan Hedberg authored
This patch adds tracking of received HCI events to the hci_dev struct. This is necessary so that a subsequent patch can implement a function for sending a single command synchronously and returning the resulting command complete parameters in the function return value. Signed-off-by:
-
Chan-yeol Park authored
This patch removes redundant whitespace from the HCI ldisc driver. Signed-off-by:
Chan-yeol Park <chanyeol.park@samsung.com> Signed-off-by:
-
Chan-yeol Park authored
This patch adds a NULL check for the HCI UART ldisc driver because some of HCI UART drivers allow hci_uart_tty_receive function to be called even though the HCI device hasn't been registered yet. Signed-off-by:
-
Chan-yeol Park authored
This patch adds a check HCI_UART_REGISTERED before reading UART data in the HCI UART H4 driver. UART data could arrive when inside the hci_uart_tty_ioctl function after calling test_and_set_bit for HCI_UART_PROTO_SET but before the hci_uart_set_proto function has returned. Backtrace: [<c05f27ec>] (hci_recv_stream_fragment+0x0/0x74) from [<c04126f4>] (h4_recv+0x18/0x40) r7:eb1d4d1c r6:eb7683b0 r5:eae8e800 r4:0000000c [<c04126dc>] (h4_recv+0x0/0x40) from [<c0411870>] (hci_uart_tty_receive+0x6c/0x94) r5:eae8e800 r4:eb768380 [<c0411804>] (hci_uart_tty_receive+0x0/0x94) from [<c027be88>] (flush_to_ldisc+0x16c/0x17c) r6:eae8e8d8 r5:eae8e800 r4:eae8e8c8 [<c027bd1c>] (flush_to_ldisc+0x0/0x17c) from [<c0050ae8>] (process_one_work+0x144/0x4d4) [<c00509a4>] (process_one_work+0x0/0x4d4) from [<c0051208>] (worker_thread+0x180/0x370) [<c0051088>] (worker_thread+0x0/0x370) from [<c005617c>] (kthread+0x90/0x9c) [<c00560ec>] (kthread+0x0/0x9c) from [<c003a3a0>] (do_exit+0x0/0x7ec) Signed-off-by:
-
Andre Guedes authored
This patch removes the hci_req_cmd_status function since it is not used anymore. The HCI request framework now considers the HCI command has complete once the Command Status or Command Complete Event is received. Signed-off-by:
Andre Guedes <andre.guedes@openbossa.org> Signed-off-by:
-
Andre Guedes authored
Since the HCI request framework was properly fixed, the hci_req_sync call, in hci_inquiry, will return as soon as the HCI command completes (not the Inquiry procedure). However, in inquiry ioctl implementation, we want to sleep the user process until the inquiry procedure finishes. This patch changes hci_inquiry so, in case the HCI Inquiry command was executed successfully, it waits the HCI_INQUIRY flag to be cleared. This way, the user process will sleep until the inquiry procedure finishes. Signed-off-by:
-
Andre Guedes authored
Some HCI commands don't send a Command Complete Event once the HCI command has completed so they require some special handling from the HCI request framework. These HCI commands, however, send a Command Status Event to indicate that the command has been received, and that the controller is currently performing the task for the command. So, in order to properly handle those HCI commands, the HCI request framework should consider the HCI command has completed once the Command Status Event is received. This way, we fix some issues regarding the Inquiry command support, as well as add support for all those HCI commands which would require some special handling from the HCI request framework. Signed-off-by:
-
Noguchi Kazutosi authored
Add support for the AR3012 chip. T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=03 Dev#= 21 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e04d Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
Noguchi Kazutosi <linux@scaltinof.net> Signed-off-by:
-
- 03 Apr, 2013 16 commits
-
-
Arend van Spriel authored
Firmware provides the driver with credits used to transmit packets to the firmware. When credits run out the packets should be queued and dequeued when receiving creditback signals from the firmware. Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
The fcmode provided by module parameter defaults to NONE, which means no flow-control is required. In this case flow-control signals should not be enabled. Reviewed-by:
Piotr Haber <phaber@broadcom.com> Reviewed-by:
-
Arend van Spriel authored
Bail out of brcmf_fws_init() when no firmware-signalling is asked for. Need to take this into account in brcmf_fws_deinit() as well. Reviewed-by:
-
Arend van Spriel authored
The functions are moved in preparation of later patches. Reviewed-by:
-
Arend van Spriel authored
The length is not according specification so better fix it. Reviewed-by:
-
Arend van Spriel authored
If iovar to the firmware fails the firmware-signalling module does a cleanup for which it needs pointer to struct brcmf_pub, which it gets from struct brcmf_fws_info::drvr. Assign this field before doing the tlv iovar. Reviewed-by:
-
Arend van Spriel authored
The low-level sdio code has a large number of trace and info messages that are mostly useful looking into bus specific issues. For tracing higher-level driver functions it is better to have a dedicated level for low-level sdio debugging. Reviewed-by:
-
Piotr Haber authored
During SDIO layer flow control signalling firmware can issue invalid packets. Prevent printing of parsing errors in such case. Reviewed-by:
-
Arend van Spriel authored
Parsing the tlv upon receiving frames can fail. Instead of printing an error message, just count the parse failure. On some devices we receive a lot of invalid tlv signals. this commit will be squashed. Signed-off-by:
-
Arend van Spriel authored
When firmware-signalling is active the brcmf_txcomplete() does a free of the sk_buff when transfer to firmware fails in the bus-specific driver code. However, it should also cleanup the packet from the hanger. This patch fixes that. Reviewed-by:
-
Arend van Spriel authored
Enabling the tx status signalling, which requires packet tagging before sending to the firmware and handling the tx status signal. Reviewed-by:
-
Arend van Spriel authored
Upcoming patches will add firmware signalled flow control. Prepare by adding the mode, which defaults to disable it. The mode can be queried by brcmf_fws_fc_active() and set by a module parameter. Reviewed-by:
-
Arend van Spriel authored
Add a callback to obtain packet queue from the bus-specific code used to cleanup packet buffers from firmware-signalling code. Reviewed-by:
Franky (Zhenhui) Lin <frankyl@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
The hanger for firmware-signalling is used to retain information for outstanding transmit packets that await tx status. Reviewed-by:
-
Arend van Spriel authored
When an interface is deleted make sure to cleanup all packet buffers related to that interface. Reviewed-by:
-
Arend van Spriel authored
The sk_buff structure contains a control buffer that can be used by different layers in the networking stack for holding packet associated information. In brcmfmac it is used to hold firmware signalling related information. Reviewed-by:
-
