<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/bluetooth/btintel.c, branch linux-6.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-10-29T13:09:00Z</updated>
<entry>
<title>Bluetooth: btintel: Add DSBR support for BlazarIW, BlazarU and GaP</title>
<updated>2025-10-29T13:09:00Z</updated>
<author>
<name>Kiran K</name>
</author>
<published>2024-10-15T12:27:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ca44ae51b99c0388d60a7879bce5fc0eafe4f52f'/>
<id>urn:sha1:ca44ae51b99c0388d60a7879bce5fc0eafe4f52f</id>
<content type='text'>
commit d88a8bb8bbbec9d57b84232a2d6f8dab84221959 upstream.

Add DSBR support for BlazarIW, BlazarU and Gale Peak2 cores.

Refer commit eb9e749c0182 ("Bluetooth: btintel: Allow configuring drive
strength of BRI") for details about DSBR.

Signed-off-by: Kiran K &lt;kiran.k@intel.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Cc: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Cc: Guido Berhoerster &lt;guido+debian@berhoerster.name&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: btintel: Check if controller is ISO capable on btintel_classify_pkt_type</title>
<updated>2025-07-24T06:56:25Z</updated>
<author>
<name>Luiz Augusto von Dentz</name>
</author>
<published>2025-07-09T19:02:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9e11e0db4e27c9690958ad65526c123ff20f3b1a'/>
<id>urn:sha1:9e11e0db4e27c9690958ad65526c123ff20f3b1a</id>
<content type='text'>
commit 6ec3185fbc3528f2284c347fb9bd8be6fa672ed4 upstream.

Due to what seem to be a bug with variant version returned by some
firmwares the code may set hdev-&gt;classify_pkt_type with
btintel_classify_pkt_type when in fact the controller doesn't even
support ISO channels feature but may use the handle range expected from
a controllers that does causing the packets to be reclassified as ISO
causing several bugs.

To fix the above btintel_classify_pkt_type will attempt to check if the
controller really supports ISO channels and in case it doesn't don't
reclassify even if the handle range is considered to be ISO, this is
considered safer than trying to fix the specific controller/firmware
version as that could change over time and causing similar problems in
the future.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=219553
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2100565
Link: https://github.com/StarLabsLtd/firmware/issues/180
Fixes: f25b7fd36cc3 ("Bluetooth: Add vendor-specific packet classification for ISO data")
Cc: stable@vger.kernel.org
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Tested-by: Sean Rhodes &lt;sean@starlabs.systems&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: btintel: Check dsbr size from EFI variable</title>
<updated>2025-06-19T13:31:53Z</updated>
<author>
<name>Kees Cook</name>
</author>
<published>2025-05-20T16:31:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9427f6081f37c795a8bd29d0ee72a4da3bd64af8'/>
<id>urn:sha1:9427f6081f37c795a8bd29d0ee72a4da3bd64af8</id>
<content type='text'>
[ Upstream commit 3aa1dc3c9060e335e82e9c182bf3d1db29220b1b ]

Since the size of struct btintel_dsbr is already known, we can just
start there instead of querying the EFI variable size. If the final
result doesn't match what we expect also fail. This fixes a stack buffer
overflow when the EFI variable is larger than struct btintel_dsbr.

Reported-by: zepta &lt;z3ptaa@gmail.com&gt;
Closes: https://lore.kernel.org/all/CAPBS6KoaWV9=dtjTESZiU6KK__OZX0KpDk-=JEH8jCHFLUYv3Q@mail.gmail.com
Fixes: eb9e749c0182 ("Bluetooth: btintel: Allow configuring drive strength of BRI")
Signed-off-by: Kees Cook &lt;kees@kernel.org&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: btintel: Do no pass vendor events to stack</title>
<updated>2024-12-05T13:01:58Z</updated>
<author>
<name>Kiran K</name>
</author>
<published>2024-10-17T11:51:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=90fe2941f54e0250c15bd6bd3f24082c7ebf3fa1'/>
<id>urn:sha1:90fe2941f54e0250c15bd6bd3f24082c7ebf3fa1</id>
<content type='text'>
[ Upstream commit 510e8380b0382ee3b070748656b00f83c9a5bf80 ]

During firmware download, vendor specific events like boot up and
secure send result are generated. These events can be safely processed at
the driver level. Passing on these events to stack prints unnecessary
log as below.

    Bluetooth: hci0: Malformed MSFT vendor event: 0x02

Fixes: 3368aa357f3b ("Bluetooth: msft: Handle MSFT Monitor Device Event")
Signed-off-by: Kiran K &lt;kiran.k@intel.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: btintel_pcie: Add handshake between driver and firmware</title>
<updated>2024-12-05T13:01:58Z</updated>
<author>
<name>Kiran K</name>
</author>
<published>2024-10-01T10:44:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c670ebfd82585f74efe81c91a2d4580f8873acb0'/>
<id>urn:sha1:c670ebfd82585f74efe81c91a2d4580f8873acb0</id>
<content type='text'>
[ Upstream commit 05c200c8f0295c9c91beeb3ee0552331c1f8adbe ]

The following handshake mechanism needs be followed after firmware
download is completed to bring the firmware to running state.

After firmware fragments of Operational image are downloaded and
secure sends result of the image succeeds,

1. Driver sends HCI Intel reset with boot option #1 to switch FW image.
2. FW sends Alive GP[0] MSIx
3. Driver enables data path (doorbell 0x460 for RBDs, etc...)
4. Driver gets Bootup event from firmware
5. Driver performs D0 entry to device (WRITE to IPC_Sleep_Control =0x0)
6. FW sends Alive GP[0] MSIx
7. Device host interface is fully set for BT protocol stack operation.
8. Driver may optionally get debug event with ID 0x97 which can be dropped

For Intermediate loadger image, all the above steps are applicable
expcept #5 and #6.

On HCI_OP_RESET, firmware raises alive interrupt. Driver needs to wait
for it before passing control over to bluetooth stack.

Co-developed-by: Devegowda Chandrashekar &lt;chandrashekar.devegowda@intel.com&gt;
Signed-off-by: Devegowda Chandrashekar &lt;chandrashekar.devegowda@intel.com&gt;
Signed-off-by: Kiran K &lt;kiran.k@intel.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Stable-dep-of: 510e8380b038 ("Bluetooth: btintel: Do no pass vendor events to stack")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: btintel: Direct exception event to bluetooth stack</title>
<updated>2024-11-12T16:39:12Z</updated>
<author>
<name>Kiran K</name>
</author>
<published>2024-10-22T09:11:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d5359a7f583ab9b7706915213b54deac065bcb81'/>
<id>urn:sha1:d5359a7f583ab9b7706915213b54deac065bcb81</id>
<content type='text'>
Have exception event part of HCI traces which helps for debug.

snoop traces:
&gt; HCI Event: Vendor (0xff) plen 79
        Vendor Prefix (0x8780)
      Intel Extended Telemetry (0x03)
        Unknown extended telemetry event type (0xde)
        01 01 de
        Unknown extended subevent 0x07
        01 01 de 07 01 de 06 1c ef be ad de ef be ad de
        ef be ad de ef be ad de ef be ad de ef be ad de
        ef be ad de 05 14 ef be ad de ef be ad de ef be
        ad de ef be ad de ef be ad de 43 10 ef be ad de
        ef be ad de ef be ad de ef be ad de

Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support")
Signed-off-by: Kiran K &lt;kiran.k@intel.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
</entry>
<entry>
<title>move asm/unaligned.h to linux/unaligned.h</title>
<updated>2024-10-02T21:23:23Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2024-10-01T19:35:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5f60d5f6bbc12e782fac78110b0ee62698f3b576'/>
<id>urn:sha1:5f60d5f6bbc12e782fac78110b0ee62698f3b576</id>
<content type='text'>
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.

auto-generated by the following:

for i in `git grep -l -w asm/unaligned.h`; do
	sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
	sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
</content>
</entry>
<entry>
<title>Bluetooth: btintel: Allow configuring drive strength of BRI</title>
<updated>2024-08-23T19:56:03Z</updated>
<author>
<name>Kiran K</name>
</author>
<published>2024-07-18T14:48:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eb9e749c0182affafadfbe5ded4503c4b5a9b57c'/>
<id>urn:sha1:eb9e749c0182affafadfbe5ded4503c4b5a9b57c</id>
<content type='text'>
BRI (Bluetooth Radio Interface) traffic from CNVr to CNVi was found causing
cross talk step errors to WiFi. To avoid this potential issue OEM platforms
can replace BRI resistor to adjust the BRI response line drive strength.
During the *setup*, driver reads the drive strength value from uefi
variable and passes it to the controller via vendor specific command with
opcode 0xfc0a.

dmesg:

..
[21.982720] Bluetooth: hci0: Bootloader timestamp 2023.33 buildtype 1 build 45995
[21.984250] Bluetooth: hci0: Found device firmware: intel/ibt-0190-0291-iml.sfi
[21.984255] Bluetooth: hci0: Boot Address: 0x30099000
[21.984256] Bluetooth: hci0: Firmware Version: 160-24.24
[22.011501] Bluetooth: hci0: Waiting for firmware download to complete
[22.011518] Bluetooth: hci0: Firmware loaded in 26624 usecs
[22.011584] Bluetooth: hci0: Waiting for device to boot
[22.013546] Bluetooth: hci0: Malformed MSFT vendor event: 0x02
[22.013552] Bluetooth: hci0: Device booted in 1967 usecs
...
[22.013792] Bluetooth: hci0: dsbr: enable: 0x01 value: 0x0b
...
[22.015027] Bluetooth: hci0: Found device firmware: intel/ibt-0190-0291.sfi
[22.015041] Bluetooth: hci0: Boot Address: 0x10000800
[22.015043] Bluetooth: hci0: Firmware Version: 160-24.24
[22.395821] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[22.395828] Bluetooth: BNEP filters: protocol multicast
...

Signed-off-by: Kiran K &lt;kiran.k@intel.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
</entry>
<entry>
<title>Bluetooth: HCI: Invert LE State quirk to be opt-out rather then opt-in</title>
<updated>2024-08-15T17:07:55Z</updated>
<author>
<name>Luiz Augusto von Dentz</name>
</author>
<published>2024-08-12T14:43:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aae6b81260fd9a7224f7eb4fc440d625852245bb'/>
<id>urn:sha1:aae6b81260fd9a7224f7eb4fc440d625852245bb</id>
<content type='text'>
This inverts the LE State quirk so by default we assume the controllers
would report valid states rather than invalid which is how quirks
normally behave, also this would result in HCI command failing it the LE
States are really broken thus exposing the controllers that are really
broken in this respect.

Link: https://github.com/bluez/bluez/issues/584
Fixes: 220915857e29 ("Bluetooth: Adding driver and quirk defs for multi-role LE")
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
</entry>
<entry>
<title>Bluetooth: btintel: Fail setup on error</title>
<updated>2024-07-26T14:53:56Z</updated>
<author>
<name>Kiran K</name>
</author>
<published>2024-07-03T08:52:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e22a3a9d4134d7e6351a2998771522e74bcc58da'/>
<id>urn:sha1:e22a3a9d4134d7e6351a2998771522e74bcc58da</id>
<content type='text'>
Do not attempt to send any hci command to controller if *setup* function
fails.

Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support")
Signed-off-by: Kiran K &lt;kiran.k@intel.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
</entry>
</feed>
