linux-kernel - Re: [git pull] drm for v4.7

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwf-xUUGE0QzbyJ9+SyjnvvWEJ23w32GzHiOxSTNbY1zg@mail.gmail.com>
Date:	Mon, 23 May 2016 11:59:56 -0700
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 for v4.7

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie <airlied@...ux.ie> wrote:
>
> Here's the main drm pull request for 4.7, it's been
> a busy one, and I've been a bit more distracted in
> real life this merge window.

Hmm.

I pulled this, but I think I'll have to unpull again.

Neither the diffstat not the shortlog match what you sent me. There's
four extra commits at the top that aren't mentioned:

  Dave Airlie (3):
      drm/edid: move displayid tiled block parsing into separate function.
      drm/edid: move displayid validation to it's own function.
      drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)

  Tomas Bzatek (1):
      drm/displayid: Iterate over all DisplayID blocks

was that intentional? What happened? Are those commits meant to be
merged, or are they wrong? They _look_ ok, but dammit, according to
your message they shouldn't be there.

I'll test this out and look what happens, but I hate getting different
results than what I'm told to expect.

This is one reason I much prefer getting explicit tags rather than a
random branch. Did you update the branch on purpose and wanted me to
get the new state, or did you update the branch just because you
happened to do development on that branch and pushed it out? With an
explicit tag, there's a much more _intentional_ "push this to Linus"
thing going on, and it's less ambiguous in cases like this.

                 Linus