Mailing List Archive

1 2  View All
Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1 [ In reply to ]
+new email ids for myself & Vaibhav H

--
thanks,
./va

On 20 September 2016 at 12:11, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Sep 16, 2016 at 04:24:59PM +0200, Greg KH wrote:
>> On Fri, Sep 16, 2016 at 03:22:08PM +0200, Greg KH wrote:
>> > On Fri, Sep 16, 2016 at 11:18:07AM +0100, Mark Brown wrote:
>> > > 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:
>> > >
>> > > > > Sending a pull request for code that's never been seen upstream seems
>> > > > > completely premature.
>> > >
>> > > > Hey, how does code get upstream then? :)
>> > >
>> > > By having the actual code to the mailing list.
>> >
>> > Ugh, vger keeps blocking the patches, I'm going to try for a third time
>> > now...
>>
>> third time seems to have worked, except for patch 01/32, which was only
>> a single .h file. That file can be seen here if people are curious:
>> https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/tree/drivers/greybus/greybus_protocols.h?h=greybus
>>
>> I'll now respin the series, moving everything into
>> drivers/staging/greybus/ and leave it there for 4.9. Then we can work
>> on moving the core out, and then the drivers to the needed locations.
>
> This is now all in drivers/staging/greybus/ and will show up in the next
> linux-next.
>
> And because of this, we already have a checkpatch.pl cleanup patch sent
> to us for the code for things we missed :)
>
> thanks,
>
> greg k-h
Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1 [ In reply to ]
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.
Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1 [ In reply to ]
On Wed, Sep 21, 2016 at 02:02:10PM +0100, Mark Rutland wrote:
> > 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.

There are no ABI implications just yet, we are free to change anything
we want. It's all in drivers/staging/ now, where we will clean it up
some more over the next few weeks and then post reviewable sets of
patches to move portions out of staging (greybus core first, then some
class drivers, then the subsystem-specific things). That will give you
your set of clean patches to review, and with the first rounds, no
device tree bindings at all :)

thanks,

greg k-h

1 2  View All