Messages in this thread | | | Date | Mon, 19 Oct 2015 16:35:49 +0100 | From | Russell King - ARM Linux <> | Subject | Re: [GIT PULL] On-demand device probing |
| |
On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote: > On 19 October 2015 at 16:30, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > I typically see one or two, maybe five maximum on the platforms I have > > here, but normally zero. > > Hmm, I have given a look at our lava farm and have seen 2 dozens as > common (with multi_v7).
No, because the lava farms tend not to be public.
> > What you can do is print those devices which have failed to probe at > > late_initcall() time - possibly augmenting that with reports from > > subsystems showing what resources are not available, but that's only > > a guide, because of the "it might or might not be in a kernel module" > > problem. > > Well, adding those reports would give you a changelog similar to the > one in this series...
I'm not sure about that, because what I was thinking of is adding a flag which would be set at late_initcall() time prior to running a final round of deferred device probing.
This flag would then be used in a deferred_warn() printk function which would normally be silent, but when this flag is set, it would print the reason for the deferral - and this would replace (or be added) to the subsystems and drivers which return -EPROBE_DEFER.
That has the effect of hiding all the deferrals up until just before launching into userspace, which should then acomplish two things - firstly, getting rid of the rather useless deferred messages up to that point, and secondly printing the reason why the remaining deferrals are happening.
That should be a small number of new lines plus a one-line change in subsystems and drivers.
-- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
| |