On Sun, Feb 02, 2020 at 08:28:16PM -0300, edes wrote:

el 2020-02-02 a las 14:41 Johan Hovold escribió:

quoted

I realised I forgot the test to match on the device descriptor when
applying the blacklist. It doesn't matter currently since I only enable
the quirk for your device, but if you haven't tested the patch already,
would you mind testing the below patch instead?

Hi, Johan, thank you for looking into this. I tested your patch, and it
works! (5.4.11 and 5.5.0).

I haven't performed extensive tests, but the card is again recognized as
both playback and capture device. Thank you!

Perfect, thanks for testing.

Do you have a full name I can use to give you credit in the commit
message for reporting and testing?

Is this and acceptable solution and will this patch be integrated into the
kernel?

Yes, I think so. We've already had one related report so far, and the
blacklist mechanism should be generic enough to handle any further
devices like this.

Either way, we'll have this fixed in stable in one way or another in a
couple of weeks.

OTOH, you said:

quoted

Ok, so the device has a broken altsetting 3 for interface 1, where
endpoint 0x85 is declared as an isochronous endpoint, despite being used
by interface 2 as an audio endpoint:

[...]

quoted

Note that the broken altsetting probably should be using endpoint 0x81
just like the other altsettings for that interface, 

I can't say I understand exactly what you're saying, but do you think it
could be worth contacting the company and see if they are willing to fix
this with a new firmware?

Yes, I guess that wouldn't hurt.

The device used to work mostly by chance as two interfaces aren't
allowed to claim the same endpoint. Fortunately, this would only ever be
an issue in one particular configuration of the device (when altsetting
3 of interface 1 was selected) and that may be one that was never used
on Linux.

Takashi may know more about how/if that third altsetting could ever end
up being set.

Johan