GitHub/LineageOS/G12/android_kernel_amlogic_linux-4.9.git
9 years agoBluetooth: Add workaround for broken OS X legacy SMP pairing
Johan Hedberg [Sun, 15 Mar 2015 17:34:04 +0000 (19:34 +0200)]
Bluetooth: Add workaround for broken OS X legacy SMP pairing

OS X version 10.10.2 (and possibly older versions) doesn't support LE
Secure Connections but incorrectly copies all authentication request
bits from a Security Request to its Pairing Request. The result is that
an SC capable initiator (such as BlueZ) will think OS X intends to do SC
when in fact it's incapable of it:

< ACL Data TX: Handle 3585 flags 0x00 dlen 6
      SMP: Security Request (0x0b) len 1
        Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
> ACL Data RX: Handle 3585 flags 0x02 dlen 11
      SMP: Pairing Request (0x01) len 6
        IO capability: KeyboardDisplay (0x04)
        OOB data: Authentication data not present (0x00)
        Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
        Max encryption key size: 16
        Initiator key distribution: EncKey (0x01)
        Responder key distribution: EncKey IdKey Sign (0x07)
< ACL Data TX: Handle 3585 flags 0x00 dlen 11
      SMP: Pairing Response (0x02) len 6
        IO capability: NoInputNoOutput (0x03)
        OOB data: Authentication data not present (0x00)
        Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
        Max encryption key size: 16
        Initiator key distribution: EncKey (0x01)
        Responder key distribution: EncKey Sign (0x05)

The pairing eventually fails when we get an unexpected Pairing Confirm
PDU instead of a Public Key PDU:

> ACL Data RX: Handle 3585 flags 0x02 dlen 21
      SMP: Pairing Confirm (0x03) len 16
        Confim value: bcc3bed31b8f313a78ec3cce32685faf

It is only at this point that we can speculate that the remote doesn't
really support SC. This patch creates a workaround for the just-works
model, however the MITM case is unsolvable because the OS X user has
already been requested to enter a PIN which we're now expected to
randomly generate and show the user (i.e. a chicken-and-egg problem).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Move generic mgmt command dispatcher to hci_sock.c
Johan Hedberg [Tue, 17 Mar 2015 11:48:50 +0000 (13:48 +0200)]
Bluetooth: Move generic mgmt command dispatcher to hci_sock.c

The mgmt.c file should be reserved purely for HCI_CHANNEL_CONTROL. The
mgmt_control() function in it is already completely generic and has a
single user in hci_sock.c. This patch moves the function there and
renames it a bit more appropriately to hci_mgmt_cmd() (as it's a command
dispatcher).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Add hdev_init callback for HCI channels
Johan Hedberg [Tue, 17 Mar 2015 11:48:49 +0000 (13:48 +0200)]
Bluetooth: Add hdev_init callback for HCI channels

In order to make the mgmt command handling more generic we can't have a
direct call to mgmt_init_hdev() from mgmt_control(). This patch adds a
new callback to struct hci_mgmt_chan. And sets it to point to the
mgmt_init_hdev() function for the HCI_CHANNEL_CONTROL instance.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Add generic mgmt helper API
Johan Hedberg [Tue, 17 Mar 2015 11:48:48 +0000 (13:48 +0200)]
Bluetooth: Add generic mgmt helper API

There are several mgmt protocol features that will be needed by more
than just the current HCI_CHANNEL_CONTROL. These include sending generic
events as well as handling pending commands. This patch moves these
functions out from mgmt.c to a new mgmt_util.c file.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Add channel parameter to mgmt_pending_find() API
Johan Hedberg [Tue, 17 Mar 2015 11:48:47 +0000 (13:48 +0200)]
Bluetooth: Add channel parameter to mgmt_pending_find() API

To be able to have pending commands for different HCI channels we need
to be able to distinguish for which channel a command was sent to. The
channel information is already part of the socket data and can be
fetched using the recently added hci_sock_get_channel() function. To not
require all mgmt.c code to pass an extra channel parameter this patch
also adds a helper pending_find() & pending_find_data() functions which
act as a wrapper to the new mgmt_pending_find() & mgmt_pending_find_data()
APIs.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Add helper to get HCI channel of a socket
Johan Hedberg [Tue, 17 Mar 2015 11:48:46 +0000 (13:48 +0200)]
Bluetooth: Add helper to get HCI channel of a socket

We'll need to have access to which HCI channel a socket is bound to, in
order to manage pending mgmt commands in clean way. This patch adds a
helper for the purpose.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_CSR
Jakub Pawlowski [Tue, 17 Mar 2015 16:04:17 +0000 (09:04 -0700)]
Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_CSR

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>
9 years agoBluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_INTEL
Jakub Pawlowski [Tue, 17 Mar 2015 16:04:16 +0000 (09:04 -0700)]
Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_INTEL

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>
9 years agoBluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_ATH3012
Jakub Pawlowski [Tue, 17 Mar 2015 16:04:15 +0000 (09:04 -0700)]
Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_ATH3012

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>
9 years agoBluetooth: Add simultaneous dual mode scan
Jakub Pawlowski [Tue, 17 Mar 2015 16:04:14 +0000 (09:04 -0700)]
Bluetooth: Add simultaneous dual mode scan

When doing scan through mgmt api, some controllers can do both le and
classic scan at same time. They can be distinguished by
HCI_QUIRK_SIMULTANEOUS_DISCOVERY set.

This patch enables them to use this feature when doing dual mode scan.
Instead of doing le, then classic scan, both scans are run at once.

Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Refactor BR/EDR inquiry and LE scan triggering.
Jakub Pawlowski [Tue, 17 Mar 2015 16:04:13 +0000 (09:04 -0700)]
Bluetooth: Refactor BR/EDR inquiry and LE scan triggering.

