On Fri, 2016-03-11 at 23:41 +0000, Boie, Andrew P wrote:
On Fri, 2016-03-11 at 22:30 +0000, Thomas, Ramesh wrote:
I see. So at boot it could use device_get_binding() or DEVICE_GET() to
For example, the PMA may chooses to apply .resume on -> APICs, Timers,
ARC, UART in that order because of dependencies and policies. Assuming
it has a list of devices, it can identify these devices in that list by
The goal is to leave the ordering of operations on devices to the PMA as
kernel can only guarantee the initialization order.
populate some data structure with device pointers which is then used at
Another reason of giving the PMA direct access to the device is toYou're already calling .suspend the first time so presumably you already
handle the case of DEV_BUSY/DEV_FAIL. It can then choose to
retry .suspend only that device that returned DEV_BUSY.
have a device pointer, so I'm not sure how this imposes a requirement on
However the custom ordering for suspend/resume dependencies makes
perfect sense, thanks for the additional detail.
Looking at our headers I see some areas needing improvement. These
anonymous drivers use SYS_INIT(). This macro declares a device with ""
for its name, and the name you would use for DEVICE_GET() is very
counter-intuitive. Which means you can't really use either
device_get_binding() or DEVICE_GET() with them.
I think this API needs to be refactored for system devices like this.
Maybe have SYS_INIT() take a dev_name parameter. Here's a potential way
with a new macro SYS_INIT_NAMED(), the difference is in the first couple
args to DEVICE_INIT():
#define SYS_INIT(init_fn, level, prio) \
DEVICE_INIT(sys_init_##init_fn, "", init_fn, NULL, NULL, level, prio)
#define SYS_INIT_NAMED(name, init_fn, level, prio) \
DEVICE_INIT(name, STRINGIFY(name), init_fn, NULL, NULL, level, prio)
Sounds good. We can use the SYS_INIT_NAMED() macro for devices that
need a name for PM purpose.
Do you think we should replace SYS_INIT() with the new one? i.e. just
modify SYS_INIT(). I am ok either way.