<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/net/bluetooth/hci.h, branch linux-5.11.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.11.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.11.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2021-03-07T11:35:51Z</updated>
<entry>
<title>Bluetooth: Add new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk</title>
<updated>2021-03-07T11:35:51Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2021-01-28T16:33:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=561c2367cf60683de619e8040fe5ab0b9e408ac7'/>
<id>urn:sha1:561c2367cf60683de619e8040fe5ab0b9e408ac7</id>
<content type='text'>
[ Upstream commit 219991e6be7f4a31d471611e265b72f75b2d0538 ]

Some devices, e.g. the RTL8723BS bluetooth part, some USB attached devices,
completely drop from the bus on a system-suspend. These devices will
have their driver unbound and rebound on resume (when the dropping of
the bus gets detected) and will show up as a new HCI after resume.

These devices do not benefit from the suspend / resume handling work done
by the hci_suspend_notifier. At best this unnecessarily adds some time to
the suspend/resume time. But this may also actually cause problems, if the
code doing the driver unbinding runs after the pm-notifier then the
hci_suspend_notifier code will try to talk to a device which is now in
an uninitialized state.

This commit adds a new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk which allows
drivers to opt-out of the hci_suspend_notifier when they know beforehand
that their device will be fully re-initialized / reprobed on resume.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Abhishek Pandit-Subedi &lt;abhishekpandit@chromium.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Query LE tx power on startup</title>
<updated>2020-12-07T15:01:38Z</updated>
<author>
<name>Daniel Winkler</name>
<email>danielwinkler@google.com</email>
</author>
<published>2020-12-03T20:12:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7c395ea521e6c8d77f643be61bf2f0f3a1f5b3e8'/>
<id>urn:sha1:7c395ea521e6c8d77f643be61bf2f0f3a1f5b3e8</id>
<content type='text'>
Queries tx power via HCI_LE_Read_Transmit_Power command when the hci
device is initialized, and stores resulting min/max LE power in hdev
struct. If command isn't available (&lt; BT5 support), min/max values
both default to HCI_TX_POWER_INVALID.

This patch is manually verified by ensuring BT5 devices correctly query
and receive controller tx power range.

Reviewed-by: Sonny Sasaka &lt;sonnysasaka@chromium.org&gt;
Signed-off-by: Daniel Winkler &lt;danielwinkler@google.com&gt;
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: Enable controller RPA resolution using Experimental feature</title>
<updated>2020-07-30T09:14:05Z</updated>
<author>
<name>Sathish Narasimman</name>
<email>nsathish41@gmail.com</email>
</author>
<published>2020-07-23T12:39:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cbbdfa6f331980c6786b4ca5df53c37b90df3246'/>
<id>urn:sha1:cbbdfa6f331980c6786b4ca5df53c37b90df3246</id>
<content type='text'>
This patch adds support to enable the use of RPA Address resolution
using expermental feature mgmt command.

Signed-off-by: Sathish Narasimman &lt;sathish.narasimman@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Enable RPA Timeout</title>
<updated>2020-07-30T07:34:43Z</updated>
<author>
<name>Sathish Narasimman</name>
<email>nsathish41@gmail.com</email>
</author>
<published>2020-07-23T12:39:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b2cc23398e8166b38f8715026273503b081c2a7a'/>
<id>urn:sha1:b2cc23398e8166b38f8715026273503b081c2a7a</id>
<content type='text'>
Enable RPA timeout during bluetooth initialization.
The RPA timeout value is used from hdev, which initialized from
debug_fs

Signed-off-by: Sathish Narasimman &lt;sathish.narasimman@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Translate additional address type correctly</title>
<updated>2020-07-30T07:34:42Z</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2020-07-23T12:38:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6540351e6f27ef718e3cf5b46349633f3ec57859'/>
<id>urn:sha1:6540351e6f27ef718e3cf5b46349633f3ec57859</id>
<content type='text'>
When using controller based address resolution, then the new address
types 0x02 and 0x03 are used. These types need to be converted back into
either public address or random address types.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Sathish Narsimman &lt;sathish.narasimman@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers</title>
<updated>2020-07-28T07:09:00Z</updated>
<author>
<name>Ismael Ferreras Morezuelas</name>
<email>swyterzone@gmail.com</email>
</author>
<published>2020-07-26T21:12:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cde1a8a992875a7479c4321b2a4a190c2e92ec2a'/>
<id>urn:sha1:cde1a8a992875a7479c4321b2a4a190c2e92ec2a</id>
<content type='text'>
For some reason they tend to squat on the very first CSR/
Cambridge Silicon Radio VID/PID instead of paying fees.

This is an extremely common problem; the issue goes as back as 2013
and these devices are only getting more popular, even rebranded by
reputable vendors and sold by retailers everywhere.

So, at this point in time there are hundreds of modern dongles reusing
the ID of what originally was an early Bluetooth 1.1 controller.

