From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753113AbdBCMZ3 (ORCPT ); Fri, 3 Feb 2017 07:25:29 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33985 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751878AbdBCMZ0 (ORCPT ); Fri, 3 Feb 2017 07:25:26 -0500 MIME-Version: 1.0 In-Reply-To: <20170203080040.qn53xnpojxzk4qoi@phenom.ffwll.local> References: <3e31-58931d80-1-221fa900@101383713> <20170203080040.qn53xnpojxzk4qoi@phenom.ffwll.local> From: Emil Velikov Date: Fri, 3 Feb 2017 12:25:24 +0000 Message-ID: Subject: Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge To: Emil Velikov , Peter Senna Tschudin , Mark Rutland , martyn.welch@collabora.co.uk, Peter Senna Tschudin , ML dri-devel , "Linux-Kernel@Vger. Kernel. Org" , Yakir Yang , Jiri Slaby , Mauro Carvalho Chehab , Russell King - ARM Linux , Peter Senna Tschudin , javier@dowhile0.org, Thierry Reding , Guenter Roeck , martin.donnelly@ge.com, devicetree , Pawel Moll , Ian Campbell , Fabio Estevam , Russell King , Rob Herring , LAKML , Greg Kroah-Hartman , tiwai@suse.com, Sascha Hauer , Kumar Gala , Enric Balletbo i Serra , Andrew Morton , Shawn Guo , "David S. Miller" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3 February 2017 at 08:00, Daniel Vetter wrote: > On Thu, Feb 02, 2017 at 12:37:21PM +0000, Emil Velikov wrote: >> - Daniel, gents - is drm-misc aimed at devs with limited (no?) >> review/commit history in the area and/or the kernel in general ? >> In this case, Peter have quite noticeable experience [in kernel >> development] with little-to no in DRM. >> Should one draw a line in the sand somewhere ? > > We're fairly lenient with accepting new drivers already, and for drivers > in drm-misc we require some checks and peer review to make sure new folks > learn faster. But it's an expirement, I fully expect some fallout and then > some learnign and fine tuning from that, and maybe we even need to crank > requirements back up to a much higher level of experience. > > But for drivers I'm honestly not too concerned: As long as there's some > process in place to foster learning&collaboration (which I think will be > better with this) I really don't see much harm in merging non-perfect > driver code. > Thank you Daniel, this is very well said. Being lenient to begin with and adjusting where/if needed is the more welcoming approach, indeed. Doubt there'll be (m)any cases of (ab|mis)use but even if so, nobody can see the future. >> - You patch has been on a long [bit rocky road] for a while, with >> devs giving you [what seems like] a partial reviews. >> Have you considered reviewing others' patches in exchange for a [more >> complete one] of this one ? According to git log people have poked you >> a handful of times, but seemingly you were busy. > > Just a clarification: When I review drivers I don't do a fairly cursor > look, hunting for areas where some refactoring and align with drm best > practices would be good. And I think that's perfectly fine and enough to > get a driver landed, but we're definitely not 100% consistent on this > within drm-misc. Probably will take some time to figure this out. Seems like I've missed "Peter, your patch..." above, silly me. Thanks for answering my [what may seem silly] questions ;-) Emil