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 5D696C433DF for ; Wed, 14 Oct 2020 14:32:21 +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 A184622201 for ; Wed, 14 Oct 2020 14:32:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="DQZvFt3y"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=superlative.org header.i=@superlative.org header.b="UJMFP9mX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A184622201 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=superlative.org 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 79F0C16EE; Wed, 14 Oct 2020 16:31:26 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 79F0C16EE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1602685936; bh=qywDCl4U2zuqaiLLIeraKxvQHiIRr02rRbNcM377dnE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=DQZvFt3ysGzGYRlxxWzYKyO60KyhT7S0EOL2jzMyoxn5MNBLU29xKhNUF8HvXlAq3 EqeiX4Sv7WWaNWou7EMenyh0ZY+s1+k7pR5qQ5W4sMmyS0LFr66al3oI2tnq97BDLr FLaRNa1WO3IIeYlK/1q46OTIESQd+Oy0oZSk0dEc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 0FBE6F8020D; Wed, 14 Oct 2020 16:31:26 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id AD64EF80217; Wed, 14 Oct 2020 16:31:23 +0200 (CEST) Received: from mail-oo1-xc43.google.com (mail-oo1-xc43.google.com [IPv6:2607:f8b0:4864:20::c43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 7B1E9F80118 for ; Wed, 14 Oct 2020 16:31:16 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 7B1E9F80118 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=superlative.org header.i=@superlative.org header.b="UJMFP9mX" Received: by mail-oo1-xc43.google.com with SMTP id l18so826315ooa.9 for ; Wed, 14 Oct 2020 07:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=superlative.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=48cTnSqKwDUcqWSFhuGP4vMjz3kUuH/B/u1xQ0vQHGc=; b=UJMFP9mXb7Y1pD9e1YWQsqfVdbnYnbJKe4UadVkbyCF6pYn5yCCVDS0CU6ahdl6tOW /vvgvr4z3eNcUR4g4/OVHKlmoYa+pw2x36zy2KqTZHYDQlEm2NsRg+cZZTdCAulq5yGC AkK6K7FziRQ+eBTMs9fBgDEgKTpLg/b9U6L48dBedgiKE1qQU9wP2En/PBMRUmxtzNQv Xh4a5TlZNqRiPi3jOPz8WnxTEVsHKE+/NYrXPjAgdv1CNZ0T06PRdWkvafHFdn1lEn2G UGIPFIS8maM4tKoY+5KeOpc33ZfZVT+yUCHaOzq8gWUW/IA0U0zdP7eZwiZ11axA6WS+ OH/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=48cTnSqKwDUcqWSFhuGP4vMjz3kUuH/B/u1xQ0vQHGc=; b=aa4chpGcMfBsARvij/zCheDKw7vKJvRnMNwyJfDAbuUwvyOBSyam3UEzvAZ8AJR4Ik /OfNQZ9L/wkus9mjWsAOpFbMHZx+Z6H8aYPMX8JFGujm02gX8BDgafNr9ZQEQnGTV+Jf ZXnL2IRULxPTbuUeHNklU16b7j9O8QiBT1SEU4TjxCmHG/2ZXYyFrOTu97fruPmY/3Cx 62UEsDcDLTNuIcegfEFIPY4JCRga0BOkjmB0/B7tpj0vZXld+5I45EYfESqnfygnf6UJ nJQjID4HVrZ8hljOZNyY4AIebQEVIW46nrixoqmKTmNP7pfk/WOvc/C0lTfHMSy1TFIR h+/Q== X-Gm-Message-State: AOAM533zivHYEOKXUVEl45W7l+4YJCB1Kzo7tum5U5WRCA1DfHXyqdYn bRm3nID8klkqKC2mcN9nlF26g1D7iYHl5Tr1lEuAVw== X-Google-Smtp-Source: ABdhPJzAODSyM6uPDdIVgiOR2SEk2TbW2eWS7vVHRKzxIoeAIgKda72Dk5A90Sxy++gAWkXFk+3h45+6/9qVRZq5rqg= X-Received: by 2002:a4a:9b01:: with SMTP id a1mr3755280ook.51.1602685873084; Wed, 14 Oct 2020 07:31:13 -0700 (PDT) MIME-Version: 1.0 References: <20191011171937.8013-1-szszoke.code@gmail.com> In-Reply-To: From: Mailing Lists Date: Wed, 14 Oct 2020 15:31:02 +0100 Message-ID: Subject: Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers To: Takashi Iwai Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" 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. 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