Kernel binary lacks quirk despite patch label #30

Open
opened 2026-08-02 19:23:30 -05:00 by cZdrikjdm · 0 comments
cZdrikjdm commented 2026-08-02 19:23:30 -05:00 (Migrated from github.com)

Title: Kernel in build 20260731-185014 still double-binds the BT chip (phantom hci1), although patches daa2e49 contain the BTUSB_IFNUM_0 quirk

Fresh flash of ps5-cachyos.img.xz from the "latest" release (build 20260731-185014, kernel 7.1.4, patches daa2e49).

On first boot, ls /sys/class/bluetooth/ shows hci0 and hci1 — the Marvell 1286:2059 chip's second USB interface is still being bound by btusb, and pairing on the internal adapter fails in that state.

However, linux.patch at daa2e49 does contain the BTUSB_IFNUM_0 quirk for 1286:2059 (device-table entry + the bInterfaceNumber != 0 filter from PR #19). So the patch tree is correct, but the kernel actually shipped in the image behaves as if built without it.

Is the prebuilt kernel package used by the image build stale relative to the patch labels (i.e. built from an older patch revision than the release notes claim)?

Workaround for anyone hitting this: a udev rule deauthorizing the chip's second interface fixes it

# /etc/udev/rules.d/99-ps5-bt-phantom.rules
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="1286", ATTRS{idProduct}=="2059", ATTR{bInterfaceNumber}=="02", ATTR{authorized}="0"

(then sudo udevadm control --reload and reboot). That's what we're shipping in ps5-cachyos-setup meanwhile.

Title: Kernel in build 20260731-185014 still double-binds the BT chip (phantom hci1), although patches daa2e49 contain the BTUSB_IFNUM_0 quirk Fresh flash of `ps5-cachyos.img.xz` from the "latest" release (build `20260731-185014`, kernel 7.1.4, patches `daa2e49`). On first boot, `ls /sys/class/bluetooth/` shows **hci0 and hci1** — the Marvell `1286:2059` chip's second USB interface is still being bound by btusb, and pairing on the internal adapter fails in that state. However, `linux.patch` at `daa2e49` **does** contain the `BTUSB_IFNUM_0` quirk for `1286:2059` (device-table entry + the `bInterfaceNumber != 0` filter from PR #19). So the patch tree is correct, but the kernel actually shipped in the image behaves as if built without it. Is the prebuilt kernel package used by the image build stale relative to the patch labels (i.e. built from an older patch revision than the release notes claim)? Workaround for anyone hitting this: a udev rule deauthorizing the chip's second interface fixes it # /etc/udev/rules.d/99-ps5-bt-phantom.rules ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="1286", ATTRS{idProduct}=="2059", ATTR{bInterfaceNumber}=="02", ATTR{authorized}="0" (then `sudo udevadm control --reload` and reboot). That's what we're shipping in [ps5-cachyos-setup](https://github.com/cZdrikjdm/ps5-cachyos-setup) meanwhile.
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-ps5-linux/ps5-linux-image#30
No description provided.