On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote: > I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator, > but as it's a mixture of internal and external dependencies (e.g. > <&pm8921_s4> vs <&pm8921_mpp 7>) this became quite messy. I started > looking at using the dt dependencies sort and iterate over the entries > in a way that adheres to their dependencies, but that's also a lot of > code. This is why I don't like trying to open code in subsystems, it's too much work. > So I think you're right, we should be able to alter the supply lookup > code to defer the EPROBE_DEFER until we actually need the supply to be > there; e.g. attempt to map supplies when an external consumer request > the regulator. > Some care needs to be taken with regards to e.g. always-on regulators. I'm not sure why always on regulators would need special casing here? Enabling is orthogonal to supply mapping. Like I said in reply to Stephen's mail I'm more worried about discoverability of problems with this approach and with interactions with dependencies on other subsystems (mainly GPIOs). Thinking about it some more the other subsystems will probably sort themselves out but the diagnosics are an issue. I do like the idea of a general mechanism for registering dependency resources and deferring completion until they're ready more - I'm not sure it's even that much more work, especially if the first cut only handles regulators as a dependency... that feels like attacking the right problem, there's other things people are raising with deferred probe like your complaint about logging.
Attachment:
signature.asc
Description: Digital signature
