Bug 203419

Summary: Logitech Group USB audio stopped working in 5.1-rc6
Product: Drivers Reporter: Ulf (ulf.norberg)
Component: USBAssignee: Default virtual assignee for Drivers/USB (drivers_usb)
Status: NEW ---    
Severity: normal CC: bartos.petr, dirk.gajewski, florianmey, frederic.grosshans, g.schmitz, hawk.it, ikjn, jamielennox, jk, josemariafg, kernel, leho, machiel.van.veen, mail, mathias.nyman, mephinet, nelg, o.freyermuth, olivier, petenewcomb, ricardo, sascha.poell, schickher2, simon.fayer05, sofro1988, stefan.ursella, tiwai
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.1.0-rc6 Subsystem:
Regression: No Bisected commit-id:
Attachments: Output from alsa-info.sh kernel 5.1-rc6 (USB audio not working)
alsa-info from 4.19.36 which works
"lsusb -v" from 5.1-rc6
dmesg from 5.1-rc6
dmesg from 5.4
testpatch that doesn't clear TT buffer after protocol STALL
dmesg fedora32 kernel 5.7.6 logic group usb
trace fedora32 kernel 5.7.6 logic group usb
trace ubuntu 20.04 5.8.4-050804-generic
dmesg ubuntu 20.04 5.8.4-050804-generic

Description Ulf 2019-04-25 12:49:22 UTC
Created attachment 282521 [details]
Output from alsa-info.sh kernel 5.1-rc6 (USB audio not working)

This is a video conferencing system with a webcam, audio and microphone - all connected with a single USB wire.  The buildt in USB audio does not work in kernel 5.1-rc6.  Tested with mainline 5.1-rc6 on a gentoo system.  Also tested in Fedora kernel 5.0.8-200.fc29.x86_64 with the same result (i.e. no audio).  However, in kernel 4.19.36 (and also Fedora 4.13.0-0.rc0.git3.1.fc27.x86_64) audio is working fine.

Tested with:

aplay -v -D "default:CARD=1" /usr/share/sounds/alsa/Noise.wav

In 4.19.36 I hear a noise (as expected), but not in kernel 5.1-rc6 where it outputs:

ALSA lib /tmp/portage/media-libs/alsa-lib-1.1.8/work/alsa-lib-1.1.8/src/pcm/pcm_direct.c:1271:(snd1_pcm_direct_initialize_slave) unable to install hw params
ALSA lib /tmp/portage/media-libs/alsa-lib-1.1.8/work/alsa-lib-1.1.8/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:828: audio open error: Input/output error

and dmesg outputs:

usb 1-14.2: 2:1: usb_set_interface failed (-110)
Comment 1 Ulf 2019-04-25 12:50:55 UTC
Created attachment 282523 [details]
alsa-info from 4.19.36 which works
Comment 2 Ulf 2019-04-25 12:52:30 UTC
Created attachment 282525 [details]
"lsusb -v" from 5.1-rc6
Comment 3 Ulf 2019-04-25 12:54:57 UTC
Created attachment 282527 [details]
dmesg from 5.1-rc6
Comment 4 José María Fernández González 2019-10-09 15:08:17 UTC
The same happens to Logitech ConferenceCam Connect (usb id 046d:084e). It started failing on kernel 5.0.0, and the last working kernel versions are in 4.20 branch.
Comment 5 José María Fernández González 2019-10-09 15:22:57 UTC
I can also confirm it persists on 5.1, 5.2 and 5.3 kernels.
Comment 6 sascha.poell 2019-10-16 12:54:20 UTC
Same for me, works on version 4.20.3 and started failing with 5.0 . Still broken with current my current version 5.2.16 . no developer can use conference microphones currently.
Comment 7 Glen Ogilvie 2019-10-30 20:26:50 UTC
+1.  Also impacted running Arch Linux with latest kernel.
Installation of 4.19.80-2-lts (pacman -S linux-lts) fixed the problem.
Comment 8 Ricardo S 2019-11-25 15:46:19 UTC
Can confirm this problem. Still present on 5.3.7.
Comment 9 Machiel 2019-12-11 13:56:41 UTC
We have the same issue with the 5.4.2 kernel. When testing the whole system starts locking up even, this is on Ubuntu 18.04 with a Logitech Group system. 

