> 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. 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. > 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. > 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. > 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 :) Thanks, Wolfram
Attachment:
signature.asc
Description: PGP signature
