On Tue, 2023-10-03 at 14:42 +0200, Erik Dobák wrote:
> Sure here you go:
>
> # lsusb -d 04c5:1670 -v
>
> Bus 001 Device 004: ID 04c5:1670 Fujitsu, Ltd Bluetooth Radio
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.00
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 64
> idVendor 0x04c5 Fujitsu, Ltd
> idProduct 0x1670
> bcdDevice 0.00
> iManufacturer 1 Realtek
> iProduct 2 Bluetooth Radio
> iSerial 3 00e04c000001
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 0x00b1
> bNumInterfaces 2
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xe0
> Self Powered
> Remote Wakeup
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 4 Bluetooth Radio
I have no idea why you referred to my commits, i.e. c13380a55522
("Bluetooth: btusb: Do not require hardcoded interface numbers") later
fixed by eaac6e223a0d ("Bluetooth: btusb: Fix bluetooth on Intel
Macbook 2014") in the first place.
BTUSB_IFNUM_2 is not even getting set for this device and therefore the
patches have no impact on your issue. If you were affected, like the
Intel Macbook 2014 was, then bear in mind that the issue would manifest
as btusb driver not even binding to the device. From your emails
however it appears that the issue is something different.
I honestly don't think it has anything to do with my patches. If you
know a Linux version where your bluetooth device works, then the next
step would be to bisect to find the first bad commit.
Best Regards,
Tomasz Moń
