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;
Date:   Fri, 11 Dec 2020 23:40:51 +0100
Message-ID: <s5hwnxom0ek.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Pavel Machek <pavel@denx.de>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 4.19 15/39] ALSA: hda/generic: Add option to enforce preferred_dacs pairs
In-Reply-To: <20201211223822.GB18452@amd>
References: <20201210142602.272595094@linuxfoundation.org>
        <20201210142603.037114540@linuxfoundation.org>
        <20201211083621.GA9395@duo.ucw.cz>
        <s5hy2i4pwdk.wl-tiwai@suse.de>
        <20201211223822.GB18452@amd>
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

On Fri, 11 Dec 2020 23:38:22 +0100,
Pavel Machek wrote:
> 
> Hi!
> 
> > > > From: Takashi Iwai <tiwai@suse.de>
> > > > 
> > > > 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.
> 
> I agree that this is safe to apply and makes sense if we get another
> quirk soon. OTOH it is trivial to backport if it is needed.

It's trivial to backport, but it's not trivial to let stable
maintainers to inform beforehand if the next patch has CC-to-stable
tag.  Keeping this makes the backport easier, that's the point.


thanks,

Takashi