Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1589635 > unrolled thread

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-28 18:20 +0100
    Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes Wolfram Sang <wsa@the-dreams.de> - 2017-03-03 18:10 +0100
      Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes Jonathan Cameron <jic23@jic23.retrosnub.co.uk> - 2017-03-03 18:50 +0100
      Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes Wolfram Sang <wsa@the-dreams.de> - 2017-03-03 20:40 +0100

#1589635 — Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

On Tue, Feb 28, 2017 at 04:17:52PM +0100, Peter Rosin wrote:
> Hi!
> 
> The status of this series [1] is that Rob Herring has acked/reviewed all
> devicetree changes, so I suppose that's ok. Jonathan Cameron has acked
> the additions to the iio subsystem and reviewed the new iio driver.
> Wolfram Sang has acked the i2c-mux driver. That's acks or reviews from
> the maintainers for all changes to the maintained areas.
> 
> What's not covered by the above is the mux subsystem itself. Jonathan
> has also acked or reviewed those changes, but I get the feeling that
> more tags are desired? So, please review the core of the mux subsystem
> and the two drivers! It's small. Really. And much of it is boilerplate
> devm functions. The relevant patches are:
> 
>  3/10 "mux: minimal mux subsystem and gpio-based mux controller"
> 10/10 "mux: adg792a: add mux controller driver for ADG792A/G"
> 
> I also wonder how I should proceed next. Jonathan kindly provided some
> hints. I have created a project on gitlab [2] to track future mux
> changes and where this series is also available (in the "mux" branch,
> of course subject to rebases, at least for now). I intend to create a
> for-next branch that I hope Stephen Rothwell will be happy to add to
> linux-next at some point after v4.11-rc1. Whomever I will feed future
> changes to will also pull from that tree. Etc. At least that's my
> picture of how this is going to work.
> 
> The question then becomes to whom I will send pull requests? My guess is
> that the plausible candidates are Greg K-H, Linus Torvalds and Andrew
> Morton. Any taker? Are there other candidates? I don't have any particular
> preference. If I don't hear anything I'll probably just send a pull
> request to Linus for the next merge window (i.e. targeting 4.12-rc1).
> 
> Or am I perhaps getting ahead of myself? Is a new tree overkill? I
> don't expect it to be exactly busy...

I pull in lots of semi-random driver subsystems into my char-misc driver
tree, and I can do that here for you as well if you want me to, to
forward things on to Linus at the proper times.

Just let me know.

thanks,

greg k-h

[toc] | [next] | [standalone]

#1592144

[Multipart message — attachments visible in raw view] — view raw

> Jonathan, Wolfram, do you have any preferences on how this should be
> coordinated regarding the new iio and i2c drivers (and iio changes)?

You got the acks, all is fine, I think.

> My plan is to at some point declare the branch immutable. Then both of
> you can pull it in. Or? 

Yup, sounds good.

> But now that I think about it I wonder what the point is of having
> Greg pull it in also? Sure, third time's a charm and all that, but...

AFAIU, Greg will be your "upstream", so he should definately pull the
branch. I will just pull it in to avoid merge conflicts in my tree.
Or did I misunderstand your question?

[toc] | [prev] | [next] | [standalone]

#1592169

On 3 March 2017 16:52:47 GMT+00:00, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> Jonathan, Wolfram, do you have any preferences on how this should be
>> coordinated regarding the new iio and i2c drivers (and iio changes)?
>
>You got the acks, all is fine, I think.
>
>> My plan is to at some point declare the branch immutable. Then both
>of
>> you can pull it in. Or? 
>
>Yup, sounds good.
>
>> But now that I think about it I wonder what the point is of having
>> Greg pull it in also? Sure, third time's a charm and all that, but...
>
>AFAIU, Greg will be your "upstream", so he should definately pull the
>branch. I will just pull it in to avoid merge conflicts in my tree.
>Or did I misunderstand your question?
Agreed, will do the same if needed. Btw Greg is a very nice upstream to have!

Jonathan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1592246

[Multipart message — attachments visible in raw view] — view raw

> And conflicts -- if they show up -- will probably be trivial given the
> nature of the series. Famous last words...

Heh. I agree, though :)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web