The Intel Snowfield Peak Bluetooth controllers use a strict scanning
filter policy that filters based on Bluetooth device addresses and
not on RSSI.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Bluetooth controllers from Intel use a strict scanning filter
policy that filters based on Bluetooth device addresses and not on
RSSI. So tell the core about this.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The wait_on_bit_timeout() is a simpler and race-free way of waiting for
a bit to be cleared than the current code in btusb.c. This patch updates
the code to use the helper function (its btusb copy - to be later
updated to use a global one).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The test for BTUSB_DOWNLOADING must be after adding to the wait queue
and setting the TASK_INTERRUPTIBLE state. Otherwise the flag may get
cleared after we test for it and we end up getting a timeout since
schedule_timeout() waits for the full duration. This patch uses a
wait_on_bit_timeout() + wake_up_bit(). To perform the task both
race-free as well as in a much simpler way.
Since there's no global wait_on_bit_timeout() helper yet (even though
all the building blocks for it are in place) this patch creates a
temporary local btusb copy of it until the global one has made it to
upstream trees.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In general all Intel Bluetooth devices support retrieving of additional
exception information. However for older generations including Wilkens
Peak and Stone Peak it is not as simple. So for now only enable the
Intel specific error handling for Snowfield Peak and later devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Bluetooth controllers from Atheros use a strict scanning filter
policy that filters based on Bluetooth device addresses and not on
RSSI. So tell the core about this.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Bluetooth HCI transport specification for USB device defines on how
a standard AMP controller is identified and operated. This patch adds
the needed handling to hook it up to the Bluetooth stack.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Intel Bluetooth devices use the generic USB device/interface class
descriptors that are assigned to Bluetooth H:2 conforming transports.
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
However newer chips have a bootloader stage and require firmware to
be loaded before they are functional. To avoid any confusion for the
users, just ignore unknown Intel Bluetooth devices.
All the released Intel Bluetooth devices have an entry in the device
table identifying their setup and support requirements. The advantage
here is that older kernel can be booted with newer devices without
causing any disturbance.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
New entries to the USB blacklist/quirk device table should be sorted
by USB vendor id. Fix the recent entry fro Marvell devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Intel Bluetooth controllers can provide an additional exception
info string when a hardware error event occurs. The core will now
call hdev->hw_error to let the driver read out this information.
This change will cause a reset of the hardware to bring it back
into functional state and then read the Intel exception info
string and print it along with the error information.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The btusb_disconnect() callback calls hci_unregister_dev() which in turn
calls btusb_close() if the HCI device is powered. The btusb_close()
function in turn will call btusb_free_frags(). It's therefore
unnecessary to have another call to btusb_free_frags() in the
btusb_disconnect() function. Besides the redundancy the second call
seems to also cause some strange stability issues which this patch then
also fixes.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When loading the Intel firmware it can happen that the firmware loading
complete vendor event arrives before the command complete event for the
last firmware fragment.
< HCI Command: Vendor (0x3f|0x0009) plen 7
01 02 fc 03 00 00 00
> HCI Event: Vendor (0xff) plen 5
06 00 00 00 00
> HCI Event: Command Complete (0x0e) plen 4
Vendor (0x3f|0x0009) ncmd 31
Status: Success (0x00)
This is mainly caused by the fact that the vendor command and its
command complete event are transported over the bulk endpoints. The
firmware loading complete event however is send over the interrupt
endpoint. So with just bad timing one event arrives before the other.
Currently the code does not account for it. There are precautions for
receiving firmware loading complete event quickly, but not for receiving
it before the command complete.
Introduce an extra flag that tracks when the firmware sending has
completed from the driver point of view and track the completion of
the firmware loading procedure with a different flag. That way the
wakeup can be handled properly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Some new upcoming drivers need to process HCI events or take extra
actions based on them before handing the event to the Bluetooth core
for processing. The new recv_event callback allows exactly such an
internal behavior.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Silicon Wave based devices do support Inquiry Result with RSSI and
so let the core know to enable them.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Roper Class 1 Bluetooth Dongle is another device that claims to
support Bluetooth 1.2 specification, but does not support the HCI
command for reading the local supported commands.
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x0
LMP Version: 1.2 (0x2) LMP Subversion: 0x757
Manufacturer: Silicon Wave (11)
It clearly claims Bluetooth 1.2 support and in that regard has the
same issue as the AVM BlueFritz! USB devices (Silicon Wave based),
but the HCI Read Local Supported Commands command fails.
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
Use the HCI_QUIRK_BROKEN_LOCAL_COMMANDS quirk for these devices and
the failing command will be skipped.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The AVM BlueFritz! 2.0 USB dongles do not support the HCI command for
reading the local supported commands. So set this quirk to let the
core know about it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Set hdev->set_bdaddr handler for ath3012. It sends the vendor specific HCI
command to change the public address. The change doesn't persist across
power cycle.
Signed-off-by: Toshi Kikuchi <toshik@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some vendors require special handling of the rx data from the USB
bulk endpoints. For that case provide an internal callback that
can overwrite it with a custom receive function.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Bluetooth controllers from Broadcom use a strict scanning filter
policy that filters based on Bluetooth device addresses and not on
RSSI. So tell the core about this.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When receiving USB interrupt, bulk or isochronous packet, they normally
come in fragments. So far the driver just handed each fragment off to
the hci_recv_fragment function of the Bluetooth core. That function is
however so specific that is does not belong in the core. This patch
implements the same reassembly logic in the driver.
In addition this fixes a long standing bug where multiple complete
packets are received within a single USB packet.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The actual packet reassembly should be done inside the driver. To allow
this to happen cleanly in future patches, split the fragment reception
into its own functions.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The btusb driver has been around for a while now and it is time to
bring its coding style in sync with what has been done for the
Bluetooth subsystem and other drivers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The complete TX URB handling is done via a switch statement in the
btusb_send_frame function. To allow for more clear separation between
control, bulk and isoc URBs, split them into allocation and submission.
Previously the inc_tx function has been used for tracking in-flight
URB for HCI commands and ACL data packets. Convert that into a common
function that either submits the URB or queues it when needed.
This provides the flexibility to allow vendor specific hdev->send_frame
callbacks without having to duplicate the whole URB handling logic.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
All hdev->send() calls are these days done through a work queue. For the
btusb driver this means the btusb_send_frame() function. Because of this
we can safely use GFP_KERNEL for all memory allocations in this code
path.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Suspend could fail for some platforms because
btusb_suspend==> btusb_stop_traffic ==> usb_kill_anchored_urbs.
When btusb_bulk_complete returns before system suspend and resubmits
an URB, the system cannot enter suspend state.
Signed-off-by: Champion Chen <champion_chen@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Implemented .set_bdaddr handler provided by bluetooth stack for
Marvell devices for public address configuration.
A reboot restores the bdaddr to its original address.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Instead of setting data->isoc manually, use BTUSB_BROKEN_ISOC to
indicate that isochronous endpoints are not needed for CSR USB
sniffer devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The isochronous endpoints are not valid when the Intel Bluetooth
controller boots up in bootloader mode. So just mark these endpoints
as broken and then they will not be configured.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The interrupt interface for the Intel USB bootloader devices is only
enabled after receiving SetInterface(0, AltSetting=0). When this USB
command is not send, then no HCI events will be received.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The module parameters to ignore devices based on USB VID/PID are not
needed at all. So just remove them.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the Broadcom USB controller has a default address, then set the quirk
so the Bluetooth core knows that controller configuration is required.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the Intel USB controller has a default address, then set the quirk
so the Bluetooth core knows that controller configuration is required.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Broadcom BCM20702A0 USB controllers might come with the default
address 00:20:70:02:A0:00 when booting up. If this happens, then warn
about such address being used.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Some Intel Bluetooth controllers come with a default address. If this
address is found, print an error to warn the user about it.
The controller is fully operational, but the danger of duplicate
Bluetooth addresses might causes issues. At least with a clear
error it becomes easier to debug these cases.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