Linux is the only place where they don't work due to spotty checks
in our detection code. It only covered a minimum subset.

So what's the big idea? Take advantage of the fact that all CSR
chips report the same internal version as both the LMP sub-version and
HCI revision number. It always matches, couple that with the manufacturer
code, that rarely lies, and we now have a good idea of who is who.

Additionally, by compiling a list of user-reported HCI/lsusb dumps, and
searching around for legit CSR dongles in similar product ranges we can
find what CSR BlueCore firmware supported which Bluetooth versions.

That way we can narrow down ranges of fakes for each of them.

e.g. Real CSR dongles with LMP subversion 0x73 are old enough that
     support BT 1.1 only; so it's a dead giveaway when some
     third-party BT 4.0 dongle reuses it.

So, to sum things up; there are multiple classes of fake controllers
reusing the same 0A12:0001 VID/PID. This has been broken for a while.

Known 'fake' bcdDevices: 0x0100, 0x0134, 0x1915, 0x2520, 0x7558, 0x8891
  IC markings on 0x7558: FR3191AHAL 749H15143 (???)

https://bugzilla.kernel.org/show_bug.cgi?id=60824

Fixes: 81cac64ba258ae (Deal with USB devices that are faking CSR vendor)
Reported-by: Michał Wiśniewski &lt;brylozketrzyn@gmail.com&gt;
Tested-by: Mike Johnson &lt;yuyuyak@gmail.com&gt;
Tested-by: Ricardo Rodrigues &lt;ekatonb@gmail.com&gt;
Tested-by: M.Hanny Sabbagh &lt;mhsabbagh@outlook.com&gt;
Tested-by: Oussama BEN BRAHIM &lt;b.brahim.oussama@gmail.com&gt;
Tested-by: Ismael Ferreras Morezuelas &lt;swyterzone@gmail.com&gt;
Signed-off-by: Ismael Ferreras Morezuelas &lt;swyterzone@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: use configured params for ext adv</title>
<updated>2020-06-22T14:03:46Z</updated>
<author>
<name>Alain Michaud</name>
<email>alainm@chromium.org</email>
</author>
<published>2020-06-22T13:30:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5cbd3ebde859bd43bd0584c146060638b1a3abb4'/>
<id>urn:sha1:5cbd3ebde859bd43bd0584c146060638b1a3abb4</id>
<content type='text'>
When the extended advertisement feature is enabled, a hardcoded min and
max interval of 0x8000 is used.  This patch fixes this issue by using
the configured min/max value.

This was validated by setting min/max in main.conf and making sure the
right setting is applied:

&lt; HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen
25                                          #93 [hci0] 10.953011
…
Min advertising interval: 181.250 msec (0x0122)
Max advertising interval: 181.250 msec (0x0122)
…

Signed-off-by: Alain Michaud &lt;alainm@chromium.org&gt;
Reviewed-by: Abhishek Pandit-Subedi &lt;abhishekpandit@chromium.org&gt;
Reviewed-by: Daniel Winkler &lt;danielwinkler@google.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Add support for experimental features configuration</title>
<updated>2020-05-11T10:13:38Z</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2020-05-06T07:57:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a10c907ce0e5e138c3da091fcb7c3d109a15aec5'/>
<id>urn:sha1:a10c907ce0e5e138c3da091fcb7c3d109a15aec5</id>
<content type='text'>
To enable platform specific experimental features, introduce this new set of
management commands and events.

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: Adding driver and quirk defs for multi-role LE</title>
<updated>2020-04-28T09:49:01Z</updated>
<author>
<name>Alain Michaud</name>
<email>alainm@chromium.org</email>
</author>
<published>2020-04-23T14:43:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=220915857e29795ae5ba4222806268b4a99c19c1'/>
<id>urn:sha1:220915857e29795ae5ba4222806268b4a99c19c1</id>
<content type='text'>
This change adds the relevant driver and quirk to allow drivers to
report the le_states as being trustworthy.

This has historically been disabled as controllers did not reliably
support this. In particular, this will be used to relax this condition
for controllers that have been well tested and reliable.

	/* Most controller will fail if we try to create new connections
	 * while we have an existing one in slave role.
	 */
	if (hdev-&gt;conn_hash.le_num_slave &gt; 0)
		return NULL;

Signed-off-by: Alain Michaud &lt;alainm@chromium.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Enable LE Enhanced Connection Complete event.</title>
<updated>2020-04-15T13:51:05Z</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2020-04-09T06:05:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ff3b8df2bd758d97aa3dd7c021864be05fec9bd5'/>
<id>urn:sha1:ff3b8df2bd758d97aa3dd7c021864be05fec9bd5</id>
<content type='text'>
In case LL Privacy is supported by the controller, it is also a good
idea to use the LE Enhanced Connection Complete event for getting all
information about the new connection and its addresses.

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