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

> 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

> 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

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.

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

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.

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

Hi! v8 -> v9 changes - dropped the suffix from the compatible string of the i2c-mux-simple binding (was ,mux-locked or ,parent-locked) and add an optional mux-locked property instead to change the desired locking behavior from the default parent-locked - add description of the difference

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

Hi! v8 -> v9 changes - dropped the suffix from the compatible string of the i2c-mux-simple binding (was ,mux-locked or ,parent-locked) and add an optional mux-locked property instead to change the desired locking behavior from the default parent-locked - add description of the difference