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=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 802EBC433E7 for ; Wed, 14 Oct 2020 14:59:39 +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 B0B8122201 for ; Wed, 14 Oct 2020 14:59:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="ea6U+jaI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0B8122201 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 2B85F174B; Wed, 14 Oct 2020 16:58:47 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 2B85F174B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1602687577; bh=1n13rRT/AQf05U8CdT+vbpB3ncNiC7hKeIN6kGYsLUI=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ea6U+jaIOwfWSG2bAgPlvxCem+/dGnGaAXCEM8McBZ/QHNj6mKVxkPVVkk3nZnPNr 5+FZR3bDTehnFNVpineHFyMEfpxdxQ7Rilc2i0q/0TFe8JCm5y00C0xUvjCGYnwsrp w6UnO7WX2O3q1pDOUeVHWeW721/3wdtQoPBxcYGo= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id EFD07F802D7; Wed, 14 Oct 2020 16:55:10 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 5551FF802E1; Wed, 14 Oct 2020 16:55:09 +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 810AEF802D7 for ; Wed, 14 Oct 2020 16:55:03 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 810AEF802D7 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 D9737AC4C; Wed, 14 Oct 2020 14:55:02 +0000 (UTC) Date: Wed, 14 Oct 2020 16:55:02 +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 16:31:02 +0200, Mailing Lists wrote: > > OK, I will do that. > > Quick question: what is the best git I should clone to create patches against > these days? I've been out of the loop for a few years now. At best, for-linus branch of my sound.git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git There is a copy in github, too. Takashi > > Cheers, > > Keith > > On Wed, 14 Oct 2020 at 15:00, Takashi Iwai wrote: > > 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 > > > > > > -- > -- > Keith A Milner > >