Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: Kevin Hilman
Date: Mon Oct 03 2011 - 19:03:15 EST
Grant Likely <grant.likely@xxxxxxxxxxxx> writes:
> Allow drivers to report at probe time that they cannot get all the resources
> required by the device, and should be retried at a later time.
> This should completely solve the problem of getting devices
> initialized in the right order. Right now this is mostly handled by
> mucking about with initcall ordering which is a complete hack, and
> doesn't even remotely handle the case where device drivers are in
> modules. This approach completely sidesteps the issues by allowing
> driver registration to occur in any order, and any driver can request
> to be retried after a few more other drivers get probed.
This is great work, thanks!
For the TODO list:
While the proposed patch should solve probe order dependencies, I don't
think it will solve the suspend/resume ordering dependencies, which are
typically the same.
Currenly suspend/resume order is based on the order devices are *added*
(device_add() -> device_pm_add() -> device added to dpm_list), so
unfortunately, deferring probe isn't going to affect suspend/resume
Extending this to also address suspend/resume ordering by also changing
when the device is added to the dpm_list (or possibly creating another
list) should probably be explored as well.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/