Works on the 4.4 kernel in Ubuntu 16.04.
Comment 10 Machiel 2019-12-20 12:58:41 UTC
Created attachment 286379 [details]
dmesg from 5.4

Attached the dmesg with the 5.4 kernel in Ubuntu 18.04 on a Intel NUC 7i5BNK.
Comment 11 Mephinet 2020-01-23 15:30:18 UTC
For users who stumble upon this bug report:

A work-around is to:

echo blacklist snd_usb_audio >> /etc/modprobe.d/logitech-speakerphone.conf

then at least the video features of the conferencing system are available (and some other microphone can be used).
Comment 12 Takashi Iwai 2020-01-23 15:35:05 UTC
Well, someone needs to run git bisect for spotting out what broke.
-110 = -ETIMEDOUT, which indicates something to do with the firmware in most cases.  From that error code, I'd rather suspect some changes in USB core side.
Comment 13 Thib Guicherd-Callin 2020-03-02 22:18:41 UTC
(In reply to Glen Ogilvie from comment #7)
> +1.  Also impacted running Arch Linux with latest kernel.
> Installation of 4.19.80-2-lts (pacman -S linux-lts) fixed the problem.

I was impacted by this in my workplace with Arch Linux and a Logitech ConferenceCam Connect. The workaround of switching to the LTS kernel worked ... except in the last two weeks or so. Now neither the LTS nor the latest kernels on Arch Linux work with my workplace conferencing equipment.
Comment 14 Florian Meyer 2020-03-20 15:39:47 UTC
I'm fairly certain that I encountered the same bug, albeit with different hardware.
Bus 003 Device 004: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
The error messages are the same though.
I bisected it and got to the following commit:
# first bad commit: [ef513be0a9057cc6baf5d29566aaaefa214ba344] usb: xhci: Add Clear_TT_Buffer

From the description it has something to do with usb audio conference systems which would fit pretty well.
Last good one was:
good: [4998f1efd1904dd21697aeeead270e3eb97691dd] usb: Add devaddr in struct usb_device
Comment 15 Leho Kraav 2020-03-27 12:22:00 UTC
Kernel 5.5.10: my Logitech C920 microphone has now stayed silent for a noticeable period of time. Input profiles are nicely listed in PulseAudio, obviously snd-usb-audio is loaded, etc, but noise level meters stay flatlined.

I'm not sure when this regressed.. maybe within the last year somewhere? It definitely has worked on older kernels, but went silent somewhere in 5.x.
Comment 16 Florian Meyer 2020-03-31 13:46:53 UTC
Could someone else maybe confirm if they get a working kernel when using commit [4998f1efd1904dd21697aeeead270e3eb97691dd] usb: Add devaddr in struct usb_device 
and that it fails at/after commit 
[ef513be0a9057cc6baf5d29566aaaefa214ba344] usb: xhci: Add Clear_TT_Buffer
? 

Because even though I get the same error message and problem and bisected it to the latter commit, that one was applied somewhere around kernel 5.2 as far as I can see, which doesn't fit the initial bug report version wise.
Comment 17 Dominique Archambault 2020-04-01 12:56:55 UTC
I have been using the Logtch ConferenceCam Connect for months before a update last autumn. Since then I can't anymore. 
now with kernel 5.4 sill not working 

[145512.291106] usb 1-2: new high-speed USB device number 9 using xhci_hcd
[145512.339897] usb 1-2: New USB device found, idVendor=046d, idProduct=084e, bcdDevice=32.98
[145512.339898] usb 1-2: New USB device strings: Mfr=10, Product=11, SerialNumber=0
[145512.339899] usb 1-2: Product: ConferenceCam Connect
[145512.339900] usb 1-2: Manufacturer: Logitech
[145512.341246] hub 1-2:1.0: USB hub found
[145512.342825] hub 1-2:1.0: 4 ports detected
[145512.635124] usb 1-2.1: new full-speed USB device number 10 using xhci_hcd
[145512.743047] usb 1-2.1: New USB device found, idVendor=046d, idProduct=084c, bcdDevice= 2.00
[145512.743048] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[145512.743049] usb 1-2.1: Product: ConferenceCam Connect
[145512.743050] usb 1-2.1: Manufacturer: Logitech
[145512.743050] usb 1-2.1: SerialNumber: 0X090X6E0X440X18
[145517.865085] usb 1-2.1: 1:1: cannot get freq at ep 0x82
[145528.103147] input: Logitech ConferenceCam Connect Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.3/0003:046D:084C.001D/input/input54
[145528.163234] input: Logitech ConferenceCam Connect as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.3/0003:046D:084C.001D/input/input55
[145528.163377] input: Logitech ConferenceCam Connect as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.3/0003:046D:084C.001D/input/input56
[145528.163710] hid-generic 0003:046D:084C.001D: input,hiddev3,hidraw4: USB HID v1.11 Device [Logitech ConferenceCam Connect] on usb-0000:00:14.0-2.1/input3
[145528.243041] usb 1-2.2: new high-speed USB device number 11 using xhci_hcd
[145528.265137] usb 1-2.2: New USB device found, idVendor=046d, idProduct=084b, bcdDevice= 0.13
[145528.265138] usb 1-2.2: New USB device strings: Mfr=0, Product=2, SerialNumber=1
[145528.265139] usb 1-2.2: Product: ConferenceCam Connect
[145528.265140] usb 1-2.2: SerialNumber: 90E64481
[145528.266908] uvcvideo: Found UVC 1.00 device ConferenceCam Connect (046d:084b)
[145528.267991] uvcvideo 1-2.2:1.0: Entity type for entity Processing 3 was not initialized!
[145528.267993] uvcvideo 1-2.2:1.0: Entity type for entity Extension 6 was not initialized!
[145528.267993] uvcvideo 1-2.2:1.0: Entity type for entity Extension 8 was not initialized!
[145528.267994] uvcvideo 1-2.2:1.0: Entity type for entity Extension 9 was not initialized!
[145528.267995] uvcvideo 1-2.2:1.0: Entity type for entity Extension 10 was not initialized!
[145528.267995] uvcvideo 1-2.2:1.0: Entity type for entity Extension 11 was not initialized!
[145528.267996] uvcvideo 1-2.2:1.0: Entity type for entity Extension 12 was not initialized!
[145528.267997] uvcvideo 1-2.2:1.0: Entity type for entity Extension 13 was not initialized!
[145528.267998] uvcvideo 1-2.2:1.0: Entity type for entity Camera 1 was not initialized!
[145528.268086] input: ConferenceCam Connect as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input58
[145528.268518] input: ConferenceCam Connect Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2:1.2/0003:046D:084B.001E/input/input59
[145528.327325] hid-generic 0003:046D:084B.001E: input,hidraw5: USB HID v1.11 Device [ConferenceCam Connect] on usb-0000:00:14.0-2.2/input2
[145559.081624] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145564.205564] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145569.321577] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145574.441624] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145579.561474] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145584.681577] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145589.801511] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145594.921441] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145600.041511] usb 1-2.1: 1:1: usb_set_interface failed (-110)
[145605.161510] usb 1-2.1: 1:1: usb_set_interface failed (-110)
Comment 18 Takashi Iwai 2020-04-01 13:10:52 UTC
Sounds more like a USB issue.  Reassigned.
Comment 19 Alan Stern 2020-04-01 16:00:44 UTC
Mathias, maybe you should look at this.

