From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philipp Zabel Subject: Re: [PATCH v3 00/24] i.MX Media Driver Date: Tue, 24 Jan 2017 12:28:09 +0100 Message-ID: <1485257289.3600.97.camel@pengutronix.de> References: <1483755102-24785-1-git-send-email-steve_longerbeam@mentor.com> <1484929911.2897.70.camel@pengutronix.de> <3fb68686-9447-2d8a-e2d2-005e4138cd43@gmail.com> <5d23d244-aa0e-401c-24a9-07f28acf1563@xs4all.nl> <1485169204.2874.57.camel@pengutronix.de> <2b6ae556-df48-6b6b-87f1-d092eba586b9@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2b6ae556-df48-6b6b-87f1-d092eba586b9@xs4all.nl> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Hans Verkuil Cc: mark.rutland@arm.com, andrew-ct.chen@mediatek.com, minghsiu.tsai@mediatek.com, nick@shmanahar.org, songjun.wu@microchip.com, Steve Longerbeam , robert.jarzmik@free.fr, devel@driverdev.osuosl.org, markus.heiser@darmarIT.de, laurent.pinchart+renesas@ideasonboard.com, linux@armlinux.org.uk, geert@linux-m68k.org, Steve Longerbeam , linux-media@vger.kernel.org, devicetree@vger.kernel.org, arnd@arndb.de, mchehab@kernel.org, bparrot@ti.com, robh+dt@kernel.org, horms+renesas@verge.net.au, tiffany.lin@mediatek.com, linux-arm-kernel@lists.infradead.org, niklas.soderlund+renesas@ragnatech.se, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, jean-christophe.trotin@st.com, kernel@pengutronix.de, fabio.estevam@nxp.com, shawnguo@kernel.org, sudipm.mukherjee@gmail.com List-Id: devicetree@vger.kernel.org On Mon, 2017-01-23 at 12:08 +0100, Hans Verkuil wrote: > On 01/23/2017 12:00 PM, Philipp Zabel wrote: > > On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote: [...] > As long as it is mentioned in the TODO, and ideally in the Kconfig as well, > then I'm fine with it. > > The big advantage of being in the kernel is that it is much easier to start > providing fixes, improvements, etc. If you use a staging driver you know > that there is no guarantee whatsoever with respect to stable ABI/APIs. Of course, but there should be a clear way how to progress on those issues that are documented as blockers, otherwise the driver will linger in staging. Worse, currently we are not even in agreement what to put into the TODO. regards Philipp