Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Andrzej Hajda <a.hajda@samsung.com>]

On 07/27/2016 06:50 PM, Luis R. Rodriguez wrote:
> (first e-mail bounced)
>
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on
> to help enable asynchronous probe, however for built-in devices this requires
> very specific platform knowledge otherwise using async probe will blow up
> your kernel -- if you get it right though, using async probe can help with
> boot. Even if you sort things out well -- there are current limitations with
> ordering semantics available, case in point the x86 IOMMUs already have a small
> sort run which expand beyond the core init entries allowed, and on top of this
> the you still have device driver dependencies which are implicitly setting
> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
> AMD KFD, and AMD radeon. This has made us realize that at the module front the
> current 2 levels of init calls limits our ordering semantics leaving only link
> order as a last measure when things are built-in. Likewise I've recently have
> had to look into dependency issues early in boot been due to differences
> between paravirtualization and non-PV kernels, this lead to some current work
> to help generalize custom section uses (linker tables) and then for us to
> consider expanding x86 semantics early in boot to address some of the
> shortcomings implicit by the some paravirtualized boot path.
>
> The goal behind Rafael's work's goal is essentially to avoid code duplication
> (as without doing that in the core many drivers potentially need to do the same
> thing in the same way) and help to address the asynchronous system
> suspend/resume case that cannot be addressed by any driver by itself anyway.
> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
> however the patterns are very similar: addressing complex dependencies and
> relationships at run time and available semantics for these.

I am also interested in this  topic. I have sent some times ago few
early RFCs
proposing solution for 'resource' life-time tracking:
In short it allows to:
- eliminate deferred probe and resulting late_initcall - consumer just
registers
callback informing when given resource(s) (clock, regulator, ...) becomes
available/unavailable,
- properly handle resource disappearance (due to driver unbind, hw
removal,...),
- track resources which are not vital to the device, but their presence
can influence
device's behavior,
- as a bonus it offers simplified resource allocation,

More info can be found on LWN [1].

The framework can be easily expanded to help with power management, as I
proposed in
Rafael's thread[2].

[1]: https://lwn.net/Articles/625454/
[2]: http://permalink.gmane.org/gmane.linux.kernel/2087152

Regards
Andrzej