On Wed, 1 Apr 2020 bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=203419
> 
> Takashi Iwai (tiwai@suse.de) changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Component|Sound(ALSA)                 |USB
>            Assignee|perex@perex.cz              |drivers_usb@kernel-bugs.ker
>                    |                            |nel.org
> 
> --- Comment #18 from Takashi Iwai (tiwai@suse.de) ---
> Sounds more like a USB issue.  Reassigned.

In the bug report, Florian Meyer tentatively identified commit 
ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") as the one causing the 
problem.  No one else has verified this, however -- and as far as I can 
see, even Florian hasn't tried starting from that commit and reverting 
it.

Alan Stern
Comment 20 Florian Meyer 2020-04-01 19:22:16 UTC
I get my sound system working if I use the version at the commit directly before ef513be0a905. 
I just don't know if my bug is the same as the one originally reported here. The error messages are the same and the problem is the same, but the commit was applied during the 5.2 developement I think? Which would not fit the versions given in the first messages here.
Comment 21 Mathias Nyman 2020-04-02 13:34:44 UTC
Any chance someone who could reproduce this on 5.1-rc6, 5.1 or 5.0 could bisect the kernel and find the problematic commit.

Also traces and logs with more usb details enabled could be useful.
These can be taken with any recent kernel.

mount -t debugfs none /sys/kernel/debug
echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
< connect the logitec device >
Send output of dmesg
Send content of /sys/kernel/debug/tracing/trace
Comment 22 Vincenzo Di Massa 2020-04-08 09:43:19 UTC
Hello all,

