The Intel Version Read command is used to retrieve information
about hardware and firmware version/revision of Intel Bluetooth
controllers. This is an Intel generic command used in USB and
UART drivers.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Older Intel controllers need to enter manufacturing mode to perform
some vendor specific operations (patching, configuration...).
Add enter/exit manufaturing methods and refactor existing
manufacturing code.
Exit can be configured to perform a reset. Reset can be performed
either with patches activated or deactivated.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The new hci_skb_pkt_* wrappers are mainly intented for drivers to
require less knowledge about bt_cb(sbk) handling. So after converting
the core packet handling, convert all drivers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Intel Bluetooth controllers can emit extra vendor specific events in
error conditions or for debugging purposes. To make the life easier for
engineers, enable them by default. When the vendor_diag options has been
enabled, then additional debug events are also enabled.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For Intel bootloader devices, set the manufacturer information so that
it becomes possible to decode the boot process.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For the controllers from Intel and Broadcom (including Apple), it is
helpful to have the information about the manufacturer send out early.
This patch sets the hdev->manufacturer information which will be send
out before actually calling the vendor specific hdev->setup driver
callback.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For the older controllers like Wilkens Peak and Stone Peak, enabling the
traces requires to switch into manufacturer mode first. This patch does
exactly that, but only for these older controllers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For Intel controllers the diagnostics settings are not persistent over
HCI Reset. So set the quirk to programm them again on every power up.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The lock states from Intel SfP controllers can only be read once before
loading the firmware. So for debugging purposes, print them out.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For Intel controllers with firmware that allows tracing of baseband
functionality this allows enabling it via set_diag driver callback.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Setting and clearing of HCI_RUNNING flag in each and every driver is
just duplicating the same code all over the place. So instead of having
the driver do it in their hdev->open and hdev->close callbacks, set it
globally in the core transport handling.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In all callbacks for hdev->send the status of HCI_RUNNING is checked. So
instead of repeating that code in every driver, move the check into the
hci_send_frame function before calling hdev->send.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
SCO packet reassembler may have a fragment of SCO packet, from
previous connection, cached and not removed when SCO connection
is ended. Packets from new SCO connection are then going to be
attached to that fragment, creating an invalid SCO packets.
Controllers like Intel's WilkinsPeak are always fragmenting
SCO packet into 3 parts (#1, #2, #3). Packet #1 contains
SCO header and audio data, others just audio data. if there is
a fragment cached from previous connection, i.e. #1, first
SCO packet from new connection is going to be attached to it
creating packet consisting of fragments #1-#1-#2. This will
be forwarded to upper layers. After that, fragment #3 is going
to be used as a starting point for another SCO packet.
It does not contain a SCO header, but the code expects it,
casts a SCO header structure on it, and reads whatever audio
data happens to be there as SCO packet length and handle.
From that point on, we are assembling random data into SCO
packets. Usually it recovers quickly as initial audio data
contains mostly zeros (muted stream), but setups of over
4 seconds were observed.
Issue manifests itself by printing on the console:
Bluetooth: hci0 SCO packet for unknown connection handle 48
Bluetooth: hci0 SCO packet for unknown connection handle 2560
Bluetooth: hci0 SCO packet for unknown connection handle 12288
It may also show random handles if audio data was non-zeroed.
Hcidump shows SCO packets with random length and handles.
Few messages with handle 0 at connection creation are OK
for some controllers (like WilkinsPeak), as there are SCO packets
with zeroed handle at the beginning (possible controller bug).
Few of such messages at connection end, with a handle looking
sane (around 256, 512, 768 ...) is also OK, as these are last
SCO packets that were assembled and sent up, before connection
was ended, but were not handled in time.
This issue may still manifest itself on WilkinsPeak as it sometimes,
at SCO connection creation, does not send third fragment of first
SCO packet (#1-#2-#1-#2-#3...). This is a firmware bug and this
patch does not address it.
Signed-off-by: Kuba Pawlak <kubax.t.pawlak@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
btintel_load_ddc_config is now part of btintel.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
btusb currently has a generic match on USB device descriptors:
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
However, http://www.usb.org/developers/defined_class states:
Base Class E0h (Wireless Controller)
This base class is defined for devices that are Wireless controllers.
Values not shown in the table below are reserved. These class codes are
to be used in Interface Descriptors, with the exception of the Bluetooth
class code which can also be used in a Device Descriptor.
Add a match on the interface descriptors accordingly.
This fixes compatibility with the RTL8723AU device shown below.
This device conforms to the USB Interface Association Descriptor
specification, which requires the device to have class ef/02/01.
The extra IAD descriptor then specifies that interfaces 0 and 1
belong to the same function/driver, which is true. Provided that
the Bluetooth device class spec accepts use of the IAD, I imagine that
technically, all btusb devices should be configured like this.
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=0724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c000001
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8723au
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Intel version information is shared between USB and UART drivers
and with that move it into a generic function of the Intel module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Intel Secure Send command is used the same in USB and UART drivers
and with that move a generic version into the Intel module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Intel specific Bluetooth module provides now an exported function
for the hardware error. Use that instead of duplicating it inside the
driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds the routine to apply the DDC parameter from device
specific ddc file.
Once the device is rest to operational mode, optionally, it can
download the device specific configration (DDC) parameters before
the BlueZ starts the stack initialization.
It opens the DDC file based on HW_VARIANT and DEV_REVISION and
send ID/Value with HCI_Intel_Write_DDC command.
Format of DDC file
DDC file contains one or more number of DDC structure.
DDC Structure
It has 'Length' field of one octet, DDC 'ID' field of
two octets followed by the array of DDC 'Value' that gives
the value of parameters itself.
'Length' contains the length of DDC 'ID' and DDC 'Value'.
+------------+----------+
| Size(byte) | Name |
+------------+----------+
| 1 | Length |
+------------+----------+
| 2 | ID |
+------------+----------+
| Length - 2 | Value |
+------------+----------+
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch fixes the command length alignment issue for Intel Bluetooth
8260.
The length of parameters in the firmware downloading command must be
multiplication of 4. If not, the command must append Intel_NOP command
with extra parameters, zeros, at the end, and the firmware file is
already included Intel_NOP command for alignment.
This patch checks the next command and if the next command is Intel_NOP
command, it reads the Intel_NOP command and send them together.
For example, if the data from the firmware file looks like this:
8E FC 03 11 22 33 02 FC 03 00 00 00
Previously, btusb sends two commands:
09 FC 06 8E FC 03 11 22 33
09 FC 06 02 FC 03 00 00 00
This won't work because the length of parameters are 6 which violates
the 4 byte alignment.
This patch will append them together and send as one command:
09 FC 0C 8E FC 03 11 22 33 02 FC 03 00 00 00
Based on previous work from Tedd Ho-Jeong An <tedd.an@intel.com>
Reported-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
The btusb_read_local_version function has only a single user and with
that just move its functionality in place where it belongs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The __hci_cmd_sync function already handles the command status and
command complete errors. No need to check the status field again.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The SKB returned from the Intel specific version information command is
missing a kfree_skb.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Johan Hedberg says:
====================
pull request: bluetooth-next 2015-05-28
Here's a set of patches intended for 4.2. The majority of the changes
are on the 802.15.4 side of things rather than Bluetooth related:
- All sorts of cleanups & fixes to ieee802154 and related drivers
- Rework of tx power support in ieee802154 and its drivers
- Support for setting ieee802154 tx power through nl802154
- New IDs for the btusb driver
- Various cleanups & smaller fixes to btusb
- New btrtl driver for Realtec devices
- Fix suspend/resume for Realtek devices
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Realtek btusb devices don't currently work after suspend/resume because
the updated firmware is quietly lost - the USB hub doesn't notice any
status change upon resume, but some kind of reset has definitely
happened as the LMP subversion has reverted to its original value.
Set the reset_resume flag to trigger probe and upload the new firmware
again.
Like the vendor code, I assume this is not needed when the device is
selected as a wakeup source and hence will retain power during suspend.
On the 2 products I have to hand, when trying this configuration the
hardware seems unable to keep the device powered up during suspend.
The USB hub then detects a status change on resume and does a reset,
so we do not end up in broken state.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The reset is a bool type variable. So assigning true to reset instead
of 1.
Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Remove test of command reply status as it is already performed by
__hci_cmd_sync().
__hci_cmd_sync_ev() function already returns an error if it got a
non-zero status either through a Command Complete or a Command
Status event.
For both of these events the status is collected up in the event
handlers called by hci_event_packet() and then passed as the second
parameter to req_complete_skb(). The req_complete_skb() callback in
turn is hci_req_sync_complete() for __hci_cmd_sync_ev() which stores
the status in hdev->req_result. The hdev->req_result is then further
converted through bt_to_errno() back in __hci_cmd_sync_ev().
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
As already done for btintel and btbcm export setup as separate function
in a vendor-specific module to hold all the Realtek specific commands.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The ">" should be ">=" so that we don't read past the end of the array.
Fixes: 9d9a113e3695 ('Bluetooth: btusb: Add Realtek 8723A/8723B/8761A/8821A support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
ERROR: spaces required around that '<' (ctx:WxV)
+ if (err <0)
^
ERROR: code indent should use tabs where possible
+^I^I^I^I sizeof(ver));$
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Realtek ship a variety of bluetooth USB devices that identify
themselves with standard USB Bluetooth device class values, but
require a special driver to actually work. Without that driver,
you never get any scan results.
More recently however, Realtek appear to have wisened up and simply
posted a firmware update that makes these devices comply with
normal btusb protocols. The firmware needs to be uploaded on each boot.
Based on Realtek code from https://github.com/lwfinger/rtl8723au_bt
('new' branch).
This enables bluetooth support in the Gigabyte Brix GB-BXBT-2807 which
has this RTL8723BE USB device:
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3410 Rev= 2.00
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
There is no change to the USB descriptor after firmware update,
however the version read by HCI_OP_READ_LOCAL_VERSION changes from
0x8723 to 0x3083.
This has also been tested on RTL8723AE and RTL8821AE. Support for
RTL8761A has also been added, but that is untested.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Intel vendors events indicating firmware loading result and the
bootup of the operational firmware are currently hardcoded byte
comparisons. So intead of doing that, provide proper data structures
and actually use them.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Since the Intel Bluetooth support has its own header, it makes sense
to move all command structs into it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Bluetooth address handling for Intel devices is provided by a generic
module now. Start using that module instead of relying it being included
in the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The version number is cosmetic, but pretty handy for debugging purposes
and since the Broadcom protocol support is now optional, just increase
it to indicate the difference.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The quirks for Broadcom devices can be set from the setup function and
to keep the code simple, just move them into Broadcom support module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With the generic Broadcom Bluetooth support module, it is possible to
turn support for firmware and patchram download into an optional
feature.
To keep backwards compatibility with previous kernel configurations,
the new option defaults to enabled.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The new Broadcom Bluetooth support module provides generic functionality
for changing and checking the Bluetooth device address. Use these new
features instead of keeping a duplicate in the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For all modern Bluetooth USB devices from Broadcom it makes a lot more
sense to use USB_VENDOR_AND_INTERFACE_INFO instead of manually adding
USB_DEVICE for each one of them. There are already interface entries
for these vendors and so just remove the duplicate device entries.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For the Apple Bluetooth devices that are Broadcom based, it makes sense
to read the chip information. It is a single HCI command and might help
gathering more information about these devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Broadcom devices expose their chip id via Read Verbose Config
Version Info command. While this information is not used at the
moment, it might be useful for debugging purposes and so read it
before patching the firmware. This makes it show up in dmesg and
HCI traces taken for the system.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
CSR controllers can do both LE scan and BR/EDR inquiry at once.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Intel controllers can do both LE scan and BR/EDR inquiry at once.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Atheros controllers can do both LE scan and BR/EDR inquiry at once.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg says:
====================
Here's another set of Bluetooth & ieee802154 patches intended for 4.1:
- Added support for QCA ROME chipset family in the btusb driver
- at86rf230 driver fixes & cleanups
- ieee802154 cleanups
- Refactoring of Bluetooth mgmt API to allow new users
- New setting for static Bluetooth address exposed to user space
- Refactoring of hci_dev flags to remove limit of 32
- Remove unnecessary fast-connectable setting usage restrictions
- Fix behavior to be consistent when trying to pair already paired device
- Service discovery corner-case fixes
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Multiple codepaths duplicate some simple code to read and
sanity-check local version information. Before I add a couple more
such codepaths, add a helper to reduce duplication.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
While qca_device_info is not coming from outside communication,
no reason to use specific endian type inside and fix the wrong
version comparison on big-endian platform.
Signed-off-by: Ben Young Tae Kim <ytkim@qca.qualcomm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Conflicts:
drivers/net/ethernet/rocker/rocker.c
The rocker commit was two overlapping changes, one to rename
the ->vport member to ->pport, and another making the bitmask
expression use '1ULL' instead of plain '1'.
Signed-off-by: David S. Miller <davem@davemloft.net>
Some of chipset does not allow to send a patch or config files through
HCI VS channel at early stage as well as they don't support to send
USB patch files to other channel except USB bulk path.
New callback added is for initialization of BT controller through USB
Signed-off-by: Ben Young Tae Kim <ytkim@qca.qualcomm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Broadcom firmware files are named with firmware version information
encoded into lmp_subver field. So BCM20702B0_002.001.014.0527.0607.hex
would be represented by 0x410e. To allow for an easier decoding of the
actual firmware names, provide an internal table that does the mapping
and request the firmware file by name.
Bluetooth: hci0: BCM20702B0 (002.001.014) build 0607
Now the complicated encoding of lmp_subver will be decoded and turned
into the name and firmware version information from the firmware files.
The previous attempt of using udev->product failed badly since it never
contains any matching entry to the actual hardware or firmware files
distributed by Broadcom in their Windows drivers. It is even worse since
it can change depending on if the internal bootstrapping happened before
the USB bus enumeration or after. This caused many race conditions.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds the device shutdown routine for Intel Bluetooth device.
Some platforms have BT LED issue with Intel Bluetooth device that BT LED goes
off 5 seconds after BT is turned off
For Intel Bluetooth device, the BT LED is turned off when:
- there is no active connection or radio activity
- USB is suspend
So, when the BT is turned off, it takes 5 seconds because USB suspend timeone
is 5 seconds by default. And if the USB suspend is not enabled, BT LED won't be
turned off.
To fix this issue, recently Intel Bluetooth firmware patch had been submitted
to turn off the BT LED immediately by the vendor specific command(0xFC3F). And
this patch sends this command to the device before closing the device.
For backward compatibility of this command with old firmware, this command was
supported before, but it behaves same as HCI_RESET internally. So, it won't be
the problem even if the system doesn't have the latest firmware patch.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There's now a proper wait_on_bit_timeout() API in linux/wait.h so we can
remove our own copy from btusb.c. Our copy had the task state and
timeout variables swapped so the patch also changes their order.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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>
For the Intel based USB devices add support for configuration of
the public device address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For the Broadcom based USB devices add support for configuration of
the public device address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This reverts commit ca58e594da.
For some unclear reason this patch tries to add suport for the
product ID 0xe005, but it ends up adding product ID 0x3005 to
all the tables. This is obviously wrong and causing multiple
issues.
The original patch seemed to be fine, but what ended up in 3.15
is not what the patch intended. The commit 0a3658cccd is
already present and adds support for this hardware. This means
only revert of this broken commit is requird.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reported-by: Alexander Holler <holler@ahsoftware.de>
Cc: stable@vger.kernel.org # 3.15.x
After hardware reset, some BCM Bluetooth adapters obtain their initial firmware
from OTPROM chip. Once this initial firmware is running, the firmware can be
further upgraded over HCI interface with .hcd files provided by Broadcom. This
is also known as "patch RAM" support. This change implements that.
If the .hcd file is not found in /lib/firmware, BCM Bluetooth adapter continues
to operate with the initial firmware. Sample kernel log:
hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-22be.hcd not found
If the .hcd file is found, btusb driver pushes it to the BCM Bluetooth adapter and
it starts using the new firmware. Sample kernel log:
hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=1000 lmp_ver=06 lmp_subver=220e
Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=1389 lmp_ver=06 lmp_subver=220e
Above, we can see that hci_rev goes from 1000 to 1389 as a result of the upgrade.
Signed-off-by: Petri Gynther <pgynther@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This reverts commit d2bee8fb6e.
Enabling autosuspend for Intel Bluetooth devices has been shown to not
work reliable. It does work for some people with certain combinations
of USB host controllers, but for others it puts the device to sleep and
it will not wake up for any event.
These events can be important ones like HCI Inquiry Complete or HCI
Connection Request. The events will arrive as soon as you poke the
device with a new command, but that is not something we can do in
these cases.
Initially there were patches to the xHCI USB controller that fixed
this for some people, but not for all. This could be well a problem
somewhere in the USB subsystem or in the USB host controllers or
just plain a hardware issue somewhere. At this moment we just do
not know and the only safe action is to revert this patch.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Tedd Ho-Jeong An <tedd.an@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
This will help to manage table of supported IDs.
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There exists a set of Bluetooth USB devices that show up on the USB
bus as 0a12:0001 and identify themselves as devices from CSR. However
they are not. When sending Read Local Version command they now have
a split personality and say they are from Broadcom.
< 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: 2.0 (0x3) HCI Revision: 0x3000
LMP Version: 2.0 (0x3) LMP Subversion: 0x420b
Manufacturer: Broadcom Corporation (15)
The assumption is that they are neither CSR nor Broadcom based devices
and that they are designed and manufactured by someone else.
For the most parts they follow the Bluetooth HCI specification and
can be used as standard Bluetooth devices. However they have the
minor problem that the Delete Stored Link Key command is not working
as it should.
During the Bluetooth controller setup, this command is needed if
stored link keys are supported. For these devices it has to be
assumed that this is broken and so just set a quirk to clearly
indicate the behavior. After that the setup can just proceed.
Now the trick part is to detect these faulty devices since we do
not want to punish all CSR and all Broadcom devices. The original
devices do actually work according to the specification.
What is known so far is that these broken devices set the USB bcdDevice
revision information to 1.0 or less.
T: Bus=02 Lev=01 Prnt=01 Port=08 Cnt=03 Dev#= 9 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a12 ProdID=0001 Rev= 1.00
S: Manufacturer=Bluetooth v2.0
S: Product=Bluetooth V2.0 Dongle
T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a12 ProdID=0001 Rev= 0.07
In case of CSR devices, the bcdDevice revision contains the firmware
build ID and that is normally a higher value. If the bcdDevice revision
is 1.0 or less, then an extra setup stage is checking if Read Local
Version returns CSR manufacturer information. If not then it will be
assumed that this is a broken device and the Delete Stored Link Key
command will be marked as broken.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch enables autosuspend for Intel Bluetooth device.
After btusb is loaded for Intel Bluetooth device, the power/control
attribute contains "on" value by default which disables the autosuspend.
Based on the USB PM document(Documentation/usb/power-management.txt),
kernel disabled the autosuspend for all devices other than hub by default.
"The USB specification states that all USB devices must support power
management. Nevertheless, the sad fact is that many devices do not
support it very well. You can suspend them all right, but when you
try to resume them they disconnect themselves from the USB bus or
they stop working entirely. This seems to be especially prevalent
among printers and scanners, but plenty of other types of device have
the same deficiency.
For this reason, by default the kernel disables autosuspend (the
power/control attribute is initialized to "on") for all devices other
than hubs. Hubs, at least, appear to be reasonably well-behaved in
this regard."
This document also described how the driver can enables the autosuspend
by using an USB api.
"Drivers can enable autosuspend for their devices by calling
usb_enable_autosuspend(struct usb_device *udev);
in their probe() routine, if they know that the device is capable of
suspending and resuming correctly. This is exactly equivalent to
writing "auto" to the device's power/control attribute."
For Intel Bluetooth device, the autosuspend needs to be enabled so the
device can transit to LPM(Low Power Mode) and ULPM(Ultra LPM) states after
receiving suspend message from the host.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
