[PATCH 1/2] drm/doc: Allow new UAPI to be used once it's in the driver's -next.

From: Eric Anholt <eric@anholt.net>
To: dri-devel@lists.freedesktop.org, Dave Airlie <airlied@gmail.com>
Cc: linux-kernel@vger.kernel.org, Eric Anholt <eric@anholt.net>
Subject: [PATCH 1/2] drm/doc: Allow new UAPI to be used once it's in the driver's -next.
Date: Wed, 24 Apr 2019 11:56:16 -0700	[thread overview]
Message-ID: <20190424185617.16865-1-eric@anholt.net> (raw)

I was trying to figure out if it was permissible to merge the Mesa
side of V3D's CSD support yet while it's in drm-misc-next but not
drm-next, and developers on #dri-devel IRC had differing opinions of
what the requirement was.  Propose a clarification here to see if Dave
Airlie agrees.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

Personally, I thought the rule was "has to be in drm-next", but
assuming our review processes aren't totally broken, this should be
enough.

 Documentation/gpu/drm-uapi.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index c9fd23efd957..8e5545dfbf82 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -92,8 +92,9 @@ leads to a few additional requirements:
   requirements by doing a quick fork.
 
 - The kernel patch can only be merged after all the above requirements are met,
-  but it **must** be merged **before** the userspace patches land. uAPI always flows
-  from the kernel, doing things the other way round risks divergence of the uAPI
+  but it **must** be merged to the driver's -next tree (as documented in
+  MAINTAINERS) **before** the userspace patches land. uAPI always flows from
+  the kernel, doing things the other way round risks divergence of the uAPI
   definitions and header files.
 
 These are fairly steep requirements, but have grown out from years of shared
-- 
2.20.1

