## Summary

A CSR8510A10 USB Bluetooth dongle (`0a12:0001`) fails to initialize under Omarchy 4.0.4 with `linux-omarchy 7.2.5-3-omarchy`. The device enumerates and `btusb` binds to it, but the HCI controller never responds, so `/dev/hci0` is never created and BlueZ reports `No default controller available`.

The same dongle works correctly on a Windows installation on the same machine, so this is not a hardware failure.

I believe the root cause is upstream (`btusb`'s legacy CSR support vs. a 7.2 kernel), not Omarchy itself. Posting here because it blocks Bluetooth on an Omarchy install and because item 2 below *is* an Omarchy bug.

---

## 1. Bluetooth: `btusb` cannot initialize CSR8510A10

### Environment

| | |
|---|---|
| OS | Omarchy 4.0.4-1 (Arch base) |
| Kernel | `linux-omarchy 7.2.5-3-omarchy` (7.2.5, built `Mon Sep 14 2026 19:55:01 +0000`) |
| Desktop | Hyprland 0.56.2 |
| BlueZ | `bluez` / `bluez-utils` 5.87-2 |
| `btusb` | version `0.8`, srcversion `D7FFD395282641FFD93A3E2`, vermagic `7.2.5-3-omarchy` |
| USB stack | `xhci_hcd` (built-in), 12 Mb/s (USB 1.1 full-speed) |

### Device

```
Bus 001 Device 007: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
usb 1-7: Product: CSR8510A10
bcdDevice=88.91   version=2.00   speed=12   bMaxPower=100mA
bDeviceClass=0xe0 bDeviceSubClass=0x01 bDeviceProtocol=0x01
```

`lsusb -t` confirms binding on both interfaces:

```
Port 007: Dev 007, If 0, Class=Wireless, Driver=btusb, 12M
Port 007: Dev 007, If 1, Class=Wireless, Driver=btusb, 12M
```

The device matches `btusb`'s generic class alias `usb:v*p*d*dc*iscE0isc01ip01in*`, which is how CSR devices bind.

### Kernel log

Clean enumeration, then a hang during CSR setup:

```
[6075.441898] usb 1-7: new full-speed USB device number 7 using xhci_hcd
[6075.565431] usb 1-7: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[6075.566006] usb 1-7: Product: CSR8510A10
[6075.573472] Bluetooth: hci0: CSR: Setting up dongle with HCI ver=6 rev=22bb
[6075.573477] Bluetooth: hci0: LMP ver=6 subver=22bb; manufacturer=10
[6077.673754] Bluetooth: hci0: Opcode 0x0c5a failed: -110
```

After any rebind, it fails earlier still, on the most basic HCI command:

```
[6127.594069] Bluetooth: hci0: command 0x1001 tx timeout
[6127.594081] Bluetooth: hci0: CSR: Local version failed (-110)
```

### Two failure modes observed

| Trigger | Failing opcode | Command |
|---|---|---|
| Fresh enumeration | `0x0c5a` | CSR vendor command |
| After unbind/bind, port reset, module reload | `0x1001` | `Read Local Version` (standard HCI) |

`0x1001` is the first command any HCI driver sends. A device that enumerates, binds, and then ignores `Read Local Version` is not failing on driver ordering.

`-110` is `ETIMEDOUT`: the USB transaction completes but no HCI response arrives.

### Symptom

```
$ bluetoothctl show
No default controller available

$ btmgmt info
Reading hci0 info failed with status 0x11 (Invalid Index)

$ ls /dev/hci*
ls: cannot access '/dev/hci*': No such file or directory

$ rfkill list
10: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

$ ls /sys/class/bluetooth/hci0/
device  power  reset  rfkill10  subsystem  uevent
```

`hci0` exists in sysfs but has **no `address`, `name`, or `class` attributes**, and no `dev` node. `hci_dev_register()` never completes. `bluetoothd` runs fine (13h uptime) but has no adapter to attach to. `rfkill` sees the device and it is not blocked, so this is not a software block.

### What was tested and ruled out

**Hardware failure** — ruled out. The identical dongle enumerates and pairs correctly on a Windows install on the same machine.

**USB port / signalling** — ruled out. Tested on two separate ports behind different hubs (`1-9` behind the ASM2142 at 12 Mb/s, `1-7` on a different hub port). Identical failure both times, identical `bcdDevice`, identical log sequence.

**USB autosuspend** — ruled out. There is a tempting correlation: each probe fails 2.1 s after setup begins, and the dongle's autosuspend delay is 2 s:

```
probe 164.273s -> timeout 166.391s = 2.118 s
probe 310.531s -> timeout 312.631s = 2.100 s
```

That correlation is a red herring — 2.1 s is `btusb`'s own init command timeout, not a suspend. Forcing `power/control=on` and `power/autosuspend=-1` changed nothing. (Note this is unrelated to item 2 below, which *is* a real bug.)

**`btusb reset=0`** — ruled out. `/etc/modprobe.d/btusb.conf` contains `options btusb reset=0`. Reloading the module with `reset=1` still gave `0x1001 tx timeout`.

**Module reload** — ruled out. `modprobe -r btusb && modprobe btusb` re-registers cleanly, then fails 2 s later on `0x1001`.

### Reproduction

```bash
# any of these reproduce it; the dongle must be plugged in first
modprobe -r btusb && modprobe btusb
echo "1-7:1.0" > /sys/bus/usb/drivers/btusb/unbind
echo "1-7:1.0" > /sys/bus/usb/drivers/btusb/bind
echo 0 > /sys/bus/usb/devices/1-7/authorized && echo 1 > /sys/bus/usb/devices/1-7/authorized
```

### Assessment

`btusb`'s CSR support is legacy. There are no CSR firmware blobs in the tree:

```bash
$ find /usr/lib/firmware -iname "*csr*"
# no output
```

CSR support is compiled into `btusb` itself rather than loaded as firmware, which is why the log reads `CSR: Setting up dongle` rather than showing a firmware load. The driver reaches the chip and then gets no response back.

I suspect this needs an upstream fix in `btusb`, not an Omarchy-side workaround. The CSR8510 dates from 2010-2012. Practical resolution for users is a dongle with a Realtek or Qualcomm chipset; this machine's motherboard has no integrated Bluetooth, so there is no fallback adapter.

Happy to provide more logs, test additional kernel versions (`linux-lts 6.18.49` is available in `core`), or try other configurations if useful.

---

## 2. `omarchy-usb-autosuspend.conf` has no effect

Separate bug, found while diagnosing the above, and it affects every Omarchy user with USB devices.

`/etc/modprobe.d/omarchy-usb-autosuspend.conf`, shipped by `omarchy-settings 4.0.4-1`, contains:

```
options usbcore autosuspend=-1
```

**This does nothing.** `usbcore` is compiled into the kernel, so it is not listed in `/proc/modules`:

```bash
$ grep usbcore /proc/modules
# no output — built-in

$ cat /sys/module/usbcore/parameters/autosuspend
2
```

`/etc/modprobe.d/*.conf` only applies to *loadable* modules. Parameters of built-in subsystems must be passed on the kernel command line (`usbcore.autosuspend=-1`) or set via sysfs.

The intended value of `−1` (never autosuspend) was never applied. The runtime value is the default `2` (autosuspend after 2 s idle), so USB autosuspend is active on every port.

Omarchy's kernel command line currently has no `usbcore.autosuspend=`:

```
cryptdevice=PARTUUID=d1ad37d3-02:root root=/dev/mapper/root zswap.enabled=0
rootflags=subvol=@ rw rootfstype=btrfs resume=/dev/mapper/root resume_offset=1918319
initramfs_async=0 quiet splash loglevel=0 systemd.show_status=false
rd.udev.log_level=0 vt.global_cursor_default=0
```

### Suggested fix

Either add `usbcore.autosuspend=-1` to the kernel command line, or drop the modprobe.d file if the setting is no longer considered desirable. Worth checking whether this file was written when `usbcore` was still modular in an older kernel, since it would have worked then.

Not urgent — autosuspend is usually a win for laptops. But a config file that silently does nothing is worse than no file, since it suggests the issue is handled.

---

## Notes

- Unrelated observation: `/etc/modprobe.d/btusb.conf` (`options btusb reset=0`, dated Sep 22) belongs to no package — `pacman -Qo` reports `No package owns /etc/modprobe.d/btusb.conf`. Not created by `omarchy-settings` (which installs only `omarchy-usb-autosuspend.conf`). May be leftover from a previous install or a manual change.
- `pacman -Sy` currently has no effect on this system: `stable-mirror.omarchy.org` is serving the same `.db` files it served on Sep 8, so package databases are stale. May be worth a separate check.