linux-next: manual merge of the mux tree with the i2c tree

linux-next: manual merge of the mux tree with the i2c tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the mux tree got conflicts in:

  drivers/i2c/muxes/Makefile
  drivers/i2c/muxes/Kconfig

between commit:

  dbed8a803bd3 ("i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch")

from the i2c tree and commit:

  69c689cbeefa ("i2c: i2c-mux-gpmux: new driver")

from the mux tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/i2c/muxes/Kconfig
index 1e160fc37ecc,11115fb34f24..000000000000
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@@ -30,17 -30,19 +30,30 @@@ config I2C_MUX_GPI
  	  This driver can also be built as a module.  If so, the module
  	  will be called i2c-mux-gpio.
  
+ config I2C_MUX_GPMUX
+ 	tristate "General Purpose I2C multiplexer"
+ 	select MULTIPLEXER
+ 	depends on OF
+ 	help
+ 	  If you say yes to this option, support will be included for a
+ 	  general purpose I2C multiplexer. This driver provides access to
+ 	  I2C busses connected through a MUX, which in turn is controlled
+ 	  by a MUX-controller from the MUX subsystem.
+ 
+ 	  This driver can also be built as a module.  If so, the module
+ 	  will be called i2c-mux-gpmux.
+ 
 +config I2C_MUX_LTC4306
 +	tristate "LTC LTC4306/5 I2C multiplexer"
 +	select GPIOLIB
 +	select REGMAP_I2C
 +	help
 +	  If you say yes here you get support for the Analog Devices
 +	  LTC4306 or LTC4305 I2C mux/switch devices.
 +
 +	  This driver can also be built as a module.  If so, the module
 +	  will be called i2c-mux-ltc4306.
 +
  config I2C_MUX_PCA9541
  	tristate "NXP PCA9541 I2C Master Selector"
  	help
diff --cc drivers/i2c/muxes/Makefile
index ff7618cd5312,af43c6c3e861..000000000000
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@@ -6,7 -6,7 +6,8 @@@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)	+
  obj-$(CONFIG_I2C_DEMUX_PINCTRL)		+= i2c-demux-pinctrl.o
  
  obj-$(CONFIG_I2C_MUX_GPIO)	+= i2c-mux-gpio.o
+ obj-$(CONFIG_I2C_MUX_GPMUX)	+= i2c-mux-gpmux.o
 +obj-$(CONFIG_I2C_MUX_LTC4306)	+= i2c-mux-ltc4306.o
  obj-$(CONFIG_I2C_MUX_MLXCPLD)	+= i2c-mux-mlxcpld.o
  obj-$(CONFIG_I2C_MUX_PCA9541)	+= i2c-mux-pca9541.o
  obj-$(CONFIG_I2C_MUX_PCA954x)	+= i2c-mux-pca954x.o

Re: linux-next: manual merge of the mux tree with the i2c tree

[Peter Rosin]

On 2017-04-18 07:59, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the mux tree got conflicts in:
> 
>   drivers/i2c/muxes/Makefile
>   drivers/i2c/muxes/Kconfig
> 
> between commit:
> 
>   dbed8a803bd3 ("i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch")
> 
> from the i2c tree and commit:
> 
>   69c689cbeefa ("i2c: i2c-mux-gpmux: new driver")
> 
> from the mux tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

This is trivial IMHO, and I see no need to juggle with immutable branches
etc. Or maybe the whole thing is moot since it is getting late for the mux
series anyway, but the only one who can answer that is Greg.

So Greg, any news on the timeline for the mux series? BTW, other people are
starting to take an interest, see

  http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1377069.html

They apparently need to mux video with either gpio pins or a syscon/mmio
register and the new mux subsystem abstracts this nicely for them.

Also Greg, if it indeed is too late for the mux series to hit 4.12, should
I then remove it from linux-next? And then simply wait for it to hit -next
when you take it? I only had it added to -next in the first place since I
was deluded and thought you would pull it from my mux repo, and wanted early
feedback from autobuilders etc before making the pull request. But as it
turned out, you wanted raw patches...

However, I'm reluctant to take it out of -next, since that may cause
trouble for the above new users?

Cheers,
peda

Re: linux-next: manual merge of the mux tree with the i2c tree

[Greg Kroah-Hartman]

On Tue, Apr 18, 2017 at 08:52:16AM +0200, Peter Rosin wrote:
> On 2017-04-18 07:59, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the mux tree got conflicts in:
> > 
> >   drivers/i2c/muxes/Makefile
> >   drivers/i2c/muxes/Kconfig
> > 
> > between commit:
> > 
> >   dbed8a803bd3 ("i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch")
> > 
> > from the i2c tree and commit:
> > 
> >   69c689cbeefa ("i2c: i2c-mux-gpmux: new driver")
> > 
> > from the mux tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> 
> This is trivial IMHO, and I see no need to juggle with immutable branches
> etc. Or maybe the whole thing is moot since it is getting late for the mux
> series anyway, but the only one who can answer that is Greg.
> 
> So Greg, any news on the timeline for the mux series? BTW, other people are
> starting to take an interest, see
> 
>   http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1377069.html
> 
> They apparently need to mux video with either gpio pins or a syscon/mmio
> register and the new mux subsystem abstracts this nicely for them.

I've now provided some review comments on what I had questions/comments
on.  So I can't take the current series.

> Also Greg, if it indeed is too late for the mux series to hit 4.12, should
> I then remove it from linux-next? And then simply wait for it to hit -next
> when you take it? I only had it added to -next in the first place since I
> was deluded and thought you would pull it from my mux repo, and wanted early
> feedback from autobuilders etc before making the pull request. But as it
> turned out, you wanted raw patches...

I want patches that are reviewed and correct, this isn't an issue of me
taking a pull request or not.  I wanted to review the code, so you need
patches for that.

> However, I'm reluctant to take it out of -next, since that may cause
> trouble for the above new users?

As I doubt this is going to make 4.12, I don't know how you are having
dependant users without them also being in your tree.  It's not wise of
those developers to put them in a different tree.

thanks,

greg k-h