On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: > I can't see adding calls like this all over the tree just to solve a > bus-specific problem, you are adding of_* calls where they aren't > needed, or wanted, at all.
This isn't bus specific, I'm not sure what makes you say that? > What is the root-problem of your delay in device probing? I read your > last patch series and I can't seem to figure out what the issue is that > this is solving in any "better" way from the existing deferred probing. So, I don't actually have any platforms that are especially bothered by this (at least not for my use cases) so there's a bit of educated guessing going on here but there's two broad things I'm aware of. One is that regardless of the actual performance of the system when deferred probe goes off it splats errors all over the console which makes it look like something is going wrong even if everything is fine in the end. If lots of deferred probing happens then the volume gets big too. People find this distracting, noisy and ugly - it obscures actual issues and trains people to ignore errors. I do think this is a reasonable concern and that it's worth trying to mitigate against deferral for this reason alone. We don't want to just ignore the errors and not print anything either since if the resource doesn't appear the user needs to know what is preventing the driver from instantiating so they can try to fix it. The other is that if you're printing to a serial console then that's not an especially fast operation so if you're getting lots of messages being printed simply physically outputting them takes measurable time. I'm not aware of any performance concerns outside of that, but like I say I'm not affected by this myself in any great way. Obviously this can be configured but not having actual errors on the console isn't super awesome either for systems that make use of the logging there and we don't have a good way of telling what's from deferral and what's not.
signature.asc
Description: PGP signature