This patch refactor BR/EDR inquiry and LE scan triggering logic into
separate methods.

Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce HCI_QUIRK_SIMULTANEOUS_DISCOVERY
Jakub Pawlowski [Tue, 17 Mar 2015 16:04:12 +0000 (09:04 -0700)]
Bluetooth: Introduce HCI_QUIRK_SIMULTANEOUS_DISCOVERY

Some controllers allow both LE scan and BR/EDR inquiry to run at
the same time, while others allow only one, LE SCAN or BR/EDR
inquiry at given time.

Since this is specific to each controller, add a new quirk setting
that allows drivers to tell the core wether given controller can
do both LE scan and BR/EDR inquiry at same time.

Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoat86rf230: fix at86rf230_read_subreg succeed handling
Alexander Aring [Tue, 17 Mar 2015 09:32:39 +0000 (10:32 +0100)]
at86rf230: fix at86rf230_read_subreg succeed handling

This patch fix an issue when at86rf230_read_subreg was successful. The
function at86rf230_read_subreg will directly call regmap_read which
returns zero on successful. Nobody figured out issues yet because it was
only necessary to evaluate dvdd state while probing. This could make
trouble because the stack variable could have an random value.

The function is also used by reset the irq line before requesting irq, but
the value isn't evaluated afterwards.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: btusb: Fix minor whitespace issue in QCA ROME device entries
Marcel Holtmann [Tue, 17 Mar 2015 06:56:04 +0000 (23:56 -0700)]
Bluetooth: btusb: Fix minor whitespace issue in QCA ROME device entries

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add support for Local OOB Extended Data Update events
Marcel Holtmann [Mon, 16 Mar 2015 23:11:21 +0000 (16:11 -0700)]
Bluetooth: Add support for Local OOB Extended Data Update events

When a different user requests a new set of local out-of-band data, then
inform all previous users that the data has been updated. To limit the
scope of users, the updates are limited to previous users. If a user has
never requested out-of-band data, it will also not see the update.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Fix length for Read Local OOB Extended Data respone packet
Marcel Holtmann [Mon, 16 Mar 2015 23:05:44 +0000 (16:05 -0700)]
Bluetooth: Fix length for Read Local OOB Extended Data respone packet

The length of the respone packet for Read Local OOB Extended Data
command has a calculation error. In case LE Secure Connections support
is not enabled, the actual response is shorter. Keep this in mind and
update the value accordingly.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Do not include LE SC out-of-band data if not enabled
Marcel Holtmann [Mon, 16 Mar 2015 19:39:00 +0000 (12:39 -0700)]
Bluetooth: Do not include LE SC out-of-band data if not enabled

In case LE Secure Connections is not enabled, then the command for
returning local out-of-band data should not include the confirmation
and random value for LE SC pairing. All other fields are still valid,
but these two need to be left out. In that case it is also no needed
to generate the public/private key pair for out-of-band pairing.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: The P-256 randomizer is 16 octets long and not 19 octets
Marcel Holtmann [Mon, 16 Mar 2015 19:34:58 +0000 (12:34 -0700)]
Bluetooth: The P-256 randomizer is 16 octets long and not 19 octets

This seems to be a simple typo in the debugfs entry for the remote
out-of-band data entries.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Rename smp->local_rr into smp->local_rand
Marcel Holtmann [Mon, 16 Mar 2015 19:34:57 +0000 (12:34 -0700)]
Bluetooth: Rename smp->local_rr into smp->local_rand

The variable for the out-of-band random number was badly named and
with that confusing. Just rename it to local_rand so it is clear
what value it represents.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add extra SMP_DBG statement for remote OOB data
Marcel Holtmann [Mon, 16 Mar 2015 19:34:56 +0000 (12:34 -0700)]
Bluetooth: Add extra SMP_DBG statement for remote OOB data

Just for pure debugging purposes print the remote out-of-band data
that has been received and is going to be used.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Use smp->remote_pk + 32 instead of &smp->remote_pk[32]
Marcel Holtmann [Mon, 16 Mar 2015 19:34:55 +0000 (12:34 -0700)]
Bluetooth: Use smp->remote_pk + 32 instead of &smp->remote_pk[32]

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add clarifying comment when setting local OOB flag
Johan Hedberg [Mon, 16 Mar 2015 19:12:34 +0000 (21:12 +0200)]
Bluetooth: Add clarifying comment when setting local OOB flag

It might be a bit counterintuitive to set a 'local' flag based on remote
data. This patch adds a clarifying comment to the pairing req/rsp
handlers when setting the LOCAL_OOB flag based on the PDU received from
the remote side.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Don't send public key if OOB data verification fails
Johan Hedberg [Mon, 16 Mar 2015 16:12:57 +0000 (18:12 +0200)]
Bluetooth: Don't send public key if OOB data verification fails

When we receive the remote public key, if we have remote OOB data
there's no point in sending our public key to the remote if the OOB data
doesn't match. This patch moves the test for this higher up in the
smp_cmd_public_key() function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Fix verifying confirm value when lacking remote OOB data
Johan Hedberg [Mon, 16 Mar 2015 09:45:46 +0000 (11:45 +0200)]
Bluetooth: Fix verifying confirm value when lacking remote OOB data

If we haven't received remote OOB data we cannot perform any special
checks on the confirm value. This patch updates the check after having
received the public key to only perform the verification if we have
remote OOB data present.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Set local OOB data flag if remote has our OOB data
Johan Hedberg [Mon, 16 Mar 2015 09:45:45 +0000 (11:45 +0200)]
Bluetooth: Set local OOB data flag if remote has our OOB data

If the SMP Pairing Request or Response PDU received from the remote
device indicates that it has received our OOB data we should set the
SMP_FLAG_LOCAL_OOB flag.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Track local vs remote OOB data availability
Johan Hedberg [Mon, 16 Mar 2015 09:45:44 +0000 (11:45 +0200)]
Bluetooth: Track local vs remote OOB data availability

