<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/bluetooth/mgmt.c, branch linux-3.14.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.14.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.14.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2014-07-09T18:18:26Z</updated>
<entry>
<title>Bluetooth: Fix locking of hdev when calling into SMP code</title>
<updated>2014-07-09T18:18:26Z</updated>
<author>
<name>Johan Hedberg</name>
</author>
<published>2014-06-13T07:22:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0d45819c973f83b1b4ef9bd92ffffe6083a7c526'/>
<id>urn:sha1:0d45819c973f83b1b4ef9bd92ffffe6083a7c526</id>
<content type='text'>
commit c73f94b8c093a615ce80eabbde0ac6eb9abfe31a upstream.

The SMP code expects hdev to be unlocked since e.g. crypto functions
will try to (re)lock it. Therefore, we need to release the lock before
calling into smp.c from mgmt.c. Without this we risk a deadlock whenever
the smp_user_confirm_reply() function is called.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Tested-by: Lukasz Rymanowski &lt;lukasz.rymanowski@tieto.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Bluetooth: Add an extra check in mgmt_device_disconnected()</title>
<updated>2013-12-04T13:09:03Z</updated>
<author>
<name>Andre Guedes</name>
</author>
<published>2013-10-30T22:01:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=57eb776feac497c8e5b561c0a24156245f0c08db'/>
<id>urn:sha1:57eb776feac497c8e5b561c0a24156245f0c08db</id>
<content type='text'>
This patch adds an extra check in mgmt_device_disconnected() so we only
send the "Device Disconnected" event if it is ACL_LINK or LE_LINK link
type.

Signed-off-by: Andre Guedes &lt;andre.guedes@openbossa.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Check address in mgmt_disconnect_failed()</title>
<updated>2013-12-04T13:09:03Z</updated>
<author>
<name>Andre Guedes</name>
</author>
<published>2013-10-30T22:01:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3655bba8fe693e31c44c43cd30a9aaeee8bd45df'/>
<id>urn:sha1:3655bba8fe693e31c44c43cd30a9aaeee8bd45df</id>
<content type='text'>
Check the address and address type in mgmt_disconnect_failed() otherwise
we may wrongly fail the MGMT_OP_DISCONNECT command.

Signed-off-by: Andre Guedes &lt;andre.guedes@openbossa.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Fix limited discoverable mode for Zeevo modules</title>
<updated>2013-12-04T13:09:02Z</updated>
<author>
<name>Marcel Holtmann</name>
</author>
<published>2013-10-23T15:28:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=33337dcb891e54d63433101af21fbff0b3f87bfa'/>
<id>urn:sha1:33337dcb891e54d63433101af21fbff0b3f87bfa</id>
<content type='text'>
There is an old Panasonic module with a Zeevo chip in there that is
not really operating according to Bluetooth core specification when
it comes to setting the IAC LAP for limited discoverable mode.

For reference, this is the vendor information about this module:

  &lt; HCI Command: Read Local Version Information (0x04|0x0001) plen 0
  &gt; HCI Event: Command Complete (0x0e) plen 12
        Read Local Version Information (0x04|0x0001) ncmd 1
          Status: Success (0x00)
          HCI version: Bluetooth 1.2 (0x02) - Revision 196 (0x00c4)
          LMP version: Bluetooth 1.2 (0x02) - Subversion 61 (0x003d)
          Manufacturer: Zeevo, Inc. (18)

The module reports only the support for one IAC at a time. And that
is totally acceptable according to the Bluetooth core specification
since the minimum supported IAC is only one.

  &lt; HCI Command: Read Number of Supported IAC (0x03|0x0038) plen 0
  &gt; HCI Event: Command Complete (0x0e) plen 5
        Read Number of Supported IAC (0x03|0x0038) ncmd 1
          Status: Success (0x00)
          Number of IAC: 1

The problem arises when trying to program two IAC into the module
on a controller that only supports one.

  &lt; HCI Command: Write Current IAC LAP (0x03|0x003a) plen 7
          Number of IAC: 2
          Access code: 0x9e8b00 (Limited Inquiry)
          Access code: 0x9e8b33 (General Inquiry)
  &gt; HCI Event: Command Status (0x0f) plen 4
        Write Current IAC LAP (0x03|0x003a) ncmd 1
          Status: Unknown HCI Command (0x01)

While this looks strange, but according to the Bluetooth core
specification it is a legal operation. The controller has to
ignore the other values and only program as many as it supports.

  This command shall clear any existing IACs and stores Num_Current_IAC
  and the IAC_LAPs in to the controller. If Num_Current_IAC is greater
  than Num_Support_IAC then only the first Num_Support_IAC shall be
  stored in the controller, and a Command Complete event with error
  code Success (0x00) shall be generated.

