Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[incogcyberpunk]

On Thursday, November 20th, 2025 at 12:16 PM <dianders@xxxxxxxxxxxx> wrote: 
> In 6.13.1, the following could happen:
> 
> 1. We'd be running btusb_mtk_setup()
> 
> 2. In btusb_mtk_setup(), we'd run:
>   btmtk_data->isopkt_intf = usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)
> 
> 3. If usb_ifnum_to_if() returned NULL, "btmtk_data->isopkt_intf" would be NULL.
> 
> 4. Next, btusb_mtk_setup() would call btusb_mtk_claim_iso_intf().
> 
> 5. btusb_mtk_claim_iso_intf() would pass "btmtk_data->isopkt_intf"
> (NULL) to usb_driver_claim_interface() as "iface".
> 
> 6. usb_driver_claim_interface() would see that its parameter "iface"
> is NULL and would return an error.
> 
> 7. btusb_mtk_claim_iso_intf() would notice the error, print "Failed to
> claim iso interface: %d", and return.
> 
> 
> In 6.13.2 after commit e9087e828827 ("Bluetooth: btusb: mediatek: Add
> locks for usb_driver_claim_interface()"), we'd add in this step after
> step 4:
> 
> 4.5 btusb_mtk_claim_iso_intf() would call:
>   device_lock(&btmtk_data->isopkt_intf->dev);
> 
> If "btmtk_data->isopkt_intf" is NULL, this is the same as
> "&(NULL->dev)", so we'd pass a number that's very close to NULL in as
> the dev pointer. Then device_lock() would try to dereference that and
> crash.


Sorry for the lack of knowledge on my part, but could you provide insights as how the bluetooth was functioning wihout errors in 6.13.1 :

1. Is it because there was no device_lock() checks in 6.13.1 and is because of the newly added `device_lock()` added on 6.13.2 ? 
2. Is it because there was `device_lock()` in 6.13.1 that despite being provided a NULL pointer,`device_lock()` could dereference and the bluetooth adapter would turn on BUT in 6.13.2 , `device_lock()` would be provided a number close to NULL which could not be dereferenced and hence the bluetooth adapter wouldn't turn on ?

Hope it's not much trouble for you.

Regards,
IncogCyberpunk