Re: drm pull for v5.3-rc1

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dave Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jason Gunthorpe <jgg@mellanox.com>,
	Jerome Glisse <jglisse@redhat.com>,
	Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: drm pull for v5.3-rc1
Date: Mon, 15 Jul 2019 11:37:51 -0700	[thread overview]
Message-ID: <CAHk-=wg5CBo_1Q8MCF9iVVY1yqUS=sVCE8qA4wXw--QxzAqzNA@mail.gmail.com> (raw)
In-Reply-To: <CAPM=9tx9N=qDnt8sn6dMw4BmfPwh-qNPGXDg5FA5fh5hKmooEA@mail.gmail.com>

On Mon, Jul 15, 2019 at 11:29 AM Dave Airlie <airlied@gmail.com> wrote:
>
> Not that I want to defend that code, but the mm patch that conflicts
> already shows that removing the token is fine as nobody needs or
> requires it. So the fixup patch in my tree was just a bridge to that patch,
> which reduces conflicts. Rip the token out of the new API, pass it as NULL
> to the old API until the mm patch is merged against it which drops the
> token from the old API.

Well, to me the "old" API looks like a new one too, since it's that
"struct page_range_apply" thing.

But I can appreciate that it makes for minimal patch to avoid
conflicts with other patches. It just doesn't look very sensible
stand-alone afaik.

I might be missing something.

But that last patch is more of a detail - it wouldn't even exist if it
wasn't for the earlier mm patches, and those are the ones that make me
go more than "Whaa?" so it's not like this is really all that big of
an issue. More of just a note I made while looking through the mm
parts.

                 Linus