Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp959031pxu; Fri, 11 Dec 2020 20:17:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJxiuy80Wu1JPNghWtpXWdHo1CsKRhpnth9cvPSAzh7rwGZujdbL3k7DhRaZ2uEvcBroBsJA X-Received: by 2002:a17:906:5847:: with SMTP id h7mr13397873ejs.124.1607746667471; Fri, 11 Dec 2020 20:17:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607746667; cv=none; d=google.com; s=arc-20160816; b=MI18qRsELOM5GiI6RPucmAOGlHvL6ra9JK/Jf7mBk5kkiePhTl/CTOoIVKCc8Qm+zD jBVfZ2tJoHmZrMvmQ3+p6CtNtn9c8hkWemWC26UVL/QWlLfkNU16KlmiIByFb2iVutJf jJRBboahUDrApLv6Ua5NLHfidjQ+ci88i+OijefC8jMO9Fx1Ky/acbw8ha4Sc3n6kr6L OqnWd1TruBQnWoKUp+qTpB5VPzcC0dV1i4kmBcj6Jqj/FyJhk2bF6KJmzRPof7DbcwwJ wKi4Rz7EQ5T/H9SepOCkXOs7oePPB/3jZy1pTbFgLBf+zXn1uI19EuJQ8E8RaevexG3h KhjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=vYPpSpEn2k13fcUpylwiQZCDxLcZuuV1eAimyO0POCU=; b=MZHSxU2mG9mlxanBbYVHAR8V5EsNlokw+4RyRtobqoHIGlwwGugQYFJYygAbyxCaPx ZXPVlA5uiIjpyKhuFCLtFqq7PBM0wvnEnLeo3ICv2btCBxYZXQ1qHUiuP0PStYrbEBFl kIiBoswkzq7tiktqcSUz8ZUGM+x/5FUL4qHu4jQl1YQ0RFetPvbkE36VQ47BGReyLqJj XkTbigjCdIXEhUKlCd1URD3W1UnO4Fn9qph2CzJCr8hFhTZPemYeXfUPuS6noZCUNZJR UIUf9JA1dSVUKUYaJdtrgnXsh5jcd3R2rImvPkQm+xTYenVu4r1kEacBg25hvpeNTwWB uNOw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g19si5802631edf.599.2020.12.11.20.17.25; Fri, 11 Dec 2020 20:17:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437022AbgLKIoW (ORCPT + 99 others); Fri, 11 Dec 2020 03:44:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:51682 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436969AbgLKImm (ORCPT ); Fri, 11 Dec 2020 03:42:42 -0500 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 0F115ACBD; Fri, 11 Dec 2020 08:42:00 +0000 (UTC) Date: Fri, 11 Dec 2020 09:41:59 +0100 Message-ID: From: Takashi Iwai To: Pavel Machek Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Takashi Iwai Subject: Re: [PATCH 4.19 15/39] ALSA: hda/generic: Add option to enforce preferred_dacs pairs In-Reply-To: <20201211083621.GA9395@duo.ucw.cz> References: <20201210142602.272595094@linuxfoundation.org> <20201210142603.037114540@linuxfoundation.org> <20201211083621.GA9395@duo.ucw.cz> 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=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 Dec 2020 09:36:21 +0100, Pavel Machek wrote: > > Hi! > > > From: Takashi Iwai > > > > commit 242d990c158d5b1dabd166516e21992baef5f26a upstream. > > > > The generic parser accepts the preferred_dacs[] pairs as a hint for > > assigning a DAC to each pin, but this hint doesn't work always > > effectively. Currently it's merely a secondary choice after the trial > > with the path index failed. This made sometimes it difficult to > > assign DACs without mimicking the connection list and/or the badness > > table. > > > > This patch adds a new flag, obey_preferred_dacs, that changes the > > behavior of the parser. As its name stands, the parser obeys the > > Option added is never used as variable is never set. We don't need > this in 4.19. Right, it seems that the succeeding fix is queued only for 5.4 and 5.9. OTOH, this change will help if another quirk is added in near future, and it's pretty safe to apply, so I think it's worth to keep it. thanks, Takashi