There are several decisions in the SMP logic that depend not only on
whether we're doing SMP or not, but also whether local and/or remote OOB
data is present. This patch splits the existing SMP_FLAG_OOB into two
new flags to track local and remote OOB data respectively.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Fix local OOB data handling for SMP
Johan Hedberg [Mon, 16 Mar 2015 09:45:43 +0000 (11:45 +0200)]
Bluetooth: Fix local OOB data handling for SMP

We need to store the local ra/rb value in order to verify the Check
value received from the remote. This patch adds a new 'lr' for the local
ra/rb value and makes sure it gets used when verifying the DHKey Check
PDU received from the remote.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoBluetooth: Use smp->local_pk + 32 instead of &smp->local_pk[32]
Marcel Holtmann [Mon, 16 Mar 2015 08:10:25 +0000 (01:10 -0700)]
Bluetooth: Use smp->local_pk + 32 instead of &smp->local_pk[32]

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Use OOB key pair for LE SC pairing with OOB method
Marcel Holtmann [Mon, 16 Mar 2015 08:10:24 +0000 (01:10 -0700)]
Bluetooth: Use OOB key pair for LE SC pairing with OOB method

The OOB public and secret key pair is different from the non-OOB pairing
procedure. SO when OOB method is in use, then use this key pair instead
of generating a new one.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Return LE SC confirm and random values for out-of-band data
Marcel Holtmann [Mon, 16 Mar 2015 08:10:23 +0000 (01:10 -0700)]
Bluetooth: Return LE SC confirm and random values for out-of-band data

Then the local out-of-band data for LE SC pairing is requested via Read
Local OOB Extended Data command, then fill in the values generated by
the smp_generate_oob function. Every call of this command will overwrite
previously generated values.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add function for generating LE SC out-of-band data
Marcel Holtmann [Mon, 16 Mar 2015 08:10:22 +0000 (01:10 -0700)]
Bluetooth: Add function for generating LE SC out-of-band data

This patch adds a smp_generate_oob function that allows to create
local out-of-band data that can be used for pairing and also provides
the confirmation and random value.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add support for AES-CMAC hash for security manager device
Marcel Holtmann [Mon, 16 Mar 2015 08:10:21 +0000 (01:10 -0700)]
Bluetooth: Add support for AES-CMAC hash for security manager device

The security manager device will require the use of AES-CMAC hash for
out-of-band data generation. This patch makes sure it is correctly
set up and available.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add constants for LE SC Confirmation and Random values
Marcel Holtmann [Mon, 16 Mar 2015 08:10:20 +0000 (01:10 -0700)]
Bluetooth: Add constants for LE SC Confirmation and Random values

The LE Secure Connections Confirmation Value and LE Secure Connections
Random Value contants are required for the out-of-band data and so
just define them.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Create SMP device structure for local crypto context
Marcel Holtmann [Mon, 16 Mar 2015 08:10:19 +0000 (01:10 -0700)]
Bluetooth: Create SMP device structure for local crypto context

Every Bluetooth Low Energy controller requires a local crypto context
to handle the resolvable private addresses. At the moment this is just
a single crypto context, but for out-of-band data generation it will
require an additional. To facility this, create a struct smp_dev that
will hold all the extra information. This patch is just the refactoring
in preparation for future changes.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Use kzfree instead of kfree in security manager
Marcel Holtmann [Mon, 16 Mar 2015 08:10:18 +0000 (01:10 -0700)]
Bluetooth: Use kzfree instead of kfree in security manager

Within the security manager, it makes sense to use kzfree instead of
kfree for all data structures. This ensures that no key material leaks
by accident.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Remove unneeded HCI_CONN_REMOTE_OOB connection flag
Marcel Holtmann [Mon, 16 Mar 2015 00:08:19 +0000 (17:08 -0700)]
Bluetooth: Remove unneeded HCI_CONN_REMOTE_OOB connection flag

The HCI_CONN_REMOTE_OOB connection flag is used to indicate if the
pairing initiator has provided out-of-band data. However since that
value is no longer used in any decision making, just remove it.

It is actually unclear what purpose the OOB data present field from
the HCI IO Capability Response event serves in the first place. If
either side provided out-of-band data, then that data will be used
for pairing.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Fix BR/EDR out-of-band pairing with only initiator data
Marcel Holtmann [Sun, 15 Mar 2015 23:42:53 +0000 (16:42 -0700)]
Bluetooth: Fix BR/EDR out-of-band pairing with only initiator data

When only the pairing initiator is providing out-of-band data, then
the receiver side was ignoring the data. For some reason the code was
checking if the initiator has received out-of-band data and only then
also provide the required inidication that the acceptor actually has
the needed data available.

For BR/EDR out-of-band pairing it is enough if one side has received
out-of-band data. There are no extra checks needed here to make this
work smoothly. The only thing that is needed is to tell the controller
if data is present (and if it is P-192 or P-256 or both) and then let
the controller actually figure out the rest.