I don't have the HW to test, but I noticed that probably this bug is similar to bug 206897, which has been bisected to the same commit.

I have the HUION device and I could help until the end of the week (pandemic == no job for me :-( )

I can build, install and develop kernel code, but i don't know about USB internals.
Comment 23 Glen Ogilvie 2020-04-08 10:00:11 UTC
(In reply to Mathias Nyman from comment #21)
> Any chance someone who could reproduce this on 5.1-rc6, 5.1 or 5.0 could
> bisect the kernel and find the problematic commit.

I am happy to do this when back at work where the device is, but currently we are in lockdown in New Zealand.. so may not be for a month or more.
Comment 24 Florian Meyer 2020-04-08 10:04:21 UTC
I've also opened a new issue for the "same" problem that started appearing from 5.2 onwards for me. 
https://bugzilla.kernel.org/show_bug.cgi?id=207065
I've posted the logs Mathias requested there.
Comment 25 Vincenzo Di Massa 2020-04-08 12:49:42 UTC
Florian, ef513be0a9057cc6baf5d29566aaaefa214ba344 is not contained in the v5.2 kernel tag...

```
$ git tag --contains  ef513be0a9057cc6baf5d29566aaaefa214ba344 | grep '^v5.[0-9]\+$'
v5.3
v5.4
v5.5
v5.6
```

do you mean that you were impacted by bug 207065 with kernels **after** v5.2 (i.e. v5.2 was the last good one)? For me 5.2.21 is unaffected.
Comment 26 Florian Meyer 2020-04-08 16:30:00 UTC
When building it, make menuconfig identified it as 5.2-rc3 which is why I thought it was part of 5.2. But yeah I think 5.3 was the first released version failing for me. Anyway, its definitely not part of 5.0 or 5.1, so the problem is different from the one discussed here.
Comment 27 Mathias Nyman 2020-04-09 12:39:05 UTC
Created attachment 288295 [details]
testpatch that doesn't clear TT buffer after protocol STALL

Adding same patch and comment here as in bug #207065, it might
help in this case as well.


"Traces show its related to Clearing TT buffer after a STALL on 
endpoint 0.

The first stall looks like a protocol stall, not a function stall, meaning that
endpoint isn't really halted, just that the device does not support the
request in the control transfer. 

Anyway, xhci starts clearing what it assumes is a halted endpoint, 
including clearing the hub TT buffer.

Specs are a bit unclear if TT should be cleared in this case, 
or at least I couldn't find it."

Attached is a tespatch that doesn't clear TT buffer on protocol stalls,
withexcessive tracing and debugging.
Comment 28 Vincenzo Di Massa 2020-04-10 18:04:26 UTC
Applying the patches in bug 207065, comment 7 the problem reported in bug 206897 for HUION tablet is fixed. Looks promising :-)
Comment 29 Marco S. 2020-07-02 10:05:10 UTC
Hi, any news about it? when it's going to be implemented in stable kernel? Thanks
Comment 30 Mathias Nyman 2020-07-02 14:13:41 UTC
(In reply to Marco S. from comment #29)
> Hi, any news about it? when it's going to be implemented in stable kernel?
> Thanks

it's in 5.4.36 stable kernel:
fceab238c534 xhci: Don't clear hub TT buffer on ep0 protocol stall
Comment 31 Marco S. 2020-07-02 14:15:11 UTC
(In reply to Mathias Nyman from comment #30)
> (In reply to Marco S. from comment #29)
> > Hi, any news about it? when it's going to be implemented in stable kernel?
> > Thanks
> 
> it's in 5.4.36 stable kernel:
> fceab238c534 xhci: Don't clear hub TT buffer on ep0 protocol stall

I'm running 5.7.6 and still have the issue with Logic Group USB
Comment 32 Dominique Archambault 2020-07-02 19:10:26 UTC
Created attachment 290071 [details]
attachment-21054-0.html

same here
$ uname -a
Linux astrolabe11 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64
GNU/Linux

connecting the ConfCam connect ruins all audio (even other cards become
unavailable)



On Thu, 2 Jul 2020 at 16:15, <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=203419
>
> --- Comment #31 from Marco S. (sofro1988@gmail.com) ---
> (In reply to Mathias Nyman from comment #30)
> > (In reply to Marco S. from comment #29)
> > > Hi, any news about it? when it's going to be implemented in stable
> kernel?
> > > Thanks
> >
> > it's in 5.4.36 stable kernel:
> > fceab238c534 xhci: Don't clear hub TT buffer on ep0 protocol stall
>
> I'm running 5.7.6 and still have the issue with Logic Group USB
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
Comment 33 Mathias Nyman 2020-07-03 11:23:36 UTC
So looks like patch:
  8f97250c21f0 xhci: Don't clear hub TT buffer on ep0 protocol stall

Works for:
  HUION tablet - Vincenzo Di Massa
  C-Media Electronics, Inc. Audio Adapter - Florian Meyer

Doesn't work for:
  Logitech ConfCam Connect - Dominique Archambault
  Logic Group USB - Marco S 

For those that the patch doesn't work, could you take new
traces and logs. See comment #21 for details
Comment 34 Marco S. 2020-07-03 14:33:36 UTC
Created attachment 290085 [details]
dmesg fedora32 kernel 5.7.6 logic group usb
Comment 35 Marco S. 2020-07-03 14:34:03 UTC
Created attachment 290087 [details]
trace fedora32 kernel 5.7.6 logic group usb
Comment 36 Marco S. 2020-07-08 11:58:19 UTC
Hi there, any news?
Comment 37 Ikjoon Jang 2020-07-09 09:22:11 UTC
like mentioned in #33, "8f97250c21f0 xhci: Don't clear hub TT buffer..." should be applied first. Moreover, it seems this device needs extra workaround in HID (This device is HUB + UVC + UAC + HID).

Adding "usbhid.quirks=0x046d:0x0882:0x4" to command line will block HID device initialized, and audio will be okay. but after this, pressing any key on a keypad will trigger disconnect.

FYI, the same bug is tracked on here: http://crbug.com/983482
Comment 38 Olivier R-D 2020-08-31 07:55:35 UTC
Created attachment 292255 [details]
trace ubuntu 20.04 5.8.4-050804-generic
Comment 39 Olivier R-D 2020-08-31 07:56:34 UTC
Created attachment 292257 [details]
dmesg ubuntu 20.04 5.8.4-050804-generic
Comment 40 Olivier R-D 2020-08-31 07:57:58 UTC
logitech group microphone and sounds does not work on ubuntu 20.04 with generic kernel 5.8.4. traces as in comment #21 attached.

I am available to test any build kernel. I have the device here
Comment 41 Ikjoon Jang 2020-09-01 06:55:34 UTC
(In reply to Olivier R-D from comment #40)
> logitech group microphone and sounds does not work on ubuntu 20.04 with
> generic kernel 5.8.4. traces as in comment #21 attached.
> 
> I am available to test any build kernel. I have the device here

comment #33:
Can you try this patch?
https://lkml.org/lkml/2020/7/21/89

note that "8f97250c21f0 xhci: Don't clear hub TT buffer..." should be included in your kernel before.
Comment 42 Stefan 2020-09-02 06:05:32 UTC
(In reply to Ikjoon Jang from comment #41)
> (In reply to Olivier R-D from comment #40)
> > logitech group microphone and sounds does not work on ubuntu 20.04 with
> > generic kernel 5.8.4. traces as in comment #21 attached.
> > 
> > I am available to test any build kernel. I have the device here
> 
> comment #33:
> Can you try this patch?
> https://lkml.org/lkml/2020/7/21/89
> 
> note that "8f97250c21f0 xhci: Don't clear hub TT buffer..." should be
> included in your kernel before.

                                                                                                                           
Hi Ikjoon Jang, the patch is working on our side butt there is a litte problem
the device id is 0x0857 from our Logitech Group
Comment 43 Ikjoon Jang 2020-09-02 11:34:58 UTC
(In reply to Stefan from comment #42)
> (In reply to Ikjoon Jang from comment #41)
> > (In reply to Olivier R-D from comment #40)
> > > logitech group microphone and sounds does not work on ubuntu 20.04 with
> > > generic kernel 5.8.4. traces as in comment #21 attached.
> > > 
> > > I am available to test any build kernel. I have the device here
> > 
> > comment #33:
> > Can you try this patch?
> > https://lkml.org/lkml/2020/7/21/89
> > 
> > note that "8f97250c21f0 xhci: Don't clear hub TT buffer..." should be
> > included in your kernel before.
> 
>                                                                             
> 
> Hi Ikjoon Jang, the patch is working on our side butt there is a litte
> problem
> the device id is 0x0857 from our Logitech Group

I don't have a device right now, from searching from saved logs, my device seems to be this (mine was 0x882) :
0x046d:0x085a - HS Hub
|- 0x046d:0x086e - Camera/HID
|- 0x046d:0x0882 - Audio/HID

We might need to add one more quirk like this?

USB_DEVICE_ID_LOGITECH_GROUP_AUDIOX 0x857
USB_DEVICE_ID_LOGITECH_GROUP_AUDIOY 0x882
...

anyway let's go registering these ids: http://www.linux-usb.org/usb-ids.html
Comment 44 Ulf 2020-09-03 09:52:44 UTC
(In reply to Ikjoon Jang from comment #41)
> (In reply to Olivier R-D from comment #40)
> > logitech group microphone and sounds does not work on ubuntu 20.04 with
> > generic kernel 5.8.4. traces as in comment #21 attached.
> > 
> > I am available to test any build kernel. I have the device here
> 
> comment #33:
> Can you try this patch?
> https://lkml.org/lkml/2020/7/21/89
> 
> note that "8f97250c21f0 xhci: Don't clear hub TT buffer..." should be
> included in your kernel before.

Works for me on Logi Group 046d:0882 and kernel 5.8.5.
Comment 45 Olivier R-D 2020-09-04 12:29:47 UTC
 I confirm the issues seems to be solved at kernel 5.8.6. Microphone and speaker work for Logitech group
New USB device found, idVendor=046d, idProduct=0882, bcdDevice= 4.71
[   32.853570] usb 2-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   32.853573] usb 2-4.2: Product: Logi Group Speakerphone
[   32.853576] usb 2-4.2: Manufacturer: Logitech
Comment 46 Oliver Freyermuth 2020-09-04 13:32:38 UTC
For me, the device shows up as:

        ID 046d:084e Logitech, Inc. 
        |__ Port 1: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 12M
            ID 046d:084c Logitech, Inc. 
        |__ Port 1: Dev 3, If 1, Class=Audio, Driver=snd-usb-audio, 12M
            ID 046d:084c Logitech, Inc. 
        |__ Port 1: Dev 3, If 2, Class=Audio, Driver=snd-usb-audio, 12M
            ID 046d:084c Logitech, Inc. 
        |__ Port 1: Dev 3, If 3, Class=Human Interface Device, Driver=usbhid, 12M
            ID 046d:084c Logitech, Inc. 
        |__ Port 2: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 480M
            ID 046d:084b Logitech, Inc. 
        |__ Port 2: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
            ID 046d:084b Logitech, Inc. 
        |__ Port 2: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
            ID 046d:084b Logitech, Inc. 

So we have another ID :-(. I'll go ahead and register these.
Comment 47 Oliver Freyermuth 2020-09-10 14:25:01 UTC
In my case, sadly, no matter wheter I add 084e or 084c to the list of quirked IDs, the issue seems to remain :-(.
Comment 48 Dirk Gajewski 2020-10-06 14:22:26 UTC
I can second the previous comment. Kernel 5.8.12: no success for Logitech conference cam. Camera is working but no audio (084b, 084c, 084e).
Comment 49 Dirk Gajewski 2020-10-12 12:37:08 UTC
Logitech conference cam (084b, 084c, 084e) is fully functional with kernel 5.9.0. 
cat /proc/asound/cards 
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xf7d10000 irq 33
 1 [Connect        ]: USB-Audio - ConferenceCam Connect
                      Logitech ConferenceCam Connect at usb-0000:00:1d.0-1.7.1, full speed

lsusb
Bus 002 Device 003: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser
Bus 002 Device 006: ID 046d:084b Logitech, Inc. 
Bus 002 Device 005: ID 046d:084c Logitech, Inc. 
Bus 002 Device 004: ID 046d:084e Logitech, Inc.
Comment 50 Peter Newcomb 2020-12-01 04:27:31 UTC
I ran into this issue and found that my Logitech Group audio device shows up with id 0x0857, not 0x0882.  I added the following patch and now it's working again:

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index fbc93d8dda5e..0f3d74ec3860 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -775,6 +775,7 @@
 #define USB_DEVICE_ID_LOGITECH_WII_WHEEL	0xc29c
 #define USB_DEVICE_ID_LOGITECH_ELITE_KBD	0xc30a
 #define USB_DEVICE_ID_LOGITECH_GROUP_AUDIO	0x0882
+#define USB_DEVICE_ID_LOGITECH_GROUP_AUDIO_2	0x0857
 #define USB_DEVICE_ID_S510_RECEIVER	0xc50c
 #define USB_DEVICE_ID_S510_RECEIVER_2	0xc517
 #define USB_DEVICE_ID_LOGITECH_CORDLESS_DESKTOP_LX500	0xc512
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 8a739ec50cc0..8a21a4e9db5a 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -183,6 +183,7 @@ static const struct hid_device_id hid_quirks[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_QUAD_USB_JOYPAD), HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE), HID_QUIRK_MULTI_INPUT },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_GROUP_AUDIO), HID_QUIRK_NOGET },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_GROUP_AUDIO_2), HID_QUIRK_NOGET },
 
 	{ 0 }
 };
Comment 51 jk 2022-10-31 14:29:50 UTC
Same issue here when I switched from 4.19 to 5.4. The original patch regarding 0x0882 did not resolve it for me. So I tried the extended patch by Peter, adding also 0x0857, and that made my setup work again. Any chance to get that patch accepted?
Comment 52 Takashi Iwai 2022-10-31 15:15:43 UTC
You'll need to show exactly what you've changed.  And, at best, submit the patch by yourself to the upstream.
Comment 53 Peter Newcomb 2022-10-31 17:09:13 UTC
FWIW, I eventually discovered that after I updated the firmware of the device I no longer needed the patch.
Comment 54 jk 2022-10-31 19:11:02 UTC
(In reply to Peter Newcomb from comment #53)
> FWIW, I eventually discovered that after I updated the firmware of the
> device I no longer needed the patch.
Thanks for the hint about the firmware update, I did not expect one considering the advanced age of this model, for today's product lifecycle. Using another machine to run the latest updater (FWUpdateGroup_9.4.52.exe), it shows there is in fact an update available for my Logitech Group, 9.1 to 9.4. The info screen reports it would update "audio" and "codec" from 8.6.102 to 8.6.111, leaving both "video" and "eeprom" untouched at 1.4. Maybe someone who already has one with USB device id 0x0882 can verify it has 9.4/8.6.111?

As the updater does not hint any roll-back function, I guess there is no easy way to check things once I updated mine, so I did not do the update yet.

Considering that this updater is only available as exe, it would make sense from my perspective to submit the patch from comment 50 any way. So people who can not run the updater or when the updater is no longer available, could still use their Logitech Group.