[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160916060519.GA17586@kroah.com>
Date: Fri, 16 Sep 2016 08:05:19 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Mark Brown <broonie@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
Johan Hovold <johan@...oldconsulting.com>,
Rui Miguel Silva <rmfrfs@...il.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Sandeep Patil <sspatil@...gle.com>,
Matt Porter <mporter@...nel.crashing.org>,
John Stultz <john.stultz@...aro.org>,
Rob Herring <robh@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Alex Elder <elder@...aro.org>, David Lin <dtwlin@...gle.com>,
Bryan O'Donoghue <pure.logic@...us-software.ie>,
Vaibhav Agarwal <vaibhav.agarwal@...aro.org>,
Mark Greer <mgreer@...malcreek.com>
Subject: Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1
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?
thanks,
greg k-h
Powered by blists - more mailing lists