Hi,

This series adds Bluetooth support for the AIC8800D80. SDIO function 1
loads firmware; a serdev UART carries H4 HCI traffic at 1500000 baud with
hardware flow control. The three patches add the AIC vendor prefix, the
Device Tree binding, and the driver with build and maintainer integration.

Changes since v3:
- Clear uart->rx_skb when serdev_device_open() or baudrate setup fails.
  RX may have started before open returns; the HCI core does not call the
  driver's close callback after an open failure. The buffer remains
  reachable and would be freed on removal, so the issue is stale RX state
  and retained memory after a failed open, rather than necessarily a
  permanent leak. serdev_device_open() can also enable the controller and
  then roll back after a runtime PM failure.
- Adjust the binding's SDIO reg constraint and use kzalloc() for the boot
  state allocation in the target tree.

Review of the other reported findings:
- The TX/RX IPC layouts are intentionally asymmetric, as in the AIC BSP.
  TX has a 4-byte dummy word before the message ID; RX has a 4-byte pattern
  after param_len. The BSP RX path casts the buffer at offset 4 to
  struct ipc_e2a_msg. Accordingly, the RX response ID is at frame offset 4
  and param_len at offset 10. The reported firmware-loading layout mismatch
  is a false positive.
- In this target tree h4_recv_buf() takes struct hci_uart * and forwards
  hu->hdev to h4_recv_skb(). The driver sets uart->hu.hdev before
  hci_register_dev(), so passing &uart->hu is type-correct. Commit
  b489556a856d ("Bluetooth: fix corruption in h4_recv_buf() after cleanup")
  changed this API; the reported type mismatch refers to the older API.
- If skb_cow_head() fails, aic_bt_send_frame() returns the error without
  consuming the skb. hci_send_frame() frees the skb when ->send() returns
  an error; freeing it in the driver would cause a double free. The
  reported skb leak is a false positive.
- sdio_bus_probe() releases the MMC host before the driver probe, and
  aic_bt_sdio_hw_init() releases it before firmware loading. No
  request_firmware() call holds the MMC host or AIC command locks. The
  command path also releases the host before waiting for IRQ completion.
  Synchronous firmware loading may delay probe, but the reported SDIO
  deadlock does not apply.

The bluez.test.bot mgmt-tester and mesh-tester failures also reproduce
with unrelated patches and appear to be CI test failures. The GitLint
failure is caused by the automatically generated "create mode" line for
the DT binding path.

Validation: The vendor has confirmed SDIO firmware loading. UART HCI
communication, controller initialization, scanning, pairing, connections,
data transfer, suspend/resume, and Wi-Fi/Bluetooth coexistence have not
been validated on hardware. The external firmware files are not included
in this series.

Thanks,
Yanli

Yanli Yang (3):
  dt-bindings: vendor-prefixes: Add AIC Semiconductor
  dt-bindings: net: bluetooth: Add AIC8800D80
  Bluetooth: btaic: Add AIC8800D80 SDIO loader and UART transport

 .../net/bluetooth/aic,aic8800d80-bt.yaml      |  84 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 MAINTAINERS                                   |  11 +
 drivers/bluetooth/Kconfig                     |  16 +
 drivers/bluetooth/Makefile                    |   3 +
 drivers/bluetooth/btaic.h                     |  26 +
 drivers/bluetooth/btaic_core.c                | 180 ++++
 drivers/bluetooth/btaic_sdio.c                | 901 ++++++++++++++++++
 drivers/bluetooth/btaic_uart.c                | 337 +++++++
 9 files changed, 1560 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/bluetooth/aic,aic8800d80-bt.yaml
 create mode 100644 drivers/bluetooth/btaic.h
 create mode 100644 drivers/bluetooth/btaic_core.c
 create mode 100644 drivers/bluetooth/btaic_sdio.c
 create mode 100644 drivers/bluetooth/btaic_uart.c

-- 
2.34.1