> 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.
Attachment:
signature.asc
Description: PGP signature
