From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933459AbcIUNCe (ORCPT ); Wed, 21 Sep 2016 09:02:34 -0400 Received: from foss.arm.com ([217.140.101.70]:47462 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933010AbcIUNCc (ORCPT ); Wed, 21 Sep 2016 09:02:32 -0400 Date: Wed, 21 Sep 2016 14:02:10 +0100 From: Mark Rutland To: Greg KH Cc: Mark Brown , Arnd Bergmann , linux-kernel@vger.kernel.org, Johan Hovold , Rui Miguel Silva , Laurent Pinchart , Sandeep Patil , Matt Porter , John Stultz , Rob Herring , Viresh Kumar , Alex Elder , David Lin , "Bryan O'Donoghue" , Vaibhav Agarwal , Mark Greer Subject: Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1 Message-ID: <20160921130209.GF18176@leverpostej> References: <20160914100949.GA6179@kroah.com> <20160915144553.GA15697@sirena.org.uk> <20160916060519.GA17586@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160916060519.GA17586@kroah.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Apologies for the late reply to this; I don't subscribe to LKML with my work address and didn't spot this sub-thread until now. On Fri, Sep 16, 2016 at 08:05:19AM +0200, Greg KH wrote: > On Thu, Sep 15, 2016 at 03:45:53PM +0100, Mark Brown wrote: > > On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote: > > > > > I'll send out a follow-up set of "simple" patches that just add the > > > files to the kernel tree, to give people an idea of the code involved. > > > Overall, it's a tiny stand-alone driver subsystem, only 37k lines, that > > > implements a protocol which allows for "generic" cameras, audio devices, > > > and other class type devices, as well as a bridged "physical" layer > > > protocol to talk to serial, spi, uart, pwm, gpio, i2c, and even USB host > > > > Just emphasizing what Mark Rutland said complete NACK, in particular the > > drivers for functions have not been posted upstream at all (and it's > > concerning that they're all being added under drivers/greybus rather > > than within the relevant subsystem like we do normally). I've not > > looked at the code as it has not been submitted but given that and that > > the reason I found this pull request was an ASoC contributor who had > > seen it and looked at the code going "oh dear, greybus..." on IRC I'm > > very concerned. > > > > Sending a pull request for code that's never been seen upstream seems > > completely premature. > > Hey, how does code get upstream then? :) As Mark Brown said, after review. > Anyway, as vger seems to be marking all of the greybus patches I send > out as "spam" according to a filter, it's making it a bit hard to send > patches out, but I'll try it again "by hand" later today... > > As for the drivers all living under drivers/greybus/ I understand, but > we need the greybus core present first before we can get the drivers in. > How about we do what happened with IIO, we take the greybus core code in > drivers/greybus/ and put the drivers in staging, and then move them out > of staging into the "real" portion of the kernel as they get reviewed > and accepted? > > Any objections to that workflow? Personally, yes. I would rather see the few core patches go through some level of review first. It's vastly easier to handle that than to reverse-engineer an understanding of the code when "move XXX out of staging/" patches appear. I'm more than happy to review a reasonably-size, linearised series for that core code. My concerns previously mentioned still apply to the patches queued in linux-next, regardless of whether these patches are under staging. Especially given the ABI implications of the devicetree bindings. Thanks, Mark.