This means the check for outgoing connection or if the initiator has
indicated data are completely pointless and are in fact actually
causing harm. The check in question is this one:

   if (conn->out || test_bit(HCI_CONN_REMOTE_OOB, &conn->flags)) {

After just taking the conditional check out and always executing the
code for determining the type of out-of-band data, the pairing works
flawlessly and prodcudes authenticated link keys.

The patch itself looks more complicated due to the reformatting of the
indentation, but it essentially just a two-line change.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add simple version of Read Local OOB Extended Data command
Marcel Holtmann [Sun, 15 Mar 2015 05:43:19 +0000 (22:43 -0700)]
Bluetooth: Add simple version of Read Local OOB Extended Data command

This adds support for the simplest possible version of Read Local OOB
Extended Data management command. It includes all mandatory fields,
but none of the actual pairing related ones.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add defines for LE Bluetooth Device Address and LE Role
Marcel Holtmann [Sun, 15 Mar 2015 05:43:18 +0000 (22:43 -0700)]
Bluetooth: Add defines for LE Bluetooth Device Address and LE Role

The OOB data requires to include LE Bluetooth Device Address and LE Role
and so add the type constants for these fields.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Move eir_append_data function to a different location
Marcel Holtmann [Sun, 15 Mar 2015 05:43:17 +0000 (22:43 -0700)]
Bluetooth: Move eir_append_data function to a different location

The eir_append_data helper function is needed for generating the
extended local OOB data fields. So move it up into the right location.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add simple version of Read Advertising Features command
Marcel Holtmann [Sun, 15 Mar 2015 03:53:25 +0000 (20:53 -0700)]
Bluetooth: Add simple version of Read Advertising Features command

This adds support for the simplest possible version of Read Advertising
Features management command. It allows basic testing of the interface.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Use BIT(n) macro instead of manually encoding (1 << n)
Marcel Holtmann [Sun, 15 Mar 2015 02:28:06 +0000 (19:28 -0700)]
Bluetooth: Use BIT(n) macro instead of manually encoding (1 << n)

The flags for the management command table used manual encoding of
bits in the form of (1 << n). It is however preferred to use BIT(n)
macro instead.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Send global configuration updates to all management users
Marcel Holtmann [Sun, 15 Mar 2015 02:28:05 +0000 (19:28 -0700)]
Bluetooth: Send global configuration updates to all management users

Changes to the global configuration updates like settings, class of
device, name etc. can be received by every user. They are allowed to
read them in the first place so provide the updates via events as
well. Otherwise untrusted users start polling for updates and that
is not a desired behavior.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Open management interface for untrusted users
Marcel Holtmann [Sun, 15 Mar 2015 02:28:04 +0000 (19:28 -0700)]
Bluetooth: Open management interface for untrusted users

Until now the management interface was restricted to CAP_NET_ADMIN. With
this change every user can open the management socket. However the list
of commands is heavily restricted to getting basic information about the
attached controllers. No access for configuration or other operation is
provided. The events are also limited. This is done so that no keys can
leak or untrusted users can mess with the Bluetooth configuration.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add support for trust verification of management commands
Marcel Holtmann [Sun, 15 Mar 2015 02:28:03 +0000 (19:28 -0700)]
Bluetooth: Add support for trust verification of management commands

Check the required trust level of each management command with the trust
level of the management socket. If it does not match up, then return the
newly introduced permission denied error.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Remove unneeded initializer for management command table
Marcel Holtmann [Sun, 15 Mar 2015 02:28:02 +0000 (19:28 -0700)]
Bluetooth: Remove unneeded initializer for management command table

The flags field for the management command table will be always
initialized to zero and thus no need to do that manually.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add support for untrusted access to management commands
Marcel Holtmann [Sun, 15 Mar 2015 02:28:01 +0000 (19:28 -0700)]
Bluetooth: Add support for untrusted access to management commands

Some management commands are safe to be accessed from any user without
special permissions. First step for allowing access to any of these
commands from untrusted application is to mark them accordingly.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add hci_sock_test_flag helper function
Marcel Holtmann [Sun, 15 Mar 2015 02:28:00 +0000 (19:28 -0700)]
Bluetooth: Add hci_sock_test_flag helper function

The management interface will need access to the socket flags and so
provide a helper function for checking them.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Consolidate socket channel sending function back into one
Marcel Holtmann [Sun, 15 Mar 2015 02:27:59 +0000 (19:27 -0700)]
Bluetooth: Consolidate socket channel sending function back into one

With the introduction of trusted socket flag for control and monitor
channels, it is now possible to use a single function for sending
packets to these sockets. And with that consolidate the handling.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce trusted flag for management control sockets
Marcel Holtmann [Sun, 15 Mar 2015 02:27:58 +0000 (19:27 -0700)]
Bluetooth: Introduce trusted flag for management control sockets

Providing a global trusted flag for management control sockets provides
an easy way for identifying sockets and imposing restriction on it. For
now all management sockets are trusted since they require CAP_NET_ADMIN.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add support for extended index management command
Marcel Holtmann [Sun, 15 Mar 2015 02:27:57 +0000 (19:27 -0700)]
Bluetooth: Add support for extended index management command

The Read Extended Contoller Index List command can be used for
retrieving the complete list of local available controllers. This
included configured, unconfigured and also AMP controllers.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add support for extended index management events
Marcel Holtmann [Sun, 15 Mar 2015 02:27:56 +0000 (19:27 -0700)]
Bluetooth: Add support for extended index management events

This introduces support for using Extended Index Added and Extended
Index Removed events. These events contain the controller type and
also the hardware bus information from the driver.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Use special function to send filter management index events
Marcel Holtmann [Sun, 15 Mar 2015 02:27:55 +0000 (19:27 -0700)]
Bluetooth: Use special function to send filter management index events

For sending Index Added, Index Removed, Unconfigured Index Added and
Unconfigured Index Removed managment events the new helper functions
allows taking into account if these events are enabled for a certain
management socket or not.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Provide hci_send_to_flagged_channel helper function
Marcel Holtmann [Sun, 15 Mar 2015 02:27:54 +0000 (19:27 -0700)]
Bluetooth: Provide hci_send_to_flagged_channel helper function

The hci_send_to_flagged_channel helper function can be used to send
packets to all channels that have a certain HCI socket flag set.

This is especially useful for managment events that are limited to
sockets that have first enabled certain functionality. This allows
for filtering of events without confusing existing users.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Add flags field and setting function for HCI sockets
Marcel Holtmann [Sun, 15 Mar 2015 02:27:53 +0000 (19:27 -0700)]
Bluetooth: Add flags field and setting function for HCI sockets

To filter out certain actions for certain HCI sockets introcuce a flags
field that allows to configure specific settings on individual sockets.

Since the hci_pinfo structure is private in hci_sock.c, provide helper
functions for setting and clearing a given flag.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agonet: dsa: do not use slave MII bus for fixed PHYs
Florian Fainelli [Sat, 14 Mar 2015 20:21:59 +0000 (13:21 -0700)]
net: dsa: do not use slave MII bus for fixed PHYs

Commit cd28a1a9baee7 ("net: dsa: fully divert PHY reads/writes if
requested") introduced a check for particular PHYs that need to be
accessed using the slave MII bus created by DSA, but this check was too
inclusive. This would prevent fixed PHYs from being successfully
registered because those should not go through the slave MII bus created
by DSA.

Make sure we check that the PHY is not a fixed PHY to prevent that from
happening.

Fixes: cd28a1a9baee7 ("net: dsa: fully divert PHY reads/writes if requested")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoMerge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next...
David S. Miller [Sat, 14 Mar 2015 19:08:02 +0000 (15:08 -0400)]
Merge branch 'master' of git://git./linux/kernel/git/jkirsher/next-queue

Jeff Kirsher says:

====================
Intel Wired LAN Driver Updates 2015-03-13

This series contains updates to ixgbe and ixgbevf.

Don adds additional support for X550 MAC types, which require additional
steps around enabling and disabling Rx.  Also cleans up variable type
inconsistency.

I provide a patch to allow relaxed ordering to be enabled on SPARC
architectures.  Also cleans up ixgbevf whitespace and code comments to
align the driver with networking coding standard.  Lastly cleaned up
uses of memcpy() where ether_addr_copy() could have been used.

Alex removes some dead code in the ixgbe cleanup patch.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoMerge branch 'listener_refactor_part_9'
David S. Miller [Sat, 14 Mar 2015 19:05:15 +0000 (15:05 -0400)]
Merge branch 'listener_refactor_part_9'

Eric Dumazet says:

====================
inet: tcp listener refactoring, part 9

This preliminary work pushes socket convergence a bit more:

1) request sock ir_iif is universally set

2) inet_diag can use common helpers to reduce LOC
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoinet_diag: factorize code in new inet_diag_msg_common_fill() helper
Eric Dumazet [Fri, 13 Mar 2015 22:51:12 +0000 (15:51 -0700)]
inet_diag: factorize code in new inet_diag_msg_common_fill() helper

