<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/net/bluetooth, branch v5.10</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.10</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.10'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2020-09-25T18:21:55Z</updated>
<entry>
<title>Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel</title>
<updated>2020-09-25T18:21:55Z</updated>
<author>
<name>Luiz Augusto von Dentz</name>
<email>luiz.von.dentz@intel.com</email>
</author>
<published>2020-08-06T18:17:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f19425641cb2572a33cb074d5e30283720bd4d22'/>
<id>urn:sha1:f19425641cb2572a33cb074d5e30283720bd4d22</id>
<content type='text'>
Only sockets will have the chan-&gt;data set to an actual sk, channels
like A2MP would have its own data which would likely cause a crash when
calling sk_filter, in order to fix this a new callback has been
introduced so channels can implement their own filtering if necessary.

Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Emit controller suspend and resume events</title>
<updated>2020-09-13T07:55:26Z</updated>
<author>
<name>Abhishek Pandit-Subedi</name>
<email>abhishekpandit@chromium.org</email>
</author>
<published>2020-09-11T21:07:13Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2f20216c1d6fe17c1a224f658be0dc6fab2269c7'/>
<id>urn:sha1:2f20216c1d6fe17c1a224f658be0dc6fab2269c7</id>
<content type='text'>
Emit controller suspend and resume events when we are ready for suspend
and we've resumed from suspend.

The controller suspend event will report whatever suspend state was
successfully entered. The controller resume event will check the first
HCI event that was received after we finished preparing for suspend and,
if it was a connection event, store the address of the peer that caused
the event. If it was not a connection event, we mark the wake reason as
an unexpected event.

Here is a sample btmon trace with these events:

@ MGMT Event: Controller Suspended (0x002d) plen 1
        Suspend state: Page scanning and/or passive scanning (2)

@ MGMT Event: Controller Resumed (0x002e) plen 8
        Wake reason: Remote wake due to peer device connection (2)
        LE Address: CD:F3:CD:13:C5:9A (OUI CD-F3-CD)

Signed-off-by: Abhishek Pandit-Subedi &lt;abhishekpandit@chromium.org&gt;
Reviewed-by: Miao-chen Chou &lt;mcchou@chromium.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Add suspend reason for device disconnect</title>
<updated>2020-09-13T07:54:28Z</updated>
<author>
<name>Abhishek Pandit-Subedi</name>
<email>abhishekpandit@chromium.org</email>
</author>
<published>2020-09-11T21:07:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f0cfc486f796dc3b67a4017357a6a8e76a8141c5'/>
<id>urn:sha1:f0cfc486f796dc3b67a4017357a6a8e76a8141c5</id>
<content type='text'>
Update device disconnect event with reason 0x5 to indicate that device
disconnected because the controller is suspending.

Signed-off-by: Abhishek Pandit-Subedi &lt;abhishekpandit@chromium.org&gt;
Reviewed-by: Miao-chen Chou &lt;mcchou@chromium.org&gt;
Reviewed-by: Sonny Sasaka &lt;sonnysasaka@chromium.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Add mgmt suspend and resume events</title>
<updated>2020-09-13T07:54:00Z</updated>
<author>
<name>Abhishek Pandit-Subedi</name>
<email>abhishekpandit@chromium.org</email>
</author>
<published>2020-09-11T21:07:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=346ce5b7d624e8cc2ec5a6abd0ea00f0e06ea8ac'/>
<id>urn:sha1:346ce5b7d624e8cc2ec5a6abd0ea00f0e06ea8ac</id>
<content type='text'>
Add the controller suspend and resume events, which will signal when
Bluetooth has completed preparing for suspend and when it's ready for
resume.

Signed-off-by: Abhishek Pandit-Subedi &lt;abhishekpandit@chromium.org&gt;
Reviewed-by: Miao-chen Chou &lt;mcchou@chromium.org&gt;
Reviewed-by: Sonny Sasaka &lt;sonnysasaka@chromium.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Add MGMT capability flags for tx power and ext advertising</title>
<updated>2020-09-11T07:17:26Z</updated>
<author>
<name>Daniel Winkler</name>
<email>danielwinkler@google.com</email>
</author>
<published>2020-08-25T23:31:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d5ea32da878d4572761ca4580631748e398542de'/>
<id>urn:sha1:d5ea32da878d4572761ca4580631748e398542de</id>
<content type='text'>
For new advertising features, it will be important for userspace to
know the capabilities of the controller and kernel. If the controller
and kernel support extended advertising, we include flags indicating
hardware offloading support and support for setting tx power of adv
instances.

In the future, vendor-specific commands may allow the setting of tx
power in advertising instances, but for now this feature is only
marked available if extended advertising is supported.

This change is manually verified in userspace by ensuring the
advertising manager's supported_flags field is updated with new flags on
hatch chromebook (ext advertising supported).

Signed-off-by: Daniel Winkler &lt;danielwinkler@google.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&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://git.shady.money/linux/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://git.shady.money/linux/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: Configure controller address resolution if available</title>
<updated>2020-07-30T07:34:42Z</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2020-07-23T12:38:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e1d572357599d142df5764b39731b6eb55a22beb'/>
<id>urn:sha1:e1d572357599d142df5764b39731b6eb55a22beb</id>
<content type='text'>
When the LL Privacy support is available, then as part of enabling or
disabling passive background scanning, it is required to set up the
controller based address resolution as well.

Since only passive background scanning is utilizing the whitelist, the
address resolution is now bound to the whitelist and passive background
scanning. All other resolution can be easily done by the host stack.

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: 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://git.shady.money/linux/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://git.shady.money/linux/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>
</feed>
