| Message ID | 20211202162256.31837-1-tiwai@suse.de |
|---|---|
| State | New |
| Headers | show |
| Series | Bluetooth: Apply initial command workaround for more Intel chips | expand |
On Fri, 03 Dec 2021 22:18:06 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > >>>>> It seems that a few more Intel chips require the workaround for the > >>>>> broken initial command. At least, per openSUSE Bugzilla reports, > >>>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag. > >>>>> > >>>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku") > >>>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124 > >>>>> Signed-off-by: Takashi Iwai <tiwai@suse.de> > >>>>> > >>>> > >>>> […] > >>>> > >>>> I have a Dell Latitude E7250 with > >>>> > >>>> Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface > >>>> > >>>> and Bluetooth seems to work fine minus some Linux warnings [1] and a > >>>> problem transferring greater than some bytes files with the Nokia N9 > >>>> [2]. > >>>> > >>>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018: > >>>> > >>>> ``` > >>>> $ sudo dmesg | grep -i bluet > >>>> [ 8.173417] calling bt_init+0x0/0xb3 [bluetooth] @ 301 > >>>> [ 8.173439] Bluetooth: Core ver 2.22 > >>>> [ 8.173463] NET: Registered PF_BLUETOOTH protocol family > >>>> [ 8.173464] Bluetooth: HCI device and connection manager initialized > >>>> [ 8.173467] Bluetooth: HCI socket layer initialized > >>>> [ 8.173470] Bluetooth: L2CAP socket layer initialized > >>>> [ 8.173473] Bluetooth: SCO socket layer initialized > >>>> [ 8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs > >>>> [ 8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014 > >>>> [ 8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq > >>>> [ 8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq > >>>> [ 8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f > >>>> [ 8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated > >>>> ``` > >>> > >>> Thanks, so this seems depending on the hardware, maybe a subtle > >>> difference matters. As far as I read the code changes, the workaround > >>> was applied in the past unconditionally, so it must be fairly safe > >>> even if the chip works as is. > >> > >> Maybe add that to the commit message? > > > > Maybe, if the upstream agrees with that. More comments needed from > > Intel, as it's a kind of black magic. > > > >>> Or, for avoiding the unnecessarily application of the workaround, > >>> should it be changed as a fallback after the failure at the first > >>> try...? > >> > >> Reading through the openSUSE Bugzilla issue, the failure is: > >> > >> Bluetooth: hci0: Reading Intel version command failed (-110) > >> Bluetooth: hci0: command 0xfc05 tx timeout > >> > >> I couldn’t find the report for 8087:0a2a in the issue. > > > > There two different machines in the report. > > > >> Can you check, > >> what firmware is used? > > > > It's the place before loading the firmware, so the firmware version > > doesn't matter. > > I want to apply this quirk to as little devices as possible. It is one of these quirks we have to hardcode per USB VID:PID since we can’t auto-detect which boot loader is faulty. > > So before I blacklist them, we better get a good understand of which they are. Can you include a btmon trace for that part. You most likely have to blacklist btusb.ko, start btmon and then load btusb.ko manually. One with and one without the quirk. And add that to the commit message. One of the reporters uploaded the logs to the kernel.org bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=215167 (I forgot to add this URL to the patch description, although this could be reached from openSUSE Bugzila entry.) Let me know (or better to access to bugzilla above by yourself) if anything else is required. thanks, Takashi
On 21/12/02 05:47PM, Takashi Iwai wrote: > Thanks, so this seems depending on the hardware, maybe a subtle > difference matters. As far as I read the code changes, the workaround > was applied in the past unconditionally, so it must be fairly safe > even if the chip works as is. > > Or, for avoiding the unnecessarily application of the workaround, > should it be changed as a fallback after the failure at the first > try...? I don't know if this helps, but I started experiencing this same issue ("hci0: command 0xfc05 tx timeout") yesterday after a kernel upgrade. My controller is a different one: 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter ^^^^^^^^^ I tried with different (older) versions of the v5.15.x kernel but none worked. Now, this is the interesting (?) part: today, when I switched on the computer to keep testing, the bluetooth was *already* working once again. I have reviewed my bash history to try to figure out what is it that I did, and the only thing I see is that yesterday, before going to sleep, I did a full poweroff instead of a reset (which is what I used yesterday to try different kernels). This does not make any sense... but then I found this [1] post from someone else who experienced the same. Is there any reasonable explanation for this? Could this be the reason why you seem to have different results with the same controller (8087:0a2a)? [1] https://bbs.archlinux.org/viewtopic.php?pid=2006188#p2006188
Hi Fernando, >> Thanks, so this seems depending on the hardware, maybe a subtle >> difference matters. As far as I read the code changes, the workaround >> was applied in the past unconditionally, so it must be fairly safe >> even if the chip works as is. >> >> Or, for avoiding the unnecessarily application of the workaround, >> should it be changed as a fallback after the failure at the first >> try...? > > I don't know if this helps, but I started experiencing this same issue ("hci0: > command 0xfc05 tx timeout") yesterday after a kernel upgrade. > > My controller is a different one: > > 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter > ^^^^^^^^^ > > I tried with different (older) versions of the v5.15.x kernel but none worked. > > Now, this is the interesting (?) part: today, when I switched on the computer > to keep testing, the bluetooth was *already* working once again. > > I have reviewed my bash history to try to figure out what is it that I did, and > the only thing I see is that yesterday, before going to sleep, I did a full > poweroff instead of a reset (which is what I used yesterday to try different > kernels). > > This does not make any sense... but then I found this [1] post from someone else > who experienced the same. > > Is there any reasonable explanation for this? Could this be the reason why you > seem to have different results with the same controller (8087:0a2a)? we trying to figure out what went wrong here. This should be really only an issue on the really early Intel hardware like Wilkens Peak. However it seems it slipped into later parts now as well. We are investigating what happened and see if this can be fixed via a firmware update or if we really have to mark this hardware as having a broken boot loader. Regards Marcel
On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote: > > Hi Fernando, > > >> Thanks, so this seems depending on the hardware, maybe a subtle > >> difference matters. As far as I read the code changes, the workaround > >> was applied in the past unconditionally, so it must be fairly safe > >> even if the chip works as is. > >> > >> Or, for avoiding the unnecessarily application of the workaround, > >> should it be changed as a fallback after the failure at the first > >> try...? > > > > I don't know if this helps, but I started experiencing this same issue ("hci0: > > command 0xfc05 tx timeout") yesterday after a kernel upgrade. > > > > My controller is a different one: > > > > 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter > > ^^^^^^^^^ > > > > I tried with different (older) versions of the v5.15.x kernel but none worked. > > > > Now, this is the interesting (?) part: today, when I switched on the computer > > to keep testing, the bluetooth was *already* working once again. > > > > I have reviewed my bash history to try to figure out what is it that I did, and > > the only thing I see is that yesterday, before going to sleep, I did a full > > poweroff instead of a reset (which is what I used yesterday to try different > > kernels). > > > > This does not make any sense... but then I found this [1] post from someone else > > who experienced the same. > > > > Is there any reasonable explanation for this? Could this be the reason why you > > seem to have different results with the same controller (8087:0a2a)? > > we trying to figure out what went wrong here. This should be really only an issue on the really early Intel hardware like Wilkens Peak. However it seems it slipped into later parts now as well. We are investigating what happened and see if this can be fixed via a firmware update or if we really have to mark this hardware as having a broken boot loader. The upstream bugzilla indicates that 8087:0aa7 seems hitting the same problem: https://bugzilla.kernel.org/show_bug.cgi?id=215167 OTOH, on openSUSE Bugzilla, there has been a report that applying the workaround for 8087:0026 may cause another issue about the reset error, so the entry for 8087:0026 should be dropped. Takashi
Hi, this is your Linux kernel regression tracker speaking. Hey bluetooth maintainers, what's the status here? It looks like the issue was discussed quite a bit, but then nothing happened anymore. Or am I missing something? Other users seem to still run into the issue, see for example this report: https://lore.kernel.org/all/b0f6f66b-28aa-9d43-0aab-e6887ee0fda8@logobject.ch/ For the rest of the mail: [TLDR: I'm adding this regression to regzbot, the Linux kernel regression tracking bot; most text you find below is compiled from a few templates paragraphs some of you might have seen already.] On 02.12.21 17:22, Takashi Iwai wrote: > It seems that a few more Intel chips require the workaround for the > broken initial command. At least, per openSUSE Bugzilla reports, > 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag. > > Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku") > Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124 > Signed-off-by: Takashi Iwai <tiwai@suse.de> > > --- > drivers/bluetooth/btusb.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > index 75c83768c257..b26989b2df23 100644 > --- a/drivers/bluetooth/btusb.c > +++ b/drivers/bluetooth/btusb.c > @@ -359,14 +359,16 @@ static const struct usb_device_id blacklist_table[] = { > > /* Intel Bluetooth devices */ > { USB_DEVICE(0x8087, 0x0025), .driver_info = BTUSB_INTEL_COMBINED }, > - { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED }, > + { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED | > + BTUSB_INTEL_BROKEN_INITIAL_NCMD }, > { USB_DEVICE(0x8087, 0x0029), .driver_info = BTUSB_INTEL_COMBINED }, > { USB_DEVICE(0x8087, 0x0032), .driver_info = BTUSB_INTEL_COMBINED }, > { USB_DEVICE(0x8087, 0x0033), .driver_info = BTUSB_INTEL_COMBINED }, > { USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR }, > { USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED | > BTUSB_INTEL_BROKEN_INITIAL_NCMD }, > - { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED }, > + { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED | > + BTUSB_INTEL_BROKEN_INITIAL_NCMD }, > { USB_DEVICE(0x8087, 0x0a2b), .driver_info = BTUSB_INTEL_COMBINED }, > { USB_DEVICE(0x8087, 0x0aa7), .driver_info = BTUSB_INTEL_COMBINED }, > { USB_DEVICE(0x8087, 0x0aaa), .driver_info = BTUSB_INTEL_COMBINED }, Adding the regression mailing list to the list of recipients, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html To be sure this issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced 83f2dafe2a62 #regzbot title bluetooth: more Intel chips require the workaround for the broken initial command #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215167 #regzbot link: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124 #regzbot ignore-activity Reminder: when fixing the issue, please add a 'Link:' tag with the URL to the report (the parent of this mail) using the kernel.org redirector, as explained in 'Documentation/process/submitting-patches.rst'. Regzbot then will automatically mark the regression as resolved once the fix lands in the appropriate tree. For more details about regzbot see footer. Sending this to everyone that got the initial report, to make all aware of the tracking. I also hope that messages like this motivate people to directly get at least the regression mailing list and ideally even regzbot involved when dealing with regressions, as messages like this wouldn't be needed then. Don't worry, I'll send further messages wrt to this regression just to the lists (with a tag in the subject so people can filter them away), as long as they are intended just for regzbot. With a bit of luck no such messages will be needed anyway. Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat) P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply, that's in everyone's interest. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activities wrt to this regression. --- Additional information about regzbot: If you want to know more about regzbot, check out its web-interface, the getting start guide, and/or the references documentation: https://linux-regtracking.leemhuis.info/regzbot/ https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md The last two documents will explain how you can interact with regzbot yourself if your want to. Hint for reporters: when reporting a regression it's in your interest to tell #regzbot about it in the report, as that will ensure the regression gets on the radar of regzbot and the regression tracker. That's in your interest, as they will make sure the report won't fall through the cracks unnoticed. Hint for developers: you normally don't need to care about regzbot once it's involved. Fix the issue as you normally would, just remember to include a 'Link:' tag to the report in the commit message, as explained in Documentation/process/submitting-patches.rst That aspect was recently was made more explicit in commit 1f57bd42b77c: https://git.kernel.org/linus/1f57bd42b77c
Dear Takashi, Am 10.12.21 um 14:23 schrieb Takashi Iwai: > On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote: >>>> Thanks, so this seems depending on the hardware, maybe a subtle >>>> difference matters. As far as I read the code changes, the workaround >>>> was applied in the past unconditionally, so it must be fairly safe >>>> even if the chip works as is. >>>> >>>> Or, for avoiding the unnecessarily application of the workaround, >>>> should it be changed as a fallback after the failure at the first >>>> try...? >>> >>> I don't know if this helps, but I started experiencing this same issue ("hci0: >>> command 0xfc05 tx timeout") yesterday after a kernel upgrade. >>> >>> My controller is a different one: >>> >>> 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter >>> ^^^^^^^^^ >>> >>> I tried with different (older) versions of the v5.15.x kernel but none worked. >>> >>> Now, this is the interesting (?) part: today, when I switched on the computer >>> to keep testing, the bluetooth was *already* working once again. >>> >>> I have reviewed my bash history to try to figure out what is it that I did, and >>> the only thing I see is that yesterday, before going to sleep, I did a full >>> poweroff instead of a reset (which is what I used yesterday to try different >>> kernels). >>> >>> This does not make any sense... but then I found this [1] post from someone else >>> who experienced the same. >>> >>> Is there any reasonable explanation for this? Could this be the reason why you >>> seem to have different results with the same controller (8087:0a2a)? >> >> we trying to figure out what went wrong here. This should be really only an >> issue on the really early Intel hardware like Wilkens Peak. However it seems >> it slipped into later parts now as well. We are investigating what happened >> and see if this can be fixed via a firmware update or if we really have to >> mark this hardware as having a broken boot loader. > > The upstream bugzilla indicates that 8087:0aa7 seems hitting the same > problem: > https://bugzilla.kernel.org/show_bug.cgi?id=215167 > > OTOH, on openSUSE Bugzilla, there has been a report that applying the > workaround for 8087:0026 may cause another issue about the reset > error, so the entry for 8087:0026 should be dropped. Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix broken LED quirk for legacy ROM devices) [1] merged in the current Linux 5.17 cycle this week fixed the issue? Kind regards, Paul [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b
Hi, this is your Linux kernel regression tracker speaking. Top-posting for once, to make this easy accessible to everyone. Could the bluetooth maintainers please provide a status update? I wonder if it's time to bring this regression to Linus attention, as it seems to be an issue that hits quite a few users -- and at the same takes quite a long time to get fixed for a issue where a patch with a workaround was already proposed one and a half months ago. Ciao, Thorsten On 16.01.22 15:06, Paul Menzel wrote: > > Dear Takashi, > > > Am 10.12.21 um 14:23 schrieb Takashi Iwai: >> On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote: > >>>>> Thanks, so this seems depending on the hardware, maybe a subtle >>>>> difference matters. As far as I read the code changes, the workaround >>>>> was applied in the past unconditionally, so it must be fairly safe >>>>> even if the chip works as is. >>>>> >>>>> Or, for avoiding the unnecessarily application of the workaround, >>>>> should it be changed as a fallback after the failure at the first >>>>> try...? >>>> >>>> I don't know if this helps, but I started experiencing this same >>>> issue ("hci0: >>>> command 0xfc05 tx timeout") yesterday after a kernel upgrade. >>>> >>>> My controller is a different one: >>>> >>>> 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter >>>> ^^^^^^^^^ >>>> >>>> I tried with different (older) versions of the v5.15.x kernel but >>>> none worked. >>>> >>>> Now, this is the interesting (?) part: today, when I switched on the >>>> computer >>>> to keep testing, the bluetooth was *already* working once again. >>>> >>>> I have reviewed my bash history to try to figure out what is it that >>>> I did, and >>>> the only thing I see is that yesterday, before going to sleep, I did >>>> a full >>>> poweroff instead of a reset (which is what I used yesterday to try >>>> different >>>> kernels). >>>> >>>> This does not make any sense... but then I found this [1] post from >>>> someone else >>>> who experienced the same. >>>> >>>> Is there any reasonable explanation for this? Could this be the >>>> reason why you >>>> seem to have different results with the same controller (8087:0a2a)? >>> >>> we trying to figure out what went wrong here. This should be really >>> only an >>> issue on the really early Intel hardware like Wilkens Peak. However >>> it seems >>> it slipped into later parts now as well. We are investigating what >>> happened >> and see if this can be fixed via a firmware update or if >>> we really > have to >>> mark this hardware as having a broken boot loader. >> >> The upstream bugzilla indicates that 8087:0aa7 seems hitting the same >> problem: >> https://bugzilla.kernel.org/show_bug.cgi?id=215167 >> >> OTOH, on openSUSE Bugzilla, there has been a report that applying the >> workaround for 8087:0026 may cause another issue about the reset >> error, so the entry for 8087:0026 should be dropped. > > Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix broken > LED quirk for legacy ROM devices) [1] merged in the current Linux 5.17 > cycle this week fixed the issue? > > > Kind regards, > > Paul > > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b >
On Sun, 16 Jan 2022 15:06:26 +0100, Paul Menzel wrote: > > > Dear Takashi, > > > Am 10.12.21 um 14:23 schrieb Takashi Iwai: > > On Tue, 07 Dec 2021 17:14:02 +0100, Marcel Holtmann wrote: > > >>>> Thanks, so this seems depending on the hardware, maybe a subtle > >>>> difference matters. As far as I read the code changes, the workaround > >>>> was applied in the past unconditionally, so it must be fairly safe > >>>> even if the chip works as is. > >>>> > >>>> Or, for avoiding the unnecessarily application of the workaround, > >>>> should it be changed as a fallback after the failure at the first > >>>> try...? > >>> > >>> I don't know if this helps, but I started experiencing this same issue ("hci0: > >>> command 0xfc05 tx timeout") yesterday after a kernel upgrade. > >>> > >>> My controller is a different one: > >>> > >>> 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter > >>> ^^^^^^^^^ > >>> > >>> I tried with different (older) versions of the v5.15.x kernel but none worked. > >>> > >>> Now, this is the interesting (?) part: today, when I switched on the computer > >>> to keep testing, the bluetooth was *already* working once again. > >>> > >>> I have reviewed my bash history to try to figure out what is it that I did, and > >>> the only thing I see is that yesterday, before going to sleep, I did a full > >>> poweroff instead of a reset (which is what I used yesterday to try different > >>> kernels). > >>> > >>> This does not make any sense... but then I found this [1] post from someone else > >>> who experienced the same. > >>> > >>> Is there any reasonable explanation for this? Could this be the reason why you > >>> seem to have different results with the same controller (8087:0a2a)? > >> > >> we trying to figure out what went wrong here. This should be really only an > >> issue on the really early Intel hardware like Wilkens Peak. However it seems > >> it slipped into later parts now as well. We are investigating what > >> happened >> and see if this can be fixed via a firmware update or > >> if we really > have to > >> mark this hardware as having a broken boot loader. > > > > The upstream bugzilla indicates that 8087:0aa7 seems hitting the same > > problem: > > https://bugzilla.kernel.org/show_bug.cgi?id=215167 > > > > OTOH, on openSUSE Bugzilla, there has been a report that applying the > > workaround for 8087:0026 may cause another issue about the reset > > error, so the entry for 8087:0026 should be dropped. > > Can you confirm that commit 95655456e7ce (Bluetooth: btintel: Fix > broken LED quirk for legacy ROM devices) [1] merged in the current > Linux 5.17 cycle this week fixed the issue? I myself have no such devices, so cannot confirm by myself. The openSUSE Tumbleweed kernel is already updated with the upstream fix (in 5.16.1), so user will notice whether any regression happens or not. Let's see. Takashi
Hi Thorsten, > Could the bluetooth maintainers please provide a status update? I wonder > if it's time to bring this regression to Linus attention, as it seems to > be an issue that hits quite a few users -- and at the same takes quite a > long time to get fixed for a issue where a patch with a workaround was > already proposed one and a half months ago. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b Regards Marcel
On 20.01.22 16:07, Marcel Holtmann wrote: > >> Could the bluetooth maintainers please provide a status update? I wonder >> if it's time to bring this regression to Linus attention, as it seems to >> be an issue that hits quite a few users -- and at the same takes quite a >> long time to get fixed for a issue where a patch with a workaround was >> already proposed one and a half months ago. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95655456e7cee858a23793f67025765b4c4c227b Ahh, okay, many thx for the update, it wasn't clear enough to me that this should fix the issue. Would have been nice if the commit would have had "Link:" tags to all reports about the issue (as explained in Documentation/process/submitting-patches.rst and Documentation/process/5.Posting.rst ), as that would have avoided confusion. Anyway, to close this: #regzbot introduced: ffcba827c0a1d #regzbot fixed-by: 95655456e7cee858a23793f67025765b4c4c227b Ciao, Thorsten
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 75c83768c257..b26989b2df23 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -359,14 +359,16 @@ static const struct usb_device_id blacklist_table[] = { /* Intel Bluetooth devices */ { USB_DEVICE(0x8087, 0x0025), .driver_info = BTUSB_INTEL_COMBINED }, - { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED }, + { USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_COMBINED | + BTUSB_INTEL_BROKEN_INITIAL_NCMD }, { USB_DEVICE(0x8087, 0x0029), .driver_info = BTUSB_INTEL_COMBINED }, { USB_DEVICE(0x8087, 0x0032), .driver_info = BTUSB_INTEL_COMBINED }, { USB_DEVICE(0x8087, 0x0033), .driver_info = BTUSB_INTEL_COMBINED }, { USB_DEVICE(0x8087, 0x07da), .driver_info = BTUSB_CSR }, { USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL_COMBINED | BTUSB_INTEL_BROKEN_INITIAL_NCMD }, - { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED }, + { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL_COMBINED | + BTUSB_INTEL_BROKEN_INITIAL_NCMD }, { USB_DEVICE(0x8087, 0x0a2b), .driver_info = BTUSB_INTEL_COMBINED }, { USB_DEVICE(0x8087, 0x0aa7), .driver_info = BTUSB_INTEL_COMBINED }, { USB_DEVICE(0x8087, 0x0aaa), .driver_info = BTUSB_INTEL_COMBINED },
It seems that a few more Intel chips require the workaround for the broken initial command. At least, per openSUSE Bugzilla reports, 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag. Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku") Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124 Signed-off-by: Takashi Iwai <tiwai@suse.de> --- drivers/bluetooth/btusb.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)