linux-kernel - Re: [git pull] drm amd acp audio support

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: <CA+55aFx2W0YRaDfbQfHjC-sqbeYA2fOwSw_MXTUksK8fUSsCGg@mail.gmail.com>
Date:	Thu, 4 Feb 2016 11:54:39 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm amd acp audio support - optional

On Wed, Feb 3, 2016 at 4:04 PM, Dave Airlie <airlied@...ux.ie> wrote:
>
> I'm happy enough it shouldn't cause any problems, just wanted to
> check if you'd take it now or not.

Honestly, this feels like "might as well wait for 4.6" to me.

I'm generally ok with taking completely new drivers later in the rc if
there's a good reason for it, but then I want to feel like there's no
way that can regress (because it doesn't impact an existing driver),
and I also tend to only do that if the driver is something critical
for new machines (ie a new network or video driver can be the
difference between "that machine is usable" and "that machine is a
doorstop").

This fails both those guidelines - it *might* screw up machines that
work now, and while audio certainly isn't unimportant, it generally
isn't a "you can't use the machine for anything" kind of issue.

Thus the "I'd rather get this in a few weeks during the next merge
window" reaction.

                 Linus