From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BCAEC433DF for ; Wed, 14 Oct 2020 14:01:10 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 073ED2222A for ; Wed, 14 Oct 2020 14:01:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="dUEw5HJh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 073ED2222A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 85CD616F2; Wed, 14 Oct 2020 16:00:15 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 85CD616F2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1602684065; bh=Nfn6Ue27BQruN7yvL3eyItXUn+Mq2Hj8/C7VXs9oAuE=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=dUEw5HJhOcDiAHt7J2JSxBqV/0eBY7mMNZW2x6gAMJeVBgT5SAxvodJPV0o6dxLzy OPuSJrhKEuxqVNNKrJaAemDs8njpReraDZ2htfjTJ/eQx0Ied01IoIKAcJ841VUb28 2X28/jOdhG0rr/LVoy8fB/iL79H2Mbjq8ez2i7FA= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 0EB3CF8020D; Wed, 14 Oct 2020 16:00:15 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 97943F80217; Wed, 14 Oct 2020 16:00:13 +0200 (CEST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id F2A7BF800F6 for ; Wed, 14 Oct 2020 16:00:10 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz F2A7BF800F6 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 285F6B120; Wed, 14 Oct 2020 14:00:10 +0000 (UTC) Date: Wed, 14 Oct 2020 16:00:10 +0200 Message-ID: From: Takashi Iwai To: Mailing Lists Subject: Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers In-Reply-To: References: <20191011171937.8013-1-szszoke.code@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: alsa-devel@alsa-project.org, Mike Oliphant X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, 14 Oct 2020 15:56:32 +0200, Mailing Lists wrote: > > Yes, and I don't think this is practical (at least, not obviously). > > The "Roland" vs "BOSS" thing is pure branding. I have BOSS branded devices, > like the JS-8, which work perfectly without the patch as an example. It > wouldn't surprise me if there are recent Roland branded devices which require > the patch. > > So I, personally, think it is beyond brand and is device range or generation > specific. I guess it is possible there may be some technical parameter within > the device descriptor which could indicate which variant the device is, but I > don't know what that might be (if at all). At this point I think we probably > have to apply a conditional setting based on the Product ID. > > Given that, is it best to continue hacking these into pcm.c, or should we be > looking at a quirks-table way to describe these? Currently it's better to grow the explicit allow-list, I suppose. Those are still handful, hence manageable enough. But, we should consider improving search_roland_implicit_fb(), too. Both actions don't conflict, and once after we establish the better implicit-fb check, the allow-list can be dropped. thanks, Takashi > > Cheers, > > Keith > > On Wed, 14 Oct 2020 at 14:47, Takashi Iwai wrote: > > On Wed, 14 Oct 2020 15:33:03 +0200, > Mailing Lists wrote: > > > > Thanks for the response Takashi, > > > > How should this be distinguishing between Roland and BOSS? They both > have the > > vendor ID 0x0582. > > Ah, right, I missed that point :-< > > So the question would be rather how to detect BOSS devices > effectively... > > thanks, > > Takashi > > > > > Cheers, > > > > Keith > > > > On Wed, 14 Oct 2020 at 14:09, Takashi Iwai wrote: > > > >     On Wed, 14 Oct 2020 14:17:35 +0200, > >     Mailing Lists wrote: > >     > > >     > Following up on this, it appears there are a bunch of the > >     newer-generation > >     > Roland/Boss devices which need similar treatment. > >     > > >     > So far I have tested the GT-1, the GT-001, and the BR-80, and > others > >     have > >     > reported the RC-300 as working with similar modifications. I have > been > >     using > >     > the following change to the code in pcm.c > set_sync_ep_implicit_fb_quirk: > >     > > >     >     case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > >     >     case USB_ID(0x0582, 0x0130): /* BOSS Micro BR-80 */ > >     >     case USB_ID(0x0582, 0x0138): /* BOSS RC-300 */ > >     >     case USB_ID(0x0582, 0x01d6): /* BOSS GT-1 */ > >     >     case USB_ID(0x0582, 0x01e5): /* BOSS GT-001 */ > >     > /* BOSS Katana amplifiers and many other newer BOSS devices do not > need > >     quirks > >     > */ > >     > > >     > There's probably others too, such as the GT-100 (I believe the > GT-001 > >     and > >     > GT-100 have similar hardware). > >     > > >     > My question is, should this just be submitted as a patch to pcm.c > or > >     would it > >     > be better handled in quirks and, if so, how? > >     > > >     > Or something else? > >    > >     Do we really need this change at all?  I looked at the code again, > and > >     I noticed that basically the function should return 0 without > setting > >     anything else even if you don't have the explicit ID checks there. > >    > >     The function looks like: > >    > >     static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream > *subs, > >                                              struct usb_device *dev, > >                                              struct > usb_interface_descriptor > >     *altsd, > >                                              unsigned int attr) > >     { > >             .... > >             switch (subs->stream->chip->usb_id) { > >             .... > >             case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > >                     /* BOSS Katana amplifiers do not need quirks */ > >                     return 0; > >             } > >    > >             if (attr == USB_ENDPOINT_SYNC_ASYNC && > >                 altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && > >                 altsd->bInterfaceProtocol == 2 && > >                 altsd->bNumEndpoints == 1 && > >                 USB_ID_VENDOR(subs->stream->chip->usb_id) == 0x0582 /* > Roland > >     */ && > >                 search_roland_implicit_fb(dev, altsd->bInterfaceNumber + > 1, > >                                           altsd->bAlternateSetting, > >                                           &alts, &ep) >= 0) { > >                     goto add_sync_ep; > >             } > >    > >             /* No quirk */ > >             return 0; > >    > >     ... and the lengthy if-conditions after the switch/case is applied > >     only for Roland devices, hence it shouldn't influence on BOSS > >     devices.  After that point, the immediate return with 0, which is > the > >     same as we do in switch/case.  So the explicit check of BOSS devices > >     there looks superfluous. > > > >     thanks, > >    > >     Takashi > > > > -- > > -- > > Keith A Milner > > > > > > -- > -- > Keith A Milner > >