All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: edes <edes@gmx.net>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Johan Hovold <johan@kernel.org>, Takashi Iwai <tiwai@suse.de>
Subject: Re: kernel 5.4.11: problems with usb sound cards
Date: Mon, 3 Feb 2020 09:42:36 +0100	[thread overview]
Message-ID: <20200203084236.GS10381@localhost> (raw)
In-Reply-To: <20200202202816.5a1d8af1@acme7.acmenet>

On Sun, Feb 02, 2020 at 08:28:16PM -0300, edes wrote:
> 
> el 2020-02-02 a las 14:41 Johan Hovold escribió:
> 
> > 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:
> 
> > 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:
> [...]
> > 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

      parent reply	other threads:[~2020-02-03  8:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-01 13:58 edes
2020-02-01 14:10 ` Johan Hovold
2020-02-01 16:26   ` edes
2020-02-02 10:19     ` Johan Hovold
2020-02-02 13:41       ` Johan Hovold
2020-02-02 23:28         ` edes
2020-02-03  7:57           ` Takashi Iwai
2020-02-03  8:29             ` Johan Hovold
2020-02-03  9:54               ` Takashi Iwai
2020-02-03  8:42           ` Johan Hovold [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200203084236.GS10381@localhost \
    --to=johan@kernel.org \
    --cc=edes@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=tiwai@suse.de \
    --subject='Re: kernel 5.4.11: problems with usb sound cards' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.