Now the three type of sockets share a common base, we can factorize
code in inet_diag_msg_common_fill().

inet_diag_entry no longer requires saddr_storage & daddr_storage
and the extra copies.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoinet_diag: adjust inet_sk_diag_fill() bug condition
Eric Dumazet [Fri, 13 Mar 2015 22:51:11 +0000 (15:51 -0700)]
inet_diag: adjust inet_sk_diag_fill() bug condition

inet_sk_diag_fill() only copes with non timewait and non request socks

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoinet: fill request sock ir_iif for IPv4
Eric Dumazet [Fri, 13 Mar 2015 22:51:10 +0000 (15:51 -0700)]
inet: fill request sock ir_iif for IPv4

Once request socks will be in ehash table, they will need to have
a valid ir_iff field.

This is currently true only for IPv6. This patch extends support
for IPv4 as well.

This means inet_diag_fill_req() can now properly use ir_iif,
which is better for IPv6 link locals anyway, as request sockets
and established sockets will propagate consistent netlink idiag_if.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoMerge branch 'tipc-next'
David S. Miller [Sat, 14 Mar 2015 18:38:41 +0000 (14:38 -0400)]
Merge branch 'tipc-next'

Jon Maloy says:

====================
tipc: some optimizations and impovements

The commits in this series contain some relatively simple changes that
lead to better throughput across TIPC connections. We also make changes
to the implementation of link transmission queueing and priority
handling, in order to make the code more comprehensible and maintainable.

v2: Commit #2: Redesigned tipc_msg_validate() to use pskb_may_pull(),
               as per feedback from David Miller.
    Commit #3: Some cosmetic changes to tipc_msg_extract(). I tried to
               replace the unconditional skb_linearize() with calls to
               pskb_may_pull() at selected locations, but I gave up.
               First, skb_trim() requires a fully linearized buffer.
               Second, it doesn't make much sense; the whole buffer
               will end up linearized, one way or another.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agotipc: clean up handling of message priorities
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:11 +0000 (16:08 -0400)]
tipc: clean up handling of message priorities

Messages transferred by TIPC are assigned an "importance priority", -an
integer value indicating how to treat the message when there is link or
destination socket congestion.

There is no separate header field for this value. Instead, the message
user values have been chosen in ascending order according to perceived
importance, so that the message user field can be used for this.

This is not a good solution. First, we have many more users than the
needed priority levels, so we end up with treating more priority
levels than necessary. Second, the user field cannot always
accurately reflect the priority of the message. E.g., a message
fragment packet should really have the priority of the enveloped
user data message, and not the priority of the MSG_FRAGMENTER user.
Until now, we have been working around this problem in different ways,
but it is now time to implement a consistent way of handling such
priorities, although still within the constraint that we cannot
allocate any more bits in the regular data message header for this.

In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE,
that will be the only one used apart from the four (lower) user data
levels. All non-data messages map down to this priority. Furthermore,
we take some free bits from the MSG_FRAGMENTER header and allocate
them to store the priority of the enveloped message. We then adjust
the functions msg_importance()/msg_set_importance() so that they
read/set the correct header fields depending on user type.

This small protocol change is fully compatible, because the code at
the receiving end of a link currently reads the importance level
only from user data messages, where there is no change.

Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agotipc: split link outqueue
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:10 +0000 (16:08 -0400)]
tipc: split link outqueue

