Hi,
On Thu, Nov 20, 2025 at 9:04 AM Paul Menzel pmenzel@molgen.mpg.de wrote:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index fcc62e2fb641..683ac02e964b 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -2751,6 +2751,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data) if (!btmtk_data) return;
if (!btmtk_data->isopkt_intf) {bt_dev_err(data->hdev, "Can't claim NULL iso interface");As an error is printed now,
An error was also printed before commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()") too, it was just a different error message. Previously the NULL would have been noticed by usb_driver_claim_interface(), which would have returned -ENODEV. That error would have been noticed and the message printed would have been:
Failed to claim iso interface: -19
So that error is merely changed into:
Can't claim NULL iso interface
what should be done about? Do drivers need fixing? Is it broken hardware?
Personally, I have no idea. I was mostly trying to get the regression fixed and, after looking at the code, I was convinced that this would get us back to working at least as well as we did before commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), plus we'd still have the device_lock() in place to avoid the problems I noticed earlier. It sounds as if, even with the error printed, things were working well enough for IncogCyberpunk.
If someone wants to analyze how / why `btmtk_data->isopkt_intf` would be NULL in this case and if we should do something better to handle it, I'd certainly support it!
return;}/* * The function usb_driver_claim_interface() is documented to need * locks held if it's not called from a probe routine. The code hereReviewed-by: Paul Menzel pmenzel@molgen.mpg.de
Thanks!
-Doug