> Thus putting an I2C master controller device driver to the same late
> init level means that due to the concurrency there will be lots of
> probe defers of endpoint device drivers, and making "heavy" device
> drivers like rcar-vin to be run in asyncronous probe increases boot
> time dispersion (rcar-vin is already probed, it's time to probe a
> sensor, but I2C controller is not yet ready to operate, defer).

I do understand the problem. Yet, the root casue is that deferred
probing is only an interim solution not well suited for such cases.

> I don't suppose that the proposed change has any single negative
> side effect, well, right, probe/remove code becomes more awkward,
> but in general the expected effect to boot time improvement should
> cover it, I hope.

We once had a discussion where one guy needed subsys_initcall and the
other one needed module_init because of different use cases. That was
not great.

I am fully aware some probe ordering solution in Linux is much desired.
But fine-tuning init levels is a workaround. Even worse, it will
reduce the pressure for a proper solution. And if we ever get that
solution, different init levels will likely make the conversion harder.

So, I do understand your customers want such a patch for their use case.
But I don't think it is a good idea for the upstream kernel.

I'd think this is an out-of-tree patch for now. I'll talk with some
other people about their view, but I remain very sceptic.

> >> Another effect seems to be improving the init time of rcar_i2c_driver
> >> itself from ~7ms to ~1ms (assuming CONFIG_I2C_RCAR=y).
> > 
> > That doesn't help the patch much ;), but still interesting because I didn't
> > expect that. Do you have an idea why?

Still interested.