From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934755AbcIPMSl (ORCPT ); Fri, 16 Sep 2016 08:18:41 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:65530 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757471AbcIPMSd (ORCPT ); Fri, 16 Sep 2016 08:18:33 -0400 From: Arnd Bergmann To: Greg KH Cc: Mark Brown , 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 Date: Fri, 16 Sep 2016 14:18:12 +0200 Message-ID: <2171719.RDPoZEHAcD@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160916060519.GA17586@kroah.com> References: <20160914100949.GA6179@kroah.com> <20160915144553.GA15697@sirena.org.uk> <20160916060519.GA17586@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:L7y7cvdxVa+RFpUVZjHso6dhbV1g5lvJgmEyfwMQDe7vEbiSSA0 hSl0yVMqv3ZfUO55LRAh2P6Nwad5lUCj0wC90TwOhbr+z6HO+H54N07WVRj5GxqyvK48R0A b3EQSOnh6to7tp0kJ9Ub/caRrwacg+MGf3pF6UxYoWPezL1WFwYcWiQeSi2JcT5VE2fZcma gK2aGGCzwfGHvyS7Fax3w== X-UI-Out-Filterresults: notjunk:1;V01:K0:DqAkYfPIY04=:s2PlTWGWDc4lq6dEfLTGEj DobHvTZeWdqgADarp0XtderiyfQhyGgeulN9VjOOBqP7UTtvk7PuxxrEoc7+RrAu98sAHjmWw 6NRfOH2coWhoxyo4W1TggwABquaY15OKwfa4iaVgmlXlCxmhRhUnw5mOypMo9kefw/5IPsL/V osg4WmOvIm2e9wtthFxFug3pcq5asKIa6rWwsoxpLsznBqqCAQVdy0do/DO0/TrgCoKVW8tfg mBnWdOO8krAWC3t0BLe0qdPwfG1pkUeW19PgrxjH0RiIBfvHyQB/rou7o9Gb7QAIFHzoav3Wq 3OarS6Isn5TV3sSYj1nUS+0Djy1OUgFpSNbQP7GnMod6SaFF9szpegv1f0XLYFE7dkW+B0Ht/ d+lYvQXHLmguBxcz8zFl9IG1Gl0SxN96/4xHq0zmYEptfqJW3bKWEQKeTHepqc+Ti/iJ8uSCD HUmRP8yDLhkgMQbTcDxfQDgf21ObZYLh90NZTEckWgoNyffZKbBRAXPEf0BfRXxA9Lyb5HeLS 46pW1nWTXDXCMsL5hprzBheXIFKve52cvoORceW00RsFPme57fsO2UdYrQPReuUVRgAsCOlYY CTJSKahENLM72YfR5fD08Nwto+rjDNtGxuyPrTcnxKfH9J+RxyFf4TrX6ZF24rEZwrQ4IHrPx V2mZ4hDWh6ZWKGx4mEQLYHInNYIQaklj/HclsPjjw3OcMvhV4iJEnHrwd5plXsclQPIsRKRio eZjrSWoxVuhTTtE9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, September 16, 2016 8:05:19 AM CEST 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? :) > > 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? I think that will work fine. If we can review just the core code, the patch series probably gets small enough that more people are inclined to take a closer look. At least speaking for me personally, reviewing 32 nontrivial patches at once is unlikely to happen. >>From a brief look, I found that at least the smaller device drivers should be uncontroversial and won't have a problem getting merged into the subsystem directories once they have be reviewed by the respective maintainers. Some drivers are larger (audio sticks out by quite a bit) and are more likely to be controversial. Some other drivers (e.g. vibrator or bootrom) don't have an obvious subsystem they belong into, which can also cause problems, but having them in staging in the meantime seems fine. Arnd