struct tipc_link contains one single queue for outgoing packets,
where both transmitted and waiting packets are queued.

This infrastructure is hard to maintain, because we need
to keep a number of fields to keep track of which packets are
sent or unsent, and the number of packets in each category.

A lot of code becomes simpler if we split this queue into a transmission
queue, where sent/unacknowledged packets are kept, and a backlog queue,
where we keep the not yet sent packets.

In this commit we do this separation.

Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agotipc: eliminate unnecessary call to broadcast ack function
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:09 +0000 (16:08 -0400)]
tipc: eliminate unnecessary call to broadcast ack function

The unicast packet header contains a broadcast acknowledge sequence
number, that may need to be conveyed to the broadcast link for proper
treatment. Currently, the function tipc_rcv(), which is on the most
critical data path, calls the function tipc_bclink_acknowledge() to
have this done. This call is made for each received packet, and results
in the unconditional grabbing of the broadcast link spinlock.

This is unnecessary, since we can see directly from tipc_rcv() if
the acknowledged number differs from what has been previously acked
from the node in question. In the vast majority of cases the numbers
won't differ, and there is nothing to update.

We now make the call to tipc_bclink_acknowledge() conditional
to that the two ack values differ.

Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agotipc: extract bundled buffers by cloning instead of copying
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:08 +0000 (16:08 -0400)]
tipc: extract bundled buffers by cloning instead of copying

When we currently extract a bundled buffer from a message bundle in
the function tipc_msg_extract(), we allocate a new buffer and explicitly
copy the linear data area.

This is unnecessary, since we can just clone the buffer and do
skb_pull() on the clone to move the data pointer to the correct
position.

This is what we do in this commit.

Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agotipc: eliminate unnecessary linearization of incoming buffers
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:07 +0000 (16:08 -0400)]
tipc: eliminate unnecessary linearization of incoming buffers

Currently, TIPC linearizes all incoming buffers directly at reception
before passing them upwards in the stack. This is clearly a waste of
CPU resources, and must be avoided.

In this commit, we eliminate this unnecessary linearization. We still
ensure that at least the message header is linear, and that the buffer
is linearized where this is still needed, i.e. when unbundling and when
reversing messages.

In addition, we ensure that fragmented messages are validated after
reassembly before delivering them upwards in the stack.

Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agotipc: move message validation function to msg.c
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:06 +0000 (16:08 -0400)]
tipc: move message validation function to msg.c

The function link_buf_validate() is in reality re-entrant and context
independent, and will in later commits be called from several locations.
Therefore, we move it to msg.c, make it outline and rename the it to
tipc_msg_validate().

We also redesign the function to make proper use of pskb_may_pull()

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agotipc: add framework for node capabilities exchange
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:05 +0000 (16:08 -0400)]
tipc: add framework for node capabilities exchange

The TIPC protocol spec has defined a 13 bit capability bitmap in
the neighbor discovery header, as a means to maintain compatibility
between different code and protocol generations. Until now this field
has been unused.

We now introduce the basic framework for exchanging capabilities
between nodes at first contact. After exchange, a peer node's
capabilities are stored as a 16 bit bitmap in struct tipc_node.

Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoMerge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetoot...
David S. Miller [Sat, 14 Mar 2015 18:29:45 +0000 (14:29 -0400)]
Merge branch 'for-upstream' of git://git./linux/kernel/git/bluetooth/bluetooth-next

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>
9 years agoieee802154: don't export static symbol
Julia Lawall [Wed, 11 Mar 2015 16:56:35 +0000 (17:56 +0100)]
ieee802154: don't export static symbol

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
type T;
identifier f;
@@

static T f (...) { ... }

@@
identifier r.f;
declarer name EXPORT_SYMBOL;
@@

-EXPORT_SYMBOL(f);
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoat86rf230: fix volatile regmap registers
Alexander Aring [Mon, 9 Mar 2015 12:56:12 +0000 (13:56 +0100)]
at86rf230: fix volatile regmap registers

These registers are also changed by transceiver and should be volatile
for right accessing via regmap debugfs.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoat86rf230: add support for calibration timeout
Alexander Aring [Mon, 9 Mar 2015 12:56:11 +0000 (13:56 +0100)]
at86rf230: add support for calibration timeout

This patch adds a handling for calibration if we are 5 minutes in PLL
state. I first tried to implement the calibration functionality in
TX_ON state via register values CF_START and DCU_START, but this occurs
a one second delay at each calibration time.

An another solution to start a calibration is to switch from TRX_OFF
state into TX_ON, then a calibration is done automatically by
transceiver. This method will be used in this patch, after each transmit
of a frame we check with jiffies if the PLL is set 5 minutes without
doing a TRX_OFF->(TX_ON || RX_AACK_ON) or channel switch. The worst case
would be a transceiver in receiving mode only, but this is under normal
operation very unlikely.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Cc: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Cc: Werner Almesberger <werner@almesberger.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoat86rf230: replace state change sleeps with hrtimer
Alexander Aring [Mon, 9 Mar 2015 12:56:10 +0000 (13:56 +0100)]
at86rf230: replace state change sleeps with hrtimer

This patch replace the state change timing relevant sleeps with
hrtimers. Currently the sleeps are done in the complete handler of
spi_async. The relation of doing the state change timing sleep with a
timer will get the sleep functionality out of spi_async complete handler
context.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoat86rf230: init xtal_trim with zero
Alexander Aring [Sat, 7 Mar 2015 21:07:07 +0000 (22:07 +0100)]
at86rf230: init xtal_trim with zero

This patch initialize xtal_trim value to zero. The xtal_trim property is
an optional device tree value. Currently if no xtal_trim property is
given the xtal_trim value can be contain random data, because it's a
stack variable. This patch init the xtal_trim value to zero which is
also the default value after reset for at86rf230 transceivers.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agomac802154: correct max sifs size handling
Alexander Aring [Wed, 4 Mar 2015 20:19:59 +0000 (21:19 +0100)]
mac802154: correct max sifs size handling

