Re: [PATCH v7 00/24] i2c mux cleanup and locking update

From: Peter Rosin
Date: Fri Apr 22 2016 - 07:52:54 EST

Wolfram Sang wrote:
> > The problem with waiting until 4.8 with the rest of the series is that it
> > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate
> > to be mux-locked) touches a ton of register accesses in that driver since
> > it removes a regmap wrapper that is rendered obsolete. Expecting that
> > patch to work for 4.8 is overly optimistic, and while patching things up
>
> Okay, that can be argued, I understand that. So, what about this
> suggestion: I pull in patches 1-15 today, and we schedule the rest of
> the patches for like next week or so. That still gives the first set of
> patches some time in linux-next for further exposure and testing whilst
> the whole series should arrive in 4.7.

That sounds really good, thanks!

> However, I need help with that. There are serious locking changes
> involved and ideally these patches are reviewed by multiple people,
> especially patches 16-19. I first want to say that the collaboration
> experience with this series was great so far, lots of testing and
> reporting back. Thanks for that already. Yet, if we want to have this in
> 4.7, this needs to be a group effort. So, if people interested could
> review even a little and report back this would be extremly helpful.

Yes please!

> > Third, should we deprecate the old i2c_add_mux_adapter, so that new
> > users do not crop up behind our backs in the transition? Or not bother?
>
> Usually it is fine to change in-kernel-APIs when you take care that all
> current users are converted. But I am also fine with being nice and
> keeping the old call around for a few cycles. It is your call.

Ok, I'm a bit fed up with this series and will ignore it then.

> > Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to
> > use an explicit i2c mux core) to not change i2c_get_clientdata() ->
> > dev_get_drvdata() as requested by Jonathan Cameron. How should I handle
> > that?
>
> I'll pull in the first patches this eveneing. You can choose to send me
> an incremental patch or resend patch 8. I am fine with both, but it
> should appear on the mailing list somehow.

I just sent a v8 of 08/24 (not sending a whole v8 for that though)

> > There are also some new Tested-by tags that I have added to my
> > local branch but have not pushed anywhere. I'm ready to push all that
> > to a new branch once you are ready to take it.
>
> For the patches 1-15, I am ready when you are :)

Ok, I pushed out v8, see below. Pick what you want :-)

Cheers,
Peter

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

https://github.com/peda-r/i2c-mux.git mux-core-and-locking-8

for you to fetch changes up to b9a0ea3a309a3a4051c7c0cc54ade0eb5a877896:

[media] rtl2832: regmap is aware of lockdep, drop local locking hack (2016-04-22 12:18:45 +0200)

----------------------------------------------------------------
Antti Palosaari (1):
[media] si2168: change the i2c gate to be mux-locked

Peter Rosin (23):
i2c-mux: add common data for every i2c-mux instance
i2c: i2c-mux-gpio: convert to use an explicit i2c mux core
i2c: i2c-mux-pinctrl: convert to use an explicit i2c mux core
i2c: i2c-arb-gpio-challenge: convert to use an explicit i2c mux core
i2c: i2c-mux-pca9541: convert to use an explicit i2c mux core
i2c: i2c-mux-pca954x: convert to use an explicit i2c mux core
i2c: i2c-mux-reg: convert to use an explicit i2c mux core
iio: imu: inv_mpu6050: convert to use an explicit i2c mux core
[media] m88ds3103: convert to use an explicit i2c mux core
[media] rtl2830: convert to use an explicit i2c mux core
[media] rtl2832: convert to use an explicit i2c mux core
[media] si2168: convert to use an explicit i2c mux core
[media] cx231xx: convert to use an explicit i2c mux core
of/unittest: convert to use an explicit i2c mux core
i2c-mux: drop old unused i2c-mux api
i2c: allow adapter drivers to override the adapter locking
i2c: muxes always lock the parent adapter
i2c-mux: relax locking of the top i2c adapter during mux-locked muxing
i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes
iio: imu: inv_mpu6050: change the i2c gate to be mux-locked
[media] rtl2832: change the i2c gate to be mux-locked
[media] rtl2832_sdr: get rid of empty regmap wrappers
[media] rtl2832: regmap is aware of lockdep, drop local locking hack

Documentation/i2c/i2c-topology | 370 +++++++++++++++++++++++++++
MAINTAINERS | 1 +
drivers/i2c/i2c-core.c | 66 +++--
drivers/i2c/i2c-mux.c | 297 ++++++++++++++++-----
drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 47 ++--
drivers/i2c/muxes/i2c-mux-gpio.c | 73 +++---
drivers/i2c/muxes/i2c-mux-pca9541.c | 58 ++---
drivers/i2c/muxes/i2c-mux-pca954x.c | 61 +++--
drivers/i2c/muxes/i2c-mux-pinctrl.c | 121 +++++----
drivers/i2c/muxes/i2c-mux-reg.c | 69 ++---
drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 2 +-
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 1 -
drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 79 ++----
drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 3 +-
drivers/media/dvb-frontends/m88ds3103.c | 19 +-
drivers/media/dvb-frontends/m88ds3103_priv.h | 2 +-
drivers/media/dvb-frontends/rtl2830.c | 20 +-
drivers/media/dvb-frontends/rtl2830_priv.h | 2 +-
drivers/media/dvb-frontends/rtl2832.c | 243 +++---------------
drivers/media/dvb-frontends/rtl2832.h | 4 +-
drivers/media/dvb-frontends/rtl2832_priv.h | 3 +-
drivers/media/dvb-frontends/rtl2832_sdr.c | 303 ++++++++++------------
drivers/media/dvb-frontends/rtl2832_sdr.h | 5 +-
drivers/media/dvb-frontends/si2168.c | 106 +++-----
drivers/media/dvb-frontends/si2168_priv.h | 3 +-
drivers/media/usb/cx231xx/cx231xx-core.c | 6 +-
drivers/media/usb/cx231xx/cx231xx-i2c.c | 47 ++--
drivers/media/usb/cx231xx/cx231xx.h | 4 +-
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 5 +-
drivers/of/unittest.c | 37 +--
include/linux/i2c-mux.h | 53 +++-
include/linux/i2c.h | 29 ++-
32 files changed, 1224 insertions(+), 915 deletions(-)
create mode 100644 Documentation/i2c/i2c-topology