On 01/12/2017 07:26 PM, Ben Hutchings wrote: > On Thu, 2017-01-12 at 18:41 +0100, Greg Kroah-Hartman wrote: >> On Thu, Jan 12, 2017 at 11:27:01AM -0600, Rob Herring wrote: >>> I just noticed that we have a new device attribute 'deferred_probe' >>> added in 4.10 with this commit: >>> >>> commit 6751667a29d6fd64afb9ce30567ad616b68ed789 >>> Author: Ben Hutchings <ben.hutchi...@codethink.co.uk> >>> Date: Tue Aug 16 14:34:18 2016 +0100 >>> >>> driver core: Add deferred_probe attribute to devices in sysfs >>> >>> It is sometimes useful to know that a device is on the deferred probe >>> list rather than, say, not having a driver available. Expose this >>> information to user-space. >>> >>> Signed-off-by: Ben Hutchings <ben.hutchi...@codethink.co.uk> >>> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> >>> >>> >>> It seems like a bad idea to add an ABI for an internal kernel feature. >>> When/if we replace deferred probe with something better based on >>> functional dependencies are we going to keep this attr around? Or >>> remove it and assume no userspace uses it? > > It should be removed then (and replaced with some kind of representation > of dependencies). > >>> Perhaps it should be hidden >>> behind CONFIG_DEBUG or just make a debugfs file that lists the >>> deferred list. Then you wouldn't have to hunt for what got deferred. >> >> Ah, debugfs would be nice, I'd much prefer that. I don't know how Ben >> is using this, but I think that would make more sense to me. > > I'm not using it any programmatic way, and don't intend to. debugfs > would be OK, but attaching it to devices was easy to do and seemed to > make sense.
Russell King started work on printing those devices in the deferred queue at late_initcall, not sure why it didn't land. But note that without proper dependency information, you cannot know for sure if a device deferred its probe just because a dependency doesn't have a matching driver. Regards, Tomeu