This patch fix the max sifs size correction when the
IEEE802154_HW_TX_OMIT_CKSUM flag is set. With this flag the sk_buff
doesn't contain the CRC, because the transceiver will add the CRC
while transmit.

Also add some defines for the max sifs frame size value and frame check
sequence according to 802.15.4 standard.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoieee802154: remove deprecated sysfs entries
Alexander Aring [Mon, 2 Mar 2015 14:10:05 +0000 (15:10 +0100)]
ieee802154: remove deprecated sysfs entries

It's only necessary to offer the name and index, others value are
available over netlink.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoieee802154: change wpan-phy name to phy
Alexander Aring [Mon, 2 Mar 2015 14:10:04 +0000 (15:10 +0100)]
ieee802154: change wpan-phy name to phy

Currently the wpan_phy under /sys/class/ieee802154/ is named as
"wpan-phy#", this patch will change the name to phy. This will
introduce the same naming convention like wireless.

Note: wpan-tools users will not type "wpan-phy#" anymore, just a simple
      "phy#" is enough.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoieee802154: 6lowpan: fix ARPHRD to ARPHRD_6LOWPAN
Alexander Aring [Mon, 2 Mar 2015 14:10:03 +0000 (15:10 +0100)]
ieee802154: 6lowpan: fix ARPHRD to ARPHRD_6LOWPAN

Currently there exists two interface types with ARPHRD_IEEE802154. These
are the 802.15.4 interfaces and 802.15.4 6LoWPAN interfaces. This is
more a bug because some userspace applications checks on this value like
wireshark. This occurs that wireshark will always try to parse a lowpan
interface as 802.15.4 frames. With ARPHRD_6LOWPAN wireshark will parse
it as IPv6 frames which is correct.

Much applications checks on this value to readout the EUI64 mac address
which should be the same for ARPHRD_6LOWPAN. BTLE 6LoWPAN and ieee802154
6LoWPAN will share now the same ARPHRD.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
9 years agoixgbevf: Use ether_addr_copy() instead of memcpy()
Jeff Kirsher [Sat, 14 Feb 2015 04:53:03 +0000 (04:53 +0000)]
ixgbevf: Use ether_addr_copy() instead of memcpy()

Use the macro to copy the Ethernet address instead of memcpy().

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
9 years agoixgbevf: Fix code comments and whitespace
Jeff Kirsher [Tue, 10 Feb 2015 11:42:33 +0000 (11:42 +0000)]
ixgbevf: Fix code comments and whitespace

Fix the code comments to align with drivers/net/ code commenting style,
as well as whitespace issues.  The whitespace issues resolve checkpatch
errors, like lines exceeding 80 chars (except for strings) and the use
of tabs where possible.

CC: <kernel-team@fb.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
9 years agoixgbe: Remove IXGBE_FLAG_IN_NETPOLL since it doesn't do anything
Alexander Duyck [Wed, 25 Feb 2015 17:45:54 +0000 (17:45 +0000)]
ixgbe: Remove IXGBE_FLAG_IN_NETPOLL since it doesn't do anything

This patch removes some dead code from the cleanup path for ixgbe.

Setting and clearing the flag doesn't do anything since all we are
doing is setting the flag, scheduling NAPI, clearing the flag and
then letting netpoll do the polling cleanup.  As such it doesn't
make much sense to have it there.

This patch also removes one minor white-space error.

CC: <kernel-team@fb.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
9 years agoixgbe: enable relaxed ordering for SPARC
Jeff Kirsher [Fri, 13 Mar 2015 21:04:35 +0000 (14:04 -0700)]
ixgbe: enable relaxed ordering for SPARC

This patch makes sure that relaxed ordering is not disabled when
on SPARC, where it helps with performance.

CC: <kernel-team@fb.com>
CC: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
9 years agoixgbe: cleanup make ixgbe_set_ethertype_anti_spoofing_X550 static
Don Skidmore [Fri, 13 Mar 2015 21:03:25 +0000 (14:03 -0700)]
ixgbe: cleanup make ixgbe_set_ethertype_anti_spoofing_X550 static

Correcting a mistake when I initial created this function.  I should
have made this static since it is only referenced where the function
pointer is assigned.

CC: <kernel-team@fb.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
9 years agoixgbe: Clean up type inconsistency
Don Skidmore [Fri, 13 Mar 2015 21:01:34 +0000 (14:01 -0700)]
ixgbe: Clean up type inconsistency

