Hi Svyatoslav,

> Herve and Luca did not come up with anything meaningful, they provided
> just a few rough ideas. It will take an inconsiderate amount of time

Well, IIRC they said that your use case can be mapped onto their
approach. Which is meaningful in my book.

> before there will be any consensus between them and schema
> maintainers, and even more time would be requited to settle this into
> schemas and implement into drivers. Why should I suffer from this? Why
> should changes I need be halted due to some incomplete 'ideas'? This
> driver uses existing i2c mux framework and fits into it just fine.

I am sorry to bring you bad news, but you need to suffer because this is
how development goes. If I get presented a generic solution (see Herve's
mail) and a specific solution (your driver), for this case I as a
maintainer will prefer the generic solution. Generic solutions need more
time because there are more things to handle, of course. This is typical
for development, I would say, it is not Linux or Free Software specific.

I appreciate that you tackled your issue and were open to share it with
the community. I see the work being done there. However, there are so
many things going on independently that I can't really prevent double
development from happening despite it having a high priority for me. As
soon as I get aware of people working on similar issues, I connect them.
That's what I did here as well.

So, if you want upstream supported I2C hot-plugging, you need to wait
for Luca's and Herve's work being accepted. Or provide a superior
solution. Or, if you want, join the ride. You already have experience in
this field (and hardware plus use case), you would be a very welcome
contributor, I would say.

All the best,

   Wolfram