Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

[Arnd Bergmann <arnd@arndb.de>]

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