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 v4:
- Use kzalloc_obj(*boot) for the boot state allocation, as requested
  by checkpatch.
- Mark the SDIO system sleep callbacks __maybe_unused for builds
  without CONFIG_PM_SLEEP.

Thanks for the report. kzalloc_obj() is defined in include/linux/slab.h
in the target bluetooth-next tree, and btaic_core.c includes that header.
Therefore, kzalloc_obj(*boot) will not cause an undefined-macro build
failure. It uses GFP_KERNEL by default and also follows checkpatch's
recommendation for this allocation.

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