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 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 49138C433DF for ; Wed, 14 Oct 2020 13:10:34 +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 9513422201 for ; Wed, 14 Oct 2020 13:10:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="mqCws1O0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9513422201 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 C681E16E9; Wed, 14 Oct 2020 15:09:38 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C681E16E9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1602681028; bh=kvr/DirSaEcU1XiSAr5cntCauV7IMT8I7z44g9MK5oU=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mqCws1O09nTTgDCN5TJHCrU2RRtxItKeSIuIyZzBaoryxqzxJizYY2fpzcvFpGoIE 2pPv8DFa+bbH7Oh8zwTTmON3m6GC+5sieOeUiXBRM5HEDp4g2eYkF+heKLfXOHXmkT xlDB0HGpcZu2vMfMBIhgX5lThEIdYkdztSixKc0U= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 5FA1DF8020D; Wed, 14 Oct 2020 15:09:38 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id EA842F80217; Wed, 14 Oct 2020 15:09:36 +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 34F6AF800F6 for ; Wed, 14 Oct 2020 15:09:33 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 34F6AF800F6 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 D5736AC4D; Wed, 14 Oct 2020 13:09:32 +0000 (UTC) Date: Wed, 14 Oct 2020 15:09:31 +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 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