lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