bluetooth-next pull request for net-next:

core:
 - hci_sync: Add support for HCI_LE_Set_Host_Feature [v2]
 - SMP: Use AES-CMAC library API
 - sockets: convert to getsockopt_iter
 - Add SPDX id lines to some source files

drivers:
 - btintel_pcie: Support Product level reset
 - btintel_pcie: Add support for smart trigger dump
 - btintel_pcie: Add 50 ms delay before MAC init on BlazarIW
 - btintel_pcie: Separate coredump work from RX work
 - btmtk: add event filter to filter specific event
 - btrtl: fix RTL8761B/BU broken LE extended scan
 - btusb: Add Realtek RTL8922AE VID/PID 0bda/d922
 - btusb: Add Realtek RTL8922AE VID/PID 0bda/d923
 - btusb: MT7922: Add VID/PID 0e8d/223c
 - btusb: MT7925: Add VID/PID 0e8d/8c38
 - btusb: Add support for TP-Link TL-UB250
 - btusb: Add Mercusys MA530 for Realtek RTL8761BUV
 - btusb: Add TP-Link UB600 for Realtek 8761BUV
 - btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)
 - btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB
 - btusb: MT7925: Add VID/PID 13d3/3609

Bluetooth: btintel_pcie: Separate coredump work from RX work

Sharing a single workqueue between coredump processing and RX
delays evacuation of RX events while a coredump is in progress.
The firmware's RX buffers can overflow during that window, leading
to dropped events. The issue was observed in HID use cases where
HID reports arrive in bursts and quickly fill the RX path while a
coredump is being collected.

Move coredump processing to a dedicated ordered coredump_workqueue
with its own coredump_work, so coredumps run independently of RX.
All four coredump trigger sources (FW assert, HW exception, user
sysfs trigger, and resume-error detection) are switched to this new
workqueue. Ordering serialises concurrent triggers without blocking
RX.

Signed-off-by: Ravindra <ravindra@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>