This specific controller has a bug here and just returns an error. So
in case the number of supported IAC is less than two and the limited
discoverable mode is requested, now only the LIAC is written to
the controller.

  &lt; HCI Command: Write Current IAC LAP (0x03|0x003a) plen 4
          Number of IAC: 1
          Access code: 0x9e8b00 (Limited Inquiry)
  &gt; HCI Event: Command Complete (0x0e) plen 4
        Write Current IAC LAP (0x03|0x003a) ncmd 1
          Status: Success (0x00)

All other controllers that only support one IAC seem to handle this
perfectly fine, but this fix will only write the LIAC for these
controllers as well.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Fix enabling fast connectable on LE-only controllers</title>
<updated>2013-10-21T14:18:27Z</updated>
<author>
<name>Johan Hedberg</name>
</author>
<published>2013-10-21T13:51:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=547003b114bcb96555cf73ec7f45ab64b2dcaf67'/>
<id>urn:sha1:547003b114bcb96555cf73ec7f45ab64b2dcaf67</id>
<content type='text'>
The current "fast connectable" feature is BR/EDR-only, so add a proper
check for BR/EDR support before proceeding with the associated HCI
commands.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Update Set Discoverable to support LE</title>
<updated>2013-10-20T16:05:41Z</updated>
<author>
<name>Johan Hedberg</name>
</author>
<published>2013-10-20T16:00:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9a43e25fff07a94f40d4a9e1081458e30c840256'/>
<id>urn:sha1:9a43e25fff07a94f40d4a9e1081458e30c840256</id>
<content type='text'>
This patch updates the Set Discoverable management command to also be
applicable for LE. In particular this affects the advertising flags
where we can say "general discoverable" or "limited discoverable".

Since the device flags may not be up-to-date when the advertising data
is written this patch introduces a get_adv_discov_flags() helper
function which also looks at any pending mgmt commands (a pending
set_discoverable would be the exception when the flags are not yet
correct).

The patch also adds HCI_DISCOVERABLE flag clearing to the
mgmt_discoverable_timeout function, since the code was previously
relying on the mgmt_discoverable callback to handle this, which is only
called for the BR/EDR-only HCI_Write_Scan_Enable command.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Move HCI_LIMITED_DISCOVERABLE changes to a general place</title>
<updated>2013-10-20T16:05:41Z</updated>
<author>
<name>Johan Hedberg</name>
</author>
<published>2013-10-19T20:38:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b456f87cb0c726cf97ce1e88aecfcbacf1cdf5fe'/>
<id>urn:sha1:b456f87cb0c726cf97ce1e88aecfcbacf1cdf5fe</id>
<content type='text'>
We'll soon be introducing also LE support for the Set Discoverable
management command, so move the HCI_LIMITED_DISCOVERABLE flag clearing
and setting out from the if-branch that is only used for a BR/EDR
specific HCI command.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Fix sending write_scan_enable when BR/EDR is disabled</title>
<updated>2013-10-20T16:05:40Z</updated>
<author>
<name>Johan Hedberg</name>
</author>
<published>2013-10-19T20:38:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4b580614e1435628490a1762726638546f3a5e4e'/>
<id>urn:sha1:4b580614e1435628490a1762726638546f3a5e4e</id>
<content type='text'>
We should only send the HCI_Write_Scan_Enable command from
mgmt_set_powered_failed() when BR/EDR support is enabled. This is
particularly important when the discoverable setting is also tied to LE.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Move mgmt_pending_find to avoid forward declarations</title>
<updated>2013-10-20T16:05:40Z</updated>
<author>
<name>Johan Hedberg</name>
</author>
<published>2013-10-19T20:38:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eb2a8d202f91b874d5650c9e0a2c42fdaf137d91'/>
<id>urn:sha1:eb2a8d202f91b874d5650c9e0a2c42fdaf137d91</id>
<content type='text'>
We will soon need this function for updating the advertising data, so
move it higher up in mgmt.c to avoid a forward declaration.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Fix updating settings when there are no HCI commands to send</title>
<updated>2013-10-20T16:05:40Z</updated>
<author>
<name>Johan Hedberg</name>
</author>
<published>2013-10-19T20:38:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a81070ba3743400444275cc87f8f91bb5b67dd4b'/>
<id>urn:sha1:a81070ba3743400444275cc87f8f91bb5b67dd4b</id>
<content type='text'>
It is possible that the Set Connectable management command doesn't cause
any HCI commands to send (such as when BR/EDR is disabled). We can't
just send a response to user space in this case but must also update the
necessary device flags and settings. This patch fixes the issue by using
the recently introduced set_connectable_update_settings function.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
</feed>