Missed this when I created commit 6a14ee0cfb197 ("ixgbe: Add X550 support
function pointers").  Use a the __be* type to be consistent with how the
value is assigned.

CC: <kernel-team@fb.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
9 years agoixgbe: add new wrapper for X550 support
Don Skidmore [Fri, 13 Mar 2015 20:54:30 +0000 (13:54 -0700)]
ixgbe: add new wrapper for X550 support

For the X550 mac type we have to do additional steps around
enabling/disabling Rx.  This patch will add a layer of indirection
around these support functions to enable this.

CC: <kernel-team@fb.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
9 years agoMerge branch 'bcmgenet_xmit_more'
David S. Miller [Fri, 13 Mar 2015 19:52:38 +0000 (15:52 -0400)]
Merge branch 'bcmgenet_xmit_more'

Florian Fainelli says:

====================
net: bcmgenet: xmit_more support

This patch series adds xmit_more support to the GENET driver by allowing
the deferal of the producer index write to the TDMA engine.

Changes in v2:

- move the netif_tx_stop_queue check *before* updating the producer index
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agonet: bcmgenet: add support for xmit_more
Florian Fainelli [Fri, 13 Mar 2015 19:11:07 +0000 (12:11 -0700)]
net: bcmgenet: add support for xmit_more

Delay the update of the TDMA producer index unless this is the last SKB
in a batch, or the queue is already stopped. Move the check for whether
the queue should be stopped before the xmit_more check to avoid locking
the transmit queue in case there was a SKB submitted which has xmit_more
set.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agonet: bcmgenet: update ring producer index and buffer count in xmit
Florian Fainelli [Fri, 13 Mar 2015 19:11:06 +0000 (12:11 -0700)]
net: bcmgenet: update ring producer index and buffer count in xmit

There is no need to have both bcmgenet_xmit_single() and
bcmgenet_xmit_frag() perform a free_bds decrement and a prod_index
increment by one. In case one of these functions fails to map a SKB or
fragment for transmit, we will return and exit bcmgenet_xmit() with an
error.

We can therefore safely use our local copy of nr_frags to know by how
much we should decrement the number of free buffers available, and by
how much the producer count must be incremented and do this in the tail
of bcmgenet_xmit().

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Petri Gynther <pgynther@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agonet: bcmgenet: rewrite bcmgenet_rx_refill()
Petri Gynther [Thu, 12 Mar 2015 22:48:00 +0000 (15:48 -0700)]
net: bcmgenet: rewrite bcmgenet_rx_refill()

Currently, bcmgenet_desc_rx() calls bcmgenet_rx_refill() at the end of
Rx packet processing loop, after the current Rx packet has already been
passed to napi_gro_receive(). However, bcmgenet_rx_refill() might fail
to allocate a new Rx skb, thus leaving a hole on the Rx queue where no
valid Rx buffer exists.

To eliminate this situation:
1. Rewrite bcmgenet_rx_refill() to retain the current Rx skb on the Rx
   queue if a new replacement Rx skb can't be allocated and DMA-mapped.
   In this case, the data on the current Rx skb is effectively dropped.
2. Modify bcmgenet_desc_rx() to call bcmgenet_rx_refill() at the top of
   Rx packet processing loop, so that the new replacement Rx skb is
   already in place before the current Rx skb is processed.

Signed-off-by: Petri Gynther <pgynther@google.com>
Tested-by: Jaedon Shin <jaedon.shin@gmail.com>--
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9 years agoBluetooth: Merge hdev->dbg_flags fields into hdev->dev_flags
Marcel Holtmann [Fri, 13 Mar 2015 17:20:35 +0000 (10:20 -0700)]
Bluetooth: Merge hdev->dbg_flags fields into hdev->dev_flags

With the extension of hdev->dev_flags utilizing a bitmap now, the space
is no longer restricted. Merge the hdev->dbg_flags into hdev->dev_flags
to save space on 64-bit architectures. On 32-bit architectures no size
reduction happens.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Use DECLARE_BITMAP for hdev->dev_flags field
Marcel Holtmann [Fri, 13 Mar 2015 16:04:17 +0000 (09:04 -0700)]
Bluetooth: Use DECLARE_BITMAP for hdev->dev_flags field

The hdev->dev_flags field has outgrown itself on 32-bit systems. So
instead of hacking around it, switch to using DECLARE_BITMAP.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: btusb: Add helper for READ_LOCAL_VERSION command
Daniel Drake [Tue, 24 Feb 2015 00:16:47 +0000 (18:16 -0600)]
Bluetooth: btusb: Add helper for READ_LOCAL_VERSION command

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>
9 years agoBluetooth: Introduce hci_dev_test_and_set_flag helper macro
Marcel Holtmann [Fri, 13 Mar 2015 09:11:06 +0000 (02:11 -0700)]
Bluetooth: Introduce hci_dev_test_and_set_flag helper macro

Instead of manually coding test_and_set_bit on hdev->dev_flags all the
time, use hci_dev_test_and_set_flag helper macro.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce hci_dev_test_and_clear_flag helper macro
Marcel Holtmann [Fri, 13 Mar 2015 09:11:05 +0000 (02:11 -0700)]
Bluetooth: Introduce hci_dev_test_and_clear_flag helper macro

Instead of manually coding test_and_clear_bit on hdev->dev_flags all the
time, use hci_dev_test_and_clear_flag helper macro.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce hci_dev_test_and_change_flag helper macro
Marcel Holtmann [Fri, 13 Mar 2015 09:11:04 +0000 (02:11 -0700)]
Bluetooth: Introduce hci_dev_test_and_change_flag helper macro

Instead of manually coding test_and_change_bit on hdev->dev_flags all the
time, use hci_dev_test_and_change_flag helper macro.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce hci_dev_change_flag helper macro
Marcel Holtmann [Fri, 13 Mar 2015 09:11:03 +0000 (02:11 -0700)]
Bluetooth: Introduce hci_dev_change_flag helper macro

Instead of manually coding change_bit on hdev->dev_flags all the time,
use hci_dev_change_flag helper macro.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce hci_dev_clear_flag helper macro
Marcel Holtmann [Fri, 13 Mar 2015 09:11:02 +0000 (02:11 -0700)]
Bluetooth: Introduce hci_dev_clear_flag helper macro

Instead of manually coding clear_bit on hdev->dev_flags all the time,
use hci_dev_clear_flag helper macro.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce hci_dev_set_flag helper macro
Marcel Holtmann [Fri, 13 Mar 2015 09:11:01 +0000 (02:11 -0700)]
Bluetooth: Introduce hci_dev_set_flag helper macro

Instead of manually coding set_bit on hdev->dev_flags all the time,
use hci_dev_set_flag helper macro.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9 years agoBluetooth: Introduce hci_dev_test_flag helper macro
Marcel Holtmann [Fri, 13 Mar 2015 09:11:00 +0000 (02:11 -0700)]
Bluetooth: Introduce hci_dev_test_flag helper macro

Instead of manually coding test_bit on hdev->dev_flags all the time,
use hci_dev_test_flag helper macro.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>