My offer is going to be this, I'll look after any unforeseen future problems
caused by this rework, and I can be the i2c-mux maintainer. But if being

Yay, thanks a lot!

the i2c-mux maintainer turns out to be a huge time-sink, there is no way I
can stay on in the long run. But I guess that is the same for any maintainer
(whose job description does not explicitly include being maintainer).

Well, since I became the I2C maintainer in late 2012, i2c-mux was always
low-bandwidth:

$ git log --pretty=oneline v3.2.. -- drivers/i2c/muxes/ drivers/i2c/i2c-mux.c | wc -l
72

And your patch series is already bigger than what was accepted in the
last year altogether :) I understand the uncertainty feeling about this
step; however, I truly think it is not much work. It is a niche -
though, one I'd like to have supported by your expertise.

the mux update. The main commonality of the demux and the preexisting muxes
seems to be that the name includes "mux" and that it is all about i2c. Agreed?

Yes, and because they are quite different, I wasn't sure if it a) is not
affected at all or b) totally breaks the design. Glad to hear it is a).

Thanks again, looks like we have a roadmap now for getting this series
in \o/

   Wolfram