[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170206084545.ke7riv6nacypqw2f@phenom.ffwll.local>
Date: Mon, 6 Feb 2017 09:45:45 +0100
From: Daniel Vetter <daniel@...ll.ch>
To: Emil Velikov <emil.l.velikov@...il.com>
Cc: Peter Senna Tschudin <peter.senna@...labora.co.uk>,
Mark Rutland <mark.rutland@....com>,
martyn.welch@...labora.co.uk,
Peter Senna Tschudin <peter.senna@...il.com>,
ML dri-devel <dri-devel@...ts.freedesktop.org>,
"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
Yakir Yang <ykk@...k-chips.com>, Jiri Slaby <jslaby@...e.cz>,
Mauro Carvalho Chehab <mchehab@....samsung.com>,
Russell King - ARM Linux <linux@...linux.org.uk>,
Peter Senna Tschudin <peter.senna@...labora.com>,
javier@...hile0.org, Thierry Reding <treding@...dia.com>,
Guenter Roeck <linux@...ck-us.net>, martin.donnelly@...com,
devicetree <devicetree@...r.kernel.org>,
Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Fabio Estevam <fabio.estevam@....com>,
Russell King <rmk+kernel@...linux.org.uk>,
Rob Herring <robh+dt@...nel.org>,
LAKML <linux-arm-kernel@...ts.infradead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
tiwai@...e.com, Sascha Hauer <kernel@...gutronix.de>,
Kumar Gala <galak@...eaurora.org>,
Enric Balletbo i Serra <enric.balletbo@...labora.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Shawn Guo <shawnguo@...nel.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++
Bridge
On Fri, Feb 03, 2017 at 12:25:24PM +0000, Emil Velikov wrote:
> On 3 February 2017 at 08:00, Daniel Vetter <daniel@...ll.ch> 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.
Yeah, the big idea behind drm-misc is also to make drm more welcoming for
new folks, and I think starting with a small driver or a few driver
patches for hw you have lying around for hacking is a great way. And every
once in a while we can "trick" one of these newbies into doing some cool
core refactoring or cleanup, and maybe even to stick around for a while.
All for world domination and other evil purposes ofc :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists