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

[Peter Rosin]

On 2017-03-03 17:52, Wolfram Sang 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?

You got the gist of it. The piece I was missing was the conditional
pull into iio/i2c. If you only pull in order to resolve conflicts
it of course makes total sense, thanks.

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

Cheers,
peda

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Wolfram Sang]

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

Heh. I agree, though :)



signature.asc
Description: PGP signature

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

[Jonathan Cameron]

On 3 March 2017 16:52:47 GMT+00:00, Wolfram Sang  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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Wolfram Sang]

> 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?



signature.asc
Description: PGP signature

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

[Peter Rosin]

On 2017-02-28 18:18, Greg Kroah-Hartman wrote:
> 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.

Ok, works for me. I'll send you the pull request when the time comes.

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

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

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...

Cheers,
peda

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Peter Rosin]

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...

Cheers,
peda

[1] https://lkml.org/lkml/2017/2/8/394
[2] https://gitlab.com/peda-linux/mux.git

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html