This patch converts the Pair Device mgmt command to use the new
cmd_complete callback for pending mgmt commands. The already existing
pairing_complete() function is exactly what's needed and doesn't need
changing.
In addition to getting the return parameters always right this patch
actually fixes a reference counting bug and memory leak with the
hci_conn that's attached to the pending mgmt command - something that
would occur when powering off or unplugging the adapter while pairing is
in progress.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch converts the user confirmation & PIN code mgmt commands to
take advantage of the new cmd_complete callback for pending mgmt
commands. The patch also adds a new generic addr_cmd_complete() helper
function to be used with commands that send a mgmt_addr_info response
based on a mgmt_addr_info in the beginning of the command parameters.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch converts the Disconnect mgmt command to take advantage of the
new cmd_complete callback that's part of the pending_cmd struct. There
are many commands whose response parameters map 1:1 to the command
parameters and Disconnect is one of them. This patch adds a
generic_cmd_complete() function for such commands that can be reused in
subsequent patches.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
As preparation for making generic cmd_complete responses possible we'll
need to track the parameter length in addition to just a pointer to
them. This patch adds the necessary variable to the pending_cmd struct.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We've got a couple of generic scenarios where all pending mgmt commands
are processed and responses are sent to them. These scenarios are
powering off the adapter and removing the adapter. So far the code has
been generating cmd_status responses with NOT_POWERED and INVALID_INDEX
resposes respectively, but this violates the mgmt specification for
commands that should always generate a cmd_complete.
This patch adds support for specifying a callback for the pending_cmd
context that each command handler can use for command-specific
cmd_complete event generation. The actual per-command event generators
will come in subsequent patches.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some have been missing and some have been needed. Just cosmetics.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Follow coding style of the kernel.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This might change and we already deliver a copy of the license with
the kernel. This was already removed form the ieee802154 code but
missed here.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Currently the discovery filter information are only cleared when the
actual discovery procedure has been stopped. To make sure that none
of the filters interfere with the background scanning and its device
found event reporting, clear the filter before starting background
scanning.
This means that the discovery filter is now cleared before either
Start Discovery, Start Service Discovery or background scanning.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In case of failure or when unplugging a controller, the allocated
memory for the UUID list of the discovery filter is not freed. Use
the newly introduced helper for reset the discovery filter and with
that also freeing existing memory.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The discovery filter allocates memory for its UUID list. So use
a helper function to free it and reset it to default states.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds support for the Start Service Discovery command. It
does all the checks for command parameters and configured the discovery
filter settings correctly. However the actual support for filtering
will be added with another patch.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The previous patch provided the framework for integrating the UUID
filtering into the service discovery. This patch now provides the
actual filter logic.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Using Start Service Discovery provides the option to specifiy a list
of UUID that are used to filter out device found events. This patch
provides the framework for hooking up the UUID filter.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Using Start Service Discovery allows to provide a RSSI threshold. This
patch implements support for filtering out device found events based
on the provided value.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With the upcoming addition of support for Start Service Discovery, the
discovery handling needs to filter on RSSI and UUID values. For that
they need to be stored in the discovery handling. This patch adds the
appropiate fields and also make sure they are reset when discovery
has been stopped.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds the opcode and structure for Start Service Discovery
operation.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Bluetooth core specification defines the value 127 as invalid for
RSSI values. So instead of hard coding it, lets add a constant for it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds support for multiple BSS interfaces (AP). In
total three AP configurations can be created. In order to use
multiple BSS firmware needs to support it.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The vendor specific commands was always using main interface,
change this to use the by caller supplied interface.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use single message MSI to replace legacy interrupt.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some 43602 devices are band specific and identify themselves
with different PCIE device ID. This patch adds support for the
43602 2.4G and 5.0G devices used in for example R8000 router.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ifidx provided by FW needs to be offsetted when receiving data
packets.
Cc: stable@vger.kernel.org # v3.17, v3.18
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Wake On Lan was not working on laptop DELL Vostro 1500.
If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
But the laptop could not be woken up with the Magic Packet. The reason for
that was that PCIE was not enabled as a system wakeup source and
therefore the host PCI bridge was not powered up in suspend mode.
PCIE was not enabled in suspend by PM because no child devices were
registered as wakeup source during suspend process.
On laptop BCM4401 is connected through the SSB bus, that is connected to the
PCI-Express bus. SSB and B44 did not use standard PM wakeup functions
and did not forward wakeup settings to their parents.
To fix that B44 driver enables PM wakeup and registers new wakeup source
using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB
bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any
child devices with enabled wakeup functionality. All other steps are
done by PM core code.
Signed-off-by: Andrey Skvortsov <Andrej.Skvortzov@gmail.com>
Signed-off-by: Michael Buesch <m@bues.ch>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg <johannes@sipsolutions.net> says:
"This time I have Felix's no-status rate control work, which will allow
drivers to work better with rate control even if they don't have perfect
status reporting. In addition to this, a small hwsim fix from Patrik,
one of the regulatory patches from Arik, and a number of cleanups and
fixes I did myself.
Of note is a patch where I disable CFG80211_WEXT so that compatibility
is no longer selectable - this is intended as a wake-up call for anyone
who's still using it, and is still easily worked around (it's a one-line
patch) before we fully remove the code as well in the future."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is the NFC pull request for 3.19.
With this one we get:
- NFC digital improvements for DEP support: Chaining, NACK and ATN
support added.
- NCI improvements: Support for p2p target, SE IO operand addition,
SE operands extensions to support proprietary implementations, and
a few fixes.
- NFC HCI improvements: OPEN_PIPE and NOTIFY_ALL_CLEARED support,
and SE IO operand addition.
- A bunch of minor improvements and fixes for STMicro st21nfcb and
st21nfca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUfjvWAAoJEIqAPN1PVmxK46MP/1QFb093QmAK3AfMS7XBZdwg
vgJkZIyFmTeRlDTonRJpv1MXZhPL+JHYK0wGANts1Ba04nZIgK9jzdcqjvd1niD1
Hk9ggHpfxsIl35FfRVcWAUpyb71Ykug2V396gJH2iiHvt2jHr8IsRWOWCVaItWMO
ZpVpV58xkROEu115wjKdrmKijL0xf7/F70RlReV4tOLGip3E/bP7EhutF2s5D8Lt
A5hfauQS3lUJIhlJ1IT59XtdnBSIS5D8OuNYjuJuFkPfIcXAHacEUBrta3KahQPy
kFGYYjj+V0vZA9JQG/j6vomP4AI0pP4DPkwWqgmioaPshkOOktwf1l21IKQrC7aw
h7EFEG6q5AxnL5JFbm4y+b5IEp8ALeVi5rv1xdRZ7/AW/n6FWGrkBHatsJceQgX+
wFhZ52USGHQUzWoJ6SC0O82U831/dgxWm5M42CV5/Bl9d69XX7Om9MWytdjQ94yB
ERoSJcivc+Q30bAiZmvb44ghv3qMGNArlBVVlcN7+3rbz4XOWLhduqCJaUs12fgY
lyGdNHxVVmEeEY9ByOjr6RD1pYpSDgEQSYvn5pbKadX+DqpXHQuGC4JHtbBkzKn0
Se9c442HRBjts0VprJ7wjLgbf5VfqFjtgsfqubD/mcTn61B4/t9zyGgV1VuI7UgL
QxK0m0rB1nOxpdWFesl1
=WHHp
-----END PGP SIGNATURE-----
Merge tag 'nfc-next-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next
Samuel Ortiz <sameo@linux.intel.com> says:
"NFC: 3.19 pull request
This is the NFC pull request for 3.19.
With this one we get:
- NFC digital improvements for DEP support: Chaining, NACK and ATN
support added.
- NCI improvements: Support for p2p target, SE IO operand addition,
SE operands extensions to support proprietary implementations, and
a few fixes.
- NFC HCI improvements: OPEN_PIPE and NOTIFY_ALL_CLEARED support,
and SE IO operand addition.
- A bunch of minor improvements and fixes for STMicro st21nfcb and
st21nfca"
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The actual process of compiling the correct HCI commands for triggering
discovery is something that should be generic. So instead of mixing it
into the Start Discover operation handling, split it out into its own
function utilizing HCI request handling and just providing status in
case of errors or invalid parameters.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Sending the required cmd_complete for the management commands should be
done in one place and not in multiple places. Especially for Start and
Stop Discovery commands this is split into to sending it in case of
failure from the complete handler, but in case of success from the
event state update function triggering mgmt_discovering. This is way
too convoluted and since hci_request serializes the HCI command
processing, send the cmd_complete response from the complete handler
for all cases.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Start Discovery command has some complicated code when it comes
to error handling. With the future introduction of Start Service
Discovery simplifying this makes it easier to read.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch increments the management interface revision due to the
addition of support for LE Secure Connection feature.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With the addition of support for Bluetooth Low Energy Secure Connections
feature, it makes sense to increase the minor version of the Bluetooth
core module.
The module version is not used anywhere, but it gives a nice extra
hint for debugging purposes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds firmware dump support for marvell
bluetooth chipset. Currently only SD8897 is supported.
This is implemented based on dev_coredump, a new mechnism
introduced in kernel 3.18rc3
Firmware dump can be trigger by
echo 1 > /sys/kernel/debug/bluetooth/hci*/config/fw_dump
and when the dump operation is completed, data can be read by
cat /sys/class/devcoredump/devcd*/data
We have prepared following script to divide fw memory
dump data into multiple files based on memory type.
[root]# cat btmrvl_split_dump_data.sh
#!/bin/bash
# usage: ./btmrvl_split_dump_data.sh dump_data
fw_dump_data=$1
mem_type="ITCM DTCM SQRAM APU CIU ICU MAC EXT7 EXT8 EXT9 EXT10 EXT11 EXT12 EXT13 EXTLAST"
for name in ${mem_type[@]}
do
sed -n "/Start dump $name/,/End dump/p" $fw_dump_data > tmp.$name.log
if [ ! -s tmp.$name.log ]
then
rm -rf tmp.$name.log
else
# Remove the describle info "Start dump" and "End dump"
sed '1d' tmp.$name.log | sed '$d' > /data/$name.log
if [ -s /data/$name.log ]
then
echo "generate /data/$name.log"
else
sed '1d' tmp.$name.log | sed '$d' > /var/$name.log
echo "generate /var/$name.log"
fi
rm -rf tmp.$name.log
fi
done
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
BT_INFO/BT_DBG etc. already takes care of adding a newline
An extra newline character inside message is removed in this
patch.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some gcc versions don't seem to be able to properly track the flow of
the smp_cmd_pairing_random() function and end up causing the following
types of (false-positive) warnings:
smp.c:1995:6: warning: ‘nb’ may be used uninitialized in this function [-Wmaybe-uninitialized]
err = smp_g2(smp->tfm_cmac, pkax, pkbx, na, nb, &passkey);
smp.c:1995:6: warning: ‘na’ may be used uninitialized in this function [-Wmaybe-uninitialized]
err = smp_g2(smp->tfm_cmac, pkax, pkbx, na, nb, &passkey);
^
smp.c:1995:6: warning: ‘pkbx’ may be used uninitialized in this function [-Wmaybe-uninitialized]
err = smp_g2(smp->tfm_cmac, pkax, pkbx, na, nb, &passkey);
^
smp.c:1995:6: warning: ‘pkax’ may be used uninitialized in this function [-Wmaybe-uninitialized]
err = smp_g2(smp->tfm_cmac, pkax, pkbx, na, nb, &passkey);
This patch fixes the issue by moving the pkax/pkbx and na/nb
initialization earlier in the function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The convention for checking for NULL pointers is !ptr and not
ptr == NULL. This patch fixes such an occurrence in smp.c.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We need to keep debug keys around at least until the point that they are
used - otherwise e.g. slave role behavior wouldn't work as there'd be no
key to be looked up. The correct behavior should therefore be to return
any stored keys but when we clean up the SMP context to remove the key
from the hdev list if keeping debug keys around hasn't been requestsed.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch organizes the various SMP crypto functions so that the LE SC
functions appear in one section and the legacy SMP functions in a
separate one.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Several SMP functions take read-only data. This patch fixes the
declaration of these parameters to use the const specifier as
appropriate.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The various inputs & outputs of the crypto functions as well as the
values of the ECDH keys can be considered security sensitive. They
should therefore not end up in dmesg by mistake. This patch introduces a
new SMP_DBG macro which requires explicit compilation with -DDEBUG to be
enabled. All crypto related data logs now use this macro instead of
BT_DBG.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds basic OOB pairing support when we've received the remote
OOB data. This includes tracking the remote r value (in smp->rr) as well
as doing the appropriate f4() call when needed. Previously the OOB rand
would have been stored in smp->rrnd however these are actually two
independent values so we need separate variables for them. Na/Nb in the
spec maps to smp->prnd/rrnd and ra/rb maps to smp->rr with smp->pr to
come once local OOB data is supported.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If we have OOB data available for the remote device in question we
should set the OOB flag appropriately in the SMP pairing request or
response.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds proper support for passing LE OOB data to the
hci_add_remote_oob_data() function. For LE the 192-bit values are not
valid and should therefore be passed as NULL values.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
To be able to support OOB data for LE pairing we need to store the
address type of the remote device. This patch extends the relevant
functions and data types with a bdaddr_type variable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There's no need to duplicate code for the 192 vs 192+256 variants of the
OOB data functions. This is also helpful to pave the way to support LE
SC OOB data where only 256 bit data is provided.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg