linux-kernel - Re: [PATCH 4.19 15/39] ALSA: hda/generic: Add option to enforce preferred

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <s5hwnxom0ek.wl-tiwai@suse.de>
Date:   Fri, 11 Dec 2020 23:40:51 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 4.19 15/39] ALSA: hda/generic: Add option to enforce preferred_dacs pairs

On Fri, 11 Dec 2020 23:38:22 +0100,
Pavel Machek wrote:
> 
> Hi!
> 
> > > > From: Takashi Iwai <tiwai@...e.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